Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[hue] Unreliable Philips Hue Dimmer Switches #7038

Closed
regnets opened this issue Feb 20, 2020 · 13 comments
Closed

[hue] Unreliable Philips Hue Dimmer Switches #7038

regnets opened this issue Feb 20, 2020 · 13 comments
Labels
bounty Issues with a Bountysource reward and the PRs that solve these question

Comments

@regnets
Copy link

regnets commented Feb 20, 2020

Expected Behavior

I press a button on a hue dimmer switch, the integrated led blinks firmly green, the responding action is taken by openhab.

Current Behavior

Sometimes the button click events are not send or received by openhab and i click a dozen times without any response from the openhab server.

Possible Solution

I have no idea :). What i could observe is, that the button presses were less reliable if i just use the channel triggered event without a corresponding item for the button press. This is also true for the deconz binding. This makes this bug report kind of mushy. Because i am not able to tell if this is only related to the hue binding or possible something inside the openhab server itself.

Steps to Reproduce (for Bugs)

Best way to observe this kind of issue is just to created the thing for a hue dimmer switch connected to a hue bridge or a tradfri dimmer switch (the round one in my case) to a deconz bridge with phoscon and the current phoscon binding. For the sake of simplicity i would stick to the hue ecosystem as this should have the same firmware accross multiple developers and should not have as many configuration variables as a deconz installation with some raspberry pi and some os and some zigbee hardware.

I solely configure my openhab installation by textual files. So this is the thing file for the hue binding

Bridge hue:bridge:<myid> "Bridge: Philips Hue" [ ipAddress="philips-hue", userName="<myusername>" ] {
  0820 Zigbee_Wohnzimmer_Fernbedienung "Philips Hue: Wohnzimmer Fernbedienung" @ "Wohnzimmer" [ sensorId="27" ]
}

With this configuration i could observe that a lot of events are just lost anywhere between the button and openhab. Take a look at this video:
https://youtu.be/uEC4HIFfnaA

It is possible to improve the number of successfully recognized events by just adding an item for the dimmer_switch channel

Number Zigbee_Wohnzimmer_Fernbedienung_Status "Wohnzimmer Status [%.1f]" { channel="hue:0820:00178827902c:Zigbee_Wohnzimmer_Fernbedienung:dimmer_switch" }

This solves arround 90% of the missed button presses. However i still can see sometimes a dozen missed presses in a short amount of time. However it is really difficult to record this behaviour, everytime i tried it it works fine for me.

Context

This is just annoyance and my family loses the trust in the smart home installation.

Your Environment

I am using the latest openhab docker image from the official openhab repository on docker hub (https://hub.docker.com/r/openhab/openhab/).
By the time of writing this should be version 2.5.1. I am using a philips hue bridge (FW: 1937045000) with standard philips hue e27 bulbs with latest firmware (FW: 1.46.13_r26312) and a hue dimmer switch with current firmware (FW: 6.1.1.28573). The openhab docker image runs on unraid 6.8.2 however i thing this shouldn't matter.

@regnets regnets added the bug An unexpected problem or unintended behavior of an add-on label Feb 20, 2020
@regnets
Copy link
Author

regnets commented Feb 20, 2020

I added a small bounty to this issue, as this is still related to #6577 where i already posted a small bounty on.

@9037568
Copy link
Contributor

9037568 commented Feb 20, 2020

However i still can see sometimes a dozen missed presses in a short amount of time. However it is really difficult to record this behaviour, everytime i tried it it works fine for me.

Then this should be closed as a non-issue, yes?

@9037568 9037568 added question and removed bug An unexpected problem or unintended behavior of an add-on labels Feb 20, 2020
@thedannymullen
Copy link

thedannymullen commented Feb 21, 2020

I am having a similar issue with the Hue dimmer on the deconz binding. I have things described in files also.

Bridge deconz:deconz:homeserver [ host="192.168.1.20", httpPort=8090, apikey="apikey7B65E" ] { switch KitchenRemote "Kitchen Dimmer On/Off Switch" [ id="6" ] }

Items file:
//Remote Battery Level Number KitchenRemote "Kitchen Remote [%s %%]" {channel="deconz:switch:homeserver:KitchenRemote:battery_level"} Switch KitchenBattLow "Kitchen Remote Low Battery" {channel ="deconz:switch:homeserver:KitchenRemote:battery_low"} Number KitchenButton "Kitchen Button" { channel ="deconz:switch:homeserver:KitchenRemote:button" }

The largest issue I am having is that the remote works when I test, but a few days later it seems to quit working. One of the errors I have seen is this one:
2020-02-21 07:32:34.497 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'FFAgent Button pressed': An error occurred during the script execution: Could not invoke method: org.eclipse.xtext.xbase.lib.ObjectExtensions.operator_plus(java.lang.Object,java.lang.String) on instance: null
A restart and cache clear fixed it.

@regnets
Copy link
Author

regnets commented Feb 21, 2020

However i still can see sometimes a dozen missed presses in a short amount of time. However it is really difficult to record this behaviour, everytime i tried it it works fine for me.

Then this should be closed as a non-issue, yes?

As i am experience this a few times a day, i think this is still an issue. However i don't have my terminal and my camera ready to record this. If i got some time this sunday i will gladly try to reproduce it while filming.

@regnets
Copy link
Author

regnets commented Feb 21, 2020

I am having a similar issue with the Hue dimmer on the deconz binding. I have things described in files also.

Bridge deconz:deconz:homeserver [ host="192.168.1.20", httpPort=8090, apikey="apikey7B65E" ] { switch KitchenRemote "Kitchen Dimmer On/Off Switch" [ id="6" ] }

Items file:
//Remote Battery Level Number KitchenRemote "Kitchen Remote [%s %%]" {channel="deconz:switch:homeserver:KitchenRemote:battery_level"} Switch KitchenBattLow "Kitchen Remote Low Battery" {channel ="deconz:switch:homeserver:KitchenRemote:battery_low"} Number KitchenButton "Kitchen Button" { channel ="deconz:switch:homeserver:KitchenRemote:button" }

The largest issue I am having is that the remote works when I test, but a few days later it seems to quit working. One of the errors I have seen is this one:
2020-02-21 07:32:34.497 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'FFAgent Button pressed': An error occurred during the script execution: Could not invoke method: org.eclipse.xtext.xbase.lib.ObjectExtensions.operator_plus(java.lang.Object,java.lang.String) on instance: null
A restart and cache clear fixed it.

I am not sure if this is related to that issue. I don't see any events in the events.log while pressing the button on the remote. Clearly your press comes to openhab and openhab starts the related rule and there is an issue in that rule.

@wborn wborn added the bounty Issues with a Bountysource reward and the PRs that solve these label Feb 22, 2020
@Novanic
Copy link
Contributor

Novanic commented Sep 16, 2021

Hi, I have the same problem. Do you have a trigger channel rule? I found out that the trigger channel is missing events, but not the normal dimmer_switch channel. I changed my rules to the dimmer_switch channel in combination with "received update", that could be a workaround.

I think it is a general problem of OpenHAB with trigger channels. Maybe there is a problem with concurrent events within OpenHAB regarding trigger channels. Hue sends at least 2 events when a button is pressed. The hue binding sends events to both channels at the same time, see the DimmerSwitchHandler class of the hue binding. There is a strange timestamp logic which may could also cause problems like this, but I think it's a general problem within OpenHAB.

@andrewfg
Copy link
Contributor

I think that this issue will have been resolved by #13570 => @regnets @Novanic can you please check it?

@gcatellani
Copy link

I still have the issue :(

@andrewfg
Copy link
Contributor

still have the issue :(

Can you please be more specific? What version of OH? What version of the binding? Are you using the Hue API v2 version of the bridge and things?

@gcatellani
Copy link

gcatellani commented Nov 27, 2023

Can you please be more specific? What version of OH? What version of the binding? Are you using the Hue API v2 version of the bridge and things?

Hi @andrewfg,
thank you for your work and for taking the time to respond to me, despite me not adhering to the netiquette. I wasn't sure, this old thread would get such a quick response or any response for that matter. So let me restate my poorly written first comment:
My setup is:

  • OpenHAB 4.0.4 (had the problem with older versions too)
  • newest version of the Hue Binding (4.0.4)
  • Among other stuff I have a range of hue bulbs and switches as well as Velux products
  • and here probably comes my problem, fault of me not having kept up with development of the Hue Binding => I am still using API v1
    So shame on me, I am gonna try out CLIP v2 this weekend and will get back to you. Hopefully that will resolve the matter and I will just have made a fool out of myself ;-)
    Sincerely,
    Gregory

@andrewfg
Copy link
Contributor

andrewfg commented Nov 27, 2023

@gcatellani no problemo. The difference is that API V1 uses a polling (pull) model, so it needs to poll very rapidly in order to catch fast transient events (like button pushes) and sometimes it is not fast enough to catch them all. By contrast API V2 uses an event driven (push) model where the bridge pushes each state change to the binding in real time, so all events will definitely be caught.

@gcatellani
Copy link

@andrewfg: switching to API v2 did indeed do the trick. Reactions to buttons are now immediate and work perfectly well. Thank you very much :)

@andrewfg
Copy link
Contributor

andrewfg commented Dec 3, 2023

Closing this issue since it is fixed in API v2

@andrewfg andrewfg closed this as completed Dec 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bounty Issues with a Bountysource reward and the PRs that solve these question
Projects
None yet
Development

No branches or pull requests

7 participants