Forcibly turn on a z-wave device if accidentally turned off

#1

Hi Patrick et all!

having some troubles with a z-wave sensor (aeotec ZW116) I have that controls a small heated tile inside a pets cage. I have this thing setup with a lovely reactor timer to turn on the heated tiles at night (9pm to 9 am). It works beautifully.

Now, the ZW116 is also wired into a switch, so that someone can manually turn it on during the daytime if desired also.

Of course (I should have anticipated this), what’s happening is the kids are of course hitting the switch sometime after 9pm, when reactor has triggered and the activity has turned on the heated tiles. So well meaning intentions, what they’re doing is turning it off. grrr…

is there some way I can check if the device to be controlled (device #21) is actually turned on? every half hour or so? and if someone accidentally turned it off, have my reactor sensor sorta re-trip and have the activity turn device #21 on again?

I was thinking about creating an expression inside the reactor sensor that checks the status of device #21… with one of Patrick’s previous code examples.

len(iterate( list(21), if(getstate( dev, "urn:upnp-org:serviceId:SwitchPower1", "Status" )=="0", 1, null ), "dev" ))

But i’m lost about where to go from there… I think it has something to do with using the sustained for on this expression?

Or perhaps I’m going about this wrong.

Is there an easy way to check if someone accidentally turned off a device during an interval where it should be ON, and then having a reactor sensor re-trip and send the trip actions?

open to ideas!!

Thanks :slight_smile:

0 Likes

#2

It sounds like if you just add a ‘Service’ (device state) condition to the same group as your time check to check that the switch is off, that’s all you need. You didn’t post the Logic Summary so I can’t be 100%, but assuming your RS has a single date/time condition “between 2100 and 0900”, adding that check of the switch state will cause the group to go true between 9pm and 9am if the switch is not on, and make the group actions turn the switch on. Any time during that period that someone comes along and turns the switch back off, the group will go true again and turn it back on.

It would be a good idea, I think, to add a little “sustained for” option to the switch condition as well. With no delay, the RS will turn the switch back on immediately, which the person operating the switch will hear (click), and may go into a tug-of-war. If you add a 30 second “sustained for” option, they will probably have walked away at that point. It will prevent the automation and user from getting into a rapid on-off battle that may damage the switch or connected equipment.

Also, if you have an activity that turns the switch off when the group is false, you’ll need to remove that and move it to a separate ReactorSensor (or install beta3.0 Reactor and you can do it all in one).

Reactor Sensor:#1

  • Group 1:
    • Date/time condition, between 2100 and 0900
    • Service condition: switch Status is FALSE option: sustained for 30 seconds
  • Trip action: turn switch ON; no untrip actions

Reactor Sensor #2

  • Group 1
    • Date/time condition: between 0900 and 2100
  • Trip action: turn switch OFF; no untrip actions
0 Likes

#3

Thanks Patrick, I’ll give this a shot. Looks simpler than I was envisioning. And yes the logic is simple, just as you typed out lol.

So add a svc condition to the logic checking the status of the switch is all that’s req’d., but I see what you’re saying… Need to move the un trip actions to a separate sensor, otherwise if the switch is “on” during the desired period, it’s going to cause the group to go false and run the untrip actions. (I think that was the piece I was struggling with)

So beta 3.0 has a setting that would allow it to not run the untrip actions in the same sensor?

0 Likes

#4

Yes. 3.0 allows you to create a full hierarchy of groups, and assign activities to groups rather than just the ReactorSensor as a whole. This allows you to create a group that contains the “on” logic, and a group that contains the “off” logic, and assign them separate actions, within the same ReactorSensor. Cleaner and tidier for things like this. So in 3.0, your ReactorSensor might look like this:

ReactorSensor #1 - “Pet Heater Control”
Group 1 - “On Control”

  • Date/time between 2100 and 0900
  • Switch is FALSE, sustained for 300 seconds
  • Group 1 “true” activity: turn on switch; no “false” activity.

Group 2 - “Off Control”

  • Date/time between 0900 and 2100
  • Group 2 “true” activity: turn off switch; no “false” activity.

Pretty much the same logic, just all contained in one ReactorSensor. Since the activities are assigned to the groups directly and run according to the group state, the overall tripped/untripped state of the ReactorSensor is irrelevant, and there are no actions there.

0 Likes

#5

Wow, ok now that’s very cool. I’m getting more and more tempted to try the beta ! ha ha!!

Meanwhile I’ve implemented the logic you suggested in my existing 2.4 version, (and moved my un-trip actions to another sensor at 9:00 pm), this should solve the problem of the switch being accidentally turned off when the device should be on. I like the 30 sec sustained for idea, to prevent a tug of war as you mentioned. You have an inept ability to think things through very well, anticipating problems that I haven’t yet considered!

0 Likes

#6

My wife often says this about many things I do! :smiley:

0 Likes