search

C19HOP / WiSafe2-to-HomeAssistant-Bridge

Connect FireAngel WiSafe2 alarm networks to HomeAssistant
50 stars 11 forks source link

Command to query info about individual SID position? #2

Closed Tho85 closed 2 years ago

Tho85 commented 2 years ago

Hi,

I also did some research into my network of ST-630-DET devices. I created a small breakout PCB where you can easily connect a logic analyzer to the SPI bus. I was able to attach a Arduino Pro Mini 3.3V to it, so I didn't need any logic level converters. My firmware for the Arduino is a more or less generic SPI slave to UART converter, and I was able to connect it to an ESP8266 programmed with ESPHome and integrate the alarms into Home Assistant. At this point I found your repo, which would have saved me quite some time in the past months... :sweat_smile:

As a next step I would like to create a generic WiSafe2-to-MQTT gateway. For this I would like to be able to query the radio module for all known devices. For all that I know, the command D3 03 7E queries the radio module for its SID map (map of devices), and a response of D4 03 81 00 00 00 00 00 00 00 7E indicates that the module knows of devices at SID 0 and 7 (0x81 = 1000001b). However, I can't find any information on how to query more data for the individual SID positions.

Do you know a command that I can send to the radio to query more details for a specific SID position? Could you maybe try to extract it from your FireAngel gateway's serial console? It looks like at this point the gateway would have sent such a command to the module, if it hadn't seen all devices before.

Thanks in advance!

PS: Interestingly, some of my ST-630-DET devices present themselves with 4-byte serial numbers, making all packets a byte longer. This may be a small challenge...

Tho85 commented 2 years ago

OK, I think I may have found it by trial and error. The command D3 06 07 7E returns a positive reply (46 7E), and after some time I get this message: D4 06 07 63 8E 00 AA F3 D8 6C 0C 00 02 7E. It looks like this is diagnostic information from the device at SID position 7, since the device's serial number (D8 6C 0C) shows up in the response. So I understand the command as follows:

Closing this issue for now.

C19HOP commented 2 years ago

Hi Tho85,

If I were going the wireless route, I'd have arrived at the same place. i.e. 3.3v Pro Mini >> ESP8266

I wasn't sold on the idea only because:

However, retrospectively, yes, I can see that MQTT is likely to be preferred by many. If I were starting over, I noted that there are some SPI slave examples for the ESP32. So even better, we could probably do it all in one chip :)

The only D3 commands I had observed myself were used for radio get-pairing-status, enter-pairing-mode, erase-pairing. I did not observe any 'query for known devices' messages. Seems like great potential for a simpler automation.

Cheers.

Tho85 commented 2 years ago

If I were starting over, I noted that there are some SPI slave examples for the ESP32. So even better, we could probably do it all in one chip :)

Been there, done that. I tried an ESP32 with the SPI slave driver, however it was very unstable. I observed hiccups on the SPI clock line, as well as many dropped transactions, and that was where I cancelled the experiment. Most of the SPI slave logic is implemented in software, and that seems to be unstable.

The ATmega328p / Arduino Pro Mini on the other hand does all of the SPI slave handling in hardware, throws an interrupt as soon as it receives data, and allows for a much more stable solution IMO. I've been using that in the last days and it looks rock solid to me.

Tho85 commented 2 years ago

PS: Interestingly, some of my ST-630-DET devices present themselves with 4-byte serial numbers, making all packets a byte longer. This may be a small challenge...

Posting this here, in case anyone stumbles across this in the far future. My assumption was wrong, the devices all only have 3-byte addresses. However, my device presented itself with a serial number of 7D 01 6C 0C. The real serial number seems to be 7E 6C 0C, but since 7E is the stop word used for communication (always the last byte of a transaction), it is converted to 7D 01 6C 0C.

--> 7E is replaced by 7D 01, and 7D is replaced by 7D 02. Not only for serial numbers, but for all fields. So if you ever come across a transaction that is a byte longer than expected, this may be the explanation.

Tho85 commented 2 years ago

FYI, I've got the first prototype of my gateway up and running: https://github.com/Tho85/ws2mqtt