Hey
I was wondering if there is anything that speaks against using ESPhome basically as an easy development environment for small projects, without ever having the plan to connect the devices to a HA instance (after the initial setup).
I could probably do all of that also via Arduino IDE, but esphome is such a nice toolbox with pre-existing building blocks, so I was just thinking about creating a new device, adding all the functionality, and going from there.
Why I don’t want to use Arduino IDE or similar options? Because I’m not that good of a developer
Bit of context: I was thinking about building a very minimalistic communicator device that I would like to give to my 6-year-old nephew. In its easiest form with 3 buttons ( ) that he can press and then I get a notification and I can send something easy back. Data sending either via mqtt or something similar, and wifi connection via the captive portal.
Any concerns? Or anyone who did something similar in the past and can tell a bit about it?
I just did something similar, a Wemos D1 Mini (ESP8266) fan controller for a new computer cabinet. If it can report sensors to HA, that’s great. But it does not rely on HA to determine or change the fan on/off/speed settings. It’s all internal to the YAML and the ESP8266.
If ESPHome doesn’t find itself connected to HA, it self-reboots after 15 minutes. This is a ‘safety’ precaution so you don’t lose OTA control of the device, e.g. if there was some kind of internal hangup on the ESP.
So if your project won’t always have access to an HA instance, be sure to include the following in your YAML:
You don’t even need HA to run ESPhome; it’ll run fine in it own docker (or run directly from python, at one stage i conpiled on my windows machine from command line )
Was just gonna lurk in this thread but this tidbit is very useful to me so wanted to thank you.
I flashed esphome to some Shellys I’m using to control the lights. Basically just made it so the light switches toggle scenes, with a fall back to a dumb light switch mode if HA or the router went down. Problem was the periodic flickering when the Shellys rebooted was annoying. You’ve pointed me to a likely fix.
but # in front of the line reading
api:
does the same trick.
The idea with fooling the reboot safety system is like ordering an antilock braking system for a car and switching it off. You will get what you asked for in case of need. For example if months later you descide to use it with HA again.
Having commented out the API will raise your attraction directly when doing so. (device not detected) Fooling around will ask you to think why device communicator got lost and won’t recover, until you remember you changed something vital.
Commenting out the API: doesn’t mean you won’t be able to edit/compile flash your device from within HA. It only stops this type of communication.
By omitting the api: component, you ensure that HA can never talk to this device.
(is that what OP really wants?)
By disabling automatic reboot, you permit it to interact with HA when desired, but prevent the device from being dependent on doing so.
Big difference.
This is in the end the scenario that would be most suitable for me, indeed. I do develop and compile and flash from my windows10 laptop, but hooking it to my own HA instance initially before I give it to my nephew isn’t really a bad thing I would say.
While we’re at it, and as I’m not 100% sure from reading the documentation: assuming I setup an external/cloud MQTT broker, and use mqtt instead of the native API, would the esphome node behave exactly like connected via native API? So showing up in esphome as a dedicated device etc? Or would I “just” be able to create dedicated mqtt-based sensors/entities in HA directly that interact with the node?
Not completely as the native api has some advances - still you should be able to control your esphome node over mqtt more or less the same (I think there is also some auto discovery for mqtt):
The ESPHome native API has many advantages over using MQTT for communication with Home Automation software (currently only Home Assistant). But MQTT is a great protocol and will never be removed. Features of native API (vs. MQTT):
Much more efficient: ESPHome encodes all messages in a highly optimized format with protocol buffers - for example binary sensor state messages are about 1/10 of the size.
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.
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.
Stability: Since ESPHome has far more control over the protocol than with MQTT, it’s really easy for us to roll out stability improvements.
Low Latency: The native API is optimized for very low latency, usually this is only a couple of milliseconds and far less than can be noticed by the eye.
If you do a bit of googling you should also find other people integrating the native api which are not related to HA. I remember for example a npm “port” of the native api.
Also beside utilizing the native api and mqtt via TCP/IP esphome also features a REST-API.
If you use any of them at home for your dev but they won’t be in use/accessible in your production location (nephews place), don’t forget to set reboot: 0s for EACH ONE that you use or you might find the device rebooting every 15min.
I discovered that the hard way.
You can configure the WiFi to connect to both your one at home and his wifi if you have some need (eg get sntp time)
I’m still working on the needed circuit to provide 5V PWM signal to the fans. Transistor and resistors only just arrived this evening.
There is one 3v3 relay to switch the 12VDC power to the fans on and off. There is a DHT22 temperature sensor to determine the current ambient/air temperature in the cabinet. Based on temperature ranges (in degrees Fahrenheit, US units of measure) the power relay is turned on when needed, and off when not. Four speeds (not including off) are: Low (25% PWM), Medium (50% PWM), High (75% PWM), and Maximum (100% PWM).
Here is the current YAML, using a BMP280 I2C device for temperature instead of the DHT22.
It’s a Wemos D1 Mini ESP8266 device. Pin D5 controls the power relay for 12VDC to the fans. Pin D6 is the PWM control line to the fans. It will be connected to an BC548 NPN transistor to switch the 5VDC from the Wemos D1 Mini as a PWM signal to the fans. This is necessary because the default PWM signal is only a 3v3 level, and computer fans expect 5v PWM signals. Pins D1 and D2 are used for the I2C signals from the BMP280. Switching to a DHT22 removes the I2C requirement and frees those two pins.
Hope this helps you in the current time.
switch:
- platform: template
id: fan_speed_off
turn_on_action:
- logger.log:
format: "The temperature sensor reports value %.1f, fans are OFF"
args: [ 'id(rack_temp_f).state' ]
- lambda: |-
id(rack_fan_speed).publish_state("Off");
- output.turn_off:
id: fan_power
- fan.turn_off:
id: fan_pwm
- platform: template
id: fan_speed_low
turn_on_action:
- logger.log:
format: "The temperature sensor reports value %.1f, fans are LOW"
args: [ 'id(rack_temp_f).state' ]
- lambda: |-
id(rack_fan_speed).publish_state("Low");
- fan.turn_on:
id: fan_pwm
speed: 25
- output.turn_on:
id: fan_power
- platform: template
id: fan_speed_medium
turn_on_action:
- logger.log:
format: "The temperature sensor reports value %.1f, fans are MEDIUM"
args: [ 'id(rack_temp_f).state' ]
- lambda: |-
id(rack_fan_speed).publish_state("Medium");
- fan.turn_on:
id: fan_pwm
speed: 50
- output.turn_on:
id: fan_power
- platform: template
id: fan_speed_high
turn_on_action:
- logger.log:
format: "The temperature sensor reports value %.1f, fans are HIGH"
args: [ 'id(rack_temp_f).state' ]
- lambda: |-
id(rack_fan_speed).publish_state("High");
- fan.turn_on:
id: fan_pwm
speed: 75
- output.turn_on:
id: fan_power
- platform: template
id: fan_speed_max
turn_on_action:
- logger.log:
format: "The temperature sensor reports value %.1f, fans are MAXIMUM"
args: [ 'id(rack_temp_f).state' ]
- lambda: |-
id(rack_fan_speed).publish_state("MAXIMUM");
- fan.turn_on:
id: fan_pwm
speed: 100
- output.turn_on:
id: fan_power
sensor:
- platform: bmp280
update_interval: 60s
address: 0x76
temperature:
id: rack_temp_f
name: "Rack Temperature"
unit_of_measurement: "°F"
filters:
lambda: |-
return (x * 1.8) + 32.0;
on_value_range:
- below: 75.0
then:
switch.turn_on: fan_speed_off
- above: 75.1
below: 77.0
then:
switch.turn_on: fan_speed_low
- above: 77.1
below: 79.0
then:
switch.turn_on: fan_speed_medium
- above: 79.1
below: 80.0
then:
switch.turn_on: fan_speed_high
- above: 80.1
then:
switch.turn_on: fan_speed_max
pressure:
id: rack_pressure
name: "Rack Pressure"
unit_of_measurement: "in"
filters:
lambda: |-
return (x * 0.02953);
#
# Text sensor provides literal speed
# Off / Low / Medium / High / MAXIMUM
#
text_sensor:
platform: template
id: rack_fan_speed
name: "Rack Fan Speed"
#
# fan_power is a relay switching 12VDC fan power on and off
# pwm_output is a speed control line to the PWM fan
#
output:
- platform: gpio
pin: D5
id: fan_power
- platform: esp8266_pwm
pin: D6
frequency: 500 Hz
id: pwm_output
#
# The fan object
#
fan:
- platform: speed
id: fan_pwm
name: "Rack Fan PWM"
output: pwm_output
speed_count: 100
restore_mode: ALWAYS_OFF
)
