Thank you!! I'll give that a try. I was already reading up on similar scenarios using variables to capture, but I was getting lost on how to capture a scene to a variable. However, your implementation is simple enough, as I don't necessarily need to revert to an exact state - simply setting default scene if captured in ON state would be good enough for me. I'll experiment with that.
1 Like
I am sure the answer to this is going to be "no way after all this time!", but I'd find it really useful if the devices brought into HE by this bridge were child devices to a main Cocohue parent. Make my device list so much more manageable :D. Various people have asked for a collapsible group structure (based on user tags) in the device list but it doesn't seem the request will be actioned.
I'm sure @bertabcd1234 can comment on this better than me, and likely should sit in another topic.... But for my own contribution.... I would add that a parent-child device has a certain technical implication for how the devices behave and how they can operate.... So if the need is purely visual and interface-driven, then I would suggest looking at some other option for achieving what you want, perhaps phrasing this sort of request around the outcome you want would be best, letting the device configuration be a by-product of how the request may be satisfied. Just my 2c....
3 Likes
They are child devices of the parent app, but that won't do anything for you on the Devices page. 
If you just want a quick way to see them all, searching/filtering for part of the DNI is easy and will work. All will contain "CCH/" at a minimum, which other device are unlikely to, or you can add in the next part, the parent app ID, which is almost certain to be unique.
2 Likes
At the moment I just sort on the device type and scroll in the relevant region but collapsing sections seems far and away the quickest - at least for the way my brain and fingers work. No I didn't seriously expect you to change your app 
For anyone interested: just released a minor update, v4.1.8, including minor fixes:
- better handling of unexpected color temperature reports of 0 (they will be ignored)
- changes to button commands (e.g.,
pushed()and similar) to handle any data type instead of explicitNumbers only - some typos like the above.
Not all files were touched, so while updating all is safe, you'd only need the specific drivers affected if you're doing things manually (and it is normal to still see some with older versions).
As usual, either manual install or HPM should both work to install or update (HPM recommended, or bundle recommended over individual files if doing manually).
5 Likes
Is anyone else seeing high usage like this?
My hub started crashing after an hour or so since the last two core platform updates. I've reverted back to 2.3.7.146 on my C8, and just paying more attention to logs. Noticed CocoHue is way up there. Am I doing something wrong, or is this normal? My Unifi integration is also very busy.
If this is normal for CocoHue, I'll keep digging elsewhere.
I see you have recently restarted (uptime ~11 minutes). I would wait a while longer to get a better reading on the performance more generally. Don't forget some of the stats are percentages, so they need to be viewed differently to a raw number, particularly so soon after a restart. You may also have some contention for the network or resources more generally if you have a lot of lighting changes happening along with apps like HADB and Unifi, potentially, running on the same hub.
IMHO, while you are working out what is going on, it may be worth creating a new topic to capture any information, then posting back here with any specifics relating to CocoHue. Like my comment above, there could be a few avenues to go down unrelated to Coco-Hue.
More specifically with Coco-Hue, I did have some issues with my HE hub at one point when I first started using the EventStream feature when I turned on the syncing on a change to a group. I think it would get into a bit of a loop or the fact I was updating multiple groups at once may have caused a flood of requests. More to do with how I set it up than anything wrong with the App. Given you have seen changes in behaviour that may coincide with platform updates or other activities, this is unlikely to be your issue.
Yeah I really don't think it's CoCoHue, just wanted to make sure it didn't look excessive.
Though it seems to be growing in percentage.
My guess is that because at night my external lights go through color cycles. I'll double-check tomorrow.
The good news is that my hub has been running for almost a whole hour. It was crashing after about 5-10 minutes when I started troubleshooting today. Been happening with the last two core firmware releases. If I still have issues, I'll definitely have to start a new thread.
I’ve never seen a state size high enough to show up red, or one that’s 6 digits. I would look into that first.
4 Likes
So the reason for the crashing was not a result of any of the integrations, despite being in red. It's some odd bug between the hub hardware or software, and my Unifi ecosystem. I saw some post that suggested turning off jumbo frames, (mine already are,) and due to that I just decided to reboot everything. I can't begin to explain why the hub would the only device on the network impacted by this, but it is what it is. Kinda scary if I was counting on it for something serious.
The high state size for Unifi was due to have alarm logging enabled. It was showing every single intrusion detection/etc. Insane.
That being said, my CoCoHue integrations are still exponentially higher than everything else. Can anyone else share a similar screenshot?
I do not have debug logging on, but I have the default descriptiveText one on. I've never touched that before. I assume it turns off all history. Maybe that would help? As long as the bulbs/groups that come through can still have the status read and be controlled appropriately.
If I was a betting man, this has to do with activating the "color loop effect" -- since it constantly reports back updates during the cycle. It might make sense to pause the parsing somehow while effects are enabled. Unless I'm way off-base here. Just seems like astronomically-higher usage than anything else.
If this was the case, you could work around it by creating a Hue scene and setting every device to the Prism effect. This would take the load of Hubitat and put it on the Hue Hub.
Don't forget the percentage of busy is just a percentage, if the hub isn't doing much, then it may be 51% of not much. The logging shouldn't be a major issue, but you could try turning it off if you want. The processing of the lighting effects may be increasing the load, you could try turning those off and seeing how it affects your stats.
I also notice you have two instances of CocoHue or at least two Hue bridges, is that correct?
I think the issue @stevenascott is referring to is not so much about where the effect is being controlled, more that as it plays out, the newer approach with the event stream means every change to a light on the Hue bridge is reported back to HE.
Logging has minimal impact on anything and no effect on events.
That's a good guess--each new state change is going to generate a change that the Bridge will see, wake the bridge driver to send to the hub and the app and child driver(s) to parse and then likely generate an event. This is one case where polling may work better than the eventstream/instant status API, though if there aren't any actual problems, it should be fine either way. If you have an active Hue system, CoCoHue is likely to be among your highest number of executions (unless you don't use eventstream and have polling either disabled or turned way down--either of which many have implications for how drivers report state and affect your use of the devices, less so if you make all your changes from the hub) just because the bridge driver has to wake for either every poll or every message from the eventstream.
As mentioned above, the precent in the table is just a percent of the busy percentage, and your total is barely over 5%. Half of that isn't much at all, IMO.
2 Likes
I'm not sure I'd consider 11.8% "high" and certainly not 11.8% of 2.6% (which is essentially what that number means), but it will typically wake more than other apps and drivers because it will do so for everything that comes into the eventstream (if you have the v2 API option enabled) or for polling (if enabled). The former depends on how much is happening on your Hue system, while the latter just happens regardless. Some setups may also use both,depending on your configuration.
2 Likes
None being used regularly... just 14 hue lights. Must be thr 1 minute polling.. thanks
Still curious, does no one use the flash command in WebCore? When doing this from the device properties, it works just fine, but not in WebCore. I want to use them for alerts/alarms, but I have to build custom flashing in webcore, and it's a pain, especially if you're running a separate loop for something else.
Just seeing this now, and I'm not sure, but if I had to guess, it would be some conflict between a webCoRE "emulated command" of the same name and the actual flash() command. In a test piston I created (I don't use webCoRE for much of anything besides testing things), all I can see is that the flash() command never actually makes it to the bulb driver, so I assume it's a webCoRE issue, though if anyone else has other devices with this command that they could try, that might narrow things down more.
I've released a minor update:
CoCoHue v4.1.9
- Added note to app that Hue Labs is now deprecated and, as such, so is the corresponding feature in CoCoHue. Existing activators should continue to work, though I'd recommend following Philips' suggestion of moving to alternative features instead (and "cleaning up" your Bridge from the Hue app afterwards).
- Added warning to logs when activator devices are used with the same information for people who never check the app (can be turned off on a device-by-device basis if so desired, but the same note as above applies)
Additional notes:
- This feature may be removed from CoCoHue in the future (if this is really a problem for anyone, old versions are still available...)
- For more from Philips themselves, see: Article Support Page | Philips Hue
Oh, also, the colorloop effect is likely meet the same fate in favor of dynamic scenes, so I'd suggest avoiding that one, too, and expect additional changes in the future.
3 Likes
