Yes, this is complicated!
And so I've put the nodes on their own separate flow to see all and nothing else.
Walk through:
there are 2 subflows in this scenario.
The small red one and the obvious one device status.
The idea is to indicate the status of a RasPi.
(And it isn't that simple - of course)
I used to use a ping to ping all my devices but for reasons of keeping it simple I went to using the nmap command.
Each have their pros and cons.
Thus the first small red subflow.
If a device is not detected this sends 3 x offline messages to..... clear down the device's status to OFF LINE.
Why? I'll get to that.
The next part is the bigger subflow.
That looks at what's going on and indicates to me what's going on.
IDEALLY, all is good and things are shown as OK/GOOD.
green (Well, ok: lime) is for good.
If a flow error happens, it turns to RED and the icon changes.
If it has just booted the colour changes as well and the icon.
(There are other things, but for the sake of simplicity, I'll leave the others out.)
If either of the above conditions happen the indicator has to LOCK itself showing that and I have to press a button to acknowledge it.
Then - all things being good - it returns to green.
So?
Well, SOMEHOW it is getting stuck/locked in an ERROR RECEIVED state.
Yet!
There are no messages received.
As you can see by the picture.
You can see the into node debug and it is set to display the entire message.
Nothing shown.
Yet, it goes from RESET to that and there is/was no message displayed.
Now, before you go off at me, here's the code from that node showing the mechanics of how it gets to this/that condition:
(rather simple)
And there are a lot of lines above it, but they are more setting things up.
No real .... code in them.
// ERROR message received.
if (msg.payload == "ERROR") {
//
// Need to set return message to indicate error
// 2025 02 05 mes2{} needs to be sent also?
//
context.set("LOCK", 1)
msg1 = { "topic": "alert", "payload": '<font color = "red" i class="fa fa-exclamation-circle fa-2x"></i></font>' }
node.status({ fill: "red", shape: "dot", text: "ERROR RECEIVED" })
return msg1
}
else
Oh, and that is the ONLY place in the code where this happens.
So it isn't being caused else where.
As you can see, it is a rather basic test.
IF the payload is ERROR then it sets things up and says ERROR RECEIVED.
LOCK is to indicate it has to specifically wait for a clear signal before echoing any newer messages/states.
To help with things, here are TWO screen shots showing the change.
This is where I RESET things.
That clears the LOCK (context) in the subflow and then waits for new status messages.
The complaint is from the small red subflow just above the inject node (which reset things)
You can clearly see the RESET message under the subflow.
This shows how the message/node changes from reset to error, but there is nothing shown in the INTO NODE debug node's output.
ITMT, the first one starts to time out and send THREE offline messages.
This is the guts of that subflow.
Basically just look at the 3 trigger nodes.
So it isn't doing anything special.
THE QUESTION:
So, HOW is that subflow changing from RESET to ERROR RECEIVED when there is no input message?
