The conversation has gone more or less of topic but... I am not entirely convinced about the use of join node to replace context storage for all situations. As it stores the values sent from different sources, it is basically a context storage itself but without the ability to see what it holds at a given point without making it trigger the flow followed by it.
I for example have conditions depending on movement detection, amount of ambient light in the room and the current state of a smart light. I could add link in nodes before it to pass in the newest values for ambient light and the light state but it just feels much more convenient having the latest sensor/light values in the global state. I can the just check prefilled state.lifx['Livingroom ceiling'] or state.binary.allLightsOff where ever I might need them.
Edit: Sorry @knolleary, I was writing while you commented meanwhile. Agree completely.
Just finally to say that I suggested considering MQTT as often it is a good solution, rather than lots of link nodes or global context, and in fact I do virtually always use MQTT.
As for how to refer to current state, use a Join node.
If anyone wants to propose a particular problem where they think context is really better then I would love to have the possibility of being convinced, so please start a new thread with such a problem.
This actually brings us onto a wider issue that I'm hoping we can discuss when the next release is out of the way.
That is more extensive use of events in Node-RED. It should be really easy to extend the context handler to issue events when using the proper set function. Then it would be equally easy to have a listener node that fired a msg when a variable is updated.
That is only one area in which wider use of events might be very powerful in Node-RED.
It comes back to a question of priorities, time and resources. Quite possibly if you were to discuss adding the code to make that happen, Nick and Dave might be willing to accept a PR - or there might be other reasons for not doing it. They are the experts at the internals of Node-RED and so you need to start with them.
But at the moment, it is just them doing the majority of the development work (with help I know from others from time-to-time, including Hitachi) and there are only so many hours in the day.
