ESPHome binding for the Native API

This one seems a little cheap, if I buy them through amazon or e.g. AZDelivery where you selected the ESP8266 one ESP32 is typically 6 - 10€

Yes - if you connect everything with these cables there is no soldering to do.

Second attempt: https://www.amazon.com.be/-/nl/dp/B07XH45MWW/? :slight_smile:

I have no idea which manufacturer is good and which is not…

They’re all devboards, the 2 different links seem to be the same boards judging the images.
In general I buy these cheaply from Alixpress if I need them for future projects and locally when needed quickly. I like to keep with one or 2 types due to same pinout and sizes so the boards can be socketed and changed out(in case of issues).
My personal favorites are mh-et live and mh-et mini, but in general any esp32 will do.

I’m sorry; I don’t understand this. :slight_smile:

(Another question: the green wires are all connected, and lead to one wire out. What’s that white block called that connects them all? I don’t know which keyword to search for on amazon…)

Edit: a friend of mine pointed out I could connect the three outputs on the relais, of course…

The goods have been ordered! Exciting!

But now I’m trying to raise my understanding of how the software/firmware part works…

In the guide I’m sort of following (Step 4: Configure ESPHome to control the relays from Home Assistant - PieterBrinkman.com), there’s talk of yaml ‘commands’ (for lack of another word) that are being sent to the ESP board. But in the guide, that’s done via Home Assistant.

How would those yaml ‘commands’ be sent to the board with the ESPHome binding for openhab?

And would that be possible from a JS script?

@ErikDB The link describes how you should configure ESPHome firmware running on the ESP32 board.

After flashing the ESP32 device using ESPHome, the device should show up in your OH inbox (assuming you have installed the ESPHome binding).

“Find your device in Home Assistant, noticed that the device now has 3 entities. Click on the device and you’ll see that it has three switches, called IN1, IN2 and IN3.”

In OH terms; after adding the ESPHome thing from the inbox, link channels IN1, IN2 and IN3 to new or existing OH items.

1 Like

Noteworthy information on the latest build:

  • Added support for encrypted communication. At the same time plaintext passwords are now deprecated and will trigger a log warning. Big thanks to @amandel !
1 Like

And how do these channels accept the yaml ‘command’?

You are asking questions about how OH works in general, so I’ve collected a few links for you to read up on:

1 Like

Thanks. But I’ve got an understanding of how openHAB works.

But sending an ON command is different from sending an entire yaml code, no?

Excellent.

The Yaml is configuration of the Esphome firmware. It will manifest itself in OH as thing channels.

So the following code could be entered in one of the channels?

- platform: template
    name: "Fireplace_ignition"
    id: Fireplace_ignition
    turn_on_action:
      - then:
        - switch.turn_on: IN1
        - switch.turn_on: IN3
        - delay: 2s
        - switch.turn_off: IN1
        - switch.turn_off: IN3
        - switch.template.publish:
            id: Fireplace_ignition
            state: ON
    turn_off_action:
      - then:
        - switch.turn_on: IN1
        - switch.turn_on: IN2
        - switch.turn_on: IN3
        - delay: 1s
        - switch.turn_off: IN1
        - switch.turn_off: IN2
        - switch.turn_off: IN3
        - switch.template.publish:
            id: Fireplace_ignition
            state: OFF

No, what you pasted is part of the Esphome firmware configuration. This part in particular would end up in a switch thing channel in OH.

I suggest you read up on Esphome and install one of the sample firmware configurations to get some more understanding of what Esphome is https://esphome.io/

Happy hacking

1 Like

I have a better understanding now. I now see it’s all one yaml file, which got larger and larger throughout the guide (rather than different yaml files stored on various locations).

I also tried reading up on the template platform documentation. Since the sensor can’t ‘read’ the status of the fireplace, I don’t like the idea of a switch. The fireplace might be turned on by the remote, for example.

So I was thinking of a push button in openHAB, which starts some actions when it is ‘pressed’. But how would that work with turn_on and turn_off?

- platform: template
    name: "Fireplace_ignition"
    id: Fireplace_ignition
    turn_on_action:
      - then:
        - switch.turn_on: IN1
        - switch.turn_on: IN3
        - delay: 2s
        - switch.turn_off: IN1
        - switch.turn_off: IN3
        - switch.template.publish:
            id: Fireplace_ignition
            state: ON
    turn_off_action:
      - then:
        - switch.turn_on: IN1
        - switch.turn_on: IN2
        - switch.turn_on: IN3
        - delay: 1s
        - switch.turn_off: IN1
        - switch.turn_off: IN2
        - switch.turn_off: IN3
        - switch.template.publish:
            id: Fireplace_ignition
            state: OFF

Based on the code, it seems that when an ON command is sent to the Fireplace_ignition item/thing channel, the state will update to ON after approx 2 seconds, and vice versa OFF after 1 second. You can use the expiry functionality to reset the state to UNDEF. If you are using sitemaps you can add a mappings to the Switch component to create a button like descirbed in the example here: Sitemaps | openHAB

I have not read through the project in detail, so I don’t know if there is some sensing in place to account for commands from other devices. Assuming there is none, here is a few ways to detect flames:

  1. A flame sensor like 0.52€ 26% OFF|Ir Flammen erkennungs sensor modul Brandmelder Infrarot Empfänger modul für Arduino DIY Kit| | - AliExpress . I tried a similar one, and found the results very unsatisfying (distance to flame, inabilitiy to sense through glass). Recommend to skip.
  1. A temperature sensor (thermocouple) like MAX6675 K-Type Thermocouple Temperature Sensor — ESPHome that you can put inside the flame. I’m using a similar like this to monitor my wood burning fireplace. It monitors the temperature and gradient and provides me with a notification when I need to add more logs.
  2. An IR-based thermometer like MLX90614 non-contact thermometer — ESPHome that you can point at the flames
  3. Possibly sniffing the state of IN1-IN3 on the controller if external triggering is “readable”. Downside to this approach is that after an ESP reboot you do not know the actual state of the fireplace.

Adding any of these sensors is just a matter of physically connecting them as well as adding a few more lines in the ESPHome yaml + flashing.

1 Like

This looks very interesting! I assume it can get its power from the ESP32, parallel to the relay board?

I don’t think it will be a problem, but to be sure you need to check the capacity of your power supply and esp32 dev board regulator vs the power drain of your relays + sensors. I’m pretty sure you’ll be fine unless you power your esp32 board with a very old usb charger delivering way less than 1amps/5v.

1 Like

This is what I bought for the job, I assume that ‘2500 mA’ means it’s ok?

How should I connect both devices to the same power supplying pin? Is that possible with a Wago like this: https://www.amazon.com.be/-/nl/gp/aw/d/B079VR3S45?psc=1&ref=ppx_pop_mob_b_asin_title? Or is the pin too small (the specifications read min 0.14 cm diameter) for this Wago?

Definately

Wago is fine, you are the one choosing the wire diameter :wink: