Use RNX to make 2 sonoff be a hotel switch

[cybe...@gmail.com]

Hello all

I am trying to get two sonoff to switch simultaneously.

But am having no success. Tried several variants, and they all did not work.

Any tips/hints/improvements welcome.

So the base premise:

Two Sonoff devices with lights and buttons attached.

If I press one button, the local light should go on as well as the remote light

I also should be able to turn on the lights using a single "virtual button" on my phone

I wish to do this with KNX, not with a MQTT broker or something in-between

Method 1:

Both devices configured to send Button1 to 2/2/1

Both devices configured to receive 2/2/1 to Output1

Result : The ON action is duplicated, but the OFF action is not.

Also, if I use a phone app or webpage to toggle, it is only working on the local device.

Method 2:

Both configured to send Output1 to 2/2/1

Both configured to receive 2/2/1 to Output1

Communication enhancement active

Result : It works at first, but after clicking a few more times, it starts to loop on and off all by itself, faster and faster, and eventually all wifi breaks down, due to ever more broadcasts.

Method 3:

Both configured to send Output1 to 2/2/1

Both configured to receive 2/2/1 to Output1

Communication enhancement *not* active

Result : It works, but sometimes a packet is lost and the other light does not switch. Quite often in fact.

But at least there seems to not be any looping.

Method 4:

Both configured to send RNX TX1 to 2/2/1

Both configured to receive 2/2/1 to Output1

Made a rule to send 1 or 0, but only if the value actually changes. So a resend of a toggle would not happen.

Result : turns out the KNX_TX is always send as 2-decimal number, so not interpreted as ON/OFF by the other device (see log)

Rule

rule1 
on system#boot do var1 0 endon 
on Power1#State>%var1% do backlog var1 %value%; knxtx_val1 %var1% endon 
on Power1#State<%var1% do backlog var1 %value%; knxtx_val1 %var1% endon

Log

21:36:32 RUL: POWER1#STATE<%VAR1% performs "backlog var1 0; knxtx_val1 0"
21:36:32 RSL: RESULT = {"Var1":"0"}
21:36:32 KNX: KNX TX 1 = 0.00 sent to 2.2.1
21:36:32 RSL: RESULT = {"KnxTx_Val1":"0.00"}
21:36:37 RSL: RESULT = {"POWER":"ON"}
21:36:37 RSL: POWER = ON
21:36:37 RUL: POWER1#STATE>%VAR1% performs "backlog var1 1; knxtx_val1 1"
21:36:38 RSL: RESULT = {"Var1":"1"}
21:36:38 KNX: KNX TX 1 = 1.00 sent to 2.2.1
21:36:38 RSL: RESULT = {"KnxTx_Val1":"1.00"}

Anyone with a good idea on this?

I think the latter warrants 2 enhancement requests, but I am a newbee and do not want to submit a enhancement till I know for sure I am not doing something wrong.

Enhancement 1:

Allow for  Power1#State!%var1% (! = not equal) in the list =; >; < (equal, greater, smaller)

Enhancement 2:

Allow for "knxtx_val1 1" to be send as single digit 1 rather then 1.00, so RNX can be used as ON/OFF

Or some other method to send the ON/OFF/TOGGLE using the KNX_TX1 mechanism.

[Philip Knowles]

Have you tried using an HTTP Post? I suspect that they are fighting each other and you may need o make one a master and the other a slave. Sonoff 2 only sends the button change to Sonoff 1 which then sends the command back to Sonoff 2. This should also resolve the webpage control issue.

I’ll experiment later this morning and get back to you.

Regards

Phil K

 

Sent from my Windows 10 device

 

From: cybe...@gmail.com
Sent: 01 December 2018 20:51
To: SonoffUsers
Subject: Use RNX to make 2 sonoff be a hotel switch

 

Hello all

 

I am trying to get two sonoff to switch simultaneously.

But am having no success. Tried several variants, and they all did not work.

Any tips/hints/improvements welcome.

 

 

So the base premise:

 

Two Sonoff devices with lights and buttons attached.

If I press one button, the local light should go on as well as the remote light

I also should be able to turn on the lights using a single "virtual button" on my phone

I wish to do this with RNX, not with a MQTT broker or something in-between

 

 

 

Method 1:

Both devices configured to send Button1 to 2/2/1

Both devices configured to receive 2/2/1 to Output1

Result : The ON action is duplicated, but the OFF action is not.

Also, if I use a phone app or webpage to toggle, it is only working on the local device.

 

 

Method 2:

Both configured to send Output1 to 2/2/1

Both configured to receive 2/2/1 to Output1

Communication enhancement active

Result : It works at first, but after clicking a few more times, it starts to loop on and off all by itself, faster and faster, and eventually all wifi breaks down, due to ever more broadcasts.

 

 

Method 3:

Both configured to send Output1 to 2/2/1

Both configured to receive 2/2/1 to Output1

Communication enhancement *not* active

Result : It works, but sometimes a packet is lost and the other light does not switch. Quite often in fact.

But at least there seems to not be any looping.

 

 

Method 4:

Both configured to send RNX TX1 to 2/2/1

Both configured to receive 2/2/1 to Output1

Made a rule to send 1 or 0, but only if the value actually changes. So a resend of a toggle would not happen.

Result : turns out the RNX_TX is always send as 2-decimal number, so not interpreted as ON/OFF by the other device (see log)

 

Rule

rule1 
on system#boot do var1 0 endon 
on Power1#State>%var1% do backlog var1 %value%; knxtx_val1 %var1% endon 
on Power1#State<%var1% do backlog var1 %value%; knxtx_val1 %var1% endon

 

Log

21:36:32 RUL: POWER1#STATE<%VAR1% performs "backlog var1 0; knxtx_val1 0"
21:36:32 RSL: RESULT = {"Var1":"0"}
21:36:32 KNX: KNX TX 1 = 0.00 sent to 2.2.1
21:36:32 RSL: RESULT = {"KnxTx_Val1":"0.00"}
21:36:37 RSL: RESULT = {"POWER":"ON"}
21:36:37 RSL: POWER = ON
21:36:37 RUL: POWER1#STATE>%VAR1% performs "backlog var1 1; knxtx_val1 1"
21:36:38 RSL: RESULT = {"Var1":"1"}
21:36:38 KNX: KNX TX 1 = 1.00 sent to 2.2.1
21:36:38 RSL: RESULT = {"KnxTx_Val1":"1.00"}

 

 

 

Anyone with a good idea on this?

I think the latter warrants 2 enhancement requests, but I am a newbee and do not want to submit a enhancement till I know for sure I am not doing something wrong.

 

 

Enhancement 1:

Allow for  Power1#State!%var1% (! = not equal) in the list =; >; < (equal, greater, smaller)

 

Enhancement 2:

Allow for "knxtx_val1 1" to be send as single digit 1 rather then 1.00, so RNX can be used as ON/OFF

Or some other method to send the ON/OFF/TOGGLE using the KNX_TX1 mechanism.

 

 

 

 

 

 

 

--
You received this message because you are subscribed to the Google Groups "SonoffUsers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonoffusers...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

 

[cybe...@gmail.com]

Using HTTP instead of KNX may work, but I was just happy about discovering the KNX protocol.

I still believe it should work, possibly just some issues to be resolved. 

My reluctance a single master and switching local by bouncing a command to that master is that it violates my core design principle: Core functionality must work even when network or intermediate servers are down.

Or to put it simple: If I press a button to turn on the light, the light should come on.

Hence my reluctance for MQTT. It is a good protocol to have my central RasPi communicate the somewhat more advanced features and orders, like lights scheduled etc, impressing friends by using my phone to turn on the light (not that they are really impressed). But when the WiFi or RasPi is hanging, being upgraded, etc, the light in the hallway should still come on locally, even if maybe the one at the top is temporary not following.

(Also, bouncing a command over the network gives just this small response delay that I dislike)

So, while I agree HTTP and MQTT could work, I want to focus on making this work with KNX, HTTP only as last resort (but no single master)

[Philip Knowles]

OK but I think that you need to have the Sonoff to toggle on the button (which is standard behaviour). Then have a rule which tells the other device to change when it changes state -

on Power1#state=1 do http://192.168.0.x/cm?cmd=Power1%201 endon

and

on Power1#state=0 do http://192.168.0.x/cm?cmd=Power1%200 endon

You'll get a bounce back from the remote device when it changes state telling the local device to switch on or off - as a ex-control engineer I dislike that. You can replace the http with your protocol. I've not had a chance to test it but it should work. For the web and app interface I would just talk to one of them and rely on the other following.

Regards

Phil K

On Sun, 2 Dec 2018, 08:20 , <cybe...@gmail.com> wrote:

Using HTTP instead of RNX may work, but I was just happy about discovering the RNX protocol.

I still believe it should work, possibly just some issues to be resolved. 

My reluctance a single master and switching local by bouncing a command to that master is that it violates my core design principle: Core functionality must work even when network or intermediate servers are down.

Or to put it simple: If I press a button to turn on the light, the light should come on.

Hence my reluctance for MQTT. It is a good protocol to have my central RasPi communicate the somewhat more advanced features and orders, like lights scheduled etc, impressing friends by using my phone to turn on the light (not that they are really impressed). But when the WiFi or RasPi is hanging, being upgraded, etc, the light in the hallway should still come on locally, even if maybe the one at the top is temporary not following.

(Also, bouncing a command over the network gives just this small response delay that I dislike)

So, while I agree HTTP and MQTT could work, I want to focus on making this work with RNX, HTTP only as last resort (but no single master)

--
You received this message because you are subscribed to the Google Groups "SonoffUsers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonoffusers...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

On 2 Dec 2018 8:20 am, <cybe...@gmail.com> wrote:

Using HTTP instead of RNX may work, but I was just happy about discovering the RNX protocol.

I still believe it should work, possibly just some issues to be resolved. 

My reluctance a single master and switching local by bouncing a command to that master is that it violates my core design principle: Core functionality must work even when network or intermediate servers are down.

Or to put it simple: If I press a button to turn on the light, the light should come on.

Hence my reluctance for MQTT. It is a good protocol to have my central RasPi communicate the somewhat more advanced features and orders, like lights scheduled etc, impressing friends by using my phone to turn on the light (not that they are really impressed). But when the WiFi or RasPi is hanging, being upgraded, etc, the light in the hallway should still come on locally, even if maybe the one at the top is temporary not following.

(Also, bouncing a command over the network gives just this small response delay that I dislike)

So, while I agree HTTP and MQTT could work, I want to focus on making this work with RNX, HTTP only as last resort (but no single master)

[Philip Knowles]

That will teach me to do something without checking. This rule works

Rule1 on power1#state=1 do websend [192.168.0.x] power1 1 endon on power1#state=0 do websend [192.168.0.x] power1 0 endon

Regards

Phil K

[cybe...@gmail.com]

Yes, correct, that is the exact principle that I am trying to build in KNX instead of MQTT or HTTP

And it works with HTTP (slight mod to your example syntax below)

But KNX seems to have some issues preventing it from working, as noted above. So if anyone has some ideas on what I am doing wrong in KNX (I am very new to KNX), or if maybe they are really implementation issues in KNX that need to be fixed, it would be good to know.

Working HTTP rules on either device:

 

rule1 
on Power1#state=1 do websend [192.168.x.x] Power1 On endon 
on Power1#state=0 do websend [192.168.x.x] Power1 Off endon

 

rule1 
on Power1#state=1 do websend [192.168.y.y] Power1 On endon
on Power1#state=0 do websend [192.168.y.y] Power1 Off endon

BTW: one more issue is with HTTP you need to hardcode different IP's on each device. The hotel switch was but an example, in my case they will be 7 light points along a hallway.

So putting in 7 different IP's in 7 different combinations, not nice. Another nice thing about the KNX group broadcast.

[cybe...@gmail.com]

Well, we seem to have had crossed emails.

And I do appreciate your help, while I can do the HTTP, it is sometimes good to be pointed out alternate solutions to avoid narrow thinking.

But still, lets stick to KNX, as suggested in the original question.

[Philip Knowles]

The RNX examples at https://github.com/arendst/Sonoff-Tasmota/wiki/KNX-Features seem to be doing what you want so it should work. I use openHAB so I can use MQTT group messages and/or Google Home Hub to achieve it so good luck with RNX - I can see a lot of advantages.

The websend was almost instantaneous so that impressed me. It would be good if you could somehow use the MQTT friendly name/group in a websend.

Regards

Phil

On Sun, 2 Dec 2018, 10:27 , <cybe...@gmail.com> wrote:

Well, we seem to have had crossed emails.

And I do appreciate your help, while I can do the HTTP, it is sometimes good to be pointed out alternate solutions to avoid narrow thinking.

But still, lets stick to RNX, as suggested in the original question.

--
You received this message because you are subscribed to the Google Groups "SonoffUsers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonoffusers...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

On 2 Dec 2018 10:27 am, <cybe...@gmail.com> wrote:

Well, we seem to have had crossed emails.

And I do appreciate your help, while I can do the HTTP, it is sometimes good to be pointed out alternate solutions to avoid narrow thinking.

But still, lets stick to RNX, as suggested in the original question.