I have the following problem: a reed-sensor is connected to the oil valve of my central heating. So i can receive via MQTT a "1", for oil burner is on and a "0", for oil burner is off.
Now i would like to open with every MQTT message ("1" or "0") a json file to read the values recorded so far. after that i would increment the data and write it back to the same file.
i have added some pseudocode. I hope with this flow, you have a better understanding of my problem.
What works for me is: I can create an read a json file. It is also possible to work with the data fom the file. And i can save the file with the new data.
What does not work for me: In my "calc operating time" function i have no access to the MGTT message ( "1" or "0") from my oil burner.
You flow is not importable as you have not used the technique in [1] when pasting it here. However if you want data from multiple paths to be available a good way is to use a join node configured something like this, which will combine payloads from two inputs, identified by topic, into key/value pairs in the payload passed on.
I hope that using a different theme will not confuse people too much. It only affects the look not the substance. I am not going to go to the effort of editing settings.js, restarting node red then changing it back and restarting again just to get a screenshot of a dialog.
Put the Join node in front of your Calc Operating Time node and then you can access both the file contents and the burner state in the function. They will both be in the payload with their topics.
When a message arrives from your MQTT node, it is passed to your Function node. It also branches the flow to read the JSON file and then pass that to the Function node.
Your Function node is triggered twice - once from the MQTT node and once from the JSON read event. That makes life unnecessarily hard as you would have to either join those two events back into one, or use flow context within the Function node.
It would be far easier to avoid branching your flow.
The important part is moving msg.payload sideways before the File node so it doesn't overwrite the value coming from MQTT. Once the message reaches the Function node, you'll have msg.payload as the contents of the file and msg.oilState as the value from the MQTT node.
I agree that it is a nuisance, having done it a couple of times myself. Still, as custom themes proliferate, we may have to do some minor mental gymnastics to read images captured from the flow editor. I wonder whether it would be feasible (or worth the effort) to allow the user to switch themes from within the editor. Then it would be more reasonable to ask posters to use the default theme.