DynamicGroupController and attributes

[SweetGenius]

I have a Hubitat device errors of devices that I am pretty sure I have never published to MSR. I have looked through my rules and cant find any reference to the devices and have checked my Maker API instance and the devices are not included. I am using Version 21129. Here is an example:

2021-05-10T01:30:00.013Z Engine:5:1032:Engine.js _process_reaction_queue() running task 4 { "tid": 4, "id": "rule-kodpluwh:R", "rule": "rule-kodpluwh", "__reaction": [RuleReaction#rule-kodpluwh:R], "next_step": 0, "status": 0, "ts": 1620610200011, "parent": --null--, "__resolve": --function--, "__reject": --function--, "__promise": [object Promise] }
2021-05-10T01:30:00.013Z Engine:NOTICE Starting reaction Test-Stairs Light<RESET> (rule-kodpluwh:R)
2021-05-10T01:30:00.013Z Engine:NOTICE Test-Stairs Light<RESET> delaying until 1620610500013<5/9/2021, 8:35:00 PM>
2021-05-10T01:30:00.014Z Engine:5:1036:Engine.js _process_reaction_queue() task returned, new status 2; task 4
2021-05-10T01:30:00.015Z Engine:5:1071:Engine.js _process_reaction_queue() ending with 1 in queue; waiting for 1 (next delayed task)
2021-05-10T01:30:04.873Z HubitatController:ERR HubitatController#hubitat device 96 not found. You may need to publish the device in Maker API to make it accessible to Reactor.
2021-05-10T01:30:04.884Z HubitatController:ERR HubitatController#hubitat device 96 not found. You may need to publish the device in Maker API to make it accessible to Reactor.
2021-05-10T01:30:04.888Z HubitatController:ERR HubitatController#hubitat failed request for device 96 info: Error: unparseable response
2021-05-10T01:30:04.889Z HubitatController:CRIT Error: unparseable response
Error: unparseable response
at /opt/reactor/server/lib/Controller.js:486:35
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:93:5)

[toggledbits]

Hubitat's websocket API that sends device events will send events for devices not pubished in Maker API. MSR can't tell the difference between a new device that hasn't yet been published via Maker API, or a device that you choose to never publish in Maker API. These messages can be safely ignored.

[SweetGenius]

That darn Hubitat API...Guess I shouldn't have sold the Vera's.

[toggledbits]

I'll see about making the log messages a little less alarming looking. They're intended to just be reminders/helpful.

[SweetGenius]

They are no big deal since I know what they are. I was troubleshooting other issues and then went down that rabbit trail. Thanks

[toggledbits]

Found another Hubitat issue today (actually, found the issue some time ago, and I've been working on it since trying to figure it out, finally understand it)...

The "Hub Login Security" feature interferes with the eventsocket WebSocket API. When "Hub Login Security" is enabled, any connections to the eventsocket interface are accepted, but no messages are sent to it (that is, device updates are not sent by the hub). This manifests most commonly as Hubitat device updates in MSR stalling after a hub reboot, but then mysteriously resuming later (when you eventually log in to your hub).

For the moment, there are two options for resolving this (either-or):

1. Disable "Hub Login Security". I suspect a lot of users run this way anyway, although it was enabled by default on my new hub. Turning this feature off makes all eventsocket connections work from the start.
2. Configure MSR's HubitatController to not use the eventsocket WebSocket interface and use the old "POST URL" notification method instead. This may be less reliable, so it's a trade-off between security and performance/reliability. Reverting to "POST URL" requires you do add use_posturl: true to the config section of reactor.yaml for your Hubitat controller(s).

For clarity, if you already are not using "Hub Login Security", there is nothing you need to do and you should not have issues with device updates.

I think I know a workaround, but it's going to take time to implement and test.

[toggledbits]

An additional follow-up: the aforementioned workaround was incorporated into the last release (21153); that is, HubitatController will now perform a login at the hub (even though the session is abandoned and no other work is done via the Hubitat UI) to clear the restriction on the eventsocket.

Hubitat users who operate hubs with "Hub Logic Security" enabled can enable this workaround simply by adding username and password keys with valid credentials to the config section of their controller configuration (in reactor.yaml).