I’m new here and investigating a switch from mediola to OH.
The first thing I did is to install the hue binding. I have the complete house with the hue lights. All 38 light are imported and can be switched. But the groups and scenes have not been imported, thats critical for me:
A lot of ios apps are dealing with and managing hue groups, which are stored on the hue bridge and can be called like bulbs: switch on/off, set color, dim and so on. Building separate groups in OH is no solution, because they are no seen by all the apps.
Furthermore its not possible to activate scenes, which are stored in the bridge and build with ios apps like huelights .com, the universal knife for hue management.
I ask/recommend to implement on base of the official Philips hue API
-Step 1: Get all groups from the bridge with https://www.developers.meethue.com/documentation/groups-api command like you are already getting all lights with the “Get All lights” command. Its nearly the same.
-Step 2: Build a thing with the group name for each received group like you do it for each received light
-Step 3: Make a group thing usable as you do it with lights: on/off/dim/color/loop/alert… Its the same!!
-Step 4: Get all Scenes from the bridge with https://www.developers.meethue.com/documentation/scenes-api#41_get_all_scenes command. Only scene name and scene ID are needed per scene to be stored.
-Step 5: Build a thing with the scene name for each received scene like you do it for each received light
-Step 6: Make a scene thing usable with only one function: “Recall Scene” with the transmission of the stored scene id. This can be easy done if you follow the recall scene command, described in the API, see above
I guess that will be helpful for every hue user. The benefits are:
-use groups from the bridge which can be comfortable edited by a lot of free smartphone apps, no need to support that in OH
-synchronous activation/manipulation of up to 50 lights
-no need to build separate OH-groups
-use complex scenes from the bridge which can be comfortable edited by a lot of free smartphone apps, special huelights .com, no need to support this in OH
If I were able to implement, I wouldt do it, unfortunately I’m not a programmer.
Any comments? Questions? Supporters? Implementers?
I see some here are tinkering with direct http put requests from rules to activate scenes on the HUE bridge.
This is something which can be used but is nothing for the average user I guess
Creating/changing scenes/groups is well implemented in the HUE app. It’s quite convenient there…
Adding groups and scenes things directly to the binding simplifies the use of it and would be a great addon to the HUE binding.
Since HUE binding is officially contributed by Deutsche Telekom AG, we may ask @sjka and @kai if there are plans to work on it…
a big +1
Actually I’m quite disappointed, I absolutely expected it to be basic functionality of the hue binding (or at least a convenient method other than sending manually configured http requests)…
I recently moved all my rule handling over to Node-Red, keeping OH2 as my main “state machine”.
Using OH2 as the only state machine in my HA setup implies that Node-Red uses state information coming from OH2 and sending state updates to OH2… nothing more nothing less… but…
The current OH2 binding is missing so much functionality (e.g. groups, scenes, physical button interaction) that i decided to ditch my principles a little… for now.
Node-Red has a new HUE specific node available (HERE) that allows me to do whatever i want with my HUE setup… all be it directly between Node-Red and the HUE bridge instead of through OH2.
Perhaps it is worth while investigating a move to Node-red for all you HUE rules? Could even be a temporary solution untill the OH2 HUE binding has all the necessary features.
Doesn’t seem to have happened yet.
Was a bit disappointed to find that OH2 group on/off was just as sluggish as Trådfri on HUE, but then I found that the HUE bridge has exactly the same REST API as Deconz, so I will just use that.
Deconz and Ikea doesn’t play well over time. Lights drop off grid, and need to be power-cycled in order to re-join. Will see how the HUE bridge fares.
Because the hue binding doesn’t have a real maintainer anymore. I refactored it to be more stable, API conform and maintainable but then the sensor addition was merged and my work was wasted time essentially. The code is not in a good condition unfortunately.
I noticed that as well. It is enough to restart deconz for me though (that seem to reinitialize the RaspBee and reestablish the mesh).
@David_Graeff : sorry to hear about your wasted effort.
I don’t fully understand the implications of ‘the sensor addition merger’, but it has maybe something to do about the ESH/OH interaction discussed in the road ahead thread?
I have often thought about maybe contributing a bit myself, being a professional programmer, but the whole Eclipse/Java initial setup stage is putting me off. At work we are in fact re-writing our code-base to get rid of Java altogether. (In favour of C++/Qt). Had it been a one button development IDE install button for bindings so perhaps.
Anyway, thanks for the deconz restart tip. Will try that the next time I lose a Bulb.
I prefer C++ as well. But at the same time I think, it is probably easier for people to contribute in Java. And nowadays Java virtual machines are performing ahead of time compilation anyway.
The build system recently got a major overhaul and it is now also possible to just download the repo and open the directory as maven project. Without any special installers and setups. Hopefully that lowers entry barriers.
Nice, do you know if there is a ‘write-up for dummies’ on how to get started?
By the way, lost an Ikea bulb during the night. Restarting deconz didn’t help, so I guess I will check out how the HUE bridge fares. Group of 16 E27 bulbs.
I had that setup before. And although I find it to be very stable, the bulb state updates are not real-time. The best thing to do is probably using the zigbee binding with a supported zigbee stick, but if you can live with non real time updates the Hue bridge should work. (Pairing is a nightmare for non Philips products though.)
