How does MSR keep in sync with devices and scenes on Vera?
-
Hi
I've been having trouble again, with a Qubino DC Shutter module today. I actually deleted one and added a new one.
Now in MSR I have several instances of "Lounge Blind"
Device number 644 is the one that is on Vera.
If I search Vera for devices numbered - 638, 643 they don't exist on Vera.
Also there is one in MSR called "device_642" that device doesn't exist on Vera either.
Also the device named _Window Covering with ID 640 that doesn't exist on Vera now rither.
So when devices or scenes are added or removed on Vera how does MSR keep in sync is there something I have to do ?
Thanks
-
Right now, the VeraController interface does not attempt to remove devices that are no longer listed, because the way the controller and the Vera talk is via an initial query for all data, followed by queries for changes, and Vera doesn't advertise device removals as a change, it just stops reporting them. Related to this is the fact that Vera reloads for every darned thing, even if you look at it the wrong way, but oddly it doesn't reload when you delete a device (whisky tango...?). Consistency will never be something for which they are known, under any name. Anyway, I have ideas, but as long as she doesn't reload on delete, even my imagined fix will not work.
So the short answer for you is just reload Reactor.
-
-
Absolutely possible, and in fact, I have several ideas on how a "leave-behind" Reactor on the Vera could get other things done. But for the most part, I've found better workarounds (handling house mode is one example). But it remains an option.
-
I've been noticing a consistent 2-second delay* between device state changes on Vera (e.g. a light turning OFF) and the corresponding change appearing in MSR's Scopes > Trace feature. Is that to be expected? And do we attribute that to Vera's delay in reporting status via HTTP?
* Mostly with HUE bulbs, which my Vera Plus controls via AltHUE plug-in. The delay is far less with Z-Wave components!
-
MSR uses Vera's long-polling feature, which means MSR makes an HTTP request for device changes, and the Vera doesn't respond for up to 15 seconds. If any device changes during that time, the Vera immediately responds with those deltas, MSR processes them, and then starts another request for more changes. While not as effective as a WebSocket always-up connection, for example, it's not much less responsive. And there is no "interval" that limits the refresh rate.
My guess is that the delay you are seeing is caused by the additional device communications required with the Hue hub. That communication not only has to happen, but it occurs when the Vera allows the plugin to run, and with whatever method the plugin uses for communication. I have mostly ZWave devices, and as you've observed, they're quick.
-
I'm at the point in my MSR experimentation where I'm wondering how users are intended to handle Vera events that cause [DEVICE] [STATE] to [UPDATE] rather than just [CHANGE] value.
I recognize that MSR may not (yet) have access to such subtleties, so the absence of this feature may be a show-stopper for certain routines I've enjoyed back on RFL (Reactor for Luup). Among the examples, I can cite are button presses on my Scene Controller remote, for which it's insufficient to know WHEN and WHICH button was pushed, but THAT it was pushed at all and whether it was pushed AGAIN during a given interval.
TIP: My current workaround involves creating a Virtual Switch (using @rigpapa's Switchboard App, assigning it an auto-reset time of 1 sec.), along with a Reactor routine that is triggered by the Scene Controller's fleeting update of its sl_CentralScene attribute whenever a button is pushed on the remote. Over on MSR, I included an Expression whose status goes TRUE when that Virtual Switch on Vera turns on, and invoke that as a Trigger in a Rule. Works great so far!
I know Patrick has a roadmap for this functionality IF IT'S POSSIBLE (Spoiler alert: It's not, see below), and now I'm all the more curious to know how he plans to resolve it. Because it's going to be awesome, no matter what!
-
This is an issue particular to Vera and cannot be handled over the request API that MSR must use to communicate with Vera. So my roadmap for this functionality as a matter of making it work like it does in Reactor for Vera is dirt road to a dead end.
My suggested workaround is to use the "x_vera_device.set_variable" action to reset
sl_SceneActivatedorsl_CentralSceneto a nonsense value (I use 0) as part of your reaction to responding to a particular value. -
I had recalled you suggesting the dummy value approach, but I got scared and didn't implement it. Now that I'm confident once more it has your blessings, I shall proceed with that.
I'd spent most of my time yesterday trying to workaround not having .SETPOINT available to my ecobee thermostat device, namely by setting both of the available COOL.SETPOINT and HEAT.SETPOINT values (I'm paraphrasing) in MSR, but that seems to be a wrong approach. Only one of them seems willing to accept the change at a time, perhaps due to API lag.
Once MSR can push values to .SETPOINT per the .JSON mapping file I submitted, I'll be golden. It's fun waiting for stuff like that!
-
That's probably not the right approach for the thermostat. The device info you sent me actually shows that its a dual-setpoint thermostat with separate heating and cooling setpoints commands. The fact it has a single command which, I assume sets the setpoint for whatever the current operating mode is, seems to be an overloaded kludge and actually, really dangerous. The data you sent me shows that your thermostat is in auto mode, meaning it could switch between heating and cooling operating modes at will, so having a generic command in an automation to set whatever setpoint is currently in effect isn't deterministic for you: you need to also look at the thermostat's operating state, or more correctly, its last operating state (because its current state could be idle and that doesn't tell you), to know which setpoint that action would set. You could easily set your heat setpoint to 81 without knowing it. So....
- I have a different mechanism as a work in progress for controller-native actions that are not supported by the standard entity capabilities;
- Regardless of #1, setting the generic setpoint seems like a really bad idea and the more specific commands are better/safer.
-
Agreed. I'll just add that my workflow back on RFL indeed used the "common" setpoint for my purposes and it has worked awesomely without a glitch. Subject to two caveats in my case: (1) I purposely limited the Temp values (using ecobee's own in-device Settings) to which the thermostat can be set; and, (2) I never leave it set to AUTO, so the thermostat is always deterministically set to either HEAT or COOL.
button is INCREMENT or DECREMENT by 1 degree the prevailing setpoint. When I bifurcated this into setting both the HEAT and COOL, rest assured I based my calculation off of each independently, so no wild swings were ever going to happen (but you were right to be concerned on that point).I'll spend today revising the MSR workflow to (a) detect mode, (b) handle each case independently, (c) remove the virtual switch kludge, and (d) use the "reset sl_ variables" trick you suggested. CHEERS!
-
If you hold off on (a) and (b), you'll have my #1 in a day or two. I'm done with the changes for Hubitat and Hass, and Vera is that last I'm working on and the most difficult. If it's acceptably safe in your use case to use the single command, that's fine, you'll have it.
-
Roger that. While sage advice, bear in mind that I do these exercises as much to keep my brain active as to hone my MSR chops. I literally have nothing else to keep me occupied, lol. So I'll go put the finishing touches on the intermediate workflow, check that it works (which I know it will), and then look forward to stringing it all back together more efficiently next week.
-
T toggledbits locked this topic on
