No prob. One of the bulbs is a color ambiance and the other one is a white ambiance.
Sending commands works without issues. I haven’t tried dimming at that time but I will.
When I realize that the item is in UNDEF I have to manually send an ON or OFF command through the UI, then it goes back to normal until it goes back to UNDEF.
Yesterday I was home all day long and the color bulb had the issue 3 times from 17:00 (observed time) until 21:00. The white ambiance one only once.
Today I’m at the office and I just checked all the lights and they are fine, so far.
I realize because my automations check periodically if it’s time to turn off a light. If it is, they check if that light’s switch is already OFF or not, not to send an OFF command to a light that is already off.
Likewise to turn them on with movement I check if they are not ON already.
When one is in UNDEF, the rule simply skips it and it is not turned on or off automatically.
Of course, I can change the rule to include the UNDEF condition, but I decided to ask whether someone else was facing the same issue.
It sounds as if Philips / Signify has changed the DTO for the On/Off state event. (This would not be a great surprise since during the last weeks they already changed the DTOs for all sensor states). So it would be helpful to see trace logs with the contents of such events. => Can you please have a look for any ‘onEvent’ messages?
I only see this with one of my items. It’s a wallsocket switch from Osram which has support for Hue but always goes offline for a short period of time and comes online for a bit longer time. (It does it since i’ve got it, colleague of mine has the same thing with this switch).
With V1 Api, the switch went offline, the item stayed OFF, came back online and the Item didn’t change. Now the Item becomes UNDEF when it’s going offline but never comes online afterwards. Doesn’t bother me but (Don’t use this switch most of the time). But I sounds a bit like your scenario.
2023-09-28 10:57:59.683 [INFO ] [openhab.event.ThingStatusInfoChangedEvent] - Thing 'hue:device:wkbridge:Thing_Watermuur' changed from ONLINE to OFFLINE: Zigbee connectivity issue.
2023-09-28 10:57:59.687 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Watermuur' changed from OFF to UNDEF
2023-09-28 11:01:01.912 [INFO ] [openhab.event.ThingStatusInfoChangedEvent] - Thing 'hue:device:wkbridge:Thing_Watermuur' changed from OFFLINE: Zigbee connectivity issue. to ONLINE
I got a problem with light color (color-temperature / color-xy-only). I change my lights to a certain color (for instance 80) in the evening when the brightness is low.but the lights always revert back to 50.17. I can’t find what i’m doing wrong. They become for a couple of seconds the value I chose but after a couple of seconds they change to 50.17.
Normally they are part of a group (item), but I also tried with the lights apart from a group with same result. Anyone else noticing this? The lights affected by this are Philips hue Ambiance lights (the ones with the blue to yellow color).
The API v2 has an event push model, versus API v1 which uses a polling model. So yes, under the v2 push model, what you report is pretty much the expected normal behaviour.
This sounds a bit confused. Is the light a full colour light, or is it a color temperature light? And what do you mean by “color 80”? Normally you would specify a color as an HSB value with three parameters for hue, saturation, and brightness. Or you would set a color temperature in Kelvin. Also what do you mean by “50.17”?
The colour light is an ambiance light. So it only has blue-ish to yellow-ish colour. I always gave these lights a number value from 0 (the most blueish white) to 100 value.
I thought it happened with all my lights, but now I notice some other lights are staying at the colour I’m sending, so I’m doing something wrong somewhere I think.
For these types of lights, what value would you send to it. I’m just sending a number. Or should I send an percent type? Color-temperature should be a dimmer type if I’m correct.
To be clear, for each light I have 2 items. One for brightness, one for color-xy-only. I first send the brightness item a certain value, when that value is above 0, I send the color to it.
Such lights support neither the color channel nor the color-xy-only channel. They support color-temperature (or advanced color-temperature-abs) and brightness (or advanced dimming-only) channels only.
If we explicitly set channel values to UNDEF when the device goes offline/gets the unreachable event, wouldn’t it be a good idea to poll it once when receiving the reachable event?
It seems that prism is a regular effect, but it was not in the binding list of EffectType’s. The issue is recorded below, and I will make a PR to fix it after my vacation.
The warning comes from the Jetty HTTP/2 client which is supplied as part of the OH core. I guess that it is possible that the core developers changed the Jetty setup (e.g. change to a new version?) between 4.1-M1 and 4.1-M2 ?? => Maybe one of the core msintainers can comment on this?
2023-10-09 14:31:57.250 [DEBUG] [.internal.handler.Clip2BridgeHandler] - checkConnection() Error opening HTTP/2 session
org.openhab.binding.hue.internal.exceptions.ApiException: Error opening HTTP/2 session
at org.openhab.binding.hue.internal.connection.Clip2Bridge.openSession(Clip2Bridge.java:1040) ~[?:?]
at org.openhab.binding.hue.internal.connection.Clip2Bridge.openPassive(Clip2Bridge.java:1012) ~[?:?]
at org.openhab.binding.hue.internal.connection.Clip2Bridge.testConnectionState(Clip2Bridge.java:1243) ~[?:?]
at org.openhab.binding.hue.internal.handler.Clip2BridgeHandler.checkConnection(Clip2BridgeHandler.java:169) ~[?:?]
at org.openhab.binding.hue.internal.handler.Clip2BridgeHandler.lambda$5(Clip2BridgeHandler.java:489) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
at java.lang.Thread.run(Thread.java:833) [?:?]
Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: No Client ALPNProcessors!
at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:396) ~[?:?]
at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2096) ~[?:?]
at org.openhab.binding.hue.internal.connection.Clip2Bridge.openSession(Clip2Bridge.java:1035) ~[?:?]
... 10 more
Caused by: java.lang.IllegalStateException: No Client ALPNProcessors!
at org.eclipse.jetty.alpn.client.ALPNClientConnectionFactory.<init>(ALPNClientConnectionFactory.java:54) ~[?:?]
at org.eclipse.jetty.http2.client.HTTP2Client.lambda$doStart$1(HTTP2Client.java:163) ~[?:?]
at org.eclipse.jetty.http2.client.HTTP2Client$ClientSelectorManager.newConnection(HTTP2Client.java:511) ~[?:?]
at org.eclipse.jetty.io.ManagedSelector.createEndPoint(ManagedSelector.java:386) ~[?:?]
at org.eclipse.jetty.io.ManagedSelector.access$2100(ManagedSelector.java:65) ~[?:?]
at org.eclipse.jetty.io.ManagedSelector$CreateEndPoint.run(ManagedSelector.java:1069) ~[?:?]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883) ~[?:?]
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034) ~[?:?]
... 1 more
