Switch default communication method from MQTT to the Home Assistant API

[cpyarger]

Is your feature request related to a problem? Please describe.

There are a bunch of issues using MQTT rather than the native API, ESPHome succulently listed them here

https://esphome.io/components/api.html#advantages-over-mqtt

Also, as a personal opinion, should the project really include home assistant in the name if it doesn't use the API for communication but uses a secondary unnecessary piece of software (The MQTT Broker)

Describe the solution you'd like

Implementation of the Home Assistant API as the primary communication path between HA, and openHASP

[nagyrobi]

@cpyarger note that the API you're referring to is not belonging to Home Assistant, it belongs to (and was developed by) ESPHome for a tighter integration of ESPHome platforms into Home Assistant. It's only usable by ESPHome and it was designed specifically for that.

OpenHASP's operation principle is completely different. If it would employ ESPHome's protocol, would appear in ESPHome's devices list, and OpenHASP's custom component wouldn't recognize it.

[cpyarger]

@nagyrobi
No, There are quite a few choices for APIs in Home Assistant that openHASP could use. ESPHome was an example of what could be accomplished using an API over MQTT,

https://developers.home-assistant.io/docs/api/rest/
https://developers.home-assistant.io/docs/api/native-app-integration
https://developers.home-assistant.io/docs/api/websocket

[nagyrobi]

It was misunderstandable, sorry. None of the above are used by ESPHome AFAIK.

MQTT is by far the simplest and easiest of all. And OpenHASP's goal is to be independent of Home Assistant - it can be used with any other home automation system which supports MQTT (and most of them do).

[cpyarger]

raises eyebrow it is called Open Home Assistant Switch Plate........... so much for being independent.......

Also, by adding a cleaner more intuitive method of communication in no way prevents you from keeping MQTT as another method.

The current Methodology for configuring OpenHASP is anything but simple or easy. You have to make changes in up to 2-3 places for any addition or update you want to have.

Please actually look into the idea and think about how it can be implemented, and the pros and cons of it before giving me any more half thought through responses.

[nagyrobi]

I think you misunderstand something. HA is an abbreviation of Home Automation both here and the original HASwitchPlate and HASPone. It never claimed to be exclusively affiliated to Home Assistant in any way. Home Automation is a generic term.

How about giving us a real hand on programming and developing, instead of just critcising? Feel free to do an implementation as you wish and submit a PR here.

People involved in this project are doing this on their own free time. That's pretty much what they were able to do in these circumstances. All, is open sourced, if you don't like it the way it is, go ahead and mod it yourself. See iif you can do the switch.

[fvanroie]

raises eyebrow it is called Open Home Assistant Switch Plate........... so much for being independent.......

This project is not called "Open Home Assistant Switch Plate". HASP stands for Home Automation Switch Plate since the early days. There are users with ioBroker, openHAB, nodeRED and Home Assistant platforms which all support MQTT as an open communication standard. So MQTT will be the default until something better comes along.

Please actually look into the idea and think about how it can be implemented, and the pros and cons of it before giving me any more half thought through responses.

@cpyarger Do have experience developing against the Home-Assistant APIs? The feature request needs an owner willing to code that interface. Feel free to share your ideas on how this can be implemented and maybe provide a proof-of-concept.

Please let me know if you are volunteering to implement this request. Otherwise this topic can be moved to the ideas discussions forum.

[cpyarger]

I do have some experience interfacing with the api, I had issues with the rtlamr2mqtt project loosing connection to the MQTT broker, at which point I modified the code to use the API directly.

I don't currently have much time in which to fully implement the request, but wanted to have a discussion regarding whether or not it makes sense to put time into developing. and if anyone would be interested in the feature.

[fvanroie]

Only the WebSocket API seems usable for two-way communications over one HTTP connection.
Subscribing to events/triggers and calling services looks the way to go.
A simple Arduino example that implements a basic two-way websocket API would be a good start imho.

[kquinsland]

raises eyebrow it is called Open Home Assistant Switch Plate........... so much for being independent.......

This confused me. MQTT is a very good choice for interoperability.

Also, by adding a cleaner more intuitive method of communication in no way prevents you from keeping MQTT as another method.

This depends a lot on the architecture. Without designing for it, one does not "just" give a codebase the ability to use a different transport in parallel. What happens if conflicting commands come in over mqtt and the native HA api at the same time?

The current Methodology for configuring OpenHASP is anything but simple or easy. You have to make changes in up to 2-3 places for any addition or update you want to have.

It's about as distributed as it is with a Tasmota device. If you're not going to type the commands directly/automatically, you've got a few pages to click to and adjust with a few reboots in there before everything is as expected. I've had to stop working on it, but I was working on a tool to abstract away some of the tedious bits of designing interfaces and deploying them to devices. There is some work in progress to de-couple the web configure screens from the actual logic that implements the config via a simple API. Tooling will still be better, but with that API you could start to build some stuff to make the process easier.

Please actually look into the idea and think about how it can be implemented, and the pros and cons of it before giving me any more half thought through responses.

Heh. On that note, about 1/2 of the points under "advantages over MQTT" can be argued to be disadvantages. I use both Tasmota and ESPHome extensively and I don't use the HA native integration specifically because of the "advantages:

• One-click configuration: ESPHome just needs one click to set up in Home Assistant - no more messing around with retained MQTT discovery messages and alike.

I also agree that everything should be automagic once HA and $device have a common communication channel. You can get a similar "once it's talking to MQTT, it'll just show up in HA" result with tasmota

• One less single point of failure: In the ESPHome native API each ESP is its own server. With MQTT, when the broker shuts off nothing can communicate anymore.

If you're running your MQTT broker on the same node that you're running HA on... this whole point is moot; if your MQTT instance is dead, so is your HA instance.

But if you're not, then yeah... a single MQTT broker is a point of failure. So is a single WiFi AP. So is a single power source. So is a single HA instance. I guess it really depends on what you consider to be the "heart" of your automation system; HA itself or the data itself. I have some ESPHome devices on my network that detect certain events. There are other devices on the network that need to react to state changes even if home assistant is not working. Every device speaks MQTT and the firmware on both uses a well known and public topic to exchange messages about the state.

It is reasonably easy (if excessive...) to set up a redundant wireless network and do run a MQTT broker in a highly available configuration.... which would make it far more reliable than a single instance of HA.

• Stability: Since ESPHome has far more control over the protocol than with MQTT, it’s really easy for us to roll out stability improvements.

I don't understand this argument. Stability of what exactly? There's been almost no change (and i'm pretty sure it's all been backward compatable) to how devices tell HA about their various capabilities.

---

TL;DR: what, exactly does switching away from MQTT improve?

[cpyarger]

Also, by adding a cleaner more intuitive method of communication in no way prevents you from keeping MQTT as another method.

This depends a lot on the architecture. Without designing for it, one does not "just" give a codebase the ability to use a different transport in parallel. What happens if conflicting commands come in over mqtt and the native HA api at the same time?

Why would you use them in parallel? If I have to choose between using an API or using MQTT I would prefer the API
If you want to run them in parallel though, let it be set up in a fallback configuration, I assume in your case it would be MQTT as the primary mode, and if it fails it falls back to the API. Personally I would use API exclusively,

TL;DR: what, exactly does switching away from MQTT improve?

Single location for configuration of a switchplate rather than having to maintain multiple config files.
Tasmota autoconfig last I used it was not that straightforward, and is yet another thing to have to run,

side note: I have had times where MQTT fails without home assistant failing, even running on the same device.

I have also had times where HA has stopped communicating randomly with the broker, or another client has. The end result being that I am unable to trust MQTT as a stable protocol for communication. and would prefer it to not be the only one.

[fvanroie]

I'm moving this to the Ideas discussion topic. The general view on Discord seems to be that it's a bad idea to use the native Home Assistant APIs for anything beyond simple usage. The view of the Home Assistant core team seems to be to use an integration for anything that's beyond what the front-end APIs offer...

[cpyarger]

The result of my testing around the subscribe_entities command

PS C:\Users\cpyar\Desktop\test> python .\websockettest.py
Opened connection
{"type":"auth_required","ha_version":"2022.4.0b1"}
{"type":"auth_ok","ha_version":"2022.4.0b1"}
{"id":7,"type":"result","success":true,"result":null}
{"id":7,"type":"event","event":{"a":{"light.kitchen":{"s":"on","a":{"supported_color_modes":["onoff"],"color_mode":"onoff","friendly_name":"Kitchen","supported_features":8},"c":{"id":"83db373a2b013c92533dc312b8cb19d0","parent_id":null,"user_id":"1dee9f1e977f4b3da9ab19feb05ee61c"},"lc":1648870498.575933},"switch.grow_light_plug":{"s":"off","a":{"friendly_name":"Grow Light Plug"},"c":"75b4f8c0408e977dad2dd702db0209c3","lc":1648850400.035601},"light.computer_light":{"s":"on","a":{"supported_color_modes":["onoff"],"color_mode":"onoff","friendly_name":"Computer Light","supported_features":8},"c":{"id":"f7d62a141ab81044e0edef1ad6423e31","parent_id":null,"user_id":"1dee9f1e977f4b3da9ab19feb05ee61c"},"lc":1648870500.15474}}}}     
{"id":7,"type":"event","event":{"c":{"switch.grow_light_plug":{"+":{"s":"on","lc":1648870587.351429,"c":{"user_id":"1dee9f1e977f4b3da9ab19feb05ee61c","id":"7bdaf8598f8a380290ee0e90f67b6a3d"}}}}}}
{"id":7,"type":"event","event":{"c":{"switch.grow_light_plug":{"+":{"s":"off","lc":1648870588.405004,"c":"3ea5ffdb63a319122958e1e558ae7a2d"}}}}}
{"id":7,"type":"event","event":{"c":{"light.computer_light":{"+":{"s":"off","lc":1648870590.334604,"c":"706e1f3e9cb045e9e5b26cf753f0b355"},"-":{"a":["color_mode"]}}}}}
{"id":7,"type":"event","event":{"c":{"light.computer_light":{"+":{"s":"on","lc":1648870591.270196,"c":"5d9251205195bf0aa649697335446260","a":{"color_mode":"onoff"}}}}}}
{"id":7,"type":"event","event":{"c":{"light.kitchen":{"+":{"s":"off","lc":1648870592.150506,"c":"2a176f041ec2cc3627da9f9150b83d7d"},"-":{"a":["color_mode"]}}}}}
{"id":7,"type":"event","event":{"c":{"light.kitchen":{"+":{"s":"on","lc":1648870592.988872,"c":"f99a9cb16842cbc46ae88f77d579b2fa","a":{"color_mode":"onoff"}}}}}}

using the following code

import websocket
import _thread
import time
import rel

def on_message(ws, message):
    print(message)

def on_error(ws, error):
    print(error)

def on_close(ws, close_status_code, close_msg):
    print("### closed ###")

def on_open(ws):
    #ws.send('{"type": "auth",  "access_token": "ACCESS TOKEN HERE"}')
    ws.send('{"type": "auth",  "access_token": "ACCESS TOKEN HERE"}')
    print("Opened connection")
    ws.send("{\"id\": 7, \"type\": \"subscribe_entities\", \"entity_ids\": [\"light.computer_light\", \"light.kitchen\", \"switch.grow_light_plug\"]}");
    #ws.send('{"id": 18, "type": "subscribe_events", "event_type": "state_changed"}')

if __name__ == "__main__":
    websocket.enableTrace(False)
    #ws = websocket.WebSocketApp("ws://localhost:8123/api/websocket",
    ws = websocket.WebSocketApp("wss://**REDACTED**:8123/api/websocket",
                              on_open=on_open,
                              on_message=on_message,
                              on_error=on_error,
                              on_close=on_close)
    ws.run_forever(dispatcher=rel)  # Set dispatcher to automatic reconnection
    rel.signal(2, rel.abort)  # Keyboard Interrupt
    rel.dispatch()

[fvanroie]

I have core-2022.3.8 and it doesn't seem to work there.
I see you're on 2022.4.0b1 so subscribe_entities must be a recent addition.
Good to see that it seems to do the job.

[cpyarger]

the command was added in 2022.4.0b0 it looks like

[cpyarger]

To be fair, I cloned HA, and am running it in vscode / dev container mode because I'd rather not mess with my production system