Any specific concerns? You just have debug logging enabled on the device (presumably the new one, and it will turn off on its own).
No I ment that error where response from bridge is null. That is nothing to worry about?
The response from the Bridge is an HTTP 200, which is OK (literally "OK" but also the expected outcome ). The actual data is not logged here since it's often quite lengthy. The "null" you see is for extra data that may sometimes be passed to the handler by the app or driver itself. There is none in this case.
I can't thank you enough for putting this as an option. Hubitat now acts almost exactly as the automations in a Hue Hub except with even greater options. It truly is wonderful!
With the above said, I'd like to make one suggestion. Is it possible that the custom transition duration number in preferences be changed to either seconds, or ideally, minutes? This would simplify it for users by having the driver do the math calculations before sending it to the API.
It would also make it easier to use Rule Machine if the driver eventually allows dynamically setting this number. For instance, if someone (okay, me!) wanted to have the duration change each day based on the differences between two times, Rule Machine initially kicks that number out in minutes. Granted, the next action could be hub math to convert, but most people think in hours and minutes rather than seconds and milliseconds.
I thought about it that way and really didn't have a preference except that ms was easier because that's what the API uses. If anyone else doesn't care, I'll make this change in the next release.
EDIT: And released, version 5.2.8.
Thanks so much for putting this in.
I am not sure how to use it, however. Is it set on the device, or the scene?
Also, is it possible to run dynamic scenes on devices that are setup through Hue, but are not Hue devices (generic LED strips, for example)?
It is set up on the scene device in Hubitat. Look at the preferences (and the command descriptions above or in state), and you will see it.
There is no way to control a device that is not in Hubitat, but you should still be able to add compatible third-party lightstrips to your Hue system, including in scenes, and then to Hubitat. (I don't see why dynamic scenes wouldn't work, but it's possible non-Hue devices may have some limitations.) It sounds like you have already done at least the first thing.
I cannot see this in Preferences for the Scene, or the Device
That is the device
This is for the Scene
It's the first two preferences in your screenshot for the scene device, your second screenshot, assuming you mean custom brightness or transition durations.
These settings are used, if applicable, when activated with the button numbers specified in the above post (or state
after you hit "Save"). If you just want dynamic or static activation specifically instead of the default, these settings are not applicable, but the (lower-numbered) button numbers referenced above are still how you do this.
Okay. A little slow here but I think I am understanding.
Where and how are the button numbers used?
If you want to test them (or run the command manually for whatever reason), you use the with the "Push" command on the device detail page.
If you want to use them in the automation, you'll have to make your app push that button number. How you do this will depend on the app. Room Lighting can do it by using the device as a button device in an Activate or Turn Off setting, for example; RM or BC can do it with rule actions, and many other apps have some way to do something similar as well.
EDIT: Maybe some way to set a "default" action for the on()
command on the device would be good for apps that don't have this or voice assistants? (Like an "On command pushes button x" preference? Right now, it's
1
, which works for any scene as the default activation type...)
@cuirbear, here is a basic example I use at home:
Starting at 8pm, Hubitat pushes button 5 on my Master Bedroom - Nighttime scene.
As set in the preferences:
I have a custom duration set to 5,400 seconds (i.e. 90 minutes). Basically, Hubitat is telling the Hue Hub to transition to my Nighttime scene over the next 90 minutes. It works wonderfully as the Hue Hub is excellent in these scenarios. Hue handles the color transitions from one scene to the next and Hubitat just commands it to do so.
Personally, I would be hesitant with this direction and feel that "On" should represent what a person would do using the Hue app (i.e. immediate activation). Theoretically, if this was protected via a preference, then maybe. It might be better to just create a virtual switch, send that to a voice assistant, and have a rule trigger the correct button push when the switch turns on.
Hi all, and @bertabcd1234 I've suddenly encountered a problem on a number of rules that have been running fine for ages and i wonder if there has been a change in the app that caused it, i need to do a workaround, or i have just been lucky up to now and i need to implement differently.
Summary of Setup:
Using V2 api, v1 polling on 1 minute default.
Room lighting rule controls:
Hue Scene (by button push 1 to activate)
Hue Group (switch) to turn off
Rule:
Motion activates and presses button 1 on scene
Limit activation when Lux >5 (only comes on when dark)
Motion inactive turns off (switches off hue group switch).
Other stuff:
Other means to activate - hue group (switch) turns on. I did this so that the rule would activate if the lights were turned on manually by Alexa, or the hue remote. This has been working well for as long as i remember. For info, in the logs I saw the rule activated by motion, a couple of seconds later the hue group turn on (logs say already activated, so ignoring) - all working great.
New problem:
The lights have stopped switching off very frequently when motion is inactive. When i look at the logs it appears to be because for some reason well into the activated time there is a new / duplicate entry for the hue group switch coming on (even though it never went off) - after the motion inactive timer starts or the 'motion time stays over' event, but before the light goes off. The side effect of that is because the lux level is above the threshold (the lights are already on), it prevents the rule from 'activating' and thus the 'switching off on motion inactive' thereafter does not happen.
Q: Has something changed in the V1 refresh logic that would make this happen (a duplicate hue group switch on emtry, even though it was already on)? I find it extremely unlikely that for over a year i have been very lucky that this has never happened once, and now suddenly it is happening multiple times a day - but it is possible, I guess.
Welcome anyones thoughts, thanks.
I am not aware of any changes that would affect on/off parsing for groups with any of the recent releases, particularly in V1 parsing (which has not been touched in some time), which seems ultimately like the main question above. Even if it did, duplicate state changes are generally filtered out by the app before they make it to the platform and by the platform itself unless an all specifically subscribes to an unfiltered list, so I'm not exactly sure what would be causing this issue for you, but seeing the actual logs and event history (events matter for RL; device logs don't but can be interesting if the device is not working as expected) as well as the RL logs and your RL setup may be interesting. If not related to this integration, a topic elsewhere may be appropriate, but without seeing more, I'm not sure if that is really the case or not.
I'm getting a series of these regularly on one of my Hue hubs and also it often struggles to load the contents of the screen (the rooms etc) in the mobile app. Lights are sometimes laggy or none existent and my bedroom light randomly turns on (major WAF impact).
Edit - also with debug
Any idea what I can do to fix?
The Hue mobile app? Sounds like a network connectivity problem with your Bridge. I would check that.
I do see a lot connections/disconnections of the eventstream on Hubitat, but the integration filters them out if they occur within a few seconds of each other, as the disconnections seem to be spurious. But yours are accompanied by an HTTP 408, which is an HTTP timeout, further fueling my suspicion of a network connectivity problem with your Bridge. If you don't have a reserved IP address for your Bridge, that could also help with this occasionally (though the integration will catch up after the first failure), but I don't think IP address changes can account for what you're seeing this frequently.
There's a lot of discussion on this above but is basically an occasional error you'll get when the JSON data with event changes from Hue is quite long and truncated (presumably by the hub, cause TBD, for some reason). States should catch up on the next poll.
yep i was just debugging it and see the whole end of the json string is cut off.. should i turn polling on.. since without it i dont think device states would ever catch up when this error occurs.. for me it happens when i have a light switch linked to 4 hue color downlights and turn on/off the master switch.
i only have hue bulbs and never control them directly from the hue app or outside of hubitat so really never needed polling..
also not sure if i should have the v1 api for polling on or not.. currently off and i have reneabled polling to 5 minutes.
That is up to you--and whether any of your automations depend on these states--but it is the default and recommended setting, as indicated in the UI and documentation, for that reason.