I’m trying to use the hueActions.dynamicCommand to fade my lights in the bathroom. But i’m unable to fade color lights. Is this limited from philips hue or does the binding not support this?
This is what I get, so it suggests it’s not supported or i’m doing something wrong.
2023-09-22 20:05:56.846 [WARN ] [g.openhab.binding.hue.internal.handler.Clip2ThingHandler] - Dynamics command '28' for thing 'hue:device:wkbridge:Thing_BadkamerDouche', channel 'brightness' and duration'30000 ms' failed.
These are the commands I use (fadevalue = string, FadeSpeed = Long):
hueLightAction = getActions("hue","hue:device:wkbridge:Thing_" + lamp)
hueLightAction.dynamicCommand("brightness", new PercentType(new DecimalType(fadevalue).intValue), FadeSpeed)
I read the documentation thoroughly and am not seeing anything strange. My rules work with all kind of lights except colour lights. So not sure where to look for the mistake I made.
[Edit] - I see, I must use color for my color lights… simple as that, completely missed it…
This is a consequence of a design decision made by OH maintainers. Which I personally did not, and do not, agree with. Namely as follows..
for lights which support color you must send the ‘brightness’ and ‘on-off’ commands to the color channel (and the respective brightness and on-off channels are suppressed.
for lights which support brightness you must send the ‘on-off’ command to the brightness channel (and the respective on-off channel is suppressed).
As I say, I personally find this approach to be non logical, and counter intuitive. However the OH maintainers overrode me during the development process.
However.. if you want to follow the more (in my opinion) consistent and logical channel usage .. if you look carefully you will see that the devices also support some ‘advanced’ (i.e. less visible) channels called color-xy-only, dimming-only and on-off-only where the above mentioned cross routing of commands and channel suppression does not occur.
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?
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"
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 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?
