Homie future?

[Tieske]

based on this discussion: https://github.com/homieiot/convention/issues/221#issuecomment-1238338960

@Thalhammer wrote:

The proper way to fix it (as I have outlined a number of times) would probably result in what would be a more or less new protocol. I am not sure what you had in mind with "take this project forward" (i.e. fix the issues, add minor features or fix it properly), would be cool if you could elaborate a bit what you thought about.

My reflection on the state of home automation (HA), and why I landed with Homie;

A HA system conceptually consists of several components. If you look at the different implementations, you'll recognize them all;

1. devices and sensors
2. one or more "logic engines"; if-this-then-that...
3. GUI's for users to control their devices
4. a central service-bus that acts as the glue between the above 3 components

Every project, open source ones (Home-Assistant, OpenHAB, etc) as well as commercial ones (Zipato, Fibaro, Girder, etc) makes the same mistake by integrating those components. And hence duplicating work. Devices connecting to one service-bus are not able to talk to another service bus. Android/iPhone apps are always specific to a single backend. Home Assistant and OpenHAB both support a ton of hardware, all driver software is a duplication of effort.

Some of those are now becoming available as standardized packages, independent of the other components;

• MQTT as a service bus
• NodeRed as a logic engine (and some GUI)

Over the years I have been involved in multiple projects in this area;

• the xPL project It was driven by HA enthusiasts (when X-10 was still a thing 😄 ). We had a protocol based on UDP multicast, we developed many "schema"s for interoperability, but the technology (UDP) was too limited (lost packets anyone?) and only worked on a local subnet, and the schemas were badly designed
• UPnP forum for the Home Automation workgroup (now part of the Open Communication Foundation) This was a professional org, mainly ran by Philips and Samsung for their Media Players and DLNA initiative. Technology wise very well designed, but also build on old corporate tech (lots of XML). No easy to use tools available or SDK's for HA folks to quickly build their own kits. And UPnP also suffered from the device profile design being inconsistent across devices.

So based on my experience a system should have the following definitions/components to enable proper interoperability and prevent lock-in:

• a service bus that:
  • responds instantaneously (no polling)
  • lightweight to connect to for small devices
  • doesn't take connectivity for granted
  • not limited to a local network
• a protocol/convention that:
  • enables discovery/presence
  • enables discovery/description of capabilities
  • is "state" based, not RPC
• device profiles that describe the same functionality:
  • independent of hardware, the driver can bridge behaviour to this profile. So users get consistent behaviour independent of hardware
  • device type identifier, well versioned
  • minimum required functionality
  • optional functionality
  • for example; what controls does a light have? only dimmer, or dimmer + switch
  • how do the controls behave? dimming value 0 does that mean its off? how does it return if switched on? or should dimming value start at 1?
  • this is the hardest part by far imho.

With these components in place, any one can implement their own "logic engine" or GUI, independent. I would love to see the OpenHAB and Home-Assistant code bases be ripped apart, such that they only provide the drivers and expose everything in a standarized device-profile. That would allow me to use all connectivity and hardware without being stuck with their horrible scripting/automation engine (looking at you Home Assistant!), or their apps and GUIs

I'm in the process of replacing my HA (commercial vendor, device going out of support) and don't want to be tied to any of these integrated solutions again. Hence my Google foo led me to the Homie convention. Homie solved the service-bus part by taking an industry standard protocol (MQTT) and building on that. It also solves the device description part, which is the convention itself. NodeRed suits me fine as a logic engine (using @schaze s modules).

So moving forward;

• the convention has some issues, that could be fixed;
  • description takes way to many topics, should be a single document probably.
  • how do nodes and properties map onto implementations; a homie device can be a single device (1 light), or it can be a gateway (zwave/zigbee/Hue, with many devices).

interestingly @schaze did some work on models/profiles; https://github.com/homie-homecontrol/hc-node-homie-smarthome#node-documenation It would be nice to see if we could reuse some of that and bring it into the convention or as separate project under the same org.

As for breaking changes; we don't like them, but they are enablers for change and progress.

@Thalhammer wrote:

I wrote an extensive post in the team discussions about how I would like to move forward

Interested to hear your thoughts on this.

[Tieske]

I invited @Thalhammer and @ogghst , but couldn't add @schaze for some reason, so please sign up yourself (can use oauth2 with Github)

[Tieske]

Since we now have a proposal for Homie 5, I think we can close this now. Note that the collected design goals (in the spreadsheet) have been merged in the readme.

Please reopen if deemed necessary.