It does indeed show that the channel was triggered twice. And the reason is that the binding received the onEventData() twice from the Hue bridge. There could be two possible reasons for this: a) that your bridge did indeed send the event data twice, or maybe b) that the binding had made two SSE subscriptions.
In order to figure out which of the above is the real cause, I am afraid that I shall need even more detailed logging – 1) at trace level, and 2) over more time to see if a second SSE subscription may have been made.
Aha! It seems that “Natural light” is a smart_scene resource instead of a standard scene. It looks like support for smart_scene was recently added to the API v2 so it did not get included in my initial release of the binding. But I will open a new Issue to add support for such.
@laursen can you let me know if the effect which you are looking for, is something that is available for a device resource or for a room/zone resource? If it would be the latter, then it may be a smart_scene – support for which was recently added to the API description, and therefore not (yet) in the current binding. If so then this issue applies. And if not, can you please open an Issue yourself for support for the effect that you want?
In the API v1 implementation it was a specific channel, effect, that could be turned to explicitly trigger a color loop:
I never came around it in the Hue app, only from openHAB. So I don’t see it as a scene or anything like that in the app. That channel is for thing types 0200, 0210, 0220, i.e. Colour Light, Extended Colour Light and Colour Temperature Light.
I’m not sure how to check it for API v2 resources.
Sorry, I have not been precise enough. I have this already in place (version 3.4.5.202306091215).
I do experience problems with 3 hue lights being controlled via an OH group since I upgraded to hue bridge software version 1.59.1959097030. This sometimes works, sometimes not. Typically at least one light is not coming on or off.
I was wondering if this issue is related to the post above and if so, if there is a fix available for 3.4 as well.
Thanks
Ok. So the channel applies to device (light) resources and not to rooms or zones. So I wonder if this could be the timed_effect field of the DTO which you can see on the API V2 documentation (yes it’s back) here
Something like the following…
// light resources
curl --insecure -H "hue-application-key: ABCDEFGHIJKLMNOPQRSTUVWXYZ -X GET "https://192.168.1.123/clip/v2/resource/light"
// NEW smart scene resources
curl --insecure -H "hue-application-key: ABCDEFGHIJKLMNOPQRSTUVWXYZ -X GET "https://192.168.1.123/clip/v2/resource/smart_scene"
// all resources
curl --insecure -H "hue-application-key: ABCDEFGHIJKLMNOPQRSTUVWXYZ -X GET "https://192.168.1.123/clip/v2/resource"
PS see this…
EDIT: just for info: I do have some full color lamps; however I do not see any timed_effects in the DTO for them.
Thank you, Andrew. then i wait for the integration of the dynamic scenes.
my last 2 question for today:
What happend with the CLIP Generic Status Sensors and CLIP Generic Flag Sensors in the API 2?Today i use this both for communication between openhab and HUE bridge.
in API 1 i change the color temperature or color from a room directly by a slider, what is now the best way? now i understand that i must create for each luminaires a thing and create for the color temperature a group channel and then i change this group channel by a slider or i am wrong?
In principle all devices in the Hue Bridge should show up as device things. A device may support different channels that correspond to API v2 defined services such as (light, button, relative_rotary, temperature, light_level, motion, entertainment, grouped_light, device_power, zigbee_bridge_connectivity, zigbee_connectivity, zgp_connectivity). Do your devices show up as things? Unfortunately I don’t see any ‘generic’ services in the preceding list, so it may be that your devices would be without functional channels. => Please advise??
In any case, can you please turn on log trace and disable/enable the bridge thing, and PM with the resulting log file, so I can see if your devices do appear somewhere in the logs?
You are wrong. As mentioned above, a light device will have different channels depending on the capabilities of the light. Below is an example for a full color light. Note: an Item linked to the Color channel will accept accept HSBType commands (for the color), PercentType commands (for dimming), and Switch commands (for on/off).
no the CLIP Generic Sensors are not in the inbox and i have no thing for that. only for the api 1 a have things for that. i clear the complete inbox and after that i disable and enable the bridge v2 thing, but in the logs are no errors. Then i make a new scan in the hue binding and then i became a lot of new things from hue, but no Generic sensors. and in the logs are no errors etc.
i can try to add the sensors manually, but i dont know where i became the resurce id from the generic sensors.
I think this is what Jacob is talking about. I still use the old version of the binding and all my color bulbs have this channel (you have to check the show advanced checkbox)
so i managed to log into API 2 and look at the raw data directly on the bridge. Here the generic sensors do not appear at all, so they do not seem to be available in API 2 and therefore cannot be retrieved.
i have the new marketplace version 3.4.5.202308090829 in place.
I am experiencing bridge errors, that i have not seen before. The bridge thing goes offline with “An unexpected exception {} occurred.”. Log file shows:
2023-08-20 10:20:50.962 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'hue:bridge-api2:66e6cxxxxx changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): An unexpected exception null occurred.
This happened twice by now with different bridges within the last 10 days.
It happened for me also yesterday. Unfortunately there are some issues with the logging/error handling, so we don’t know for sure what actually happened. I created an issue for that:
As mentioned above, a light device will have different channels depending on the capabilities of the light. Below is an example for a full color light. Note: an Item linked to the Color channel will accept accept HSBType commands (for the color), PercentType commands (for dimming), and Switch commands (for on/off).
