Monitoring state of a value in the Context

General
1

Is the following polling for value the correct way to get a message for each change in value of a key in the Context?

image
image1092Ă—408 27.4 KB 

[{"id":"f029180a.bf5918","type":"inject","z":"38af556d.c263fa","name":"","topic":"","payload":"true","payloadType":"bool","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":130,"y":100,"wires":[["18f9bc44.0dcef4"]]},{"id":"d724e195.5623e","type":"inject","z":"38af556d.c263fa","name":"","topic":"","payload":"false","payloadType":"bool","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":130,"y":140,"wires":[["18f9bc44.0dcef4"]]},{"id":"18f9bc44.0dcef4","type":"change","z":"38af556d.c263fa","name":"","rules":[{"t":"set","p":"flag1","pt":"global","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":320,"y":120,"wires":[[]]},{"id":"e1e43f40.63f9","type":"inject","z":"38af556d.c263fa","name":"","topic":"","payload":"flag1","payloadType":"global","repeat":"0.1","crontab":"","once":true,"onceDelay":0.1,"x":150,"y":220,"wires":[["9c2615d4.4a33a8"]]},{"id":"9c2615d4.4a33a8","type":"rbe","z":"38af556d.c263fa","name":"","func":"rbe","gap":"","start":"","inout":"out","property":"payload","x":310,"y":220,"wires":[["95bdf790.0c09c8"]]},{"id":"95bdf790.0c09c8","type":"debug","z":"38af556d.c263fa","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":470,"y":220,"wires":[]}]

How expensive is it in terms of load (with an interval of 0.1 sec and with a dozen of flows monitoring the same value)?

Or is there a better practice?

2

Correct? Well not really. But currently the only way without doing something a bit more radical.

Currently, the context handlers don't produce events when something changes so you can't easily watch for a change and so polling is the only other option.

However, probably what most people do is to write the value out to an MQTT topic at the same time. Then you can watch for changes since you can subscribe to the topic.

Of course, in the simple example you've used, the "Node-RED way" would be to pass the true/false straight to your rbe node. Using flags is only for more complex flows where you need to control an input msg via a separate variable that is set by a different part of your flow. Even then, the flag variable would normally be queried as part of your main flow. So a msg comes in, it is sent to a change node that adds the flag from the variable and then is sent on to a switch node.

1 Like
3

Or in fact dispense completely with global and flow context and use retained topics in MQTT instead, which some believe (well me anyway) is usually a better way.

1 Like
4

Or use link nodes to pass the messages directly between tabs.

3 Likes
5

link nodes were what I was using extensively, but there is no way to link to nodes inside subflows, so I went with the Context.

MQTT is a very intriguing idea and a likely solution. Somehow I missed the fact that I could use it as a data store.

However, in the meantime, I started to take advantage of the persistent context. Do MQTT retained topics survive broker's restart?

6

They do if you have configured the broker to do so.

1 Like
7

Mosquitto docs say:

autosave_interval seconds
The number of seconds that mosquitto will wait between each time it saves the in-memory database to disk. If set to 0, the in-memory database will only be saved when mosquitto exits or when receiving the SIGUSR1 signal. Note that this setting only has an effect if persistence is enabled. Defaults to 1800 seconds (30 minutes).

Why is the default so large? Compared to Node-RED's 30 seconds for persistent storage...

8

It only matters if the pi is powered down without warning or crashes as it will be saved on a normal power down when mosquitto is closed.

1 Like
9

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.