I read a topic about detecting context changes and I understand this may be quite involved.
Perhaps a more "simple" thought;
Would it be possible for the inject node to detect flow/global changes and emit upon change (additional checkbox/option to emit on change if flow/global) ?
And/or: the capability for the RBE node to block/or not based on global/flow variables.
ie. msg.payload arrives at RBE, block unless flow/global x has changed. I think this would be a great addition in general.
Reasoning:
I use (battery powered) z-wave devices to control the heating (with ramping). If I bombard the z-wave devices with messages, the batteries die quickly.
I have to jump through hoops to capture values and pass/block messages.
No. As you say in your first sentence - detecting context changes is quite involved and would not scale.
That is something to consider. That said you can achieve it by putting a Change node in-front of the RBE node to attach the context property you want to test onto the message.
Everybody is probably fed up with me saying this, but I believe that if a flow requires to know when a context object is changed then context is not the best tool for the job. Instead MQTT can be used (with retained topics where necessary) and anything that needs to know will automatically get a message with the new value whenever it changes.
Although not everyone may be using MQTT. Though I agree of course in general. Other message queues could, in theory be used as well.
There is something to be said for having events firing on context variable changes though. The danger is in trying to reinvent MQTT. But in general, event driven interfaces are very powerful.
Of course, you can simulate the same effect by using link nodes. Whatever flow is updating a variable is extended to send a msg via a link to the flow that needs to know it has been updated. I'm using that extensively in my home automation flows to track when updates come in from the heating system.
but I believe that if a flow requires to know when a context object is changed then context is not the best tool for the job.
Perhaps not in Node-red, but event emitters/listeners are quite common in programming.
Instead MQTT can be used
Although I am aware, not everyone is using mqtt, nor can it be injected in the middle of a flow and more importantly: if you inject the same value into mqtt, mqtt still sees this as a change and emits the same value.
This topic was about detecting changes/passing/blocking messages and Nick's suggestion works just as well: implemented.
Why can it not be injected into the middle of a flow? An mqtt message coming in is no different to an inject node triggering when a context changes, is it?
Duplicate values can be handled by an RBE node for situations where it matters. In fact if the inject node idea were to be implemented I guess it would most likely trigger on write rather than trigger on change, just like mqtt.
