[MSR] Copy&past of actions and/or drag&drop between set/reset

[toggledbits]

You can also add maxsize: n where n is an integer number of megabytes (default 2) before the log file rotates. Same indent level as keep.

[Alan_F]

@toggledbits So it took quite a while to capture a missed reaction, but I had one this morning. The Hubitat log shows a switch turn on twice. The (virtual) switch is set to auto-off in Hubitat. The reactor log shows the reaction only fired the second time the switch was turned on. What's the best way to send you the logs?

[toggledbits]

PM'd link and instructions.

[toggledbits]

@alan_f OK. I've looked at the logs. Here's what I see going on:

1. At 11:57:56.126Z, Reactor, specifically HubitatController receives an event from the hub on the events websocket for device 519 switch state changing to on (your virtual switch).
2. 7ms later, HubitatController enqueues a request to the hub's Maker API for a full device update. This is an asynchronous operation done in response to the received event.
3. 1ms later (now 11:57:56.134Z) the device update request is made via HTTP to the hub.
4. At 11:58:01.134Z, HubitatController receives another update event on the websocket for the switch returning to off.
5. Over the next 3ms, steps 2 and 3 above repeat for the new event as expected.

What's not here in this timing is the response from Hubitat to the query to Maker API between steps 3 and 4. We would have had to have log level 6 to confirm it, but it appears from what we do have here that Maker API did not respond to the HTTP request within the 5 second timing of the switch reset. That is, by the time Maker API got around to responding with the full state of the switch, the switch had already gone back to off state, so Reactor saw no change. For whatever reason, the hub was busy and didn't respond within 5 seconds, which is a bit alarming, actually.

HubitatController uses the full update, rather than acting piecewise to the event and its single value, because some attributes are driven by multiple values from the device, and it needs all of the values together to correctly ascertain the target attribute values on the entity.

I see two immediate solutions for this:

1. Increase the timing of the reset of your virtual switch at the hub. Go to 10 or 15 seconds. If the hub doesn't respond within that window, it needs to be examined more closely.
2. Don't automatically reset the virtual switch on the hub, do it in the Reactor rule that responds to the switch change. This will be more reliable than #1 because it removes the effect of latency... it will not matter how long it takes the hub to respond, when Reactor sees the change, it will reset the switch and (maybe) perform the other actions. Your trigger remains the switch state, but alone; your other conditions can go into a conditioned action group in the SET reaction of the rule with the action to modify the thermostat.

I will take a second look at HubitatController to see if I can remove the need for the additional query, but at the time it was written, it seemed necessary given the limited data in the event from the websocket.

[Alan_F]

Option 2 seems like the way to go. I'll make that change and wait for nothing to happen