Question, not an issue - Have you considered ESPHome as firmware ?

[Zixim]

Hello,

I've just ordered one of these, eagerly awaiting delivery 📦 . Meanwhile, I'm going through the docs, and I find myself wondering if you considered ESPHome at all?

Thanks for this great project!

[nplan]

Considered it briefly at the beginning, when looking into how to make Home Assistant configuration as easy as possible. But decided to use MQTT discovery in the end. What do you think would be the main advantage?

[Zixim]

The main advantage would be ease of adapting the functionality of the device, for those who like to tinker. For instance, changing what is displayed on screen becomes really simple, increasing/decreasing the temp/hum reporting interval. Probably other things that I could come up with, when I've actually got a device in hand 😝

For about 2 years, I've been using the Hugo buttons ( https://github.com/mcer12/Hugo-ESP8266 ), also without ESPHome. And they are a pain to update, even though they function wonderfully.

You're right about needing to use MQTT (the api just takes waaaay too long to connect to Home Assistant), but ESPHome also handles MQTT & discovery - so that shouldn't be any kind of hurdle.

[vincegre]

althouth the e-ink display used is not supported (yet) by ESPHome no ?

[nplan]

I will look into this. I see why integrating it into a widely used platform would be an advantage. Thanks for the idea.

[Zixim]

althouth the e-ink display used is not supported (yet) by ESPHome no ?

The display looks like it's using SPI. So there's a good chance that it's gonna be compatible with one of the display components already present in ESPHome, perhaps this one https://esphome.io/components/display/waveshare_epaper.html

edited : a letter.

[vincegre]

I will look into this. I see why integrating it into a widely used platform would be an advantage. Thanks for the idea.

Well if you can share even a draft document about GPIO used by the different components I would be happy to submit a draft sketch for test ;)

[nplan]

@vincegre Sure, please do. 🙂 You can see the GPIO definitions here (in the hw_rev_2_0 struct).

[Zixim]

I'm trying to get an ESPHome config up & running, but I'm not finding which pins are used on the ESP32 for SPI ? ESPHome needs CLK and MOSI , this is an example for a very similar display :

spi:
  clk_pin: 36 ?
  mosi_pin: 35 ?

display:
  - platform: waveshare_epaper
    cs_pin: 34
    dc_pin: 8
    busy_pin: 7
    reset_pin: 9
    model: 2.90in

I'm guessing 36 & 35 are the pins, but would like some confirmation ?

[Zixim]

Progress.

[pfoff]

Wow cute!-) platform.io based stuff is no real fun l8-] Do you have a repo for that or are you going to publish it via esphome?

[Zixim]

@nplan From what I see in the GPIO definitions, pin 14 is used as ADC for reading battery voltage, ESPHome won't allow this. Have a look at what they told me : https://github.com/esphome/issues/issues/3835

I'm afraid that this means Game Over for reading the battery on ESPHome 😭

[nplan]

@Zixim That's unfortunate. I was not aware of this limitation, since the firmware is always reading battery voltage before connecting to Wi-FI. Can ESPHome somehow be configured to also connect only after reading the ADC?

[Zixim]

@nplan I have a first, incomplete, ESPHome config that I'd like your input on. Specifically re the MQTT topics configuration. Should I post it here, or do you prefer a PR ?

[nplan]

@Zixim I created a new branch ESPHome. Please do a PR there.

[vincegre]

Any progress on the ESPHome support ? no time on my side till now to work on it so nothing to share :(

[Zixim]

@vincegre It works with a few caveats, biggest one is the hardware issue where ESPHome can not read the battery charge. Also, I haven't spent any time on cleaning up the MQTT topics, which would be needed before considering this useable for the wide public.

[vincegre]

@vincegre It works with a few caveats, biggest one is the hardware issue where ESPHome can not read the battery charge. Also, I haven't spent any time on cleaning up the MQTT topics, which would be needed before considering this useable for the wide public.

@Zixim Thanks for the update ;) For battery no big deal as it can be detected that battery is dead when you don't get anymore the cyclic wake-up to send sensors values ;) Why MQTT ? your esphome code doesn't use the native HA API ? Would you mind to share the code ?

[Zixim]

Our dev made the ESPHome branch where I uploaded what I had at that point : https://github.com/nplan/HomeButtons/tree/ESPHome

MQTT for ESPHome for 2 reasons, in no particular order :

• the original HomeButtons firmware master branch is also using MQTT for communications
• ESPHome + HA API is just too slow when using deepsleep/battery power. This is because HA API isn't push from device to HA (as one might expect), instead HA API is dependant on the HA server polling the ESPHome devices...which can take a while (up to a couple of minutes). MQTT just sends the data from ESPHome device to the MQTT broker, one-shot style, and then the device goes back to sleep, this entire process takes about 5 seconds from wake-up and back to sleep. Most of that time is spent trying to connect to WiFi, so use a fixed ip address (no DHCP) and wifi fastconnect in ESPHome config, to save a sec or 2.

[vincegre]

MQTT for ESPHome for 2 reasons, in no particular order :

• the original HomeButtons firmware master branch is also using MQTT for communications
• ESPHome + HA API is just too slow when using deepsleep/battery power. This is because HA API isn't push from device to HA (as one might expect), instead HA API is dependant on the HA server polling the ESPHome devices...which can take a while (up to a couple of minutes). MQTT just sends the data from ESPHome device to the MQTT broker, one-shot style, and then the device goes back to sleep, this entire process takes about 5 seconds from wake-up and back to sleep. Most of that time is spent trying to connect to WiFi, so use a fixed ip address (no DHCP) and wifi fastconnect in ESPHome config, to save a sec or 2.

Thanks for the explanation and yep makes perfect sense for a sleeping device ;) Will give a try with esphome code you linked :)

[sgrunf]

Our dev made the ESPHome branch where I uploaded what I had at that point : https://github.com/nplan/HomeButtons/tree/ESPHome

MQTT for ESPHome for 2 reasons, in no particular order :

• the original HomeButtons firmware master branch is also using MQTT for communications
• ESPHome + HA API is just too slow when using deepsleep/battery power. This is because HA API isn't push from device to HA (as one might expect), instead HA API is dependant on the HA server polling the ESPHome devices...which can take a while (up to a couple of minutes). MQTT just sends the data from ESPHome device to the MQTT broker, one-shot style, and then the device goes back to sleep, this entire process takes about 5 seconds from wake-up and back to sleep. Most of that time is spent trying to connect to WiFi, so use a fixed ip address (no DHCP) and wifi fastconnect in ESPHome config, to save a sec or 2.

Thank you for your work on Esphome version. I have a question: it would be possible to send material icons for epaper display view from Homeassistant to Esphome device?

[Zixim]

I don't know, but using icons in ESPHome is certainly possible. I'm not using esphome firmware on my HomeButtons, I tried it as a proof-of -concept but stopped it given the rapid & positive evolution of the "standard" firmware.