@marcel1: sorry, I had to mention you need to change some packet conditions, my bad!
The old script contains the following condition, but we actually need packet b\ ‘xd8’
elif packet[:1] == b'\xd0' or packet[:1] == b'\xd2' or packet[:1] == b'\xd8':
pass # recognised, but as yet undeciphered JA-101 packets
So I changed this condition to
elif packet[:1] == b'\xd0' or packet[:1] == b'\xd2':
pass # recognised, but as yet undeciphered JA-101 packets
And I added a new condition for the sensors only
elif packet[:2] == b'\x55\x09' or (packet[:2] == b'\xd8\x08' and packet[10:12] == b'\x55\x09'):
What it actually scans for is:
- packets which start with 55 09 or
- packets which start with d8 08 and have 55 09 on position 11 and 12 (this seems to be the only anomaly)
So packet[10:12] is from packet 11 (remember, start counting at 0) til 12 (not including). I also had to test this before I used it.
I checked your analysis before analyzing my data, but it seems to be different.
- All sensors I tested were wireless and starting in the 55 09 range.
- At the moment, I don’t have any messages starting with 52 or 55 08. I’ve added them in my script to keep an eye on them. Maybe I miss important data we could use
Things in common:
- I have tested 2 doors with wireless magnetic sensors, but both seem to have different bytes for opening and closing it. But at least they seem to be consistent per device.
- I also noticed 1 instead of 2 different bytes for PIR sensors. So for now I’ve build a time out after 1 sec.
This afternoon I’ve made some progress. Pretty hard with zero python skills, but there are some good examples online. It just takes a while to figure out how things work and how I think we could make this work for anyone, without sniffing packets.
So I decided to make a copy of @matt’s Jablotron component to build a multiple platform component in order to add binary sensors (on/off/opened/closed/etc.). Here you’ll see a working PIR sensor as a binary sensor:
Later on I thought, as a user you don’t want to define all your sensors one by one. And if you would, how would you even know how to identify them? You don’t want users to sniff their packets like we did, so we need to make something what’s more dynamic.
If HA finds a unknown packet starting with 55 09, it’s probably a device which hasn’t been triggered yet. So I used the 5th and 6th byte to give the binary sensor an ID. You could always give it a friendly name and a device class (door/window/motion):
Here you can see new binary sensors incoming as soon you trigger them. Sensor 40_01 is a wireless PIR, 00 02 is a wireless magnetic door sensor and 80_01 is another wireless magnetic door sensor I opened.
Please ignore the ‘binary_sensor.jablotron_door_sensor’ sensor. This was the original binary sensor catching all 55 09 packets regardless the device or state.
Pro’s: as a user you don’t need to setup all sensors manually in configuration.yaml. The script will currently create new binary sensors as soon as it receives the right packets.
Con’s: after a reboot, all your binary sensors are gone. Your history is still there, but sensors will be shown as soon as they report. Which could be never if you won’t open all windows, doors, etc.
So I guess we need to decide how we want to take this to another level.
@matt: do you have any idea what we should do? At the moment, I used set_state to create any binary sensor we want, but I’m not sure if this would cause any problems later on.
In the meanwhile, I’ll work on my python skills, try to add more functionality (icons, attributes) keep an eye on unknown packets and try to work a new release to publish/test.