Thanks for the link, I read through quite a few of those protocols already (including pronto) 
I tried using pronto initially because I liked the fact it encoded 4byte chucks that could include text but when I tried to work with it in ESPHome I struggled with sending variable commands. Maybe I did something wrong but the error logs led me to believe that I might have to make adjustments to the backend code that generates the protocol should I wanted to send commands that weren’t predefined in the code. As I couldn’t figure out how to send custom (not predefined) commands over pronto, and I didn’t want to define all commands from state 0-100 in the code, I switched to raw and it was much easier to work with.
You are right that I could use something like an aircon protocol but my data structure for the raw implementation already includes the adress and checksum so I’d rather stick to raw as I have more freedom. Also I figured that by building my own specifically for esphome device to device communication, it might be useful to more people as opposed to “hacking”/(mis)using an existing (aircon) protocol.
Currently I’m setting up the data array I transmit over raw in the following manner:
- The first number in the array will be used as the adress/id of the channel (could be seen as id of the slave but there is nothing that would prevent there being multiple channels between a master and slave device.)
- The second number will probably end up being used to indicate if this message is a command that requires action and a response, or if it is just a state update.
- The next numbers in the array will represent target states (if it is a command action), or current states (if it is status update).
- …
- As the array needs to be an odd length a number (‘333’) is added here if needed to make the array length odd. (Could be any number, but I arbitrarily picked 333 as my code for “blank”).
- This number is the checksum [ array_sum - (array_sum%2000) ]
- As I had some issues reading the last value a couple of times (I made a mistake in the setup but figured I’d just leave this) this value is also set to a random number just so the checksum isn’t the last number, in this case it’s ‘333’ (Again could be any number, but I arbitrarily picked 333 as my code for “blank”).
Basically this array is a list of positive non zero integer numbers that represent the pulse lengths of the signal. For sending numbers, I’m not using any fancy encoding to binary, I’m literally just using a pulse length to represent the number value. ie a pulse of length 900 would represent the number 90 etc… Then when i receive 900, i divide by 10 and round to the nearest integer to get the number again to read the state. Has worked well so far.
If you look at the code I shared in my previous post, I made a proof of concept. The state of the number entity is transmitted from pin 16 over a wire that is connected to pin 17. The received data on pin 17 is then interpreted and used to update the sensor entity. This simple test is working very quickly and reliably (so far… 
)
If you have suggestions, see any potential pitfalls or have ideas for improvements I’d definitely be interested!
This is a really nice repo thank you for sharing! However I would prefer a wired solution to reduce the wireless signals in my house, but this is indeed very similar to what I am looking for. I am currently trying to make something very similar with the remote_transmit and remote_receive protocols that can work both as a wireless implementation and as a wired implementation. Nevertheless this repo will be useful to see how they handle interactions between devices, dropped messages, error handling, etc… Again, thank you for sharing, hadn’t found that one yet