I suppose Prism is either a “timed effect” or a “smart scene”?
https://github.com/openhab/openhab-addons/pulls?q=is%3Aopen+is%3Apr+hue
Ok. So it should be supported in the official binding as soon as those changes have been merged. Or you can manually install the jars from here
1 Like
just FYI: the jar does not support/solve it.
(tested with OH4.1.0M1 with binding from Add-on store and testedt with manual installed jar file).
Hmm. I must be honest that I wrote the timed effect code based on the API specification but without having my own actual device to test it. So perhaps you can help me to get this right? Can you please give any more information about what you (do not) see? It is possible that if your device did not have any effects (be they regular or timed effects) with the OH standard Jar, then after installing the latest Jar you might need to delete and recreate the device thing, in order for the timed effects to become visible. And if you do that, can you please turn on log trace and post the result during the process of recreating the thing?
Hi.
I created a separate topic here:
I don’t know whether this is due to OH 4.0.3 or the API v2.
Has anyone experienced the same?
I sent trace log file via PM.
I have another question while I gather the logs for the topic with the dimmer switch.
I started noticing that after the upgrade to OH 4 (4.0.X), the status of the switch items for the Hue lights linked to the switch channel change to UNDEF.
I have faced the issue with individual lights, not all of them at the same time.
A light switch might be in OFF or ON status and I realize it changed to UNDEF because my rules to turn on or off based on movement stop working.
Has anyone else faced the same behavior?
Could it be an issue with OH or the binding?
I believe this is the bridge after an software update less than a week ago. I noticed it in the scenes, which change to UNDEF right after they’ve been set, which did not happen before. It changed for me from one day to the other without any change on the OH side.
The api-call to the bridge via browser returns swversion "1960062030" and
lastchange "2023-09-24T20:18:03"
Hi, @Rivi.
That might not be my case. I update most of the elements in my smart home manually so I can be aware of new functionalities or breaking changes.
In the last week I’ve faced the problem at least 3 times, 2 of them with one light in the evening, on different days, the other one with another light very early this morning.
Apart from OH 4.0.2 (later 4.0.3) and API v2 (including the file-based items), nothing else has changed.
As mentioned elsewhere, button channels do not have a state; instead they issue trigger events when a button is pressed. Your rules should respond to those trigger events. There is really no point to try to link state items to such trigger channels, since the resulting ‘state’ is actually meaningless.
Interesting. According to Philips / Signify the latest firmware release was mid August to v1959194030 … which means that if they did change anything last week, it is still probably undocumented.
EDIT: the September 14th firmware is now documented to have been the official release of Matter support in the bridge.
^
A few more points apropos latest firmware…
- A few months ago, Philips / Signify did notify some intended deprecations of their API, specifically relating to all kinds of sensors including buttons, and announced replacemement DTO structures; we do have a PR in the pipeline to adopt those new DTOs.
- So it may be that, if there was a firmware update last week, they may have force removed support for those deprecated API DTOs. In my opinion it is bad manners for a manufacturer to announce a deprecation and then force remove the feature in such a short time. But if that is the case, you will need to wait until the current PR is merged before we can catch up with that change.
- Notwithstanding the above, I am not aware of any announced deprecation concerning Scenes (nor the On-Off channel) … only sensors were announced.
- Notwithstanding the above, Philips / Signify did announce new features called ‘timed effects’ and ‘smart scenes’, and we do have two PRs in the pipeline to add support for these.
- Also in the last weeks they also announced a new range of Home Security products, and we do have a PR in the pipeline to add support for those. And it could be that any firmware update of last week might be related to this new range.
- And finally it is worth mentioning that in the past days Philips / Signify has announced that their Matter support, which was previously in beta, has now officially been released. So it is possible that any September firmware update may be related to this Matter release.
I believe you’re talking about the issue with the Dimmer Switch but you quoted the one about the lights.
With that assumption in mind, I don’t think it makes a difference for my setup. I store the value provided by the channel in the item and reference the item in the rules so it’s easier to change things such as the channel name from a single place.
I know the value is only valid in the moment when it was triggered, that’s why my rule for that item is just when the item received a command and then with cases it checks the received command and performs the required action.
Obviously, I can’t check what’s the “status” of the button X minutes later 
I think the outcome would be the same if I wrote the rule as a trigger channel instead of a trigger item. Isn’t it?
Now, the issue with the light is different. The switch item changes from (apparently) any valid value to UNDEF. Today I faced it 3 times and I took note of the times when I realized the problem (which could have happened 2 hours before). Whenever I can narrow down the time I will try to investigate what could be the root cause.
Ok. Sorry for the misunderstanding about the button versus the switch item on a light channel. It sounds as though your issue might indeed be related to the new firmware, (which I don’t have yet, so cannot test). What type of light is it i.e. full color, color temperature, simple dimmable, or on/off? And if you issue (say) brightness = 0% command, what happens to the on/off switch channel? And vice versa, if you send on or off, what happens to the brightness channel?
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).
Dimmer Schuifpuilinks_A "Schuifpui spot Links" <colorwheel> (lgKeuken_A,lgSchuifpui_A) { channel="hue:device:wkbridge:Thing_Schuifpuilinks:color-xy-only" }
Thing device Thing_Schuifpuilinks "Schuifpui_spot_links" [resourceId="e1e18a41-c976-4500-8bd8-7b3569e182f9"] // Hue ambiance spot idV1:/lights/5
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.