ESP-Now integration

[megane999]

Describe the problem you have/What new integration you would like Integration of ESP-NOW protocol

Please describe your use case for this integration and alternatives you've tried: Just use separated esp on this protocol, but didn't know how to use esp-now with esp-home

Additional context

[OttoWinter]

Similar to https://github.com/esphome/feature-requests/issues/124

New communication channels are a lot of work to add - and probably you will not see this any time soon natively supported.

Also, I don't think ESP-NOW offers many benefits for ESPHome directly - yes it (ab)uses an optimized and slimmer WiFi stack with smaller connection times etc, but with ESPHome you need a wifi connection anyway for integration with HA.

[rradar]

@OttoWinter

with smaller connection times

much:star: smaller connection times should be possible which should enable long running battery powered esp devices

but with ESPHome you need a wifi connection anyway for integration with HA.

Depends. One esphome node could work as a gateway for all the battery powered esphome nodes using esp-now to communicate

Why esp-now?

• Works with or without WiFi connection
• Works with or without HomeAssistant
• Instant startup time if not using wifi
• No addition hardware needed
• Easy to use pub/sub event model
• Send and receive from multiple devices

@iphong did a nice start here: https://github.com/iphong/esphome-espnow

:star2: In this video the time measured using esp-now instead of wifi was a run time of total 280ms. The same hardware build using 'classic' wifi with mqtt had a run time of around 7 seconds. This is a factor of 25 :warning:

[OttoWinter]

@rradar Yeah I see ESP-NOW is an interesting protocol for cross-device communication. However, bringing this into ESPHome as an official component is a bit difficult. Of course you can create a quick component that can send/broadcast some arbitrary bytes to devices in range, but the user then is exposed very much to the inner workings of C and has to deal with bytes/etc. Also selecting which devices to send something to, or getting some sort of acknowledgement that data was received would be necessary for an official integration.

[iphong]

One thing that make esp-now so great is that it can work along side with home assistant. So you get the best of both worlds with no trade offs. In my opinion, espnow should not be a used as a main comunication transport. Native API and home assistant does it so well already. Since espnow doesn't rely on wifi router connection, it can be used for sensors update, or direct remote control switches. A perfect application for espnow I can think of is a 2-way or 3-way switches. Your light connect to home assistant as a usual via local wifi connection, while receiving on off command from all switches using esp-now. And your switches can get state update of that light and display it accordingly. In case home assistant somehow disconnected, your switches still work.

[glmnet]

This is cool. I believe we need another abstraction for these

• Espnow
• LoRa
• Rs485
• can bus
• http May be, much like what web server and http components currently do
• ir, ok this one is odd

Those I believe can be target for a lightweight node to node api.

Ideally one would change the backend comm layer and node to node comm will keep working.

Api should support sending and receiving events, if the api is crafted maybe non core esphome developers (not Otto) can support those.

[iphong]

I'm working on a personal project that will push the esp8266 to its limit to see how good the esp-now protocol performs. The EspRC library used in my esphome integration example was part of this project.

Check it out at https://github.com/iphong/esp-visual-led

[OttoWinter]

@glmnet Yeah I agree we need some abstraction to enable strutured communication over all those interfaces (I've been working on some prototypes for a while based on the current native API, but it's hard to create one that works well for all base communication layers).

One major problem with ESP-Now definitely is the missing acknowledgement support, so you can broadcast something but you never know if it arrived. which means for a real protocol we will have to invent some sort of our own TCP

[rradar]

One major problem with ESP-Now definitely is the missing acknowledgement support, so you can broadcast something but you never know if it arrived.

@OttoWinter actually esp-now supports encryption which should include an acknowledgement.

From https://www.programmersought.com/article/90502088859:

ESP-NOW CCMP encryption method used VSA frame. CCMP can be found inIEEE Std. 802.11-2012standard.

WiFiDevice holds a PMK (Primary Master Key) with several LMK (Local Master Key), the length of these are 16-bit Key. PWK for AES-128 encryption algorithm by LMK, call interface esp_now_set_pmk () is provided. If the PWM is not set by the user, it will use the default PWK. LMK is arranged to encrypt the VSA frame. Support for up to six LMK, VSA does not support multicast encryption frame.

But as it looks like it's not only bad documented but actually also has a hard limitation of nodes (maximum 10 or 6 depends of SoftAP/Station mode).

A very interesting approach to overcome this limitation is the EnigmaIOT protocol:

EnigmaIoT is an open source solution for wireless multi sensor systems. It has two main components, multiple nodes and one gateway.

A number of nodes with one or more sensors each one communicate in a secure way to a central gateway in a star network using EnigmaIoT protocol.

This protocol has been designed with security on mind. All node data is encrypted with a random key that changes periodically. Key is unique for each node and dynamically negotiated, so user do not have to enter any key. Indeed, all encryption and key agreement is transparent to user.

Actually the protocol only focus on the link layer which would perfectly fit with esphome which would act as the application layer:

• Application layer is not controlled by EnigmaIoT protocol but main program. User may choose whatever data format or final destination of payload. [...] The only limit is the maximum packet length that, for ESP-NOW is around 200 bytes.
• Link layer is the one that add privacy and security. It manages connection between nodes and gateway in a transparent way. It does key agreement and node registration and checks the correctness of data messages. In case of any error it automatically start a new registration process. On this layer, data packets are encrypted using calculated symmetric key.
• Physical layer currently uses connectionless ESP-NOW. But a hardware abstraction layer has been designed so it is possible to develop interfaces for any other layer 1 technology like LoRa or nRF24F01 radios.

This actually could act like the abstraction @glmnet suggested just three posts up

[motwok]

I am working on a ESPHome component that will use ESP-Now supporting ESP8266 and ESP32 including ESP-Now based Crypto.

Basic communication is already working great... i am just in the phase to make ist usable with yaml and a sensor integration.

May i am able to do the first release next weekend.

Emmo

[motwok]

After struggle with some resource problem connected to the ESP32, crypto and wifi_component, i gave up to fix this, might be there is a complete overhauling of the wifi component needed. So i release the component with the restriction that ESP32 with Wifi enabled can't communicate with ESP8266 and vice versa.

Emmo

[motwok]

If some one likes to check out my Wifi-Now component:

https://github.com/motwok/esphome/releases/tag/0.0.1.0

Have fun.

Also it would be great if somone does a review of the code.

Emmo

[fabir-git]

Would be great to see this functionality in ESPHome. Thanks for your work, motwok.

[rarroyo6]

Even if ESP-Now is not integrated, it would be nice to have ESPHome-ESPHome communications, bypassing the HA. @iphong gives a good example using 2 and 3 way switches. I have the same situation, I have 2 Sonoff IFan-03 and I have 2 Sonoff switches to control them via HA. When the HA goes down, which it has, I loose control of the fans and the lights in the room. Even a simple request server, that can be accessed with the "HTTP Request" component would be nice, and probably much simpler to integrate. That way HA can still control the devices, but if it goes down, the devices can still function manually on their own.

[motwok]

Even if ESP-Now is not integrated, it would be nice to have ESPHome-ESPHome communications, bypassing the HA. This is exactly one of the reasons i created the wifi-Now module

@iphong gives a good example using 2 and 3 way switches. I have the same situation, I have 2 Sonoff IFan-03 and I have 2 Sonoff switches to control them via HA. When the HA goes down, which it has, I loose control of the fans and the lights in the room. You can do similar things with Wifi-Now Module.

Even a simple request server, that can be accessed with the "HTTP Request" component would be nice, and probably much simpler to integrate. That way HA can still control the devices, but if it goes down, the devices can still function manually on their own. An HTTP request requires at least a functioning Access Point... Wifi-Now requieres only that both modules are in range of each other.

Try it even when there is the word Alpha... it is stable enougth to be used.

Emmo

[jkdobro]

Interesting Esp-Now Flooding Mesh project: https://github.com/arttupii/EspNowFloodingMesh

[motwok]

Interesting Esp-Now Flooding Mesh project: https://github.com/arttupii/EspNowFloodingMesh

I made the "intresting" Esp now implementation... and i had also mesh in mind... but after wasting many hours for an Pullrequest that is completly ignored (there was a request to remove tests, no comment) like allmost all other PR with Wifi in name... i have better things to do than obeying dumb changing CI Rules and maintain PR for futhur ignorance over the next years.

The reason: the "community" is not intrested, at least the intrested people in the community do not show intrest...

mo

[ybarigou]

@motwok I tried your fork (with 'wifi' and 'wifi_now') as external components, unfortunately, I kept getting a bunch of compilation errors one after the other, seems like it does not fit with the current ESPHome internal structure anymore. Is this the case or am I doing something wrong ?!

[motwok]

Is this the case or am I doing something wrong ?!

I am sorry... due to an currently overvelming job i have no time to investigate this in near future.

[racingpassion]

Has this project died :( was looking forward to some low powered esp.

[motwok]

Nope... near future there will be an overhaul dividing it into 2 parts... one is meant as shared library and the other part is the yaml stuff

[gmag11]

One major problem with ESP-Now definitely is the missing acknowledgement support, so you can broadcast something but you never know if it arrived.

@OttoWinter actually esp-now supports encryption which should include an acknowledgement.

From https://www.programmersought.com/article/90502088859:

ESP-NOW CCMP encryption method used VSA frame. CCMP can be found inIEEE Std. 802.11-2012standard. WiFiDevice holds a PMK (Primary Master Key) with several LMK (Local Master Key), the length of these are 16-bit Key. PWK for AES-128 encryption algorithm by LMK, call interface esp_now_set_pmk () is provided. If the PWM is not set by the user, it will use the default PWK. LMK is arranged to encrypt the VSA frame. Support for up to six LMK, VSA does not support multicast encryption frame.

But as it looks like it's not only bad documented but actually also has a hard limitation of nodes (maximum 10 or 6 depends of SoftAP/Station mode).

A very interesting approach to overcome this limitation is the EnigmaIOT protocol:

EnigmaIoT is an open source solution for wireless multi sensor systems. It has two main components, multiple nodes and one gateway. A number of nodes with one or more sensors each one communicate in a secure way to a central gateway in a star network using EnigmaIoT protocol. This protocol has been designed with security on mind. All node data is encrypted with a random key that changes periodically. Key is unique for each node and dynamically negotiated, so user do not have to enter any key. Indeed, all encryption and key agreement is transparent to user.

Actually the protocol only focus on the link layer which would perfectly fit with esphome which would act as the application layer:

• Application layer is not controlled by EnigmaIoT protocol but main program. User may choose whatever data format or final destination of payload. [...] The only limit is the maximum packet length that, for ESP-NOW is around 200 bytes.
• Link layer is the one that add privacy and security. It manages connection between nodes and gateway in a transparent way. It does key agreement and node registration and checks the correctness of data messages. In case of any error it automatically start a new registration process. On this layer, data packets are encrypted using calculated symmetric key.
• Physical layer currently uses connectionless ESP-NOW. But a hardware abstraction layer has been designed so it is possible to develop interfaces for any other layer 1 technology like LoRa or nRF24F01 radios.

This actually could act like the abstraction @glmnet suggested just three posts up

Hi,

I did not see this before.

Actually I guess it could be feasible to integrate EnigmaIOT as a EspHome component. I've just started reading about ESPHome, but I am not ready to start a development yet.

If anyone who is familiar with EspHome developint wants to try I'm open to give my help. I guess some changes would be necessary to do it but it is possible.

EnigmaIOT is quite stable now. As it solves my use case I'm not developing new features until needed.

This integration would enable EspHome to run in battery powered devices for long time, just like ZigBee but with a simple ESP32 as a gateway.

This gateway could be even modified to do a more straight integration with HomeAssistant.

Let me know any idea.

Regards

[jkdobro]

@gmag11 EnigmaIOT has a star topology. Can you expand so that it can work like Mesh Network?

[gmag11]

This is one of my target for long term. I could use MDF sdk, but it is only compatible with ESP32. As EnigmaIOT pretends to keep compatibility with ESP8266 this will not happen soon.

[motwok]

You are not 100% right.

One major problem with ESP-Now definitely is the missing acknowledgement support, so you can broadcast something but you never know if it arrived.

There is a akknowledge and you get an error when not doing multicast....

But as it looks like it's not only bad documented but actually also has a hard limitation of nodes (maximum 10 or 6 depends of SoftAP/Station mode).

You can communicate with 20 registerded "Partners" and 6 different Keys (you can have 20 Stations with same key),

EnigmaIOT ...

Even with my almost 35 years experience i would not implement such security protocol by myself (ok... except for ROT13 :) ). And sorry i dont understand why people tend to reinvent the wheel? Its a mystery for me. If AES is not enough what will be enought? And please think again, having rolling keys needs some periodic communication and/or a reliable timebase, that is not an option for a low power device.

There are 2 real Problems with esp-now:

1. On receive you can not distinguish between a unencrypted broadcast and a direct send crypted packet this is the only reason for an additional encryption... and with a 32-Bit nonce and AES this should be easy enougth. So "authenticate" a packet is not possible, but needed for security applications like a low power remote for e. g. a door opener.

2. Channels... you never know on Wifi channel your "partner" (that depends in Station Mode always on the connected router) and you can receive packets when on the neightbor-channel. Switching channels to long can mess up the Wifi.

If anyone who is familiar with EspHome developint wants to try I'm open to give my help. I guess some changes would be necessary to do it but it is possible.

Unfortunately such a module is mostly one man show... to small to have multible programmers on it. If you like you can support the current development with severe testing (also developmend of tests), Documentation and code reviews. I currently divide my "wifi now" module in 2 parts, one will be a base so espnow can be used by several other modules and the other is a helper so you can do the Communication in yaml.

And for the additions it is important to overcome the channel problem (there are a few strategies but non is w/o a compromise for power consumption and timing). In a second step an oprion to use AES encryption (in addition or as alternate to the espnow encryption) will be added.

And then on top of this a proxy is needed for OTA update and HA communication (i already did a POC for nDNS)

If this is working we can do some addions for ESP-MESH! (The dream may come true)

Emmo

[gmag11]

Hi, I add some comments about EnigmaIOT ESP-NOW implementation. I invite you to go to its repository and keel talking there

You are not 100% right.

One major problem with ESP-Now definitely is the missing acknowledgement support, so you can broadcast something but you never know if it arrived.

There is a akknowledge and you get an error when not doing multicast....

Right. unicast communication is acknowledged.

But as it looks like it's not only bad documented but actually also has a hard limitation of nodes (maximum 10 or 6 depends of SoftAP/Station mode).

You can communicate with 20 registerded "Partners" and 6 different Keys (you can have 20 Stations with same key),

With EnigmaIOT, a gateway than manage more than 100 nodes with dynamic key encryption.

EnigmaIOT ...

Even with my almost 35 years experience i would not implement such security protocol by myself (ok... except for ROT13 :) ). And sorry i dont understand why people tend to reinvent the wheel? Its a mystery for me. If AES is not enough what will be enought? And please think again, having rolling keys needs some periodic communication and/or a reliable timebase, that is not an option for a low power device.

EnigmaIOT does not try to reinvent the wheel. It uses diffie-hellman algorythm to find a common key to be used with ChaCha Poly encryption. It could use AES with some minor changes.

There are 2 real Problems with esp-now:

1. On receive you can not distinguish between a unencrypted broadcast and a direct send crypted packet this is the only reason for an additional encryption... and with a 32-Bit nonce and AES this should be easy enougth. So "authenticate" a packet is not possible, but needed for security applications like a low power remote for e. g. a door opener.

EnigmaIOT solves this with a few bytes of metadata. ChaCha Poly encryption does authentication. That was one of the reasons I chose it.

2. Channels... you never know on Wifi channel your "partner" (that depends in Station Mode always on the connected router) and you can receive packets when on the neightbor-channel. Switching channels to long can mess up the Wifi.

You can broadcast an AP on gateway to mark the channel. Nodes find that AP then try to authenticate to it. This avoids gateway impersonation. After that they disconnect from AP and continue taking through ESP-NOW. In case of a channel change in gateway, nodes try to find it again after a timeout. Authenticated encryption allows to ignore out-of-network messages.

If anyone who is familiar with EspHome developint wants to try I'm open to give my help. I guess some changes would be necessary to do it but it is possible.

Unfortunately such a module is mostly one man show... to small to have multible programmers on it. If you like you can support the current development with severe testing (also developmend of tests), Documentation and code reviews. I currently divide my "wifi now" module in 2 parts, one will be a base so espnow can be used by several other modules and the other is a helper so you can do the Communication in yaml.

And for the additions it is important to overcome the channel problem (there are a few strategies but non is w/o a compromise for power consumption and timing). In a second step an oprion to use AES encryption (in addition or as alternate to the espnow encryption) will be added.

And then on top of this a proxy is needed for OTA update and HA communication (i already did a POC for nDNS)

You can tigger a node to connect to wifi to get an OTA update. This is not developed right now. Currently a python script allows to send OTA update through MQTT to gateway and then through esp-now to nodes.

If this is working we can do some addions for ESP-MESH! (The dream may come true) Sure, this would be super

Emmo

[RubenKelevra]

If ESP-Now LR does really improve the WiFi capabilities to 480 meters and adds mesh functionality it would be a nice alternative to Zigbee.

Would be super interesting to have ESP-Now LR to tunnel information to a dedicated ESP32 which connects to the HA instance like a hub.

In theory this only needs a dedicated port on the hub for each "endpoint" in the ESP-Now network. On the "endpoint" node we convert it back to TCP/IP packages and receive it via the normal tcp/ip stack.

This should in theory allow all regular features except mDNS discovery.

[RubenKelevra]

@RubenKelevra wrote

adds mesh functionality

I've looked a bit deeper into EPS-Now, while it can do mesh as in "everyone connects to everyone" it can't route packages like Zigbee routers do.

So we could do multiple-start topology, where every device with a Network-Uplink is working as a hub while the devices will be available via each of those hubs. In this case HA would just try each of those forwarded ports until it reaches the node.

Say we start with 10000 as port for the first node, on each hub the port would end up on the same node in the ESP-Now network. So HA would get a list of hubs and just try to reach the node via each of those IPs with the port 10000.

This allows for redundancies and mobility, while the connection might dropout for a short duration, it will be picked up again as long as the node is within the range of an ESP-Now "hub".

The other solution would be to do routing via a simple implementation of Batman-adv. That's a protocol to route L2 packages inside a L2 network.

The idea is to send out a broadcast-package from time to time to determine the "best" next hop to each hub. This ways an ESP-Now "endpoint" would just need to store the best reachable mac address towards the hub and send the packages to this node.

Since we don't need the full length of a mac address to address a hub we might loose just 1-2 bytes for this "routing" as each package need to contain the selected hub (by enum number).

[RubenKelevra]

Another option might be, to implement a minimal subset of 802.11s with a smaller channel width (if the hardware is capable of that). Using a 5 MHz channel, you could (at least in Europe) "squeeze" the ESP32/8266 network above channel 11, as we have up to channel 13 available here.

The default HWMP protocol for routing isn't possible to use tho, as all nodes need to keep track of the whole network.

But using ideas from Batman-adv (like pointed out earlier) we could get away with just storing just "next hop" informations to the "hubs".

The main advantage compared to ESP-Now would be, that 5 MHz channels are also supported by OpenWRT (depending on the hardware capabilites). So the network could just be routed in the local router or the (in most setups) unused Wifi card in the Rasberry Pi could be used as hub for this network.

This would on one hand eliminate all broadcast/multicast traffic to be received and processed by the ESPHome nodes and on the other hand allow for low power hop-to-hop communication of the ESPHome nodes in a mesh network, extending the range of individual nodes.

While this might not reach the extremly large distances of the ESP-Now, this on the other hand does not need any tunneling or something like this - as the package size is not restricted.

TL;DR

So this would reduce the power consumption, the processing overhead for wifi, allow for long range communications via hops, make the connections more stable and also reduce the latency - as we don't have to wait for free airtime as much as with a 20 MHz channel in the crowded 1, 6, 11 channels.

[motwok]

@RubenKelevra wrote ...

Here is the deal: Let us finish esp-now... currently i am recovering slow from an temporary blindness... so it will take a bit of time.

If this is done you might use the base module in your own to realize this stuff you describe (may be you make something meshy) but be aware that there are already a mesh implementation for ESP32 that works reliable.

So in mesh (and also esp-now) the biggest Problem is that almost every thing in ESP Home relies on TCP/IP for example try the MQTT component having communicating to a serial partner or pipe instead of TCP/IP connection (i tryed already... upsi, the library used includes the TCP/IP stuff... yust rewriting is needed)... When thinking on most components, thats a sysipus task... So my approach is to have something simple and easy to implement: a simple port-proxy that has the cababiity to make client connections over a "hub"-module and accepts connections on the "hub"-Module including announcments via mDNS, may be its possible to avoid manual configuration for the incoming connections.

We will see in the next few month.

Emmo

[motwok]

@RubenKelevra wrote ...

What you propose is not legal in most countrys, because you modify Layer 1 and loos the certification for your ESP Module... running those modifications is only legal for HAM Operators. And real low power with Wifi-Routing , what do you dream at night, its like try light a match under water, sorry.

And Whhhhyyyy at all??? Again, an advanced selforganizing mesh is already implemented, no need to f..k around with illegal WIFI-Protocol tricks, its just there, it works and you can use it.

The only thing to do for mesh in ESPHome is the communiction from a mesh-node to TCP/IP. Thats all you need. (Having a proxy solves this problem)

Emmo

[RubenKelevra]

@motwok hope you get well soon! :)

I build a while ago open source networks with some hundreds hotspots for end devices via 802.11s and batman-adv. This technology works really great.

For ESPHome the setup wouldn't work as ESP-Now or like mesh approaches mentioned ealier, as a regular OpenWRT box or Home Assistant itself could act as a 802.11s hotspot. Compared to the ESP-Now / Mesh approaches mentioned earlier a 802.11s mesh would also allow for regular TCP/IP traffic. So there's much less headaches attached. Google's Wifi system for example uses 802.11s mesh networks.

I also don't want to reinvent the wheel. I would rely on the battle tested batman-adv protocol, which needs to be "microfied" to run on ESPHome nodes. But it's certainly duable, as we don't have to hold any "client" tables.

Let me line out this idea:

• We would create an 802.11s "mesh point" which has the build in HWMP mesh protocol deactivated.
• Batman-adv does the routing and forwarding of packages over this L2 network.
• All ESPHome nodes which can "see" the Home-Assistant or OpenWRT AP can just directly send data to it, while other nodes rely on relayed connections via 802.11s and batman-adv.

Using 802.11s/batman-adv would have multiple advantages:

• It's implemented in the Linux Kernel, so you can use it with nearly all hardware.
• You can use it on an OpenWRT-AP additionally to your regular wifi, as most hardware allows 8 hotspots/mesh-points at the same time.
• You can use TCP/IP and don't need any additional mesh software on the AP. It's just like any other L2 interface on the AP side.
• Compared to ESP-Now this is not vendor locked. ESPHome can support other hardware in the future with full compability.
• There's no limitation in message length with 802.11s, as you can just send regular 1500 MTU packages over this protocol.
• Compared to ESP-Now all 802.11n networks send multiple packages together so even larger amounts of data using multiple 1500 MTU packages, like a image or video stream, isn't an issue.

Regard the legality of my 5 MHz channel 13 upper end idea: This is perfectly legal. Those are considered "normal" wifi signals, just with less subbands, so less channel width. All other wifi hardware can detect those like it's a half-overlapping wifi signal - like if you have a channel 1 and a channel 2 wifi. Sure channel 12/13 are not legal to be used in the US - but that's not necessary to do. You can use a regular 20 MHz channel as well, or 20/40 MHz mixed. The idea doesn't need to use the "free" band here in Europe. Japan for example also got the channel 14 available (with 802.11b only) - which is especially interesting there since it got even more spacing from the regular 1, 6, 11 channels everyone uses. So perfect for a mesh network.

[MasterCATZ]

I really do wish this was integrated

I need esp devices to be able to still communicate with each other if HA server is down / crashed as I am needing them to read temperatures from ~60m away on another esp device to control relays in the shed for heaters and their are ESP devices floating around at least every 3m in every which direction

[nagyrobi]

https://github.com/esphome/feature-requests/issues/1108

[github-k8n]

I think there are two distinct use cases which probably shouldn't be mixed together.

(1) First would be the possibility to just pair a few devices and let them send simple commands (e.g. update a sensor/switch to allow control even if HA or WiFi is down or was never set up) most of those use cases are probably a switch controlling some light in the same room or reading some sensor data and probably just require a handful of devices for each "group", like a few switches and a few lights in one room, so the possible number of peers shouldn't be an issue.

Ideally an integration with a sensor component (binary/text) on one end (receiving side) and a corresponding component (switch? display? output?) on the other side (sending side) where as updates on the switch/display get transmitted to the sensor on the target.

Edit: I just noticed that there seems to be a comment pointing to something that would pretty much be what would be needed: https://github.com/esphome/feature-requests/issues/275#issuecomment-711422481 Would it be possible to maybe include something like this officially in esphome? Edit 2: As the above does not seem to work in combination with WiFi either that would need to be fixed OR some kind of condition would be required (e.g. if wifi and/or HA not available then enable this and check periodically if wifi/HA are available again).. I am not sure if esp-now is supposed to work in parallel with wifi enabled at all?

(2) Second would be the stuff that is floating around here about using this as some kind of mesh network like zigbee/z-wave. While that would be nice I don't think it should be the focus here.

[evlo]

I agree with @github-k8n that mesh certainly is nice, but not what is really missing, at least form my point of view. The direct control of light from switch if there is now wifi AP and connection to the coordinator is, in my opinion, more of an priority. Especially for the setups where one uses some lights that have no direct connection to the switch/relay.

I know for some people zigbee or z-wave is good enough, i just don't have much luck with it, honestly for sensors that can be slow and is easier to run on batteries i moved from zigbee to ble + esphome proxy and now I have much more reliable data and resilient setup. I think it comes down to no pairing.

[Cougar]

I guess it is hard to make ESPHome sensors communicating without WiFi. Then it is totally different case and needs some BLE magic or sensors should set up their own WiFi network but then they can't associate with WiFi router when it comes back. Workaround for missing Home Assistant would be much more realistic than workaround for missing WiFi.

For direct connectivity between lamps and switches the Zigbee (or Z-Wave) looks much better, if not only option right now. Maybe Matter could make this thing easier in the future?

[motwok]

I guess it is hard to make ESPHome sensors communicating without WiFi.

Define "without Wifi"... do you mean "no Accesspoint" or more like "no Wifi protocols / frequencies used at all"

set up their own WiFi network but then they can't associate with WiFi router when it comes back.

Wrong... you can run AP and Station Mode in paralell, the only restriction is that both run on the same Wifi channel (in fact this means Channel is selected by the Stationmode aka from the connected Accesspoint)

for direct connectivity between lamps and switches the Zigbee (or Z-Wave) looks much better,

From a biased view yes... but tell me what sence has it to connect two ESP via one of the popular RF systems when you need to add the hardware for it... (not mentioning other little problems) ... when there is a protocol that works with the existing Hardware...

I run currently 4 ESP-Now direct connection between switch and lamps.

Emmo

[rradar]

@tomrusteze got a little working custom component in his githubs:

https://github.com/tomrusteze/esphome-esp-now

[vks007]

I am sorry... due to an currently overvelming job i have no time to investigate this in near future.

Hi @motwok , do you plan to resume this anytime soon? Compilation fails with esphome and your library.

[evlo]

Was someone able to work around https://github.com/esphome/esphome/pull/1290#issuecomment-1005880024 ( there are no arguments to 'millis' that depend on a template parameter ) with current esphome realease?

I have tried installing older esphome as mentioned in https://github.com/esphome/esphome/pull/1290#issuecomment-1005952467 , but I think it failed, I do get version 2022.3.0-dev

ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
ltchiptool 3.0.0 requires click<9.0.0,>=8.1.3, but you have click 8.0.3 which is incompatible.
ltchiptool 3.0.0 requires colorama<0.5.0,>=0.4.5, but you have colorama 0.4.4 which is incompatible.

maybe it is not possible to have 2 versions at the same time? Or venv is needed for that or something?

---

---

---

It seemed to me that it is loading /config/esphome/.esphome/external_components/db99c277/esphome/core/base_automation.h instead of the current version of that file So have modified the structure like this, but no change.

After checking current version ( https://github.com/esphome/esphome/blob/dev/esphome/core/base_automation.h ) now I'm out of ideas.

[Kimotu]

Hello @evlo,

I managed to compile wifi_now via external_component. The trick was to add #include "esphome/core/hal.h" in base_automation.h. But take care to edit the correct file. base_automation.h gets copied from your site-packages library path to your build directory with each compile run and overwrites your changes if you modified the "wrong" base_automation.h.

In windows I had to edit %USERPROFILE%\AppData\Local\Programs\Python\Python311\Lib\site-packages\esphome\core\base_automation.h

After this modification, I could sucessfully create a espnow transmitter/receiver pair and successfully transmit int, float and bool. With strings I had no luck in decoding. The on_fail: seems to be a bit buggy. Cannot use it more than once in a yaml file.

[evlo]

@Kimotu thank you, now it compiles. Can you share your full yamls?

I tried this https://pastebin.com/MFqf1KQp for sender; and https://pastebin.com/J6mhywkK for the receiver I get _error: no matching function for call to 'esphome::wifinow::WifiNowSendAction::send()' When i trid with - binary_sensor_event: !lambda return wifi_now::WifiNowBinarySensorEvent::CLICK; it looked like it sent the thing, I even got error https://i.imgur.com/WXXUJq3.png message when I tried sending too fast, but no reaction on the receiving end

I'm using this https://deploy-preview-775--esphome.netlify.app/components/wifi_now.html#wifi-now-inject-action to figure out how to set it up and it is a bit confusing for me. working example would help me a lot or at least I could figure out if this thing works for me at all.

[Kimotu]

@evlo You are right. It's still buggy. ATM only float and int seem to work clueless. The binary log never triggers and no idea how to receive strings. Yesterday I set up a battery powered transmitter that transfers a LDR value whenever I trigger a button and returns into deepsleep and everything was done in a 1-2 seconds. Much faster (20x) when I use api. So I hope there will be a working ESPHome ESPNOW component in near future.

Transmitter: https://pastebin.com/rgRjT2Bf Receiver: https://pastebin.com/fP3WKp9k

[evlo]

Did try this for battery powered Devicess https://gitlab.com/dbuggz/ripnetuk-esphome-easynow ?

[dbuezas]

That component looks really nice!

[evlo]

https://esphome.io/components/esp32_ble_server.html https://esphome.io/components/ble_client.html

Maybe this can be used to control the lights without relying on wifi AP

[Kimotu]

@evlo unfortunately it's ESP32 only and does not compile for 8266. I already contacted George for a 8266 version. He will grab some of his old 8266 and try to adapt it if somebody will test it.

[evlo]

To conclude, and for my future reference (as quite often I found my own posts when searching for solutions :) ) i succeeded using BLE, I used this https://github.com/wifwucite/esphome-ble-controller for the server component.

Only real issue was that the BLE and WiFi MAC are different and I did not know that.

[Ulrar]

That's an interesting idea if all you're using is esp32, but it won't work with esp8266 unfortunately since they don't have bluetooth, ESPNow would still be very useful.

Sadly given that all the no neutral switches seem to use esp8266, that doesn't help me :(

[ripnetuk]

Hi... i made the easynow component - i am planning on doing 8266 support, but real life keeps me busy. I see that someone has already been working on it here https://gitlab.com/dbuggz/ripnetuk-esphome-easynow i would be delighted to get a pull request if you get it working, otherwise it will be looked at when the kids are back at school after easter :)