Watchdog Behavior

[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!

[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]

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]

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]

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]

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.

[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]

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.

[Vit]

In the last couple of weeks, I've been having the same problem and spent fair amount of time watching the watchdog count seconds

The 'beer' message does appear. You just need to be patient. (In my case, the refresh process often takes more than a minute).

Connect/Rescan and Watchdog buttons did not always help with re-establishing communication.
And so, I now have an event that launches a 'program' if Watchdog exceeds 250s. The program, the whole 5 lines of it , kills the Hubitat process.
Nothing else is needed - HS automatically restarts the plugin.

Based on the logs, the problem occurs several times per day; and often, it takes two-three plugin restarts to re-establish connection (this probably explains why Connect/Rescan at times appears non-functional).

My thing is that I've never had this problem before; and although there were some recent changes in the environment, I could not associate any of these changes with the issue.

Michael,

is there any way we can troubleshoot this?

[Michael McSharry]

I just realized you are in the HS3 forum. The ability to control sync programmatically is only with HS4 plugin. I believe Jon00 has a utility to restart a plugin.

[simonmason]

Also, I did a little more testing on shutting down the hubitat by cutting off the power. When it has restarted I don't think the "Connect / Re-Scan Devices" button re-establishes the connection. I hit it 5 times in row and no dice. I then unloaded and loaded the plugin from the manage plugins page and everything was back to normal.

Also, don't know if this is related. The "Perhaps go have a beer" (which is always an excellent idea) doesn't display every time I hit the connect button. For example it only displayed once in the 5 times I hit the connect button when testing.

[simonmason]

I am probably overlooking something obvious here but I don't see a way to set the value? Thanks.

[Michael McSharry]

You have a Sync feature that is part of the root hub device. Use the Control a Device event action and set it to any value (e.g.0)

[simonmason]

I did set it up with a smart plug so I can restart it remotely. Of course, being an idiot, I used a plug that is connected to the Hubitat hub. So I will have to move that plug over to homeseer.

How can I programmatically issue a sync command through an event after the habitat has restarted? Thanks.

[Michael McSharry]

The plugin only establishes the event reporting connection with Hubitat at startup. I changed this starting with version 4.4.1.1 to establish this connection at every Sync operation.

http://mcsSprinklers.com/HSPI_mcsHubitat_4_4_1_1.zip

The reboot button on the plugin will send a command to restart Hubitat, but if it is locked up there will be no effect.

The process I suggest as the Event action when the watchdog exceeds the time threshold is to command the power cycle via other technology such as wifi smart plug, zwave smart plug, etc. Wait 5 minutes or whatever your hub's worst-case startup time is, Command the plugin's Sync feature.