Watchdog Behavior

[Michael McSharry]

The HS4 plugin has a setting for how long the plugin should wait after a sync/connect attempt is made. This was added after several users had a very long startup time. Significantly increase it to see if it changes your restart behavior.

I have a modest Hubitat setup so my restarts are pretty quick. I remember last year that I had some versions of the Hubitat firmware where the sync/connect took a very long time. Nothing I did other than keeping Hubitat firmware current and now the sync/connect is only a few seconds. My reboot time is 2 minutes before Hubitat completes its "initialaizing" messages.

The debug log does show the traffic between the plugin and Hubitat this would include any heartbeat handshake you are using for a watchdog. The place to start is to look at the debug to understand what the plugin sees. My testing stimuli is cycling power followed by sync/connect button and then observing a motion sensor updates in HS after the test. When the brute-force technique is used to restart the plugin then the debug history is lost as it gets created at each plugin start. Again, only HS4 plugin has the updated logic that is posted in this thread #9.

[Ltek]

Michael McSharry for me, the HS3 plugin has never reconnected when the Hubitat reboots, or such. Tried it again today and the watchdog nor the Rescan/Reconnect button did anything. I had to open HS3's plugin manager and stop/restart the Hubitat plugin manually... works perfectly after that.

[Michael McSharry]

is there any way we can troubleshoot this?

Are you using 4.4.1.1?

The plugin can collect and provide information that it observes. Do you have specific request for information that the plugin can provide?

At startup, and now with 4.4.1.1 a new connection is established. to request data from MakerAPI. At the same time a webhook is setup to receive event data from Maker API. The timeout is the internal update based upon any traffic received over the webhook.

[Vit]

I am still on HS3 and my plugin version is 3.4.0.2.
I saw this
Flair Puck and Vent integration - HomeSeer Message Board
discussion with newer version of the plugin but I believe the attached executable is for HS4.

Regarding the issue I was having, I found the cause and fixed it. And now, the plugin is back to its original state - it's working perfectly, 100%, never misses a bit (Thank you!).
The cause of the problem was completely unrelated to the plugin; however, the plugin, after loosing the connection, seemed to simply count the watchdog endlessly but made no attempts to re-establish the connection, or so it looked. The "Connect/Re-Scan" button did not do anything for me and I actually thought that I had broken the plugin/HS/Windows to the point that the plugin would not even respond to the button events.
And so, I was wondering if you could add some log entries to notify of critical events (lost connection, manual/automatic attempts to re-connect and similar).

Separately, a completely unrelated question: if I need to replace a failed HE device with the new one (but of the same type), what is the best/correct way of bringing the replacement over to HS? Can I simply modify the respective HE device references in 'hubitat-devicemap.json' file? Do names of the devices need to be synchronized between HE/HS/devicemap?

[Michael McSharry]

If you want to keep the same HS device reference then the process is to edit /Config/mcsHubitat-devicemap.json and change the Hubitat deivce id for what is being replaced. In the following example for HS4 and HS3 plugin, respectively the 98 is the Hubitat device id and 8476 is the HS device reference. volume is the capability being provided. The hubitat name is not used.

"0_98_volume": 8476 or "98_volume": 8476

In the HS3 plugin there is no means to programmatically request a reconnection and there is no internal automatic action taken to reconnect. New commands from HS to control Hubitat devices makes a new connection. Event data received from Hubitat is obtained from an open websocket. If Hubitat does not have any events to report then pluign has no means to know if this is normal or not. This is the where the elapsed time device is provided so the user who has implemented a regular heartbeat in Hubitat can detect the lack of heartbeat echo in HS.

In the HS4 plugin a device feature is commanded so there is a HS log entry that this device has been commanded to indicate when a restart has occurred. What changed recently in the HS4 plugin is that the websocket was closed if previously open so a new websocket connection will be setup when a sync/connection operation is performed. A user, as part of their recovery process would toggle power on Hubitat and this would break the websocket connection so the plugin would be deaf of the websocket that it has previously setup.

[Vit]

Michael,

Thank you for the explanation.

It sounds like there are advantages in switching to HS4. Don't know if I am ready for it.

[Michael McSharry]

Something that is possible is to put the detection logic in the program so that when the time since last Hubitat message was higher than a user-entered value then the plugin would conduct a reset of the connections. The problem with this approach is that it does not provide a means to cycle power on the Hubitat hub so it would handle a smaller set of potential failure modes. Seems like you do have a solution already so likely not worth the effort in implementing a partial solution for HS3.

[Vit]

Yes, I agree.
I did not have too many communication issues but every time there was an issue, the culprit was the hub.
The marginal potential benefits certainly not worth your time.
Thanks again!