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

Thing 1 = iFan03 w/ Tasmota firmware and MQTT connection.
Thing 2 = Z-Wave S2 Zooz switch

Each has a channel linked to a simple switch item for the light controlled by the iFan, and they are set to use the follow profile.

If I toggle the light in openHAB, it works as expected. The light turns on, the panel is updated and the Zooz switch flips to on. If I toggle the light with Zooz switch, nothing but the Zooz changes and if I toggle the light via the webui for the iFan,same thing, nothing but the iFan changes.

If I set the iFan light channel to default, but leave the Zooz on follow. Toggling in Openhab works, toggling the WebUI works, but toggling the Zooz changes nothing but it’self.

If the iFan link is set to follow, and Zooz is set to default. The it all works as expected from the Zooz, the WebUI on the iFan changes nothing but it’self and toggling it from openHab causes it to react to the button click, changes the iFan and the Zooz, but then immediately toggles again by it’self, puts a red halo around the button and no matter how many times you click it, it’ll execute the action, then immediately toggle it a second time afterwards.

If both are set to the default profile then very odd things happen that are hard to explain, things like ifan turning itself back on after you click the button in openHAB, but suffice it to say it does not work as expected.

I suspect this is probably an easy fix, but no amount of googling seems to be helping me on this one, or searching the forum. So any advice or help would be greatly appreciated.

It’s a bit unclear what you want to happen. Should the light be ON when the fan is ON? Should the zooz switch be able to control the fan?

Also, how does your config look at the moment? Are everything configured in paperui, or do you use item files? If so, could you paste your config here?

What do you mean by “toggle the light in openhab” as opposed to the webui? Through the console?

You likely need Rules for this.

General comments.

Where you have two channels linked to one Item and a follow profile, you would usually expect to see the follow on only one channel.

What a follow does; it swaps an incoming status update to become a command.r
So you might link a channel from a wall control to a fan switch with follow. When the wall control is operated, the change is reported to openHAB as a state, but the follow transforms it into a command for the switch Item. Like when you send commands from UI, the other non-follow binding passes to fan switch device for action.

1 Like

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?