no probs (btw follow profile is still the same … useless for tasmota devices)
So little bit about my setup:
OH is running in docker on NAS (indeed under ups) alongside with grafana, influx, mqtt and other stuff
several rpi’s around the house, but two “important” are running node-red, one is inhouse running Pi-hole DNS, second is at the garden.
All light switches are Sonoff with custom Tasmota firmware (1gang, 2gang, 3gang) and I’ve rewired physical connection to the light in the way there is always only ONE switch which operates the light and rest are dummy - eg. connected to power but not to the light itself. (no need to rebuild the house to do it 
)
side note: I do have node-red on rpi rather than nas because of history as well because i do like to use what is always on - as nodered on rpi is doing variety of stuff, lights have been another logical task.
Let’s talk about the solution:
There are two(three) main usecase in my environment:
- room with several switches but operating one light (also called stairs switches)
- room with switch which can be told to operate light in connected room
- switch which could be programmed to do whatever, like turning on garden etc.
1 case is not really hard, this is mainly solvable by the same mqtt topic which switches are subscribed to
node-red : in this case it’s just a policemen and blocks all messagess unless state is changed + limits 1/s
why? because tasmota broadcasting STATE which would trigger another switch ON, and ON and ON … and it would loop self. Limit + Block is a MUST
Ground hall has got 4switches which only one is connected directly to the light by wires.
In OH I do have defined only ONE item in the Ground Hall does not matter really which one, to trigger the lights, rest is taken care by the node-red - eg. all switches are turned on/off
2 case
This is more complicated version of case 1, because we do have switches in different places which can operate same lights and also operates “own” lights.
For example I have Entrance Hall with 3gang switch :
1: is for Entrance hall itself, which also have another 1gang operating that light from different spot
2: is for connected staircase
3: is for Upstairs hall
then I do have separate staircase switch and upstairs I do have another 3gang which operates Entrance Hall, Staircase and Upsatirs hall which also have another switches.
This setup leads to four different mqtt topics because of four diferent groups of switches. (entrance hall, entrance hall side switches, staircase, upstairs hall). with five different kind of buttons (entrance, staircase, upstairs from entrance, entrance from upstairs, upstairs)
side note:
In this case, rules purely in OH would require insane amount of work and would be impossible to maintain as well as different Tasmota topics for each switch location. Tasmota can have different topics on one switch, but tasmota console management is pain … so to keep it simple I’m using default behaviour when one mqtt topic is used per device and buttons are identified by POWER1 POWER2 POWER3
node-red in this case we need to have five (shown second node with three) mqtt topic’s IN, then function which calls other two topics when one was triggered and broadcast that information to coresponding topics. I can’t imagine simpliest way how to manage this. These two flows manages in total 9 physical switches with five different topics… (looks quite easy hm? …
why? because of default tasmota firmare there is need to have different topics for different areas and/or purposes. I do have entrancehallslave and entrancehall just because entrancehall/POWER does not exist on 3gang switch, it’s entrance/POWER1,2,3 but single switches does have topic/POWER instead, it was bit easier to manage than making rule which combines POWER1 to POWER etc.
flow reads mqtt status topics for given area, then function node creates CMND topics, rbe ensures that nothing else than CHANGED status is passed thru and finaly cmnd topics are sent to mqtt
ra = { topic: "home/light/entrance/cmnd/POWER2", payload: msg.payload };
rb = { topic: "home/light/entranceslave/cmnd/POWER", payload: msg.payload };
rc = { topic: "home/light/hallfloor/cmnd/POWER3", payload: msg.payload };
return [[ra,rb,rc]];
RBE is configured as block unless changes
MQTT simply passing topics defined in the function
This is variable solution, if there will be anothe area/switch, I simply add another source mqtt, another line to the function node and everything will be synced.
In OH again there is need only to define ONE item per area to trigger mqtt chain.
// hall upstairs + staircase + entrance //
Switch HallUp_WSwitch "Hall Upstairs" <light> (gFFL, gWSwitch, gLightsHome, gLights, gStoreChange) { channel="mqtt:topic:HallUpstairs_WSwitch:hall" }
Switch Staircase_WSwitch "Staircase" <light> (gGFL, gFFL, gWSwitch, gLightsHome, gLights, gStoreChange) { channel="mqtt:topic:HallUpstairs_WSwitch:stairs" }
// entrance //
Switch Entrance_WSwitch "Entrance Hall" <light> (gGFL, gWSwitch, gLightsHome, gLights, gStoreChange) { channel="mqtt:topic:Entrance_WSwitch:entrance" }
These three items operates every single swtich thanks to node-red, and of course as well when it’s physically touched, OH gets updated thanks to these and mqtt. Every coresponding switch button is lighten up when state is changed, so userexperience is as expected when you turn on light on one point you want to turn it off on another so that switch has to be “ON” already.
case 3 : it’s basically case 2, but let’s leave it here separetely. In previous cases it was about switching areas which are connected or are just big rooms with many switches in it.
But you can be way more creative. For example change 1gang switch to 2gang and use second button for anything. You don’t need to rewire entire house. So, why not to take porch swich which leads to the garden and why not to expand it to swhich which lights up the garden as well?
all you need to do is to change two lines of code in function node… voala, wife happy
ra = { topic: "home/light/porch/cmnd/POWER2", payload: msg.payload };
rb = { topic: "garden/lights/main/cmd", payload: msg.payload };
return [[ra,rb]];
All you need to do is to map “dummy” button to the node-red to trigger garden which is operated by rpi at the garden via gpio and relays
That’s why I have node-red at garden rpi as well, as it is picking up mqtt and doing some magics as well as measuring water, air, etc.
And world of possibilities is not at the end, then we can utilize OH rules for motion, luminiscence, presence to combine everything … but what you can be entirely sure about is, ALL switches will be in their right state no matter what rules will do.
Managing this in OH directly is (at least for me) absolutely unthinkable, but who knows maybe I’m doing it wrong 
If you find this usefull, it was not waste of time!
Cheers
(that’s also why I’ve introduced 1/s limit, because nobody in real life needs to switch lights on/off faster than that, but in case of loop you’ll not be looping ever 0.3s )
