This flow hasn't changed in the last 18 months or so, and it was rock-solid until upgrading to Node-RED v5 (all of the dot revisions so far up to 5.0.6).
The Status node is just meant to monitor the TCP node named "EPSON_REMOTE_ETH", but it not always, but regularly fails to register when the TCP is connected.
I'm assuming it is a timing issue of some sort.
If the Status node offered a user defined way of forcing it to poll the status, this could be resolved easily on the user end, but since the Status node is a bit of a black-box, I need some help figuring out what is actually causing the issue.
Configure the debug node 'status remote ETH' to output to 'node status' and enable it. Then the status on the Debug node should follow the status on the TCP node. If you do not see them showing the same then export the TCP node, the Status node and the Debug node and paste here please. Also show us a screenshot with the status values different.
@Colin, I turned on the "node status" for the attached debug node so hopefully I'll be able to check it periodically and see if I can catch it when there is a status discrepancy.
It's going to be difficult to debug and catch this... I only have one machine that connects to the Epson robot and it is a production machine that runs all day, every day. I used to know when the issue would happen because the "connected status" flow variable enables/disables the Epson robot controls on the screen so I would get notified when the controls were disabled.
To keep the machine running, I hacked in a work around that sets the "connected status" flow variable to true every time a message comes out the TCP node... of course this means the "connected status" flow variable will never get set to false if/when the connection actually drops/fails... but I'll know because it won't respond and I'll get a work order to come look at it.
For now it's a workable solution since the connection never really drops once it is established anyhow.
