3-way switch with openHab 2.4 and Sonoff devices (using Tasmota)

I have several Sonoff devices with the Tasmota firmware installed in my home. Before OH version 2.4 I was using the mqtt binding to control all these devices.
I need a special configuration for my corridor lights because before replacing the light switches on this area with smart ones, it was using a 3-way circuit to allow turn on/off the lights using any of the light switches in the edges of the corridor (make sense right).

After I replaced those light switched with smart ones the additional wire to implement the 3-way circuit become useless. I used the following configuration for the Corridor Light “Item” to accomplish the same behavior:

# The multiline and indentation are not in the original configuration
# but improved the readability of the configuration in here.
# This configuration was perfectly valid in OpenHab v2.3
Switch Corridor_Light "Corridor lights" <light> (Corridor) ["Lighting"]  {

With the release of OH 2.4 I had to update the configuration of my devices to use OpenHab Things instead. After you learn how “Things” works it’s obvious that it was an improvement to the previous system. But I missed something. A simple way to “synchronize” the state of two Things with a single Item.

I solved the problem writing a Rule, but I could avoid noticed that the new MQTT Generic Thing Binding hastwo configuration parameters that could potentially avoid me to use Rules to achieve the same goal. These parameters are postCommand and trigger. Sadly they were poorly documented and, due to a bug in the release 2.4 that forces me to restart the server each time I change the parameters of a Thing, I didn’t have much time to dig in how to use these options.

Do any of you have the same problem? and how did you solved it?

Actually, what you probably want is the new follow Profile.

postCommand determines whether the incoming message received causes a command to the Item or an update. By default, the message is interpreted as an update and updates do not get forwarded to the bindings. I would have expected setting postCommand to true would have worked in this case, though there would be a slight short loop. I think if you link the Item to all of the channels with postCommand set to true that it might work. But there are all sorts of things that could cause problems.

The trigger property is a way to make the Channel be a trigger channel. Similar to the Astro binding, where Sunrise and Sunset events are created using a Channel Trigger, this lets you define a similar behavior with a Channel. A trigger Channel would not be linked to an Item and would be used to trigger a Rule directly. This is not going to be useful for this use case.

If you are using the new MQTT binding, you should be running 2.5 M1 instead of 2.4. There are some significant bugs in 2.4 that were fixed in 2.5 M1. There are additional bugs that have been fixed that will make you want to move to 2.5 M2 when it gets released.

Hi @rlkoshak
Thanks for the fast response.

I can’t use the follow profile because I have two switches that I want to be synchronized between each other.

The postCommand option (from the MQTT Generic Thing Binding) did nothing. But I didn’t restart the service after I set it to “true”. I upgraded to v2.5 M1 and I noticed that sometimes an mqtt topic channel does not update an item unless I restart the service (and no error is printed in the logs).

I will try again with postCommand later.

That’s what follow does. When one changes it sends the command to the other channels.

1 Like

Forum wouldn’t let me post a new topic with my new account, so I’m responding to this one on pretty much the same thing.

As far as I can tell, the follow profile does not work this way, unless I’m missing something.

I have two different TP-Link switches that I want to control one light fixture. One of them is hardwired to the fixture; the other isn’t wired to anything.

Just now I set them up in OpenHAB so that switch A (which is hardwired) uses the default profile, and switch B (not hardwired) uses the follow profile. When I turn either switch on using the OpenHAB control interface, the light switches on, and the same for turning them off. All good.

The problem is when I press switch B manually, or turn it on/off via the TP-Link Kasa app on my phone. In that case, the light fixture does not respond at all.

So I tried the reverse—I set up switch B to control the channel of switch A using the default profile, and set up switch A to follow switch B. Doing that, if I turn on switch B, then the fixture turns on. But if I turn it off via switch A, then it immediately turns back on again.

I just want to figure out how to have two switches mirror each other and both control the same fixture (wired to only one of the switches). Is it possible via the Paper UI, or should I use another method?

(And no, rewiring everything to use 3-way switches isn’t a practical option.)

Follow profile can’t be used (been there seen that recently) because it will create a loop.
It can be solved by several approaches:

1. in OH

rule "Switch A"
    Item Switch_A changed
    if(Switch_B.state != Switch_A.state) Switch_B.sendCommand(Switch_A.state.toString)
    //logInfo("Switch A", Switch_A.state.toString)


rule "Switch B"
    Item Switch_B changed
    if(Switch_B.state != Switch_A.state) Switch_A.sendCommand(Switch_B.state.toString)
    //logInfo("Switch B", Switch_B.state.toString)

Simple rule, but you are reusing quite a bit of same code for every switch here and there

2. Node red (using OH node) and group topic in Tasmota

[{"id":"c4a5544a.56c7e8","type":"mqtt out","z":"591acf63.f864a","name":"qqq","topic":"testswitch/cmnd/POWER","qos":"","retain":"","broker":"83323ac5.ab4df8","x":310,"y":500,"wires":[]},{"id":"c821fbee.b17468","type":"openhab2-in","z":"591acf63.f864a","name":"A","controller":"1a82237b.8ca69d","itemname":"Switch_TA","x":120,"y":460,"wires":[[],["c4a5544a.56c7e8"]]},{"id":"676af932.7ef478","type":"openhab2-in","z":"591acf63.f864a","name":"B","controller":"1a82237b.8ca69d","itemname":"Switch_TB","x":120,"y":540,"wires":[[],["c4a5544a.56c7e8"]]},{"id":"83323ac5.ab4df8","type":"mqtt-broker","z":"","name":"MQTT","broker":"IP","port":"1883","clientid":"","usetls":false,"compatmode":true,"keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","closeTopic":"","closeQos":"0","closePayload":"","willTopic":"","willQos":"0","willPayload":""},{"id":"1a82237b.8ca69d","type":"openhab2-controller","z":"","name":"OH","protocol":"http","host":"localhost","port":"8080","path":"","username":"","password":""}]

This needs bit of love as it causes mqtt spam, so more check on states needed.

3. only Node red without OH/HA etc.

[{"id":"a7769c75.cda58","type":"mqtt in","z":"9d128c8a.994b5","name":"Switch 08","topic":"sonoff-touch-08/stat/POWER","qos":"0","datatype":"utf8","broker":"83323ac5.ab4df8","x":300,"y":4120,"wires":[["134b5b18.61d3e5","88b82873.07df98"]]},{"id":"3a4af89a.3d3d48","type":"mqtt in","z":"9d128c8a.994b5","name":"Switch 09","topic":"sonoff-touch-09/stat/POWER","qos":"0","datatype":"utf8","broker":"83323ac5.ab4df8","x":300,"y":4220,"wires":[["88b82873.07df98","134b5b18.61d3e5"]]},{"id":"a2bb607f.6bd8a","type":"change","z":"9d128c8a.994b5","name":"08","rules":[{"t":"set","p":"status08","pt":"flow","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":690,"y":4120,"wires":[[]]},{"id":"134b5b18.61d3e5","type":"switch","z":"9d128c8a.994b5","name":"08s","property":"payload","propertyType":"msg","rules":[{"t":"eq","v":"status08","vt":"flow"},{"t":"neq","v":"status08","vt":"flow"}],"checkall":"true","repair":false,"outputs":2,"x":510,"y":4120,"wires":[["a2bb607f.6bd8a"],["a2bb607f.6bd8a","48747ed4.c73b2"]]},{"id":"88b82873.07df98","type":"switch","z":"9d128c8a.994b5","name":"09s","property":"payload","propertyType":"msg","rules":[{"t":"eq","v":"status09","vt":"flow"},{"t":"neq","v":"status09","vt":"flow"}],"checkall":"true","repair":false,"outputs":2,"x":510,"y":4220,"wires":[["aacb9062.c6922"],["aacb9062.c6922","27d97c2.8192d84"]]},{"id":"aacb9062.c6922","type":"change","z":"9d128c8a.994b5","name":"09","rules":[{"t":"set","p":"status09","pt":"flow","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":690,"y":4220,"wires":[[]]},{"id":"48747ed4.c73b2","type":"mqtt out","z":"9d128c8a.994b5","name":"to the 08","topic":"sonoff-touch-08/cmnd/POWER","qos":"","retain":"","broker":"83323ac5.ab4df8","x":700,"y":4160,"wires":[]},{"id":"27d97c2.8192d84","type":"mqtt out","z":"9d128c8a.994b5","name":"to the 09","topic":"sonoff-touch-09/cmnd/POWER","qos":"","retain":"","broker":"83323ac5.ab4df8","x":700,"y":4260,"wires":[]},{"id":"83323ac5.ab4df8","type":"mqtt-broker","z":"","name":"MQTT","broker":"IP","port":"1883","clientid":"","usetls":false,"compatmode":true,"keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","closeTopic":"","closeQos":"0","closePayload":"","willTopic":"","willQos":"0","willPayload":""}]

This is my prefered solution for now, as it is completely independend on OH or whatever automatization system you are using => so your switches will be working even when OH is taking a break, restarting etc.
And because it’s using purely mqtt it’s quite reliable in terms of responses.

  • your tasmota group topic can be used for updates as it’s not used in here
1 Like

Oh boy. Things have changed a lot since I last used OpenHAB over two years ago. The first suggestion I understand; it’s straightforward. Node.red looks a lot less user-friendly in the scripting!

nodered is super user friendly, you just need to import these jsons to actual nodered gui :slight_smile: