Maybe. Can you please explain more? Background is that from your logs, I can see that your 8 colour spot lights (and the bridge itself) all support a service called ‘entertainment’ in addition to the ‘light’ and ‘zigbee_connectivity’ services. And by contrast none of the devices in my own system indicate any support for such ‘entertainment’ service. So I am curious…
Only ever really used it once. Kids had a party and it worked nicely. The following probably explains better than I could. But yes, in the ap you setup Entertainment Areas and they can be “controlled” by Spotify.
That is consistent with your logs: the bridge reports ‘connectivity_issue’ on the Zigbee service of some of your lights. You might also see this in the App. The possible Zigbee service states are CONNECTED, DISCONNECTED, CONNECTIVITY_ISSUE, and I interpret anything other than CONNECTED to indicate the device thing status as offline. I suppose we can debate whether CONNECTIVITY_ISSUE shall be interpreted as on- or off-line…
Possibly. To be honest I don’t know the extent of likely interaction between API v1 and API v2 running in parallel on the bridge. But I could imagine that the firmware would not have been specifically optimised to avoid potential conflicts in that (uncommon) case. Anyway as a general rule when I am testing the bridge thing on one OH machine, I usually disable the bridge thing on the other OH machine.
Note: it is possible that the slow, or missing, status updates, are indeed due to the above-mentioned connectivity issue. Just a thought.
Thanks for the clarification. I think as far as OH is concerned, there is no particular handling required for such entertainment services, so I shall for the time being simply ignore them. Or??
I dont see any connectivity issues on the V1 bridge.
Was wary of upgrading my live system the the V2 API. But will look at that and disable the V1 bridge for further testing.
What is the reason to keep the existing “password” for the V2 bridge? Is this not more likely to result in a conflict? Cresting a new one woukd just look like a new hue app etc? Dies this affect the migration?
Just to clarify, on API v1 the key is called ‘User Name’ (although it is not actually a name). Whereas on API v2 it is called ‘Application Key’ (which is a much better description of its function). It works if you take over the same value of a v1 ‘User Name’ into a v2 ‘Application Key’. But it also works if you create a new ‘Application Key’ instead. The migration process is currently that if the binding discovers a v1 bridge (obviously on the same OH machine) then it copies that key from old to new. The purpose is to avoid the need to press button on the Hue to create a new key. I think that once the v2 is running on the OH machine, there is no need to have the v1 also running on that machine, so the v1 bridge could then be disabled. Obviously the migration process on one OH machine cannot take account of possible v1 bridges on another machine, so in that case the key would not be taken over. And honestly I don’t know if having different keys on v1 on one machine and on v2 on another machine might prevent possible conflicts between those two parallel running OH instances.
That is because the v1 API doesn’t have a specific API command set to monitor the Zigbee status in real time. One of the new features of the v2 API is that it adds the ability to dynamically monitor the Zigbee status. So ironically you are being hit by this new feature. I don’t know what to say…
PS I do not see CONNECTIVITY_ISSUES on my Hue system – except when I force an error by physically removing the lamp from the socket.
Thankyou for catching this one! It was actually a Json parsing error related to a scene, where I think Philips / Signify is guilty of an API inconsistency. Anyway, I have fixed it, and the new Jar is at the same location HERE
1 Like
Hi Andrew
I have installed your latest build.
While testing “Scenes” I see that they do not seem to be working?
I have a “Lounge Room”, but there is no scene channel offered? I also see that there are other channels that do not show up? Last Updated etc. Is this because it is a Room/Group?
Also, in the Lounge Room, the color channel item doe snot show the color selector:
But the selector is available on an individual lamp:
Cheers
Mark
Can you please check your Bridge thing to see if it has a Scene channel?
Ok. I will look into that.
Yes, you are right. My logic was that it could be important to know when a physical device sent its last signal (e.g. to see when say its battery went flat). But I did not think it important to know when a logical group was last updated. But can you please let me know what would be your use case for having a last updated channel on logical groups?
Yes, the Bridge THING has a Scenes Channel. The individual Lamps also do NOT have the scenes channel. I would generally (and have always) assigned a scene to each room, not to all the lights etc.
Great
No real use case :-). I just noticed that the Room/Group was different from the individual Lamp. Your logic makes perfect sense. Just in my case I generally only use the Room/Group. Tried using individual lamps for alarm states etc. But the response was never great. Plan to relook at that when all working on the V2 API
@Mark_VG it turns out that Philips/Signify don’t actually support color, or color-temperature states or actions on light groups (rooms/zones/all). For groups the only actual channels are the switch and brightness channels. You can actually see this in the Hue App. So it is in fact ‘correct’ that groups would display the state of such channels as ‘null’. And therefore I think I shall to remove the color and color temperature channels from groups in OH as well.
Just for info: it looks like the brightness of a group is the arithmetic average over the lights within it; and the switch state of a group is the logical OR over the lights within it. And I guess the complexity of ‘averaging’ the color or color temperature over several lights might explain why Philips / Signify does not do this. Although in the App if lights in the group do have different colors, the App displays a kind of amalgam of the two…
As you mentioned earlier, the only way to set a color or color temperature for a group, is to activate a scene on that group. However the scene does not set a color or color temperature on the group; it actually sets color or color temperature for the individual lights only.
1 Like
Yes, the speed is much faster.
1 Like
Just for info: I am working on getting the scenes to function. I will get back tomorrow.
1 Like
Sorry I didn’t make it. I discovered that I made a basic error in resource nesting for rooms and zones. Perhaps tomorrow…,
EDIT: I made a whole bunch of improvements, (see link below) but I didn’t rally test it properly yet. So please hang on a bit more…
1 Like
Thank you for the hard work. I am happy to test when you ready to share. Just let me know.
I presume i will havevto delete things and re-add?
Ok. The new jar is ready on the same LINK as before.
Yes. Unfortunately you must delete all your hue:groupedLight things – and please do so BEFORE you install the new jar; otherwise the OH UI doesn’t know the groupedLight thing type so it even lacks the functionality to delete them. (Otherwise you wil have to manually edit your things json file, which is not fun). Then you install the new jar and add the corresponding hue:room \ hue:zone things instead.
1 Like
hi
Thanks, I have installed and re-added my Rooms, I see the new hue: room...
There are still just the Brightness and Switch Channels - so no scene (color etc removed?)?
Trace Log in case you need it?
hue.log (102.1 KB)
Please let me know if you would like me to do anything else? The basic functionality does work.
Cheers
Mark
Some background: in the Hue bridge, the ‘room’ and ‘zone’ entities have the following functionality…
- They support two direct light commands only (i.e. on/off and dimmer).
- They do not directly support Color or Color Temperature setting commands.
- If you want to (indirectly) apply Color or Color Temperature commands then you need to create one or more Scenes to do so.
Therefore your OH ‘room’ and ‘zone’ things should show the following channels…
- Always: Switch and Brightness
- Never: Color or Color Temperature
- Case by case: one or more Scene channels depending on what is configured in the App.
The example below is a zone with four scenes…
Thanks for the clarity.
That is pretty different from the V1 Things. Each Room/Group had a single Scene Channel that you sent the scene required in order to activate. This could be populated by a dropdown to select the scene you wanted. This was read from the list of possibilities on the Hue Hub.
The new model (if I understand correctly) will have multiple (varying) channels and items to activate a scene? Could complicate the creation/use of a widget quiet a lot I think?
I do have Scenes activated and in use in my Lounge Room, see screen shot from app below (I use the “Lounge Default” extensively. There are also the “packaged” scenes in the app.:
However they have not been detected by the binding?
I am also not sure how the Binding will detect new scenes? Will you not have to delete the THING and re-add to detect the new scene channels? Scenes can be added at any time by the user, so this could prove to be problematic?
Maybe I am not understanding correctly? Especially regarding how to assign a scene to a room? Hope you don’t mind me asking?