Either msg.downtime or msg.runtime is missing
we need to see better debugs and the section of flow this comes from.
Feed an inject into the functon set with msg downtime and msg,uptime.
Until @Colin can weigh in, are you sure the numbers or payload (msg.runtime) and (msg.downtime) are what you think they are? You can stick
node.status({fill:"blue",shape:"dot",text: msg.runtime});
in your node and see underneath the node what the value is
[EDIT]
I think @E1cid may have the right idea though, unless you are doing some tricks upstream of the node I'll bet you are missing one of the values, you realize that the values aren't persistent so unless the message has both values in it you will need to save them somewhere then read them back or ensure they are both present in the msg.
But to the previous point, are msg.runtime and msg.downtime in the same message? In other words does the value runtime come from one node and the value downtime come from another? It looks that way in your flow. If that is the case then you will be missing one of the numbers when you do your math.
try this status and see if both numbers appear at the same time
node.status({fill:"blue",shape:"dot",text: msg.runtime + " " + msg.downtime});
They are in seperate message streams . Set the debug msg.uptime to 'complete message object' and you will see they are not in same debug message. you will need to join the messages or store them.
Example of storing to context, first run will have default 0 values.
[{"id":"de919c9d.bae398","type":"function","z":"8d22ae29.7df6d","name":"","func":"var runtime = msg.runtime || (flow.get('runtime') || 0);\nvar downtime = msg.downtime || (flow.get('downtime') || 0);\nflow.set(['runtime','downtime'], [runtime, downtime]);\n\nmsg.uptime = runtime - downtime;\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":350,"y":820,"wires":[["ca18810d.3ed83"]]}]
You have now given us the vital information that they are not in the same message (I think you gave the impression earlier that they were in the same message).
Rather than using context I prefer to join them using the technique shown in this example from the cookbook. Move the values or structures into msg.payload in each path and make sure they have different topics. Import the example from the cookbook and play with it and make sure you understand how it works. Then you should be able to incorporate it in your flow.
I am interested in where the messages come from, are the values received from the device in separate messages or are you splitting them in node red? If you are splitting them then don't do that.
If they arrive in separate messages where are they coming from and how do you get them?
Hi Colin,
The messages msg.runtime and msg.downtime come from different timers via different messages.
Since i discovered i could give the 'seconds value' of the timer to a self chosen msg.x name I tried to solve it like this way.
Before I also tried to do it like the example described in the cookbook.
I have defined the timers by different topic names.
How can I define the different topics to variabeles in the function node?
Is it like?: var runtime = msg.topic.runtime
Did you import the Joining Streams example and play with it so that you understand what it does?
[Edit] If so then where in the message does the example need the values it is joining, and what message property does it use to know which message is which?
I imported the flow as shown in the cookbook. And played with it to onderstaand what is going on.
The disadvantage of a join node is that it only gives a msg.payload when all messages have arrived. I mean: first both msg.topic messages must have arrived. Only then does it issue a msg.payload
I also tried the flow from @E1cid
That works great!
The only one issue. And that is when the msg.runtime gives the second value. And the msg.downtime counter is still at zero (0). Then the calculation doesnt go well.
But when the msg.downtime counter counter once, everything works fine.
Thanks guys!
I am grateful to you for your help.
If you store runtime and downtime to context earlier in your flow , then they will see present later and the default 0 will not be called.
That is only true if 'After number of message parts' is set to 2. If you set that to 1 and select 'And every subsequent message', then you will get a message after the first message and every subsequent message. The topic of each message sent tells you which input message has triggered this output.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
