Using ESPhome for permanent non-HA usecase?

ESPHome
6

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 :yum:)

7

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.

1 Like
8

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.

9

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.

10

Sure it depends if the request is as topic states … permanent.

11

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?

12

my esphome devices communicate with HA just over mqtt so that makes HA optional

13

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):

Advantages over 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.

14

For api, wifi AND mqtt.

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)

15

Easy way would to consult the FAQ as it is just written there in plain text :writing_hand:

My node keeps reconnecting randomly

1 Like
16

FAQ delivers! :love_you_gesture:

17

I’ve used this lib with success. My build script uses it to check version # on the devices, for example.
https://github.com/esphome/aioesphomeapi

18

can you post the circuit diagram etc?

19

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
1 Like
20

I am using 12V fan, which transistor I should use?

21

Is that the complete YAML for the node?

22

I ordered NPN transistor BC548. As I understand, any NPN transistor that switches on with a base voltage of 3v3 should work. (I mentioned BC548 in my post above.)

23

No, it does not include the first several segments necessary for ESPHome. These are typically unique to each individual’s environment/configuration.

esphome:
  name: computer-rack-fans

esp8266:
  board: d1_mini

# Enable logging
logger:
  level: DEBUG

# Enable Home Assistant API
api:
  password: !secret api_password

ota:
  password: !secret ota_password

wifi:
  ssid:     !secret wifi_ssid
  password: !secret wifi_password

i2c:
  scl: D1
  sda: D2
  scan: true
24

This fellow has prepared quite a nice video performing the same temperature and PWM control of fans.

Because I’m not a practiced EE, I kept trying different configurations, but nothing worked reliably. UNTIL I read Post #12 from Railroader at the arduino forum. I did not have 1K ohm resistors, so used 1.5K ohm. Wiring exactly as suggested below, using transistor BC548 for switching, and accounting for the PWM signal inversion, my two 12VDC Noctua NF-P12 redux fans are working reliably as desired. :slight_smile:

ESPHome PWM Fan Controller
ESPHome PWM Fan Controller615×507 67 KB

frequency value is 25000 Hz
speed count value is 1000.
Off: The relay connecting 12VDC to the fans is switched off.
Low: The 12VDC relay is switched on and the PWM is set to 800.
Medium: The 12VDC relay is switched on and the PWM is set to 500.
High: The 12VDC relay is switched on and the PWM is set to 250.
Maximum: The 12VDC relay is switched on and the PWM is set to 1.

Railroader [Feb '21] (Using ESP to drive a computer 4pin fan - #12 by Railroader - Project Guidance - Arduino Forum) post #12

I think a common bipolar NPN transistor would work. A signal transistor, not any power one.
From controller D4 a serial resistor of some 1 kOhm to transistor Base. From +5 volt a 1 kOhm to transistor Collector. From Collector connect to fan PWM pin. Emitter connects to GND.
PWM will be reversed. PWM 255 will give 0% fan and PWM 0 will give 100%.

25

The ‘reversal’ of the PWM’s effect is because the fan’s PWM control line is pulled-down, so if the wire is left dangling, the fan will run at full speed. Pull it to 5V to stop.
(Or, maybe it’s exactly the other way 'round. Either way, it’s so that a disconnected control line will cause the fan to run, not stop.)