Interfacing Alexa with Reactor via Routines and Dimmer VS
-
Upon further testing, I've concluded that Alexa Routines are a not reliable means of sending discrete data. For instance, in a simple test to see whether MSR could receive individual "Dim" commands from Alexa, the failure rate was almost 100%.
I created a Routine that sets the same device (a Hue bulb running on the Hue hub, connected with Vera Plus via the AltHue plug-in) to three different "Dim" levels (21%, 67%, then 3%) in rapid succession.
As this graph shows, displaying 3 separate runs of the Routine over the course of a minute, the resulting final "Dim" level was effectively random among the three possible values.
Additional testing -- using a Virtual Dimmer Switch instead, thinking that may remove several lag points in the workflow -- revealed that results vary. I changed the "Dim" levels to 99%, 21%, followed by 0%. While this setup was slightly more dependable in terms of the desired outcome (e.g. VS gets set to proper brightness levels, but not always in the correct order), the only way to guarantee results was to introduce 5-second delays between steps. (Alexa Routines only permit delays in 5-second increments, thus vastly reducing the utility of this approach.)
Avoid. Unless you are confident in sending only a single datum with no delay. Even then, I would test the routine a bunch to make sure it actually fires each time you think it should.
-
Tracking same as you show, except the inescapable fact that when it's an Alexa Routine doing the dimming, the bulb was apt to wind up dimmed to 21%, or 67%, or 3% at the end of the test. In other words, Alexa sending multiple different values over a short span were not going to be honored faithfully on the receiving end, which means MSR was going to detect erroneous data. Therefore, triggering Scenes off of such data seems like a bad idea.
-
Tracking same as you show, except the inescapable fact that when it's an Alexa Routine doing the dimming, the bulb was apt to wind up dimmed to 21%, or 67%, or 3% at the end of the test. In other words, Alexa sending multiple different values over a short span were not going to be honored faithfully on the receiving end, which means MSR was going to detect erroneous data. Therefore, triggering Scenes off of such data seems like a bad idea.
@librasun said in Interfacing Alexa with Reactor via Routines and Dimmer VS:
Tracking same as you show
You are tracking dimming.level, which is the status I believe. My example was tracking the target level. The difference being, target is set to to loadLevelTarget in the controller so is clearly defined and MSR should pick it up clearly as it is set. Tracking the status means tracking a moving target, as the new level target sent from alexa will mess with the status level.
My image is a routine from alexa with 2 levels, fired by voice several time in quick successio.
-
Here are my results, after running the same (revised) Alexa Routine, which is supposed to send out four events in a row: "Dim to 39%", "Dim to 21%", "Dim to 100%", and "Dim to 0%". Literally all four tests resulted in different data, as shown by this Scope snapshot.
If you examine the four graphs closely, it's almost as if Alexa is doing a "look-ahead" and skipping some of the earlier assigned values when she "knows" the VS is already set to a later value.
Either way, I feel more confident now that "Dimming Level" and "loadLevelTarget" are identical in value for testing purposes.
-
Roger that. I had tacitly assumed that
dimming.levelin MSR land was the same asloadLevelTarget.Let me delve into the details of what I was tracing and get back to you. Thanks for the clarification!
-
@librasun
here is image with 4 commands in routine no delays
dim20
dim30
dim20
dim30
the hall switch turns off/on when 20/30
and here it is from routine with a set alexa device volue between each command
@elcid Intriguing how your setup seems so much more consistent than mine. It's the story of my life. In fact, while doing this test battery, I realized that Switchboard plug-in for some reason is refusing to "Reset" the Test Dimmer despite its ImpulseTime value being non-zero (I've tried 1, 3, 5, doesn't matter). Never resets.
I find a problem, it always has a baby.
-
@elcid "Test Dimmer" is a child device of Switchboard plug-in on my VeraPlus. MSR runs in a Docker container on my Synology NAS, connected to the same local network.
I'm accessing and executing the Alexa Routine using an Android phone (also connected to the same WiFi).
Clearly the type and timing of propagated data in this arrangement is not deterministic enough to be used as a Trigger in MSR. Spent two solid days proving that to myself, lol!
Surely with Node-Red and other more modern, streamlined data channels in place, it would not be a problem, I'm sure. Just wanted to test what I have in my arsenal, which is always 1-2 generations old.
-
@elcid "Test Dimmer" is a child device of Switchboard plug-in on my VeraPlus. MSR runs in a Docker container on my Synology NAS, connected to the same local network.
I'm accessing and executing the Alexa Routine using an Android phone (also connected to the same WiFi).
Clearly the type and timing of propagated data in this arrangement is not deterministic enough to be used as a Trigger in MSR. Spent two solid days proving that to myself, lol!
Surely with Node-Red and other more modern, streamlined data channels in place, it would not be a problem, I'm sure. Just wanted to test what I have in my arsenal, which is always 1-2 generations old.
@librasun said in Interfacing Alexa with Reactor via Routines and Dimmer VS:
Test Dimmer" is a child device of Switchboard plug-in on my VeraPlus. MSR runs in a Docker container on my Synology NAS, connected to the same local network.
That did not answer my question, how is alexa communicating with the vera virtual device?
-
@librasun said in Interfacing Alexa with Reactor via Routines and Dimmer VS:
Test Dimmer" is a child device of Switchboard plug-in on my VeraPlus. MSR runs in a Docker container on my Synology NAS, connected to the same local network.
That did not answer my question, how is alexa communicating with the vera virtual device?
@elcid Hmm, I gotta think about that.... All I can say is that after creating the virtual switch "Test Dimmer" I went into GetVera configuration > Alexa > checked the new device, then FINISH. Then I ran Alexa app's "Discovery" mode (it found the new device), whereupon it became available inside my Routines.
So as to "how" it communicates, I suppose it's happening through the Alexa <> Vera connection at an API level. That's my best guess.
-
So it's using the laggy Ezlo Alexa plugin. Can you not use HA bridge on your NAS?
[edit] I moved most of the plugins off vera and no aleax plugin , result is alexa is faster and veraplus reloads 1 or 2 times a week, and i am still on firmware 7.31, waiting for offical release of 7.32 as don't want to fall into the no support as you loaded beta firmware trap. -
Ha, your suggestion led me to Google "HA Bridge" and I read up on it over at Github. Fascinating concept, although a bit beyond my technical level (i.e. "slightly scary") and I dare say it solves problems I'm not quite sure (yet) that I have.
As for Vera firmware, yep, on the advice of others, I took the plunge upgrading to 7.32 (beta) and have no regrets. In fact, at the same time I also uninstalled several plug-ins (Site Sensor, Reactor, and GCal3) and have experienced exactly ZERO Luup engine restarts since!
I'll keep your advice in mind for the future, as I learn more about my system's weaknesses. Right now, it does everything I need and more. The experimentation I do here is mostly connected with beta testing MSR, which has kept me occupied for over a month now.
-
-
Does it also spare you having to go through those godforsaken steps I mentioned earlier (Vera > Logout > Name > Alexa Setup > enable/rename devices > Finish > Alexa app > Discovery)? Cuz that would be wonderful, lol. Have added it to my Reading List.
@librasun said in Interfacing Alexa with Reactor via Routines and Dimmer VS:
Does it also spare you having to go through those godforsaken steps I mentioned earlier (Vera > Logout > Name > Alexa Setup > enable/rename devices > Finish > Alexa app > Discovery)? Cuz that would be wonderful, lol. Have added it to my Reading List.
Probably not, because, as I read it, Vera is the problem......
Openluup is nothing like that bad.
C
The Ex-Vera abuser know as CatmanV2.....
-
@librasun said in Interfacing Alexa with Reactor via Routines and Dimmer VS:
Does it also spare you having to go through those godforsaken steps I mentioned earlier (Vera > Logout > Name > Alexa Setup > enable/rename devices > Finish > Alexa app > Discovery)? Cuz that would be wonderful, lol. Have added it to my Reading List.
Probably not, because, as I read it, Vera is the problem......
Openluup is nothing like that bad.
C
@catmanv2 said in Interfacing Alexa with Reactor via Routines and Dimmer VS:
Does it also spare you having to go through those godforsaken steps I mentioned earlier (Vera > Logout > Name > Alexa Setup > enable/rename devices > Finish > Alexa app > Discovery)? Cuz that would be wonderful, lol. Have added it to my Reading List.
Probably not, because, as I read it, Vera is the problem......
Is it not as easy as creating the links to the devices in the HA bridge, then asking alexa to discover devices?
-
@catmanv2 said in Interfacing Alexa with Reactor via Routines and Dimmer VS:
Does it also spare you having to go through those godforsaken steps I mentioned earlier (Vera > Logout > Name > Alexa Setup > enable/rename devices > Finish > Alexa app > Discovery)? Cuz that would be wonderful, lol. Have added it to my Reading List.
Probably not, because, as I read it, Vera is the problem......
Is it not as easy as creating the links to the devices in the HA bridge, then asking alexa to discover devices?
-
Ha-bridge is really plug&play. There’s also a docker image available.
--
On a mission to automate everything.
