nRF24L01 support

[brandond]

I have a use case for some small battery-powered distributed sensors. Ideally this would be a good use for BLE or Z-Wave, but BLE support has a ton of overhead and Z-Wave is proprietary and expensive.

What I'm probably going to end up doing is setting up a few devices with STM32s that will spend most of their time in suspend, occasionally waking to make a sensor reading and send it off via a nRF24L01 radio if conditions are met. On the ESP side, it would just be a matter of wiring up the RF24 SPI/Enable/IRQ pins to GPIOs.

The chip is limited in hardware to 32 byte message payloads. Perhaps something like this:

struct payload {
  unit8_t type;
  char unit[3];
  char value[14];
  char name[14];
};

Ideally, esphomelib would not need to define a list of sensors ahead of time, but simply reformat and pass the messages through to MQTT.

[OttoWinter]

So in principle, this would be awesome. But for one part I'm so certain:

Ideally, esphomelib would not need to define a list of sensors ahead of time, but simply reformat and pass the messages through to MQTT.

I mean I do understand the usability aspect of that, but the backend sensor should not know about the front-end (here MQTT). esphomelib is purposefully not built in a way to make it depend on MQTT and in the future it might also support other frontends. For example, one such frontend is already the web server.

One way this could still not make usability too bad I hope is with how I recently did it with the remote_receiver. The remote receiver can listen on any pin for IR/433MHz/similar for any sequence of encoded data. For example, it can listen to the IR codes sent by a TV remote. Of course all these codes have to be learned first, that's why there are "dumpers" that just dump any received IR code in the logs together with their decoded values. The user can then just copy+paste this into their configuration and they're already done.

This way, the backend can expose individual binary sensors without ever knowing how the frontend handles them. In this case with these packets you have there, the same thing could be done with sensors, with the name identifying them or however the protocol works.

[brandond]

Is there any reason that sensors cannot be dynamically registered? I know that right now, pretty much everything is added during app setup. Would it break any current assumptions if sensors are added or removed dynamically? Thinking something like adding new sensors as they are discovered via broadcast messages, or removing/offlining them if they miss a few heartbeat intervals.

[OttoWinter]

Theoretically it's possible to register them dynamically, you would only need to handle their setup lifecycle (with setup_()) manually.

Removing them dynamically too would probably be a bit more difficult, as there are many inter-object dependencies like callbacks that could break if a component on the heap is manually deleted.

But I would say a big drawback of such a solution would be that these dynamically created sensors would pretty much be inaccessible from automations and triggers.

[nekromant]

Hm, this would be useful. I happen to have my own pure-C optimized library for nrf24l01 (basically @ManiacBug 's arduino ported to pure C. I'll see if it compiles for esp8266 (it should). But it's pretty lowlevel. @OttoWinter are you interested?

[diogosalazar]

The mysensors/MySensors project handles communication between nrF24l01 modules and seems to be able to register devices dynamically. ESP8266 is supported as a gateway.

Would it make sense to integrate with that project instead of implementing from scratch?

[nekromant]

As far as I got the nRF24L01 part, we have a huge bunch of hardware and stacks:

• Dumb sensors/boards using simple protocols. As simple as send/receive a predefined payload. (Should be easiest).
• rf24mesh devices. rf24mesh doesn't specify any protocol, it's just read/write, no device method discovery/enumeration.
• mysensors that @diogosalazar mentioned. (That one is new to me, I'll have to check it out)
• My own libaura RPC over nRF24L01 ( https://gitlab.com/ncrmnt/aura-transport-rf24 ).

Some nodes have encryption (e.g. car immobilizer tokens), and that's a whole other layer of weirdness. I really want to help out with this task and have quite a lot of experience with nRF24L01 (non-arduino, pure C), but I don't know the inner workings of esphome good enough.

[glmnet]

I discovered ESPHome because I hated MySensors, their code quality seems ok, but these things communicating never was reliable for me, probably I was doing something wrong, I don't know.

As for today I believe this FR is outdated, I don't see need for dynamic sensor creation, though it is possible, in fact it is done already, you can just pick the message analyze it and push to any template sensor / binary sensor / cover... whatever, if that is what you need.

@brandond What ended happening here?

[nekromant]

@glmnet I just learned about mysensors from this thread and rigged up a test mesh based on my older projects. (Yay, they're no longer sitting in the attic!). So far it looks like the best we have for nRF24L01. As for being outdated - I doubt that. nRF24L01 still provides better battery life for devices like leak sensors, compared to esp8266 and doesn't have a severely over-engineered std, like BLE. As for esphome, I think the only thing we can add - integrating a mysensors gateway in a few lines of yaml. For some cases this may be useful.

[glmnet]

It’s a great platform. It did not work for me.

I just don’t know why would you use it within an esphome controller node. They provide a esp8266 gateway. That is you can connect hass to it then to my sensors network. It’s fully supported and documented.

[nekromant]

@glmnet I guess you're right. The only thing I can think of - combining esphome node and mysensors gateway. As for non-mysensors protocols - perhaps nrf24l01 beacons and presense sensors come to my mind, but still with something like mysensors around, the whole idea of integrating nrf24l01 into esphome sounds like a waste of time (

[Niorix]

Any news? I have an esphome-based LED dimmer and I would have controlled it with a touch R11 remote controler (https://aliexpress.ru/wholesale?catid=&Searchtext=R11%20Remote). It's apparently uses 2.4. NRF. Therefore, I cannot directly connect him with Esphome((

[kluszczyn]

The only thing I can think of - combining esphome node and mysensors gateway.

See: https://github.com/mannkind/ESPHomeMySensorsGatewayShim

[nekromant]

The only thing I can think of - combining esphome node and mysensors gateway.

See: https://github.com/mannkind/ESPHomeMySensorsGatewayShim

Thanks a ton! That's precisely what I've been looking for!

[otmezger]

I would love to be able to write yaml and leverage a nrf24l01 wireless network. let esphome do all the job ;-)

[jamesmyatt]

I wonder if this could be modelled on bluetooth_proxy and BTHome .

[3esmit]

I need nRF24L01 support for integrating a device that uses a remote control on 2.4GHz. I have captured the signals and I can send it using HackRF, but for integrating with home assistant would be nice to have this support.

[jhogendorn]

I need nRF24L01 support for integrating a device that uses a remote control on 2.4GHz. I have captured the signals and I can send it using HackRF, but for integrating with home assistant would be nice to have this support.

I am also keen to get this use case working

[zackfuchtel]

[x] AOL