JTsao Posted December 7, 2022 Posted December 7, 2022 Does anyone have IoP programs that check the status of node servers (off-line / on-line) and generate a message if there is an issue? Is there a compelling reason to do this?
Goose66 Posted December 7, 2022 Posted December 7, 2022 (edited) The short answer is that you are likely to see different solutions here depending on the node server. There is no "built-in" node server running/operating state (status) in the Node Server API, and the requirement for a "Controller" node representing the node server that was present in PG2 node servers was removed in PG3 (which is a good thing for reasons I would be glad to discuss 😆). One consequence of this is there is no standard way for PG3 node servers to report their state. Node servers do various things here depending on the design philosophy of the developer: some choose a state (driver) value for one of their nodes to (attempt to) reflect the running state of the node server; some send heartbeats (e.g., AWAKE commands) periodically form a node that allow the ISY to monitor the running state; some use a driver to effect heartbeat (e.g., alternating 1 and -1 in the ST driver of a "controller-type" node). Personally, my hope is that state tracking for node server running state (heartbeat or otherwise) is built into the API at some point - potentially when the intervening REST layer is removed and node servers start communicating with the ISY directly through MQTT (let's call it the "Polyglot" API). Edited December 7, 2022 by Goose66
bpwwer Posted December 7, 2022 Posted December 7, 2022 The node server API in the ISY/IoP has never had the ability to track node server state. Everything that has been done in both PG2 and PG3 has been a bit of hack to try and provide that information, typically for use in programs. First you have to define what it is you want. If you take a high level view, a "node server" is really supposed to be just a bridge between the ISY/IoP and a device. So do you want the status of the bridge or the status of the device? (or more likely both). In an ideal world, the bridge status should be irrelevant as it should never fail, but in the real world that's pretty much never true. The ISY/IoP is basically a rules engine with Insteon and Z-Wave node servers built it. Where's the status for the built in node servers? With all of that, PG3 does track connection status for the node servers and PG3 does have an API that allows node server developers to expose this connection status if they want to. Like @Goose66I believe the right solution would be to add node server status to the ISY/IoP API and have a system variable for each node server that can be used in programs. But the priority to add something like that is very low right now. 1
larryllix Posted December 7, 2022 Posted December 7, 2022 I would think an overall, high level comm success would be the best to start.The most important factor is to gather attention from the user that something isn't functioning. Then where and why is up to the user to find by troubleshooting, if they have the tech skills, or gain assistance from more techie people.Sent from my SM-G781W using Tapatalk
Recommended Posts