At the moment I hold the references to the hardware, the digitalWrite() etc. What makes me slightly resistive to is that you more-or-less relinquish some or all of that low level control into higher level APIs. While that can have advantages it does also have disadvantages. While sometimes APIs and abstractions make things easier, they can also be a pain in the neck to get around when they don’t work or don’t want to do the thing you want to do. “I’m sorry, I can’t let you do that Dave”, are all too common. When the API really means, “I don’t know how to do that.”
I know the home automation space is still in flux, but just because a convention, api or system is open source does not mean you aren’t “boxing yourself in” to a system if you adopt it. To that end I don’t really want to create “Home Assistant” (or any other) specific end points/devices. I would rather use a standard protocol that is supported or can easily be supported by any and all such systems.
As an example. MQTT discovery. I have seen this banded around as a “standard”, but there is no mention of it in the MQTT protocol documentation. Now while that’s not surprising as MQTT does not involve itself in how you use the application protocol, the only references to MQTT discovery are within Home Assistant.
There is a good potential that the MQTT Discovery used by HA will propagate out to other systems and more devices, but it could also just get surpassed by something else. I suppose that’s the space we are in though, different systems bumping elbows for dominance. I would prefer that, where possible, standard protocols that exist outside of anyone system are used to communicate freely between them. They did this once before, it was called the Internet, apparently it was quite successful.
One related thing I want to avoid is having devices which are “Owned” by one hub or other. “Owned” meaning that you must communicate with them via that hub or risk corruption of state etc. I want my devices to be standalone and smart enough to be tinkered with by any API/Device/mechanism. If HA turns it on, can OH turn it off and they still play nice for example?
On discovery. It works absolutely fine as “Discovery”, but unfortunately that is, just like most other machine discovery mechanism ever made, even DHCP, full of draw backs and annoyances. Double discovery, missed discovery, cryptic names, discovered devices not responding, incorrect auto-generated config, the config buried off in machine generated, overly verbose, uninitiative places like the .storeage hierarchy.
And when you come to try and fix it… hash keys everywhere.
Hash keys are brilliant for machines to be able to generate and have a very low probability of collision, but they are NOT human consumable. Peppering config files with hash keys is irritating even for experienced developers. Especially when they create associations between things using them. I get why they use them, but the cost is too great IMHO. My attempts to clean out of the rubbish generated by discovery in the .storeage hierarchy was painful and tedious.
I’d go as far as to say the .storeage hierarchy is no better than the Windows Registry and I have yet to meet one person who like dealing with that.
I think I will take the risk that the configuration.yaml style config will be around for a while and stick to manually configuring things.
I know I may sound negative. It’s a bad habit of mine to immediately look for problems in things. However if you don’t look for problems, you won’t look for solutions and what is the point of being an engineer if you don’t have problems to solve. Every problem has a solution, but never forget that ever solution has problems.
