MQTT and profile=follow

I have a zwave wall switch and a magichome led controller flashed with tasmota fw. the wall switch does not power the led controller, it´s just to trigger an item in OH.
now I want to sync both power states with the profile=follow.

Switch Light_indirekt_LaraZimmer "indirekte Beleuchtung [MAP(OnOff.map):%s]" <light> (gLicht)       {channel="zwave:device:d7de781e:node30:switch_binary1", channel="mqtt:topic:myBroker:LaraZimmerLED:power"[profile="follow"] }
Switch LED_LaraZimmer "indirekte Beleuchtung [MAP(OnOff.map):%s]" <light> (gLicht)                  {channel="mqtt:topic:myBroker:LaraZimmerLED:power", channel="zwave:device:d7de781e:node30:switch_binary1"[profile="follow"] }

the mqtt thing for the led controller:

Type switch : power "indirekte Beleuchtung" [ commandTopic="cmnd/LED_LaraZimmer/POWER", stateTopic="stat/LED_LaraZimmer/POWER"]

both items are following each other BUT, my led controller logs continously reports the last sent command topic:

20:44:13 MQT: stat/LED_LaraZimmer/RESULT = {"POWER":"OFF"}
20:44:13 MQT: stat/LED_LaraZimmer/POWER = OFF
20:44:15 MQT: stat/LED_LaraZimmer/RESULT = {"POWER":"OFF"}
20:44:15 MQT: stat/LED_LaraZimmer/POWER = OFF
20:44:17 MQT: stat/LED_LaraZimmer/RESULT = {"POWER":"OFF"}
20:44:17 MQT: stat/LED_LaraZimmer/POWER = OFF
20:44:19 MQT: stat/LED_LaraZimmer/RESULT = {"POWER":"OFF"}
20:44:19 MQT: stat/LED_LaraZimmer/POWER = OFF
20:44:20 MQT: stat/LED_LaraZimmer/RESULT = {"POWER":"OFF"}
20:44:20 MQT: stat/LED_LaraZimmer/POWER = OFF
20:44:23 MQT: stat/LED_LaraZimmer/RESULT = {"POWER":"OFF"}
20:44:23 MQT: stat/LED_LaraZimmer/POWER = OFF

the problem is that if I try to toggle POWER from an OH rule or via the led controllers remote control, it often toggles back to the previous state. using MQTT explorer I can see that the cmnd/LED_LaraZimmer/POWER is repeatedly sent every 1,8 seconds. If I remove the stateTopic=“stat/LED_LaraZimmer/POWER” from the thing to this:

Type switch : power "indirekte Beleuchtung" [ commandTopic="cmnd/LED_LaraZimmer/POWER"]

the repeated cmnd stop but I loose knowledge about the power state of the item.

for me it seems like the follow profile jumps into a loop, sending a commandtopic, receiving a statetopic and again publishes the commandtopic and so on…
anybody had this issue already or can help to fix it?
(I`m on 2.5.0. release build, MQTT binding 2.5)

Because your Thing has both stat and cmnd defined.

“It takes state updates on an Item and sends them as a command onto the Channel. In the direction from the ThingHandler towards the Item, this Profile ignores state updates.

Create another channel in your Thing file, add the stat as separate switch item and see if that works.

tried to split cmnd and stat to two seperate items but after 1 day of playing around I gave up and use simple rules now…
came across a post that described the same symptom:

All of that is in the docs link and be sure to read the info to bottom of page. :wink:

@powerpolly if you need both items to follow each other, this feature is useless as it’s triggered over and over again.
Far better solution is to use Node-red outside of OH (so your switches are synced even OH is restarting or whatever) or ruleset in OH (which is unnecessary complicated for this kind of usage)

follow profile is quite nice idea, but as it is triggered by statusTopic and not cmndTopic, for certain devices (tasmota for example) it’s not usable

Well, the rule to do it is hardly complicated, without installing anything else.

rule "auto follow two switches"
when
   Item Light_indirekt_LaraZimmer changed or
   Item LED_LaraZimmer changed
then
   if (triggeringItem.state != Light_indirekt_LaraZimmer.state) {
      Light_indirekt_LaraZimmer.sendCommand(triggeringItem.state.toString)
   } else if  (triggeringItem.state != LED_LaraZimmer.state) {
     LED_LaraZimmer.sendCommand(triggeringItem.state.toString)
   }
end

It doesn’t get in a loop because unlike follow profile it acts on changes, not on simple updates.

you`re both right.
@rossko57 thats exactly the code I use now…
@kriznik I guess the best solution outside of OH would be MQTT itself, it should be possible with tasmota rules to send commands from one device to another. unfortunately my wall switch is a z-wave device without MQTT capability. on the other hand thats the strength of OH, to interconnect different protocols.

still not real solution (managing rules in tasmota is not very comfortable tho not to mention more than master mqtt topic), but as quick fix possible.

imagine you have a house with 15rooms which like 12 of those have 2way, some of them 3way switches
That’s why I have Node-red for this purpose. This allows me to have in OH only “master” switches (so i don’t need 40items just for lightswitches, but only 12). Ruleset for that in OH was simply not manageable, or in better words was quite fragile and slow. So all switches i need to are synchronized and OH is taking care only about automatisation and state of the master.
Slaves are following masters via node-red when slave/master is triggered manually (eg. you press wall switch) they follow each other and master propages that information to OH indeed and vice versa

1 Like

I was having the same issue and this cleaned up my rules significantly thanks to your code, since I didn’t know triggeredItem is a keyword. Thanks!

What I did for mine is I added all my Items to a group and if any item gets updated, then it propagates to the group. This makes it easier (to me at least) to keep adding devices in the future if I need.

rule "Auto Follow Office Lights and Switch"
when
   Item OfficeLightsZigbeeSwitch changed or
   Item OfficeSwitchToggle changed
then
   gOfficeLights.sendCommand(triggeringItem.state.toString)
end

Love to hear more about your node-red solution? Can you give me an overview of how you do it? where it runs etc?

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 :wink: )

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:

  1. room with several switches but operating one light (also called stairs switches)
  2. room with switch which can be told to operate light in connected room
  3. 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
opt1
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? … :wink:
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.

opt2

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

rbe

MQTT simply passing topics defined in the function
mqtt

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?

garden

all you need to do is to change two lines of code in function node… voala, wife happy :wink:

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 :slight_smile:

If you find this usefull, it was not waste of time! :slight_smile:
Cheers

Amazing!..we have very similar setups! I run OH on a Dell PowerEdge these days, but will be moving to docker in the near future. All my light switches are tasmota (DETA which is an Australian brand).

Trying to get rid of any loops with lights flicking on and off! I have several 2 and 3 way switches where only one of the switches is physically connected to the lights.

In scenario one, do you drop intermediate messages in the delay step? U assume the RBE step is just so you don’t possibly get multiple state messages without a change as well?

Thanks for the detail! it’s awesome. Is there a reason you use the MQTT node and not the OpenHAB2 node?

Thanks,
Paul

yes I drop intermediate messages in the limiter and yes rbe is just guarding tasmota’s state topics with same state already

RBE in that case is set to : "block unless value changes (ignore initial value)"
I found out that for single mqtt topic is ignoring initial value somehow better - let’s say safer in case system went off/reboot and in the meanwhile one of the switches changed their state.
It’s not very common case (but happened few times) that I have been restarting or/deploying node-red and someone pressed button.
Without ignoring initial value it ended up trying to catch each other, one was sending OFF, one ON and it was quite funny discoteque in the Hall :wink: (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 )
So this ensures RBE gets initialised FIRST without sending anything thru. and second press would work as expected.
Yes it has that downside that when button is pressed after restart of the nodered you have to press it twice to get right states everywhere.
It would be probably solvable by some function or something, but I’m lazy and this is acceptable discomfort :wink:

It’s because I do experiment with OH a lot (well now way less as everything is working perfectly) and when I do, MQTT would be offline - therefore nothing in house will be working, which is not acceptable.
That’s why i have standalone mqtt which is just always awailable and together with nodered I have always working “dumb” lights for everyone else in the house.

I do not like bundled solution just because of dependency on each other, while mqtt is very lightweight and stable so it does not need to be tighted with OH which get’s updates, restarts and so on, when needed :wink:

Cheers

Last question…I promise…for now :slight_smile: For scenario one can you show me the inputs to the mqtt in and out step? and also maybe the corresponding item definition on OH please?

Thanks,
Paul

surely
so Tasmota config has got SAME topic for each of these (4 of them), only thing I’m having different is a hostname (obviously) and Name (because of TasmoAdmin)
These are values for own compiled (stripped down) firmware based on tasmota 8.1.0

## LIGHT Hall Downstairs 00
    Backlog Module 10; Hostname iot-light-hallground-00; Topic home/light/hallground; FriendlyName1 Hall Downstairs; TelePeriod 0; SetOption1 1; SetOption13 0; SetOption40 5; ButtonDebounce 175; SetOption56 1; SetOption57 0; WifiConfig 0;

That’s it for Tasmota part

Then in OH i have only this in things

// HallDownstairs
Thing mqtt:topic:HallDownstairs_WSwitch "Light Hall Downstairs" (mqtt:broker:home) @ "Hall Downstairs" {
Channels:
    Type switch : switch        "Hall Light"           [ stateTopic="home/light/hallground/stat/POWER", commandTopic="home/light/hallground/cmnd/POWER", on="ON", off="OFF" ]
}

and items

// hall downstairs //
Switch      HallDown_WSwitch        "Hall Downstairs"   <light>         (gGFL, gWSwitch, gLightsHome, gLights, gStoreChange)        { channel="mqtt:topic:HallDownstairs_WSwitch:switch" }

That’s it for OpenHab part

Nodered is quite simple
mqtt

mqtt in node:
Topic: home/light/hallground/stat/POWER
Name: Hall ground

rbe node:
Mode: block unless value changes (ignore initial value)
Property: msg.payload

Delay node:
Action: Rate limit , All messages
Rate: 1msg per 1 second
drop intermediate messages : yes

mqtt out node:
Topic: home/light/hallground/cmnd/POWER
Name: CMND

ON/OFF is just inject node to home/light/hallground/stat/POWER with payload ON/OFF for testing

And that’s all… :wink:
Hope it hels!

Cheers

makes perfect sense…great…thats what I thought it would be. Thanks heaps!

Another question…I assume yours are all single switches?

I just realised, most of mine have at least 2 gang switches that control two seperate lights. So I can’t really have them pointing to the same MQTT queue…hmmmm

it still is usecase 1 you just need to make 2 flows which one will be listening to sometopic/stat/POWER1 and second to sometopic/stat/POWER2

or you’ll make bit more complex usecase 2 where you will combine it via function node as show in my previous post and you will have as many mqtt topics as you’ll need to work with

no biggie :wink:

I was still getting loops if I pressed one of the switches quickly in succession. or worse…if I drop messages, they can become out of sync. I am trialling the below for use case 1. It replaces delay with a trigger. I don’t even think I need the RBE any more. It seems to be working a little better…

Basically, the trigger says wait 250ms before sending the outbound command. If another message is received during the 250ms, then reset to time and start again…after the 250ms expires, send the latest message.

Hope that makes sense!

using OH reading is one layer of issues more than direct mqtt
because what is really happening is
button -> tasmota -> mqtt -> OH trigger -> MQTT -> tasmota -> broadcast status -> OH confirm change via status topic -> nodered informed
there can be delays indeed and in the meanwhile something else can change

I was experiencing with it, and besides fact that I would have like 40 different items just for switches, it was not working very well.

Try direct mqtt, everything will be just fine I guess