Last night, I noticed that my tried-and-true “Lights Out” routine would not run, no matter how many times I asked Alexa to “Turn it on” or pressed the assigned button my my handheld remote.
So I went to Vera and examined my setup:
- The virtual switch was in the “ON” position (correct)
- The Reactor sensor containing “Lights Out” had no yellow triangle (correct)
- In Conditions, the intended trigger was TRUE (virtual switch = ON) (correct)
- In Activities, some of the “OFF” fields were empty (PROBLEM)
In fact, of the six [Device Action]'s in the .TRUE group, two or three of them were showing:
[Device Action] [Dining Room Light] [Turn On or Off] [CLICK FOR PREDEFINED VALUES] in yellow
I corrected them, saved the Reactor sensor, and all was well.
But why would a routine drop these values when it hasn’t been edited in many days and has been working fine otherwise? The only change to Reactor in the intervening 4 days that might have touched that routine were the 2-3 times I clicked Tools > Update Device Information Database.
Do those periodic updates run any risk of upsetting established values?
Very curious!
P.S. Had I not inspected the routine, I would have had no idea it was refusing to run. This makes me wanna go check ALL my routines, just in case.
The update of the device information database only downloads a file from my server and installs it in place of the same-named filed on your Vera. It does not alter the configuration in any way–it doesn’t even read the configuration on the Tools tab or in that downloader, as it isn’t needed.
Are you on 3.5 or 3.6dev?
Good to know! I’m still on 3.5, with a LuaXP module borrowed from later repo update.
The other thing to know is that the only way the configuration gets written by the UI is when you hit the “Save” button. There are no automatic saves. There are no sneaky updates or upgrades between versions. If you don’t hit “Save” (or answer “OK” if it warns you about unsaved changes on exit), it isn’t written.
Can you describe in more detail what you were doing? For example, did you go back and forth between the Tools tab and the Activities tab, specifically? Were you ever asked to save changes? Did you make a change to any action in other activities in that RS? The yellow highlight is a warning that does not block “Save”, so it’s possible to miss them if your screen is full of one activity of interest and the problem manifests in others that are off-screen, so I’m wondering if you edited something and there was a bug that ended up modifying those other actions and you didn’t notice. It would be easy to do. I’ll do some specific testing for that, but try and retrace your steps…
And do you have 3.5 hotfixes applies, or on 3.5 as installed? What’s the version number in the footer of the “Tools” tab?
I’m on 3.5 as originally installed. Footer says Reactor ver 3.5.
At no time did I visit or modify the “Lights Out” set of Activities since last successfully using that routine (daily if not more so). That .TRUE group just turns off six lights/switches, as it always has.
The changes to those two or three actions (the “0” entries becoming “blanks”) within the group seemingly happened independently of anything I was doing … since I literally did nothing, lol!
My SINGULAR visit to this Reactor sensor during the prior 24 hours was to edit a different .TRUE group, namely to re-select the ‘Sonos Beam’ player (due to its device number having changed over the weekend), to make its ‘Say’ action resume working. At which time I clicked SAVE w/o manually/knowingly making any other changes.
I’ll just watch for this or similar to recur, and chalk it up to my karma for now. 
That’s my point… that could do it. The UI can conceivably have a bug where modifying a field in an action modifies another action that may be off-screen. Not in a different RS; that would not happen. But in the same RS, that’s a conceivable bug, because the fields for each action reuse components, and I have to be very carefully when modifying any field that I’m on the right row… I go to great lengths to make sure that I’m specific as possible with my selectors in jQuery. I usually make sure my selector is context-limited to the specific row that is being modified, but I have made mistakes in the past and forgotten that qualification and caught it, and it’s possible there’s one sitting there I haven’t caught. Or seen, as I just did a code review, line by line, of every action field modification. Nothing found, not yet. I can’t reproduce it in the UI of 3.5hotfix or 3.6 either. I haven’t tried 3.5. But be assured I’ll spend some time testing on this, and doing more code reviews. It’s obviously something sneaky, because one would think I would have this reported much more frequently if it was a generic problem to modifying actions. There’s some specific path to what you were doing that’s key here, we just have to find it…
Also, can you PM me the contents of your cdata variable on that RS. I want to see if any trail of crumbs was left in there.
1 Like
Your config turned up nothing notable. I’ve been over the code again and again and again in review, and only found some minor unrelated nits to pick at. What I’ve done for the moment is added warning icons next to the “Save” buttons in all activities to tell you if there’s a warning anywhere. So once you’re on 3.6, if you get a warning icon on an edit suddenly, immediately let me know what steps you took to get there. In the meanwhile, I’ll keep testing, testing, testing…
Always count on me to somehow cause trouble! (So against my nature, too!)
Love the warning icons for any ‘dirty’ data, since that would apply to several of my Sensors, now that I finally think on it (things unrelated to my renumbered Sonos, for example, that nevertheless would adjust the Sonos volume).
Again, must be my karma. Last night at 2am, an X10 siren I’ve had plugged in and unused for 10+ years decided to start blaring and woke us up. Vera and Reactor seem not to be the culprits (the only routine I have for the dang thing also would send me a notification), so I’m blaming either (a) a rogue Insteon PLM, or (b) a neighbor who just got X10, set his device to ‘O6’ and pressed the ON/OFF toggle a bunch o’ times (only way to make the siren shriek!). 
Will be updating to Reactor 3.6 TODAY WITHOUT FAIL! THANKS!!
P.S. I, too, was unable to replicate whatever tripped those blank fields we were discussing.