Improved handling of non-responsive and semi-responsive nodes
Torfinn Brokke
I think the logic for handling non-responsive and semi-responsive nodes should be improved. As things are now, some nodes may have gone for hours and days without updating their status, while others have “no data” on one or more of the items they are supposed to be reporting.
Both the reporting interval (from the relevant parameter) and the data that are supposed to be reported (from the node type) are easily known. The system should then be able to use algorithms to find out when either of these issues exist. The system should then try to fix this autonomously by trying to establish a two-way connection with the node and updating it. If this does not work, the user should be notified of the error and what steps to take.
To clarify: When talking about non-responsive nodes I mean those nodes where you look at the timestamp for the last update and see that this has gone far past what it is supposed to. When talking about semi-responsive nodes I mean those where one or more pieces of data is not sent as it should. There are two types of this: Either the relevant field reads “no data” (e.g. battery status for a Sensative Strip) or the relevant field does not exist at all (e.g. the “motion” field completely missing from an Aeotec Multisensor 6).