[FR] SJWS01LM support?

[ilgrank]

Hi (re-opening as the previous FR got auto-closed because of my inactivity)
The Xiaomi SJWS01LM BLE water leak sensor is not currently supported by Theengs, but it is working in Home Assistant, and the device can be activated unlocked from xiaomi in the same way as the other ATC1441 devices

Could support for it please be considered?
Thanks

[DigiH]

Hi @ilgrank

Can you let us know which exact firmware you are installing on your SJWS01LM ?

Then also set Advertisement and advanced data to true on your OpenMQTTGateway and copy and past some sample undecoded MQTT messages from your SJWS01LM.

[ilgrank]

Thanks for the lightining-fast reply DigiH
I am running the stock firmware (and don't know if there is an alternative, since PVVX told me that the stock FW is good enough)
Turning on Advertisement and Advanced data, I have, I get:

{
 "id":"18:C2:3C:23:xx:xx",
 "mac_type":0,
 "adv_type":0,
 "name":"Mi Flood Detector",
 "rssi":-56,
 "servicedata":"105963085ccb04233cc218",
 "servicedatauuid":"0xfe95"
}

EDIT: this post from Ircama is very informative about the payload

[DigiH]

Ok, if it is the stock firmware, could you post a few more similar samples as above, along with the status of the SJWS01LM BLE water leak sensor?

I assume the sample above was with 'no leak detected', correct? Some 'leak detected' messages would also be required.

And could you also let me know what the current battery level of the device is?

[ilgrank]

I just put another one in water, and I got:

{
  "id": "54:EF:44:E0:xx:xx",
  "UTCtime": "2026-03-29T20:20:06Z",
  "unixtime": 1774815606,
  "mac_type": 0,
  "adv_type": 0,
  "name": "Mi Flood Detector",
  "rssi": -79,
  "servicedata": "305a6308019634e044ef5408",
  "servicedatauuid": "0xfe95"
}

EDIT: I am monitoring the servicedata but it seems not to be changing

[DigiH]

These messages do look encrypted. Is there still the default encryption active on the device, or has it been removed discussed in the PVVX thread?

And as per the previously closed issue. Several more messages would be required, no leak and leak. But only without any stock firmware default encryption active for possible OpenMQTTGateway inclusion.

[ilgrank]

correct, afaik the beacon is encrypted.
Ircama provided a sample code to decrypt it, but I lack the skills to have it running.
I have monitored the beacon with and without the sensor in the water, and data seems not to be changing.
If it can be of use, I also have the MI Token and the MI Bind Key that the flashed produced.

[DigiH]

And it also seems to have randomly changing MAC addresses, which is not possible for address resolving in OpenMQTTGateway - that is if the two above messages are from the same device, but with different MAC addresses.

[ilgrank]

No, sorry for the confusion, I wrote "I put another one", i was meaning a different one, i have several, sorry if I was not clear about that.
Just to be sure, I also re-did the binding, and did a leak ON/OFF cycle. now the servicedata has changed to:
10596308039634e044ef54

[ilgrank]

According to Gemini:

Byte-by-Byte Decoding
Hex Segment	Meaning	Value / Details
10 59	Frame Control	Indicates a version 2 MiBeacon (unencrypted).
63 08	Product ID	0x0863 (2147) = Xiaomi Mijia LYWSD03MMC
03	Frame Counter	A sequence number used to detect duplicate packets.
xxx xx e0 44 ef 54	     MAC Address	54:EF:44:E0:xx:xx (in reverse order).

[DigiH]

The two different devices have different length servicedata, and the MAC address is in reverse right at the end of the 1st. while there is an extra byte before at the end, and only then the MAC address is in reverse for the 3nd.

Pretty late here, so off for today. I'll have a look at it over the next few days, and would require you posting a few more samples, with no leak and leak, but both for the same devices'.

[ilgrank]

The two different devices have different length servicedata, and the MAC address is in reverse right at the end of the 1st. while there is an extra byte before at the end, and only then the MAC address is in reverse for the 3nd.

yes, sorry for the confusion. It is also possible that these sensors have different firmwares vesion, but now I removed the first one and I'll keep doing tests on the later one
Thanks for your support

[DigiH]

Byte-by-Byte Decoding
Hex Segment Meaning Value / Details
10 59 Frame Control Indicates a version 2 MiBeacon (unencrypted).
63 08 Product ID 0x0863 (2147) = Xiaomi Mijia LYWSD03MMC
03 Frame Counter A sequence number used to detect duplicate packets.
xxx xx e0 44 ef 54 MAC Address 54:EF:44:E0:xx:xx (in reverse order).

Yes, but that leaves no additional bytes for any actual device properties to be included ;) apart from the one message with the one byte longer message. Which could mean that this longer messages happens when a leak is detected, but it doesn't seem to include any battery ;eve;, unless you can also post the battery level along with more sample messages.

U less there are also other broadcasts data messages which the device send out along with the above ones.

Let's see what other sample messages you can add along with the leak and battery status.

[ilgrank]

Ok, some interesting finding at last. After the initial, non-encrypted beacon, the device sleeps for 10 minutes.
After that, finally it begins transmitting the encrypted beacons:

flood: 58596308029634e044ef5409b00b0f0000002422d233
No flood: 58596308059634e044ef5487567fa30000009b1a91b9

I made Gemini analyze them, and I got this analysis for 'No-Flooad' beacon:

Using the decryption logic required for MiBeacon V5 and your Bindkey, we can finally see exactly what the sensor is reporting.

The string 58596308059634e044ef5487567fa30000009b1a91b9 breaks down as follows after AES-CCM decryption with key b865b76ebf9271b16862b3175bf31693:

The Decrypted Data

Decrypted Payload: 10 00 01 00

Technical Breakdown

For the Mi Flood Detector (Product ID 0863), the payload follows the Xiaomi "Object" format:

Byte Segment | Meaning | Value / Description -- | -- | -- 10 00 | Object ID | 0x0010 = Flood/Moisture Status 01 | Length | 1 Byte of data follows 00 | Value | Dry (No Flood Detected)

Export to Sheets

---

Correcting the Code Assumptions

You mentioned some of my previous assumptions were wrong, specifically regarding how the device is identified. Looking at the code you provided from the atc_mi_interface library, here is the critical clarification:

1. Object IDs: In MiBeacon V5, the "Event" and "Property" IDs are standardized. For this device, 0x0010 is the specific moisture object.

2. State Logic: In your "Flood" state (which you mentioned previously), that last byte 00 would flip to 01.

3. The Parser: Your code uses atc_mi_data.search_all("^flooding$"). Depending on the version of the atc_mi_interface you are using, the key might actually be named moisture or leakage.

Note: If your script isn't printing the "Flooding:" line even when you know it's wet, try adding print(atc_mi_data.keys()) to see the exact string the library uses for the 10 00 ID.

Summary of this Packet

• MAC: 54:EF:44:E0:34:96

• Status: Dry (The value is 00).

• Message Type: This was the 5th message sent (05) in this sequence.

(Also, I'm not 'censoring' the MAC address anymore since it is needed for the actual decryption, along with the bind key)

[DigiH]

I do not know where the much longer data comes from in your above conversation with Gemini as you haven't posted any related undecoded MQTT messages, so I really do not know if and how this might be integrated into OpenMQTTGateway.

[ilgrank]

Sorry, it was late at night and I had just posted the undecoded servicedata in a very messy way. To rectify:

servicedata: 58596308029634e044ef5409b00b0f0000002422d233 <-Flood
servicedata: 58596308059634e044ef5487567fa30000009b1a91b9 <-No Flood

but in retrospect, I should have posted the full payload instead for clarity and for the missing serviceuuid.
I will re-capture and post the full payload later when I'm back home
Thanks for your support