Apparently this requires the api:
section add to the .yaml
file. Is there another way to connect? I do not use Home Assistant so none of my ESPHome devices include this section as it caused them to reboot every 15 minutes. If I reconfigure them and include the api:
section, will this contrib keep the device from rebooting unless the reboot is necessary to reconnect to Node-RED?
Do you have an MQTT broker? I use ESPHome and never use HA. I simply route everything via MQTT.
I do, and have been using it for my current devices, but there are some items which I thought do not work well with MQTT such as camera devices.
OK, not used a camera on an ESP to be honest. Probably depends on what you are doing with it. Single images probably OK. streamed video maybe not so much.
Even so though, I imagine there are ways to stream a video stream.
I use ESPhome as well with MQTT (no HA) and it works really well in Node-Red.
I have 2 used-cased for ESPHome with video (some garden monitoring), where I get the alerts via MQTT and get the video
and picture feeds via http / RTSP. Yes there are some delays but they are usually less than 3 sec.
My main video- surveillance is via BlueIris where I get all the alerts and handle the vide/picture feeds. Any alert from BueIris is sent to NR with details on where the respective alert file (Video or JPG) is stored on my NAS.. which I than can watch in NR
I recognize MQTT can be used, negating the need for the contrib and that one less contrib in Node-Red is probably a good thing. But I'm still interested to know if the contrib will replace the home assistant connection the API section requires to keep from rebooting the ESPHome device.
Julian,
My understanding was that the Home Assistant controlling body/foundation has subsumed the ESPHome project - i could imagine them closing down/stopping developing some of the non core HA functionality in HA going forward - had you read anything about this ?
Craig
Hi Craig,
Both HA and ESPHome now are part of the Open Home foundation.
I can't see any sign of ESPHome going away and I know that many people use it without HA.
The foundation was created to manage a number of now critical home automation projects.
I have been using these nodes for about a year now and I love them.
Advantages over MQTT:
- The configured sensors within the ESPHome device's yaml are auto discovered by the config node. No more guessing what topic the ESP based device is using.
- You don't need an MQTT broker, or to manage another authentication layer
- It's really fast - combined with the NRCHKB HomeKit Nodes, the device response time is damn near instant when interacting with Siri or the Home.app
- It's easy to lookup what the network address is of the various ESPHome devices since the address is in the config node. When you use MQTT you don't know where the broadcasted messages are coming from.
Yes it does. The ESPHome device recognizes the API connection from this node. It only reboots if the connection is dropped for the configured period of time (which is by design).
Not disagreeing with your assessment - however:
Useful - but I use standard YAML components in all my ESPhome devices - that's what drew me to it in the first place.
I use a standard topic structure for all devices so each sensor YAML automatically goes into the right place - no guessing required, the structure is always the same and all ESP devices have a common root.
All my IoT devices have static IP's so they still work even if the router fails. The standard YAML build for all devices include publishing the IP address to MQTT to avoid confusion.
I've not used the nodes so not sure if they tell you if each device is on/off-line? My MQTT posts include status and timestamp.
The advantage of MQTT is that, if you want/need to access the data from another instance of Node-RED or from some other tooling, you can. I have at least a live and a dev instance of Node-RED so I can do dev/test against the live sensors using the same topics as live.
So, as usual with Node-RED, you have choices and can use whatever best fits your needs. Thanks for sharing this.