Syncronizing 3 NEXA 433 light switches

Nice to have a dedicated forum for this wonderful plugin!

This setup is for my hallway (norwegian: Gang), I have a 433 dimmer directly mated to a 433 Light switch. I also wanted to control it from the other entrys to the room, so two reactors is set up to turn on and off.

Attached is the “ON” logic, which worked well for a few days, but now is not doing what it should. As the other attachment shows, I just turned the main switch ON, but the reactor says that this hasn’t happend for about two days. It seems like the time of switching the light wasnt updated?

I tried to restart everything, no effect. Any Ideas?

This is the OFF logic BTW… Both agreed that the main switch hasn’t been true since 13 september…

[quote=“Forzaalfa, post:1, topic:199782”]Nice to have a dedicated forum for this wonderful plugin!

This setup is for my hallway (norwegian: Gang), I have a 433 dimmer directly mated to a 433 Light switch. I also wanted to control it from the other entrys to the room, so two reactors is set up to turn on and off.

Attached is the “ON” logic, which worked well for a few days, but now is not doing what it should. As the other attachment shows, I just turned the main switch ON, but the reactor says that this hasn’t happend for about two days. It seems like the time of switching the light wasnt updated?

I tried to restart everything, no effect. Any Ideas?[/quote]

It’s interesting to me that although the dimming level of “Lys” in your screen shot shows 100%, the switch status of the device in the screen shot shows “Off”. That’s… not what I’d expect from the device implementation if the switch is on. However, since you are looking at status and not dimming level in your Reactor logic, I’m not surprised you are not getting the result you expect, because it appears that Status is, in fact, 0. This seems like an issue with the 433 driver. The device should not have Status 0 when LoadLevelStatus > 0, I think.

Well, the light in the hallway was at this point in fact at 100%, its just the Status = 0 that is wrong…

I’ll look into the RFX plugin side and get back to this…

[quote=“Forzaalfa, post:4, topic:199782”]Well, the light in the hallway was at this point in fact at 100%, its just the Status = 0 that is wrong…

I’ll look into the RFX plugin side and get back to this…[/quote]

Seems like those two variables should agree.

But if they can’t/won’t/don’t, it may be possible/reliable to test LoadLevelStatus instead of Status in your Reactor conditions.

[quote=“rigpapa, post:5, topic:199782”][quote=“Forzaalfa, post:4, topic:199782”]Well, the light in the hallway was at this point in fact at 100%, its just the Status = 0 that is wrong…

I’ll look into the RFX plugin side and get back to this…[/quote]

Seems like those two variables should agree.

But if they can’t/won’t/don’t, it may be possible/reliable to test LoadLevelStatus instead of Status in your Reactor conditions for that device.[/quote]

(is the previous post in the wrong thread? Don’t think this one has any scene issues? :wink: )

I changed the dimmer conditions to look at “load level” instead of “status”, and now it works fine. :slight_smile:

Also notified tinman about the issue, pretty sure this is a glitch in the new RFX plugin version.

Picking this up again as i’m exploring new functions in 3.0. The use case is the same, and i want to collect this in one tidy reactor using the new logic additions.

In short, the plan is to have 3 switches syncronized no matter which is switched. in my head this logic would do it:

The XOR ensures that only one switch that differs will fire either of the sub groups.

Activities are set up like this:

Quite simple, but when I enable this reactor and flip a switch, it throttles off. This is probably because of which order the switches are flipped?

Probably some glitch in my logic here, but it might be nice practice in using these functions for others too… :slight_smile:

I think your tests for device #285 are backwards and causing the conditions to oscillate.

Yes, found that one, still oscilates.

You agree on the logic here?

Yeah, as I stare at this more, this approach won’t work. If you switch one switch on, there is always at least one switch on, and at least one off, and the states will always compete. In order to keep the switches in sync, the state of the switches overall is not really what’s important, it’s the state of the last change that’s important. That is, if the last thing to happen is one switch gets turned on, the others should all get turned on, and if the last thing to happen is one gets turned off, the others should all get turned off.

Here’s how I would approach that:

Expressions/Variables:

state1 = if( tonumber( getstate( "Lys - Gang", "urn:upnp-org:serviceId:Dimming1", "LoadLevelStatus" ) ) > 0, 1, 0 )
state2 = getstate( "Extrabryter - Gang", "urn:upnp-org:serviceId:SwitchPower1", "Status" )
state3 = getstate( "Extrabryter2 - Gang", "urn:upnp-org:serviceId:SwitchPower1", "Status" )

Conditions:

Group 1 - name “Switch 1”

  • Device State: Lys - Gang Status changes (leave value fields empty)

Group 2 - name “Switch 2”

  • Device State: Extrabryter - Gang changes (leave value fields empty)

Group 3 - name “Switch 3”

  • Device State: Extrabryter2 - Gang changes (leave value fields empty)

Activities:

Switch 1 is TRUE:

  • Device Action: Extrabryter - Gang turn on/off; put this text in value field: { state1 }
  • Device Action: Extrabryter2 - Gang turn on/off; put this text in value field: { state1 }

Switch 2 is TRUE:

  • Device Action: Lys - Gang turn on/off; put this text in value field: { state2 }
  • Device Action: Extrabryter2 - Gang turn on/off; put this text in value field: { state2 }

Switch 3 is TRUE:

  • Device Action: Lys - Gang turn on/off; put this text in value field: { state3 }
  • Device Action: Extrabryter - Gang turn on/off; put this text in value field: { state3 }

How it Works

The expression variables track the current state of each device. The conditions react to a change in the device state; since each condition is in its own group, the group state is the same as the condition state for each. When any switch state is changed, the activity for that group is run, and it sets the state of the other two switches to whatever the new state of the changed switch is. The { state1 } syntax in the action field means take the value to be sent to the device from the named expression/variable. That means the new state of the changed switch is sent to the other two switches.

Adjustment of the throttling limits may still be needed, as the running actions cause additional evaluations.

Note: for the expression/variable state1, I’ve done some extra work to look at the dimming level for status, because that’s what you did, but actually, you should still be able to look at SwitchPower1/Status just like the other two switches. If not, that’s a bug in the RFX plugin that should be fixed (it’s not updating status the way similar Vera Z-Wave devices would), IMO.


This is what my test rig looks like:

To conclude, considering that all conditions one goes through during the activities run, this particular use case can’t be simplified too much really. I ended up using some sequencing rules instead of your approach, and as far as i can see this setup wouldn’t have throttling issues…(?)

Edit: Rigpapa’s approach is more clean, but i wanted to avoid potential throttle issues, and for me(rookie), the logic is easier to read this way…

you see the “only after” conditions… It works well now.

This is the content of two separate reactors in the previous setup, so at least it is a bit tidier. :slight_smile:

The dimmer status issue is still there with the RFX plugin, but its easy to work around. It shows correctly in my imperihome panels, so it works as is.

One slighty annoying thing (OCD wise) is that in the top group in the shown setup, the 3 devices gets reordered after I press save. its supposed to be #285, #375, #130 in all groups… Not to keep you up all night, its no big issue. :wink:

Known issue that another user reported earlier, and I’m working with him on testing a fix.

1 Like

@rigpapa
I know this is an old thread m but trying to figure out something similar, but with 2 switches.

  1. Wall switch
  2. Appliance module

Essentially, I want to the wall switch and appliance module to be in sync. Note : I dont run Pleg and associations does not work

Here is what I have below , what am I doing wrong ?

I prefer to see Logic Summaries from the Tools page for things like this. It looks like you’re using a variable/expression, but you’re not showing that. The Logic Summary shows me everything in one text output, so more useful.

But that said, I can tell you what I would do, and it’s not far off from what I can see you’ve done:

Conditions:

  • Group “BedroomWallSwitch” (root) – AND operator
    • Device State Bedroom Wall Switch #264 Status “changes” (no operands–leave them blank)
      (no other conditions or groups)

Variable/expression:
SwitchState: getstate( 264, "urn:upnp-org:serviceId:SwitchPower1", "Status" )

Activities:

  • BedroomWallSwitch is TRUE
    • Device Action Bedroom Lights #107 Turn on/off value {SwitchState}

Theory of operation: The SwitchState variable is set up to retrieve the current state of the switch. This will be updated whenever the conditions are about to be evaluated. The device state condition with the “changes” operator will pulse briefly true whenever the state of the tested device changes, so a change of the switch state causes a variable update followed by a true pulse of the condition and therefore its parent group “BedroomWallSwitch”. That true pulse will cause the “BedroomWallSwitch is TRUE” action to run, which will set the Bedroom Lights device to whatever the Wall Switch state is.

That’s it. It is simply “If the switch changes, take the switch’s current state and set it on the appliance module.” There is no need to test the bedroom lights device directly in an additional group. There is no need for a “is FALSE” activity. The only time they would get out of sync is if there was a communication problem with one or the other device (and in that case, that is the problem to solve).

That pulse for the “changes” condition is really fast–faster than Vera’s UI refresh, so if you want, you can safely stretch out the pulse and make it visible in the Status tab by adding a “delay reset” of a few seconds (click the down-arrow on your Device State condition and you’ll find that option). Don’t make it too long, though, or the switch won’t respond to fast on-off/off-on changes. In fact, I recommend you remove the “delay reset” value once you’ve proven to yourself that you see the transition and it works. The faster the response the better.

Thanks a lot for the help… I implemented the logic , it’s working thus far, still testing , I got throttled due to a high change rate.

Right now it seems like the wall switch is the only trigger for the appliance module, I would like it to work both ways , as alexa has been the default controller before adding a wall switch, also in case reactor blows up :smile: I have a fall back

90% of the time a motion sensor turns on the light, which has a delay timer ( another awesome plugin by you) , that turns it off when no motion is detected. The wall switch comes in when it much easier to hit the switch on the way out of the room than issue a command via alexa , or wait till no motion is detected , saving myself 5min of electricity a day 5mins*365 =1825mins or 30hrs and 25 mins :nerd_face:

Add another condition group, another variable, another action…

Conditions:

  • Group “AppModuleChanges” – AND
    • Device State Bedroom Lights #107 “changes” (no operands)

Variable/Expression:
AppModuleState: getstate( 107, "urn:upnp-org:serviceId:SwitchPower1", "Status" )

Activities:

  • AppModuleChanges is TRUE
    • Device Action Bedroom Wall Switch #264 Turn on/off value {AppModuleState}

Works the same way. This will not ping-pong infinitely because once both devices are in the same state, there are no more changes conditions met.

© 2019 Vera Control Ltd., All Rights Reserved. Terms of Use | Privacy Policy