[SOLVED] Multiple things linked to a single item - How to make this work

rules or nodered
some devices does not broadcast their state changed by button press as regular cmnd so you have to make sure OH knows what’s happening when it’s changing outside of OH.

search for 2way switch rules, that’s what you are basically looking for - same principle

tl;dr: you can’t use follow profile to follow both devices each other, it’s looping (especially with tasmota, because follow profiles reacts to the state topic)

1 Like

Sorry for being unclear, it was late. The iFan has 2 channels, one for the light and one for the fan, and the zooz only one. For this I am just controlling the light channel on the ifan and not the other, that will come later.

I am configuring everything in the PaperUI, so there are no item files I can post.

By Webui I mean the built in tasmota WebUi on the ifan it’self.

By toggle in openhab I mean with the control section of the PaperUI or a Habpanel .

My goal is to have these things work in sync and update each other. So it should not matter which of the three options you use to turn the light on or off, they should toggles the light and update the status for all of them.

So am I seriously the first person to run into this? Is my use case really that unique? All I want to do is control the iFan light channel with both openHAB (control section in PaperUI and/or a widget on the habPanel) and a smart switch, and have them work together not against each other.

I fail to see why this would not simply work that way when I linked the “thing” to the second channel. But if I have to write a rule, then I can do that, but I’ve no idea where even start with that.

Of course not. Generally you’ll find discussions under two-way switching.

You’ve given no detail about what you have actually done,so there’ll be no specific “change that” answers.

This thread has fairly extensive exploring of both rules based and follow profile based solutions.


Later on in that thread you will find an outline of why cross-linking two Items, each with two channel links,one of which is profiled ‘follow’, can end in tears. But it is device specific, it depends what the devices respond with when commanded.

1 Like

@Lutiana you misunderstand this forum. It is not a HelpDesk dispensing solutions.

This is a community of volunteer users to help you solve your problems. In order to do that we need to know what you have already tried so we have something on which to base the help.

1 Like

No, I get that, and you are completely correct that this has not come across in my posts here. This has just been a bit frustrating and feeling like there is no solution. I will endeavour to keep such frustrations in check.

1 Like

You are correct, I thought I had, but reading my posts again I can see what you mean.

My goal here is to have the ceiling fan in the room controlled via a traditional-esk switch on the wall and via the widgets on a habpanel, with the relevant status being accurately represented on both the habpanel and the physical wall switch/dimmer.

Ok, so I got an iFan03, flashed it with tasmota and setup the MQTT connection.

Via PaperUI I added it as a “Thing”

Master Bedroom - iFan03 (mqtt:topic:9a97613b)

Two channels were create:

Master Bedroom Light (mqtt:topic:9a97613b:MB-Light)
MQTT State Topic: stat/ifan03-mb/POWER1
MQTT Command Topic: cmnd/ifan03-mb/POWER1

and

Master Bedroom Fan (mqtt:topic:9a97613b:MB-Fan)
MQTT State Topic: stat/ifan03-mb/POWER1
MQTT Command Topic: cmnd/ifan03-mb/POWER1
Transformation Value: JSONPATH:$.FanSpeed

I then created linked items:

Master Bedroom Light (MasterBedroom_Light)
Type Switch, default profile

and

Master Bedroom Fan (MasterBedroom_Fan)
Type Number, default profile

This worked well, I was able to control both the fan and light from the Control Section in PaperUI and from widgets I added to a habpanel.

The next step was to get the wall switch working to control the just the light (I have not yet decided on what I want to use to control the fan speed). So I grabbed the Z-Wave Zooz switch I had. It is a simple on and off switch with an LED on it that lights up when it’s off, and goes out when it’s on (and you can hear the relay click when it changes state, but this setup won’t use the relay).

I paired the Zooz switch with OpenHab, again via the PaperUI. This created a new “Thing”

Z-Wave Plus S2 ON/OFF Switch (zwave:device:5426e5af:node3)

and this created a new channel:

Switch (zwave:device:5426e5af:node3:switch_binary)

I then linked this new “Thing” to the “Item” Master Bedroom Light (MasterBedroom_Light) with the default profile and tested it. Toggling the Zooz switch would change the little slider on the control page in the PaperUI, and even change the icon on the habpanel, but it would not actually toggle the light on the iFan03. If I tapped the widget in the habpanel, the ifan03 light would toggle as would the Zooz switch and lastly if I toggled the iFan03 light in the Tasmota WebUI, the hapPanel would update, but the Zooz switch would not. And this is where I am completely stumped, though I have not reviewed the info linked about 2 way switches yet (will do that tonight).

Other possible relevant info:
Openhabian on a Raspberry Pi3, completely up to date.
Mosquitto MQTT server.
Everything done via the PaperUI

Thanks!

1 Like

Thank you.
Many people seem to come here feeling entitled and it is sometimes difficult to weed them out.

1 Like

Yes. The normal flow of events is that Item commands originating in UI or rules are passed via bindings to devices.
Status changes originating in devices are passed via bindings to Items as state updates.

So when you poke the Zooz, openHAB is informed - but no command, no passing to device .

If you only wanted the fan to obey Zooz commands, that would be easy. Using a follow profile on the Zooz channel, that magics incoming status into an openHAB command. Which would go out on the MQTT channel and work the light…

But the missing link there is feeding anyone else’s light command to the Zooz (to use the indicator).
You might think you could just add an ordinary non-follow zwave channel to the same Light Item, to pass any light commands to both MQTT and Zooz.
Problem: I would think you’ve got this set up so that Zooz reports state after command.

You would make a loop - command prompts update from Zooz, the follow profile converts update to command, round we go again.
The underlying problem is that none of the links in the loop are clever enough
to only react to changes rather than same-as-before updates.

I think you need to represent your two devices in openHAB as two separate Items, with ordinary channels. We’re going to make them follow each other, so only one of them need go in your sitemap or get commanded by rules.

Don’t try to cross-link those Items using follow profile - you would need to do both and arrive back at the loop.

Use a rule as outlined in the linked thread. That can be smart enough to only act upon changes.

Very recent thread covering the same ground

So add an item “MasterBedroom_Light_Zooz” linked to the Zooz switch channel and in /etc/openhab2/rules create `MB_Light.rule" with:

rule "master bedroom light switches"
when
   Item MasterBedroom_Light changed or
   Item MasterBedroom_Light_Zooz changed
then
   if (triggeringItem.state != MasterBedroom_Light.state) {
     MasterBedroom_Light.sendCommand(triggeringItem.state.toString)
   } else if  (triggeringItem.state != MasterBedroom_Light_Zooz.state) {
     MasterBedroom_Light_Zooz.sendCommand(triggeringItem.state.toString)
   }
end

Also, just to make sure I understand the process of writing and enabling rule.

  1. Create .rule file in /etc/openhab2/rules with nano.
  2. Save it, making sure the file is openhab:openhab with -rw-rw-r-- (664) permissions?
  3. Restart openhab, or will the rule immediately be useable?

Shortly after saving a file xxx.rules in the appropriate folder after edit/creation, openHAB is watching and will load the file. A load message or error will be reported in openhab.log If the rules file loaded successfully, rules are immediately active.

1 Like

Thanks! The rule definitely seems to have helped, however it is not working as expected.

The zooz switch works, turns the light on and off. But if I turn the light on via the iFan03 Webgui or the habPanel it works. However if I turn the light off from either the iFan03 WebGui, the HabPanel or the control section in the PaperUI it turns off, but then immediately turns back on.

I went through the settings for all the things and items to make sure they are using the default profile and items are tied to the correct channels etc, and it all looked right.

The event log shows me this:

2020-02-04 15:50:37.536 [vent.ItemStateChangedEvent] - MasterBedroom_Light changed from ON to OFF
2020-02-04 15:50:37.553 [ome.event.ItemCommandEvent] - Item 'MasterBedroom_Light_Zooz' received command OFF
2020-02-04 15:50:37.585 [nt.ItemStatePredictedEvent] - MasterBedroom_Light_Zooz predicted to become OFF
2020-02-04 15:50:37.608 [GroupItemStateChangedEvent] - gLight changed from ON to OFF through MasterBedroom_Light_Zooz
2020-02-04 15:50:37.613 [vent.ItemStateChangedEvent] - MasterBedroom_Light_Zooz changed from ON to OFF

2020-02-04 15:50:39.166 [vent.ItemStateChangedEvent] - MasterBedroom_Light_Zooz changed from OFF to ON
2020-02-04 15:50:39.171 [GroupItemStateChangedEvent] - gLight changed from OFF to ON through MasterBedroom_Light_Zooz
2020-02-04 15:50:39.185 [ome.event.ItemCommandEvent] - Item 'MasterBedroom_Light' received command ON
2020-02-04 15:50:39.208 [nt.ItemStatePredictedEvent] - MasterBedroom_Light predicted to become ON
2020-02-04 15:50:39.236 [vent.ItemStateChangedEvent] - MasterBedroom_Light changed from OFF to ON

The events after the line break are not generated from a button press on the zooz, even though it seems to imply that it is. The interesting thing is that the off indicator on the zooz remains light and the relay does not click. So I have no idea where openHab is getting that command from.

It’s not a command, the second “event”. It’s a status report from the Zooz.
If it says it’s OFF, then the mechanism you have put in place to have the fan-light follow will do it’s thing.

This is going to be a thing about zwave, most zwave devices do not respond by default to being sent a command. The binding includes an option to explicitly poll for status shortly after sending a command. That “shortly” often needs tweaking to avoid getting an “old” pre-command status.

It shows up as a change in openHAB because of the action of autoupdate - this is the prediction you see in your logs, which is based on commands.
Autoupdate sets Item state to OFF very quickly. A while later the Zooz pops up and reports old ON, then the binding updates Item back to ON. The rapid change sets your mirroring rule in motion again.

A circumvention to avoid the change is to disable autoupdate on these Items. This degrades the UI performance because state updates now rely on devices reporting, which takes time,
The real fix is to get a timely but updated status from the Zooz.

The command poll period is 1500, thought it’s not clear what units that is.

Right, that makes sense, but how do I do that exactly? And why does this only happen when I turn the light off, and not when I turn it on?

I don’t know anything about your Zooz, can only show what happens in openHAB.

If I disable the update, then I the Zooz no longer turns the light on or off. So I put the 1500 back into the `Command Poll Period’ and it still does not work anymore.

I can see the MasterBedroom_Light_Zooz being updated when I toggle the Zooz, but it no longer updates the other item.

So this setting would be set on the Z-Wave device and not in openHab? Then what is the Command Poll Period used for?

I guess you mean autoupdate.
That suggests your Zooz just isn’t reporting to the Item correctly, whether that’s misconfiguration or misunderstanding of OH or device settings.
Uncouple it from the rule for now by removing the trigger, concentrate on getting reliable Zooz feedback at your Item. Send it commands from UI and watch events.log

So change the command poll interval randomly till it stays off when turned off in the ophab UI? Or is another thing I should be changing and testing?

Another thought I had would be to ask for a recommendation on what switches I should use that are known to work with OpenHAB, I’d need an on/off and a dimmer (for fan control). I am not married to the Zooz at all, nor to Z-Wave either.

zwave works with openHAB. Sometimes stuff needs configuring.

I am not a zwave user, I do not know Zooz, the problem is now buried in a thread about Items and two-way controls.

Remove autoupdate from your zooz Item. (to stop it muddying the waters)
Comment out the cross-linking rule for now. (ditto)
That will leave your zooz Item so that you can send commands to it and observe the responses in your events.log
Maybe it responds too quickly with old status. Maybe it doesn’t actually respond, you just get periodic reports. Maybe your zwave network is horribly delayed. I don’t know.

Armed with evidence, you might consider creating a new post specifically about your zooz/zwave problem to attract the right answers.
Don’t be shy of making a new thread - specific requests get more useful responses than long rambles around the whole system.