At present, I am working on automatic scene discovery. By that I mean that Scenes are not a state for Hue. Scenes are activated, but there is no way to determine if the members of the scene are all in a state the is equal to the scene that was activated.
Ex: If a "relaxing" scene in the Office room is to turn on the ceiling light to 50%, and turn off the desk light. And you turn on the scene, there isn't anything in Hue to tell me this scene is in use.
If I don't activate the scene, but set the light to 50% manually, and turn off the desk light, my update would detect that all the conditions of the scene are true, and turn on the scene child device, as well as set a local attribute to declare the current scene. And if any device in a scene is changed from the scene's expected state, the scene would no longer to set.
This is a very important feature for me, so this is next on my list. I am open to requests though.
I discovered capture state, and restore state wasn't working right 100% of the time. I updated the hue devices so that if the device is off, the new state will be queue up, and when the device gets turned on, it will send the new state along with the on event, so the transition from off to new state is seamless, and instant. It also means that the restore state should be reliable now.
I fixed a bug in the colorTemperature attribute. I was using "colortemperature", not "colorTemperature", which works for setting the color temp, but does not work for tracking the current color temp. This means capture scenes would not work correctly and if the hue group is used in scenes, they would fail to react correctly when replaying the scene.
This looks very interesting. I've resigned myself to having to have a Hue bridge for lighting applications as putting lamps directly on to Hubitat has only ever led to tears as my mesh dissolves, even when all lamps are left on.
I also didn't realise how easy it was to add non-Hue lamps to the Hue bridge, which probably means I'll be taking this Trådfri hub back at some point!
Just be careful which non-hue bulbs you add. The US version of Osram/Sylvania Ligtify bulbs won't link to hue. Sengled perform exceptionally well, but they don't group well. I have four Sengled candalabra bulbs in a ceiling fan. I had too pair each while being net to hue hub, then once installed in their final resting spot (1 room over) only three participate in the zigbe group, the 4th is slightly behind in all activities.
Additionally, with Hue bulbs, I the light was Red at 20% then turned off, when turned on it will return to the same state (expected) but if you want the light to be white at 100%, I send all that information with the on event, and the hue hub seamlessly switches to white. -- no indication it was ever red, while the Sengled bulbs turn on first (making them red) then transitions to white. Not a huge deal, but there are some quirks to be aware of when you use 3rd party bulbs in hue hub.
As long as it is a version 2 hub, I am sure you will be very happy with it. I put off hue for years, but then decided to give it a try. The experience is so much more fluid/organic feeling. The ability to send simple commands and let it take over all the work is a huge win. I am in the process of replacing my non hue lights with hue lights, and adding all sorts of new lighting to my system with hue and hue compatible outdoor lighting options.
Just installed this and I'm getting an error when i try to start the app and look for hubs...
Unexpected Error
An unexpected error has occurred trying to load the app. Check [Logs] for more information.
Error: Cannot cast object '[]' with class 'java.util.ArrayList' to class 'java.util.Map' due to: groovy.lang.GroovyRuntimeException: Could not find matching constructor for: java.util.Map()
This is what appears in the log:
2021-01-16 11:13:04.617 pm [error]
org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object '[]' with class 'java.util.ArrayList' to class 'java.util.Map' due to: groovy.lang.GroovyRuntimeException: Could not find matching constructor for: java.util.Map() on line 134 (mainPage)
New at this...just got my Hubitat a few days ago. Hope you can help..
Thanks. I will take a look. A. Other issue was fixed just the other day that was introduced because of a patch. I wonder if I’m this is related. Regardless I should have a fix tomorrow if I can reproduce.
Welcome to the community, and thank you for trying my software. I have identified and correct the bug. I cannot easily test the fix on my end, as I do not have any spare equipment for testing at this time. Can you update you app code (if using HPM, just us the update button, and pick my driver) and try again?
I had to deal with caching issues, but I fixed the issue and found the bug -- it was a bug I introduced during optimization coding. Sorry about that. I can now run a full install from HPM on my unused C3 hub. I did not perform the linking so let me know if you see any other issues.
@armand Thanks so much! The proactive devices state updates are really so important and nice compared with the built-in hue bridge integration in HE. One issue I identified is that the color change for white ambiance hue bulb (i.e. warm white to cool daylight) appears to be unavailable in HE?
HE doesn’t deal with color names per se. Some color name mappings exist, and some are managed by smart speakers, like Alexa.
I only deal in numbers, as that is really all HE supports. You can define any color of white by entering the color temperature in kelvin.
I asked Alexa to set light to warm white, and that worked. I asked to set to cool white and that works. I asked to set to daylight and that works. When I asked for cool daylight it was unknown.
I never heard the term cool daylight either, so I tried to look it up. I did find this chart, but it would imply cool and daylight are mutually exclusive.
@armand Thanks for your explaination as I'm quite new to HE while originally I centralised all my devices in alexa. Recently, I tried to centralise the devices in HE and use homebridge-hubitat to flow the devices to homekit dashboard (as homekit supports cantonese for my mum in Hong Kong); however, I cannot set the white ambiance hue bulbs to warm white via homekit dashboard/siri. Do you mean that I can define the color of the white ambiance hue bulbs in HE (e.g. 2XXXK for warm white/ 6XXXK for daylight) so that I could change their colors in homekit?
I think what you are experiencing is unique. I also use HomeKit via the makers API, and I can change color temps in HomeKit. I just tried warm white and daylight, and they both worked, although Siri kept asking if I wanted to toggle my lights which was odd.
As for temperature, the interface allows setting the color temperature, and I was referring to that. I am not aware of how to set a temperature via smart speaker, they all seem to want to set level, not color temp.
If you are using the hombridge app for HE, try replacing that with maker API app, and using homebridge-hubitat-makerapi (maybe it is a difference in the HeE app...
dev:6952021-02-15 08:40:32.208 pm errorjava.lang.IllegalArgumentException: A device with the same device network ID exists, Please use a different DNI (addChildDevice)
Do I need to remove the other Hue Bridge Integration app, or can the two live in peace?
Interesting. I don't know if I already fixed this. I did not see this until today. Can you make sure you have the latest version? I think I addressed an issue recently for something like this that was reported to me, but I am fuzzy on the details. Let me know if this is still an issue after using all the latest code.
