I'm going to offer this last note about CoCoHue 5.x and it is written to the person who wrote it. I'm not exactly sure who that is, but that is the "you" I am referring to. Everyone else will benefit from reading this as well.
Iām pleased to hear youāve reconsidered some of your changes to CoCoHue 5.0. In a perfect settings, I would ask you to go further and rollback all of your 5.x changes for the reason that I donāt think you have a sufficient understanding of your users, might be trying to do too much and are compromise your past work, and this community forum has qualities of "echo chamber" so you might not be getting the best feedback.
Though there are plenty of people on these forums that you might consider "users," they aren't ALL of your users. Most of your users, like me, won't communicate with you at all -- assume the quiet ones are happy users. I consider myself a happy CoCoHue user one most of the time. I'd bet that I interact with CoCoHue dozens of times a day.
Am I grateful for this? Sure. But I'm a "user," not your mother. I'm not going to kiss your holy ring because you built something for free, we're not friends, and I suspect the limited relationship we have between "maker" and "user" may be the happiest one we will ever have ;-).
Danny -- the TV installer I mentioned in a previous post -- is also a happy user. He's so happy, he put Hubitat, Hue, CoCoHue, a MiniPC running MicroK8S, and ngrok into his clients' homes. He took advantage of the massive growth in housing construction around Walt Disney World and was able to leave his job working as an A/V tech for a major resort chain and support his family with his own business installing TVs and home automation. He administers these environments remotely and has achieved the ability to scale the deployments across houses of similar design. He's been quite clever and his success is a story for another time
Danny's approach changes the way I look at Hubitat as a piece of bigger picture. If you were to put this setup into 20 homes and install 20 Hue light fixtures per home, you'd run into the unfortunate fact that as you added each light to its Hue hub, it would get a different ID in the Hue API. Which means if you want to standardize across homes and have a command that turns on lights in different configurations in different rooms, you'd set up scenes and groups in Hue and reference them by name.
The Living Room group, for instance, could have any number of lights in it, all with different assigned Hue IDs, but as long as you named the Living Group something standard -- "LVR_GRP" -- you could easily discover the group in the API, find its ID, and call its Hue endpoint to turn on all the lights in the group. Same goes for Hue Scenes, and I understand you can also invoke actions on these scenes. CoCoHue made this obvious and easy to do for a time.
You'd also teach users to communicate with devices using a series of commands that start with "Alexa, turn on XXXXXX" where XXXXXX is not necessarily a light or a series of lights but a lighting "experience." You'd have "Alexa turn off the living room" which would such shut off all lights in a living group regardless of their actual state. You'd have an "Alexa turn off the house" to shut off every light and "Alexa turn on the house" to return all of the lights to the state they were in when you left the house. Of course you can do all sorts of other things as Maker, but as a User who has limited time and attention for the minutiae, Danny thinks this is enough. Does Hubitat do this? Does Hue this? Do CoCoHue do this? Sort of yes, but nothing does it all in a repeatable way that can be deployed at scale and remain reliable over time.
It gets better. You can give the Hue app to the homeowner and let them tweak the lights all they want. Users can handle tweaking, but they can't grok how to make intelligent groups, name them well, add lots of lights to a group, or handle cases where 10 lights on multiple platforms all need to change from a command and autocorrect if some transient failure stops all the jobs on a particular platform from running. So long as the users don't blow up the groups or the scenes, the mapping of lights to group/scene remain the same. Danny also did something clever with Hue to reset a customer's hubs to its default when he installed it.
Life is great if every device were in Hue. But they aren't. This is where Hubitat comes in. You could, for instance, add Matter devices into these groups and call them along with the Hue lights. And with the Maker API, you wind up standard API interface to Hue, Matter, Zwave, and Zigbee devices. This makes Hubitat a kind of "proxy" to hardware devices.
As an aside, going further you can pull this map of APIs and express them as custom resources in Kubernetes and write services against them which Danny did (with help) and deploy that cluster on a mini PC running MicroK8S. For instance, my LVR_GRP gets activated with a turn_on event at 5 AM using the kubernetes job scheduler which is a bit more robust than the job schedulers in Hubitat or the Hue alone with configuration that can be manipulated using standard DevOps-y tooling. The K8S custom resource in the fronts a pod that can written in any language to make API calls to one or more Maker API services and provide a discoverable log stream or metrics endpoint that can be pulled remotely. This is powerful but it does shrink Hubitat's role in managing a smart home, which is a good thing because the Hubitat capability is limited. It is no trivial feat to write driver code for it in Groovy script (I think??). It is hard to test and deploy at scale. (If Hubitat didn't have a reliable means to backup and restore the state from files, the device would be useless, but also a topic for another time.)
I share this with you so that you can understand that CoCoHue is part of a bigger picture. One of its BEST qualities is that it treats Hue Scenes and Groups as SWITCHES.
Some time ago, smartPeople (not me) started treating the Hubitat Package Manager (HPM) as a potential attack vector for malicious code. Baring an alternative, they forked the HPM repo that had these package sources, kept it private, did some fancy security things with code signing and proxies, and used whitelisting to only include packages from sources they trusted. The CoCoHue source was one. Those smartPeople also started scraping GitHub API to see changes to release tags so that they can be aware that something has changed and update their whitelist. For CoCoHue, that would be this page
https://github.com/HubitatCommunity/CoCoHue/releases/
Now what they didn't see here is a release for 5.x.
The error in their judgement, and mine, is that we trusted the 5.x was a continuation of the general design of 4.x and that turned out to not be the case. They also trusted that they could pull code from the Hubitat Package Manager that pointed to this repo without risk.
12 Hubitat installations died in the process and had to be restored from backups.
Now one could easily point to the release notes and say -- "you didn't read them." I did read them. I didn't make the connection that the consequence of adopting the CoCoHue is that that nearly integration touching a scene would need to change and that I would break the interactions I have with Alexa to turn on and off scenes.
I remember reading something somewhere that suggested letting Alexa handle the communication between itself and Hue is better. I suppose that it might be in some cases, but not in my case or in Danny's. Learning new voice commands already well-practiced is a consider change of behavior and burden on the brain.
There was one enterprising person homeowner who decided to roll with the changes in 5.x and adjust his code to accept that Hubitat scenes would now be push button events. He was able to get this to work, having much more patience than me, but got burned when some other function fired several hundred thousand events to that Maker API endpoint in front of the push button. Since it was no longer a switch, he was not able to use the fail safe intrinsic in switches which is that if you to fire 100K "ON" events to a switch that was already on, the subsequent events are ignored. One of the most useful things about switches that only POWER ON is that the automated POWER OFF event (which is ignored by a Hue scene entirely) can be delayed so the switch state machine absorbs erroneous calls and does nothing for time and eventually triggered to reset itself to POWER OFF state that will accept new commands -- a kind of circuit breaker pattern. As the state machine was lost by making these things buttons that you can trigger with GET HTTP commands, those events managed to fire and hit the Hue box which triggered the scene many times (don't know if all 100K made it, but a bunch did) and burned out the bulbs and the light fixture socket. It also flooded his network with traffic making every other Zigbee device inoperable. The change from switch to button also makes the Maker API more vulnerable -- you have add rate limiting to the HTTP GET commands as you now longer have the circuit breaker.
So, can Hubitat more than just "inconvenience" a homeowner if something goes wrong? In this case, yes. You can call it a strange edge case only a nutter would create for himself if you wish, but I'm telling you the story as it happened, and there could have been 12 such nutters had the first one not been very noisy about his plight. Picture the sight of outdoor Jack Skellington Halloween inflatables (this is Disney World backyard) on people's lawns controlled with Hue lights burning out, setting fires to the background music "This is Halloween, every laugh and scream" airing on CNN. The lesson here is that any script loaded into a Hubitat box is a potential attack vector for malicious code and should be treated with the same due diligence -- release communication, package tagging, signing, software supply chain defenses -- a developer would treat any other code on the Hubitat box itself.
Now, are you the maker responsible for any of this? Hell no. Danny is responsible for this clients, takes actions to protect his users, implements controls, insures his business, etc. CoCoHue is not the only open-source app he deals with. I would not have mentioned him at all had I not thought that you might take pride in knowing your code is being used by people -- both high praise and all the thanks you should need. So, please give him some credit -- he doesn't have a poor support model. What is he has is a flaw in his ability to detect changes to CoCoHue using the standard, automated means he thought he could rely on -- which in this case is a 5.x release tag on Github.
Next time, can you make sure he has that? It's up to you, of course. I'm asking for a friend.
A reasonable person would look at this statement and ask "Why?" and suspect this isn't really an upgrade. I'm not always a reasonable person.
Thankfully, in the cases I have seen, the individuals all had reliable hub backups. They will stay at 4.x and will be using clones of CoCoHue for now. I'm not suggesting you are responsible for what they do, but as the 5.x branch breaks the API contracts you set previously in a way that would require many changes to the other things CoCoHue depends on, perhaps, they would be foolish to stay on your release train. A security-conscious person might think that anything that gets deployed on a Hubitat box that causes a user to have to restore a backup is MALWARE even if the maker's intentions are pure.
II don't see any pull requests or commentary on the 5.x changes in Github. I understand you maintain this work in your spare time. Itās a labor of love perhaps. But CoCoHue is an important piece of code to some people that has the potential to cause physical damage (as we have observed). You should not bear the burden of making sure your stuff works alone. Even if your release notes are the clearest of possible communication known to humans, it would not have replaced seeing the actual change in black and white more easily. Pull requests and their discussion give folks like me a means to help you and call you off the ledge if necessary. Tracking a pull request makes it harder to lose the thread between idea, intent, and resulting action.
There are folks here that will tell me after reading this note that I'm being harsh and attacking a person who is benevolently giving their time to others. They are entitled to do this. They may also be the sort who vote for candidates in elections on the basis of "vibes." I cannot control what they think or do.
If you feel that you've been attacked, you can fault my inability to communicate effectively. I don't know you, and have no reason to wish you ill. But I also don't want to get phone calls from people who say, "You told me to use this CoCoHue on my hub and I blew up my lamp post and summoned Satan from my garage sink." I hope you can make some changes to improve your release hygiene and not put too much reliance on release notes alone. If you do feel you've been victimized by me, I remind you that nobody is asking you to be a martyr for anyone's cause, and beg you to please step down off the crucifix.
It is the obligation of people who release code to the world to protect their users first effectively -- their good intentions are not enough. If the burden of this moral obligation is too much for you to take on, you are welcome to decline it and hand it off to others. But please get your Github in order and use it well. Don't treat this code as if you are just sharing some scripts with buddies and you know how it will be used in every possible case.
