I have a feeling all these sudden problems are either because of
a bug I introduced
ST being a bit iffy…
Trying to consolidate some things, found a bug where location/shm conditions were not filtered to only events coming from the location, but from any device. Fixed that. Some other fixes regarding the stability of comparisons. Tested with a piston I could not get to work right…
Also temporarily fixed the changes away from - this is however historical, it should look at what the state was previously (and I cache that, so the first round did not work as I had no cached value). What it does now, it acts exactly opposite to “changing to any of”. If you have 4 values, 1, 2, 3, and 4 and you say “changes away from 1 or 2”, it should only trigger when the value WAS 1 or 2 and now is not 1 nor 2. However, that’s complicated. What it does right now is it looks to see if the new value is not in that list. So if it changes from 3 to 4, “changes away from [1,2]” is TRUE. I think the name should be different or I should do away with it…
v0.0.066.20160603 - Alpha test version - Fixed some bugs involving the “changes away from” - still keeping an eye on this though
Pretty slow. I’ve seen much better days. My pistons have been very stable, except one that included location - I have a DTH from my own integrationwith Digital Life’s alarm. In that DTH, I implement an attribute called “mode”. Turns out, subscribing to location’s mode will trigger events even when that device changes that “mode” attribute - and I haven’t subscribed to that! It’s as if any event for attribute “mode”, regardless of source device is broadcast as a location event. Perhaps, similarly, one can subscribe to location’s “switch” attribute and get all events for “switch” from all devices? That would be cool. Anyways, had to implement code to ensure that listening for location’s “mode” is actually triggered by the location only. Problem solved and all good and stable…
I don’t think the Else ever runs since the Or and Or-If are mutually exclusive? One of them will always be true and the other one false. The OR between them ensures piston is always true. Point is, Else is not needed. But yeah, turning the switch on turns on the lights, turning the switch off brings the lights to their initial state prior to switch turning on. Just what the capture/restore is designed to do. Really thinking I should rename them Capture/Restore.
Can anyone please test the physical switch? I don’t have any in the house… In expert mode, when using the switch attribute, a new option shows up called “Interaction” and has three possible values: Any, Physical, Programmatic. Set it to physical and that condition should only be true whenever you manually push the switch button.
Here’s my alarm management piston works like a charm. Digital Life was built to automatically sync with mode and SHM, so all three are tied together. I change any, the other two follow.
This piston locks doors and lets me know of what’s going on
works like a charm. Digital Life was built to automatically sync with mode and SHM, so all three are tied together. I change any, the other two follow.