@rigpapa, when an action is performed by a Reactor, is it verified that it completed (if possible) or is the command just sent and we assume the Vera is going to handle it? If it’s the former, is there a setting to enable this? If it’s the latter, could i suggest a “verified action” where we send the command to the network and wait for the change to actually happen before we continue on to the next step?
Just trying to overcome some of the z wave limitations in Vera when sending actions to multiple devices. In my particular setup, this produces the “got CAN” messages, and whatever command was in flight at that time disappears into the Vera ether. I have added delays between all my calls to z wave devices to try to fix this, but in really complex reactors, trying to get the timing correct can be a bit of a pain.
Unfortunately there’s no consistent, useful status information that comes back other than that of the device itself, and that is actually unbelievably hard to make work in every case (I’ve tried). It relies heavily on (here’s that word again) consistent performance and adherence to standards by Luup and the various plugins that can drive devices, and that’s light years away from where the environment is today.
I’ve been pondering ways to make it easier to slow the roll on actions. It’s not easy, as Luup hates delays. It’s very much a “Catch-22”. On the current firmware, there will never be a solution that works 100% of the time, even on a perfect mesh. Too many implementation errors at too many critical junctures.
Yeah, i hear you! it was driving me crazy since i knew my logic was sound, but for some reason changes were not taking effect. i finally sat there looking at the logs while testing and saw all the got CAN messages when actions started firing. i was much more agressive with my delays (5-30 seconds) depending on the actions, wonder if i should try to cut those down a bit?
