Support for non-ESP microcontrollers using RF modules

[henrikssn]

Describe the problem you have/What new integration you would like

While ESPs are supernice together with ESPHome for grid powered devices, I find it tricky to make it work on batteries. The fact that wakeup from deep sleep takes ~ seconds and that light sleep is consuming ~ mA of current means that battery life is going to be severely limited.

My proposal is to add support for some AVR platform and to use an RF module to make it wireless. One option would be to base this on some commonly available development platform, such as Adafruit Feather 32u4, Adafruit Feather M0 (ARM Cortex M0 / RFM69), Moteino M0 (ARM Cortex M0 / RFM69) or Whisper Node (328p / RFM69). These all have sleep current in the uA range and can go from sleep to RX in ~ ms. There are already efforts that do OTA updates for them, for example FOTA from MySensors or WirelessProgramming from LowPowerLab.

Please describe your use case for this integration and alternatives you've tried:

I want to run battery powered sensors that can do reading every ~ minute and have battery life that lasts for ~ years.

Additional context

The problems that are likely to arise to from this includes:

• Compilation issues in core or integrations due to new uC platform
• OTA updater needs some new code to support different bootloader
• In addition to WiFi, there needs to be support for new transport protocol (RF)
• A new node type (gateway) needs to be introduced that can forward messages between RF powered devices and Home Assistant. This could possibly be achieved by wiring an RF module directly to the RPi running Home Assistant (e.g. http://www.kittley.com/2018/04/05/blog-rfm69-pi).

The advantages of doing this in ESPHome instead of starting a new framework are:

• Most (if not all) integrations can be shared
• The frontend / hassio plugin can be shared
• Large part of configuration can be shared (common yaml format)

I am happy to help out / drive this, if you deem it a reasonable extension for this project.

[henrikssn]

Mentioning @OttoWinter for visibility.

[randybb]

Basically you are looking for similar implementation as https://www.mysensors.org/ and then it can be related to serial bridge #660 and auto-dicovery #678 .

[henrikssn]

Yes, one option is to merge mysensors.org with all the bells and whistles into ESPHome, although I am worried that would be more pain than gain, as there are quite some overlapping functionality (e.g. all the sensor integrations).

However, some parts, like possibly transport protocol and OTA bootloader is definitely something where there is opportunity for reuse.

It is not clear to me how #660 and #678 relates to this issue though. The former is about tunneling serial ports over WiFi (here we are more looking for tunneling ESPHome protocol over RF) and the latter is about auto-discovery (which is ortogonal to this, I expect sensors to be defined as usual in yaml).

[glmnet]

This is a nice idea but a lot will need to be done.

[henrikssn]

I started investigating this for the SAMD platform (i.e. Arduino Zero / Moteino M0) in https://github.com/henrikssn/esphome/tree/samd.

So far, I got very minimal version of ESPHome (no logger, api, wifi, ota) to compile and esphome tool can upload the sketch.

Next step would be to write a component for the rfm69. What I am currently uncertain about is how to eventually hook into the API component, ideally I would reuse the current protocol and use something like the RadioHead library instead of AsyncTCP, but that remains to be investigated.

[the1snm]

I came to the feature request section to make a request to add RFM69HW functionality and found this request with the search function. I just wanted to throw in some additional desire to see this added if possible. As henrikssn mention there are a lot of potential uses for these deep sleep options for both distance and battery only items. Like many others I have used some Moteinos as a stand alone controller for automated solar powered blinds. I'm using a Wemos D1 right now with a RFM69HW on it as a gateway for communicating with those blinds. While I have that gateway integrated into HA it's not sexy with curl GET to the gateway in order to control the blinds.

I'm not a programming genius so I won't be a bunch of help there but I can give lots of moral support and way-to-go's!

[glmnet]

@henrikssn are you pushing this somewhere? I'd love to see how messy it gets.

Btw, Otto did some cool abstraction on the connection stuff which will be a must for stuff like this, not sure if you've seen it already because it's not merged in and a bit old: esphome/esphome#809

[OttoWinter]

@glmnet Yeah I just updated that with some minor fixes/etc. It's absolutely not done yet (the API is also quite bad tbh). Plus that's currently only for OTA and native API, not mqtt.

[henrikssn]

@henrikssn are you pushing this somewhere? I'd love to see how messy it gets.

Btw, Otto did some cool abstraction on the connection stuff which will be a must for stuff like this, not sure if you've seen it already because it's not merged in and a bit old: esphome/esphome#809

Haven't had time in a while to look further into this, I believe the main challenge is to make it both low power and responsive. It would need some serious work on the radio stack to make that happen, and I haven't seen something which would be easy to reuse.

[RoganDawes]

I have some rough WIP commits adding support for STM32 (BluePill - STM32F103) at https://github.com/roganDawes/esphome/tree/generic_arduino, mixed in with other commits supporting the ProtoBuf API over a Stream as well as over AsyncTCP. I suspect that work should not be too difficult to extend to other communications mechanisms, as I have abstracted the methods that send the protobuf messages, and override ::loop() to read from the stream and fill the receive buffer. A similar aproach could be taken for other transports, such as radio, etc.

[TiddlyWiddly]

I found this while searching and for the exact same reasons. Was any progress made on this? Struggling to find a working example of something like this.

[RoganDawes]

The API component was worked on a lot since my attempt, and that will no longer apply, I'm sure.

I suspect that some work would have to be done to slim down the api, or perhaps otherwise deal with splitting a large protobuf over a small RF payload.