@Mark_VG apropos the NUpnp discovery issue, can you please open the following url https://discovery.meethue.com/ in your browser and let me know the result? It should return a JSON payload, but in your case I am guessing that it does not. ??
Fix created:
That’s a somewhat unfair and inaccurate description. It’s not only one maintainer, but multiple, and the reason for the insistence is that all current bindings dealing with lights (including Hue V1) work the requested way (only a single color or brightness channel, no dedicated switch).
@Mark_VG probably was just confused because the initial Hue V2 binding behaved differently, but I’d be surprised if the switch was actually needed in his case.
Hi There
I was not confused at all.
I have used the SWITCH option in a widget that I modified from other versions and examples found in the forums.
I cleaned up my system after installing the Marketplace version of the binding yesterday, so no longer have any of my V1 THING and ITEMS to show this, but can restore a 3.4.2 backup to show this if you like?
HUE allows one to switch off the lights and turn them back on in the same state as they were when turned off - which we use a lot. In my case I hardly ever use the DIMMER, other than to temporarily adjust lights to suite a short term mood.
I am however OK with the SWITCH hidden in advanced - at least it is still available, so thanks for that.
I am not qualified to comment on how it worked in the background, or what the SWITCH was linked to.
Cheers
Mark
PS: These are some examples showing that the SWITCH was available (and used) in the V1 Binding:
You can just create a switch item and link it to the brightness channel if you want to have a switch. If you also want the dimmer control you can use a dimmer item as well in parallel.
Exactly that also works with dimmer channels. You can send ON and OFF commands to it, which does precisely what you want.
Thank you. I did not know that. This will make it less of an issue for me for the reasons explained above.
I have however restored a backup from my 4.0.0-SNAPSHOT - Build #3359 system prior to using the V2 API Binding, so running the stock V1 binding that ships with openHAB:
244 │ Active │ 80 │ 4.0.0.202303082024 │ openHAB Add-ons :: Bundles :: hue Binding
This version did offer the SWITCH channel (and not under Advanced):
So thank you all for the comments and advise and keep up the good work.
And thanks Andrew for the hard work in getting this all updated. The V2 API binding is most certainly a lot more responsive and as I mentioned on the other thread I have been able to achieve some things that just di dnto work before.
@AndrewFG On a lightly different note - Rooms with Color Temperature and Color Channels
This is something I brought up in your original Topic if you recall?
I was actually incorrect. It appears that the color and color temperature can actually be set on all lamps in a room - though the process if far from intuitive:
I got this procedure from the Facebook Hue Support group:
1. Tap on a Room
2. Tap on a Scene that sets all lights to the same colour (such as the Bright Scene).
3. Tap on any light
4. Tap on a blank area around the colour wheel to unselect the light you just selected.
5. Tap on the dot on the colour wheel
6. Drag the numbered icon (that represents all lights in the Room) around the colour wheel.
I am not sure how this works in the background - though it would be really nice to have the Color and Color Temperature CHANNELS back on the V2 binding. Creating a scene to change all the lights in a room is just such an overkill for what can at times be a once off change?
What do you think?
Please correct me if I am wrong, but step 2 is probably unnecessary, or? (In other words, the described procedure is not being applied to a scene, but rather to the grouped lights within the respective room or zone). Can you confirm that?
Me neither. In order to find out, I would need to see the encrypted HTTPS traffic between the Hue App, and the Hue bridge. And to do that I would need to set up an SSL Proxy server on my LAN, so that I could sniff the actual traffic. Depending on the Hue certificate authentication mechanics this may or may not even be possible. But in any case, it might take me a day or two to figure that out.
To add further to the fun, the documentation for the Hue API grouped_light GET command shows that it is not possible to read a color XY state or a color temperature state from such a resource; whereas by contrast the documentation for the grouped_light PUT command says that it would indeed be possible to write a color temperature or color xy command to such a resource. So in other words it might indeed be possible to introduce a ‘half channel’ for rooms and zones, whereby you could write a new value to them, but not read their actual state. Reason being that a) the GET would not return those data, and b) I have never observed an SSE state update for color xy or color temperature from a grouped_light resource. In yet other words the state would have to be shown permanently as as UNDEF. And there is a further difficulty in that there is no way to actually determine if any, or all, resources in a room or zone would actually support color xy commands or color temperature commands. Nor what would happen if you tried to send such commands to such a room or zone where one, more, or all, lights there-in do not support such features.
{BTW simply writing the above paragraph yet further strengthens my belief that the four Color XY, Dimming, Color Temperature, and On/Off state elements of a light or grouped_light resource need to be (also) accessible via individual channels and not (only) accessible (partly) via an HSB …}
Hi.
Yes. Just checked and step 2 is notc equired.
I will have to digest the rest of your redpknse to understand. 
But thought i woukd respond where i could.
EDIT: I did not consider the possible case of room with lights that do not support color? But as you know this was supported in the V1 API.
It would however be nice to have that functionality back if possible.
Actually if the lights are already both the same color (including color temperature) the step is not needed; whereas if they are not already the same, then an intermediate step 2 is needed to make them so before you can proceed with step 3.
1 Like
Sorry. Tried from my current scene which has all the same
Apropos rooms or zone with mixed functionalities: I just tried it in the Hue App on a room with two switch lights and two full color lights. The room dimmer command acts (only) on the two (dimmable) color lights but not on the switch lights. And the room switch command acts on all four lights, and – as you would expect – does not change the full color lights’ prior persisted dimmer (nor indeed their color xy or color temperature) state.
{BTW yet further strengthening the argument to (also) allow separable command channels in addition to amalgamated HSB command elements … hey ho…}
EDIT: whereas by contrast, activating a scene of that room DOES activate both the on state of the switch lights, and the dimmer state, color xy, and/or color temperature state elements of the full color lights.
Ok. The NUPnP discovery is fixed again.
1 Like
Hi,
I’m trying to install the add-on directly from the marketplace but I’m always ending with the following error message: “Installation of add-on marketplace:146648 failed”.
What am I doing wrong? I uninstalled the “old” hue add-on and installed the mentioned upnp feature.
Alternatively I tried downloading the jar but ended up with github saying 404.
1 Like
The binding is bundled with 4.0, so you shouldn’t need to use the Marketplace version anymore. It should probably be unpublished.
Yes, this in on my “todo” list. The marketplace version is way behind the official v4.x release, so I plan to remove it. And update the v3.4x marketplace version to the same latest state.
Okay, thanks.