@xap things seem to be working fine with latest version, however, I noticed that the scenes no longer appear to have the "push button" option anymore? RM sees it as an option, but the device page doesn't show it anymore and using the RM push button causes an error saying that the device doesn't support "push button"
Was this a deliberate change or possibly an oversight? Since I can still use "switch on" it's OK if it was deliberate, but I prefer to use button presses.
Thanks again for all your support and quick attention to errors.
I had removed the explicit definition of the "push" command as the explicit definitions don't seem to be needed for the other built-in capabilities. However, it appears the PushableButton capability does still need the command to be explicitly defined. So... I've added it back in and tested that it works for me, so if you update the driver for the Scene you should have that back. My bad, should've tested the change more.
@xap I'm noticing some system lag again but not seeing any errors in log, have you noticed anything in your setup. I have quite a few Hue lights but I have the majority setup in "groups" so I only have:
6 bulbs
8 scenes
11 groups
I used Hue b Smart in ST and didn't get the impression it was burdening the hub, is there something different with the HE port that might be causing this? The built-in HE Hue integration doesn't exhibit this for me (albiet without the scene capabilities).
Well, with the SSDP not polling any more there's only a single REST request every five minutes (and refresh requests are sent when you change a bulb's state) so there shouldn't be any real load on the system. If you have the debug logging on that generates a LOT of info though so that will slow things down probably.
I've got 31 hue bulbs with 2 bridges and I'm not seeing slow down.
I disabled logging and will monitor the system performance over a period of time. Hopefully it's just my imagination, I really don't want to give up the scene functionality of this port.
If only HE staff would add support for transition times to the stock HE integration.... It's really the primary "feature" that I don't want to live without if possible, and the flash feature is a real plus too.
I'm glad I did, that would have been a wasted couple of hours. I didn't realize you had posted it here already. Just wanted to say that your driver/app is working fine for me in a system with 2 bridges and 95~ lights in 23 "groups"/rooms.
Since you are checking the bridges every 5 minutes I had to test and see if there was a delay when your refresh polled the hub, and unfortunately there is still a little bit of delay, but it seems to be less than the built in driver and it only happens every 5 minutes rather than every minute, so it's a big improvement in responsiveness/"my wife gets pissed at the money I spent when the light doesn't turn on immediately" factor.
After a few attempts I'm seeing anywhere from a 1-4 second delay in rule processing compared to 1-10 for the built in driver. This is a 1-4 second delay every 5 minutes compared to 1-10 every minute.
I'll check out your refresh code and see if there are any possible improvements for speed/clock cycle usage, I'll send a pull request your way if I stumble on anything. I think some low hanging fruit would be breaking up the bridges so that they never refresh at the same time.
If you make a few tweaks to the endpoints you are calling, it should get rid of the weird lag everytime discoverItems() is run on hue bridges containing a ludicrous amount of scenes.
That's interesting. I'll have a look at that. I'm thinking maybe split the discovery up as you suggest but also to use the asynchronous http methods so the different groups can be processed concurrently.
This sounds a lot like what I am seeing with regards to the system slowness with this app installed. I thought it was specific to this app but after going back to the stock integration I was seeing it even worse, but more predictable since it's occurring more often.
I just checked and I indeed had all the stock hue scenes installed in my groups (I also NEVER use them). Just deleted all off them and already notice a significant change in performance. I'll be reconfiguring my HE back to Hue B Smart tomorrow to see if things are better now that I only have the actual scenes that I use installed on the Hue Bridge.
@xap is SUPER responsive when it comes to addressing possible issues with this app so I'm sure these alternative methods will be implemented shortly which should help even more!
Edit: I should also mention that I only really started to see the performance degradation when I added about 20 white ambiance bulbs and 5 groups, along with their default group scenes. Previously I only had 4 Groups and so I didn't seem as noticeable.
It also might save a few clock cycles using JsonSlurper() with INDEX_OVERLAY as the JsonParserType rather than JsonSlurperClassic(). I tried it out some last night and it didn't crash anything, but I didn't get a chance to run it through a profiler to see how much faster it was -- I've never run debug/profilers on java/groovy code so I haven't had a chance to setup an environment for it yet.
@Collisionc@xap Finished re-installing and configuring Hue B Smart this morning. With the stock scenes removed it's definitely performing better for me. I still get a slow down periodically (probably during the scheduled refresh) but it's not as disruptive as before. I'd say the delay is only a few seconds now, not perfect, but MUCH improved.
@xap noticed this in my logs, don't know if it's a problem or something that should even be displaying with debug logging disabled. The two devices are hue white (2700k) groups.
Nope, that's nothing to worry about. However, it shouldn't be logged if debug logging is switched off. I suggest check if you are running the latest device drivers and double check your debug logging setting.
I have had a go at optimising the device polling so that it only polls the state of lights and groups. It should still discover scenes correctly when setting up.
I am not planning to do any more modifications to these drivers now. They work perfectly for me at the moment and my intent was just to cover the gap in functionality until HE natively supports scenes. I hadn't intended to build a competing driver.
Please feel free to fork the code if anyone wants to make further changes.
I ended up finding out what was causing the latency issues on the hubitat driver:
tl;dr: Hubitat does some talking to their amazon server as each minute ticks over, and it looks like it is not setup to run via async. Because your version of hue doesn't automatically stick the hub to refresh at xx:xx:00, you are missing the 1-5 seconds where the hub is unable to send any network commands.
The amazon server is probably being used for either cloud access or alexa.
That's interesting. I guess Hubitat is polling for incoming messages hence synchronous maybe.
The biggest impact on the performance I've seen whilst testing is simply when debugging is on. Converting the JSON into a string for logging seems to have a significant impact. If you're doing any performance testing just make sure debug is disabled (as I'm sure you do )
I doubled checked that I have the latest drivers, and my logging is disabled in the app settings. But, the referenced debug logging is still occuring on the "smart lux group". Anything else I should be checking for?
Edit: Compared the code for smart lux group and the other groups and found some differences in the parse events into attributes section.
I didn't realize you had posted it here already. Just wanted to say that your driver/app is working fine for me in a system with 2 bridges and 95~ lights in 23 "groups"/rooms.
)
