Aeon Garage Door Controler Switch behaviour

Can someone explain the strange behaviour of the swich with the Garage Door controller from Aeon?
I added the switch in my sitemap.
Current status is ON and I tap on it, it goes OFF and after 1 second it switches again to ON.
And sometimes it will stay OFF.

As my understanding the switch should never be on OFF because ON/OFF reacts like an “button” tap. A onetime pulse to the controller.

Hi Christian, please share your .things, .items and .sitemap files so we can see how and what you are sending specifically. Hopefully we can help from there.

I don’t use files. I use the GUI.

Here is the sitemap entry:
Default item=Garage_Door_Controller_Fibaro icon="garage"

Thing entry:

Item entry:

For the thing channel when you click on the blue circle to expose the bound items it shows Garage_Door_Controller_Fibaro, right?
Can you show the thing section above the channels to show the thing type? I noticed you titled the post “Aeon Garage Door Controller” but named the item “Fibaro”? I assume you just reused an older item and you are using the Aeotec ZW062?

I have other Aeotec devices, but not this one. Assuming you are using the Aeotec ZW062 according to the documentation switch_binary turns the power on or off. You stated that the switch should never turn off. Can you clarify what you are trying to accomplish and what behavior you expect?

Yeah sorry. Fibaro is a typo it should be AEON :slight_smile:
image

This switch should open and close the garage door.
And if I am adding it to the sitemap it behaves like I have described. Nothing changed here on my side.

It is always “ON” and if I type the switch it goes “OFF” and afterwards again “ON”.
Now the garage door controller opens or closing (depends on the current state).

So I always expect that the witch goes from ON to OFF and ON again.
And sometimes this is not the case. It goes to OFF and not to ON anymore.
And of course no open/close on the Garage door.

If I read the device definition correctly (https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/256) sending ON would open the door and sending OFF would close the door (or possibly the other way around).
It looks like you are expecting a toggle behavior, i.e. sending ON closes the door if open and opens if closed. Why do you expect that behavior - or is that what you would like it to do?
Regardless, the immediate challenge is that when you send ON nothing happens with the door, right? (we can figure out the on/off vs. toggle afterwards).

  1. What OH version are you running?
  2. What is the status of your garage thing? In the thing list does it have the green “Online” next to it?
  3. Have you tried turning on debugging (in Karaf submit log:set DEBUG org.openhab.binding.zwave; use log:list to validate your change)? Please reboot and issue another ON command, then share the resulting openhab.log and events.log.

I don’t expect it :slight_smile:
Currently it does this and I have nothing “changed” here.

Only added to the sitemap and it is a “Switch” item.
Now it reacts like I have wrote earlier. It is always ON and if I tap on it, it goes OFF and ON again.
Now the Garage door opens. If I tap again it goes again on OFF and ON again and the Garage door is closing.

And only sometimes the switch goes to OFF and stays on OFF.
If this happen the Garage door does nothing. No closing or opening.

  1. 2.5.5
  2. Yes it is online.
  3. I will try turning on DEBUG and will check the logs, thanks.

As far as I know now it seems the the Garage Door controler looses sometimes the connection, but in opneHAB it shows it still as ONLINE.

Seems the ONLINE/OFFLINE state of the thing is not real time or is only checked in an intervall.

That is absolutely correct. Do not treat Thing status as reflecting device status.

Is it possible to have near real time info about the Z-Wave thing?
Is this the “polling interval”?

I use also Hue things and they are real time it seems.
If I turn off the power of my hue lamp I see in a second that the thing is offline.

The same would be great with the garage door controller thing because I think that the connection is not perfect.

Be careful with this. You could easily clag up your zwave network attempting to poll something that you say keeps losing connection. It’s not going to fix the underlying problem that you have.

1 Like

I think I finally got the full picture, sorry :slight_smile: . Do you actually ever see your thing go offline?
In an ideal world the thing would go immediately offline as something happens to it. It is the job of the binding implementation to make that happen. In reality that is often not easy to accomplish for the binding. If something bad happens to the device that the device becomes aware of itself then the device can inform the binding in real-time. However, more often than not the very problem that happened to the device prevents it from telling the binding (device breaks, loss of power, loss of connectivity). For those cases the binding can only infer that the device has problems by lack of response. But checking whether the device is alive comes at a cost - network bandwidth, overall system load - we don’t want to check every couple milliseconds. The binding will decide how often to check based on that cost. For your Hue light checks are very frequent as they are not too costly (bit of network load). For Zwave however, where many devices run on battery, connections are kept to a minimum as each connection impacts battery life. That’s why you see a slower response to detect problems for ZWave devices. If I remove my Aeotec Multisensor’s power it takes ~2 minutes (which is its configured reporting interval) for it to go offline. While that is not real-time it is quite reasonable for most use cases given that a device going offline should be a very rare occurrence.

The problem is that you have a frequent connection issue. Hopefully the debug logging will tell us more about the issue. BTW, how far away is your garage device from the next zwave device or controller?

I am curious about one other thing - would you do me a favor? You say the switch is normally ON and then you press it. That means you are sending an OFF command to the device. I am curious what happens when you send an ON command to the device. It is interesting that Aeotec exposed the toggle behavior of the garage door as a switch, because as you said it’s a trigger and not a switch. My guess would be that sending ON or OFF will both trigger, but would love to see.
To test this easily you can replace your sitemap entry with

Switch item=Garage_Door_Controller_Fibaro mappings=[“ON”=“On”, “OFF”=“Off”] icon=“garage”

Now the UI will render the switch with two push buttons - that way you decide at any time whether you want to send an ON or an OFF command. Could you try both commands and report what happens?
Side note: Once you are past the failing connection a single button is probably a nice UI choice to let the user operate the door as it avoids the weird “switch goes to off and then back on”, something like:

Switch item=Garage_Door_Controller_Fibaro mappings=[“ON”=“Operate”] icon=“garage”

2 Likes

Thank you very much for all the details.

I think my main problem is that I often loose the connection.
So I think that this will be the problem when the switch stays at the OFF value.

Need to check how I can make a better connection.
But this is not easy because I don’t have a direct way to access the garage.
I live in a house with 6 tops.

My garage is the nr. 3 and “OH” stands for where my openHab Z-Wave stick is:
image

Connectivity does seem to be the problem. There are range extenders (e.g. from Aeotec) - perhaps you can get Garage1’s buy-in to put one there?

If you get a chance to test what happens for both ON and OFF command (not just OFF) as mentioned above I would love to hear the result. This has nothing to do with your problem - I am just curious about this toggle behavior that is expressed as a switch.

For sure I will test this tomorrow and let you know.
Thanks again for your help so far and for the tip with the range extender.
Will check this.