(Voting question) New ESP8266 communication protocol

First - hello to everyone!
I am fairly new to the Home Assistant community, however I’ve been using HASS for the past 6-7 months and it’s AWESOME! The last 2-3 months I’ve been developing my own ESP8266 communication protocol, which does not require WiFi connection between the nodes. Currently the project is close sourced but if there are enough interested people I will open source it.

About the “thing”:

  • The nodes are in mesh-like network by sending raw packets in the air.
  • The message throughput is around 100-200 messages/s
  • Every node acts as a repeater for other messages
  • The addressing is done via the device’s MAC address
  • Every node is connected to only one bridge(gateway) device
  • The gateway device is ESP8266 communicating to python script through serial
  • The hex(raw) packets are unpacked in Python which leaves the ESP to do only the RX & TX to the network
  • The messages are encrypted between the nodes
  • The encryption is message to message based(the key is different for every message and it is generated from the recieved message)…

Downsides:

  • The maximum message size is 72 bytes (BTW this is enough because the values are sent as hex)
  • There is no ACK packets and you are never sure if the packet is recieved but if the network is dense enough the dropped messages would be down to the minimum (5-6 or less out of 1000)
  • You have to convert values to HEX before you send them… and convert them back when recieved by the gateway…

If you have any questions - you could ask in the topic :slight_smile:

BTW: Sorry for my english… It’s not my native language.

Sounds interesting. Although the missing ACKs could be a drawback. For a temperature sensor a few dropped samples wouldn’t be important. But if you want to have automations based on detected events, then a missing event would result in inconsistent behavior. Lets say you want a shutter-contact at the door to trigger an alarm when opened while not home. If exactly that one critical packet got lost, then the alarm would never go off.
Besides that I really like that approach of just using raw packets. Making it open source maybe could get you a few more pairs of eyes to tackle possible security issues and some ideas on how to implement bi-directional communication.

1 Like

Hi Daniel, Thanks for the interest!

For the first problem my solution is in the python file - in random interval (1-3 minutes) the script resubscribes to the MQTT broker and sends the retained messages to the network again.
About the second issue - the code could be configured to send more than one packet. But this has to be done only to critical nodes…
Ex: an alarm trigger could send packets forever until the door is closed or send 10-20 packets and forget…

This got me thinking: the EPSs operate on 2,4GHz. Which nowadays is pretty crowded. It would be interesting to see how the ESP-packets behave in a very WiFi-polluted area. Would they be dropped more often? And could their presence (in the case of permanent transmission while door open if we stick to the example) have a negative impact on WiFi performance? Since I am not deep into wireless communications I don’t know if those channels WiFi is using would be a useful manual setting for such an ESP network.

Sure, they’ll have negative impact on WiFi performance but this has to be done only to critical nodes - other nodes could transmit packet every 200-500ms… Now I am testing the consumer WiFi impact when transmitting packets with 5ms delay. I’m doing speed tests from my laptop and when the packet transmission begins it drops the WiFi channel speed by around 50%…

BTW: My router is on channel 11 and when the ESP operates on channel 12 there is no (noticeable) impact on my WiFi…
I am looking for maybe another one or two interested people to release the source… :wink: