Q: SJWS01LM is now supported?

[ilgrank]

Hi
I see you have added SJWS01LM firmware to the list of official firmwares, and merged #310 into the repo, but SJWS01LM is not among the list of supported devices.
..what is the current status of SJWS01LM?
Thanks!

[pvvx]

There is nothing to add or correct to SJWS01LM. The official firmware works well.
CGPR1 also does not have alternative firmware. The official firmware is also normal.

[ilgrank]

Well, what is missing from SJWS01LM is the ability to use custom data formats (ATC,PVVX and BHome), the possibility to alter beacon frequency, unbind from mihome and so on.. there's much lacking, actually.

[pvvx]

ATC and PVVX formats are not suitable for SJWS01LM and CGPR1.
Unbinding from MiHome is done in TelinkMiFlasher.
In Home Assistant, SJWS01LM and CGPR1 will be recognized automatically.

[ilgrank]

You're right about unbinding, thanks!
...but adjustable RF TX Power and Bluetooth advertising interval frequency can't be set with stock firmware
As far as I understand, these should be possible on SJWS01LM , no?

[pvvx]

RF TX boost will fail if powered by CR2032. The device will crash and restart. Higher RF TX levels require a larger power supply.
The advertising interval is set to be compatible with all BT adapters. If you increase the interval, many issues - "Does not connect... in Linux"

What else? Play flashing?

[ilgrank]

RF TX boost will fail if powered by CR2032

It is an issue just of SJWS01LM? I have the LYWSD03MMC without capacitors and I have upped the TX power slightly with no issues.

My LYWSD03MMC(s) are a floor away from the receiver and the receiver has a pretty good external antenna already, so there's not much else I can do, other than increase TX power.
With stock FW I seldom receive LYWSD03MMC(s) beacons, while the reception is good with your firmware and a slight TX power increase, that I compensate on the battery with reduced beacon frequency
Also, I used CR2050 on some of the LYWSD03MMC: it is an easy mod, will fit in the LYWSD03MMC case, and has a little more capacity/power.

I also lowered the beacon interval to 15 seconds to save battery (as per your consumption graphs) and I had hope to do the same with SJWS01LM

[Ircama]

Hi I see you have added SJWS01LM firmware to the list of official firmwares, and merged #310 into the repo, but SJWS01LM is not among the list of supported devices. ..what is the current status of SJWS01LM? Thanks!

That PR was simply referring to a preliminary support of the native SJWS01LM protocol in atc_mi_interface, including tools and related codec and does not imply the need of a specific custom firmware. A completion of the work might be pulled in the near future, depending on the available time to test and close it.

I also lowered the beacon interval to 15 seconds to save battery (as per your consumption graphs) and I had hope to do the same with SJWS01LM

The native firmware of the SJWS01LM device appears to have a beacon interval of about 10 minutes (with one repetition in the subsequent minute: each beaconing consists of up to 4 frames, generally 1 or 2, with encrypted content including the battery percentage level).

[pvvx]

In the future, if there is nothing else to do, it is possible to convert the SJWS01LM to Zigbee...
SJWS01LM cannot be disassembled, and any error in the firmware means the sensor is thrown into the trash.

[ilgrank]

Thanks for the clarification @Ircama and @pvvx !
As a side question, is there any range improvement going from BLE (LR) to Zigbee?
I have seen plenty of BLE vs Zigbee comparisons, but no BLE LR vs Zigbee ones.

[pvvx]

Comparison Table

Real measurements on TLSR825x chips with line of sight and 0 dB transmitter power:

Zigbee - 100..500 м
LE Long Range - 200..1000 м

For +10 dB transmitter power:

Zigbee - 200..700 м
LE Long Range - 500..1600 м

According to theory, due to different modulation and recovery codes, the difference in range should be twofold.
Depends on the sensitivity of the receiving device and the level of interference on the radio.
Old chips from TI, nRF, (and any old) have a poor lower reception level and this cannot be corrected with an antenna.
At the same data transmission frequency, Zigbee loses due to higher battery consumption.

---

An example that works for me:

Receiver - inexpensive Realtek RTL8761 BT adapter

Transmitter: MJWSD05MMC, setting: TX +0dB, LE Long Range, BTHome, BLE advertising interval 5 sec.

Signal Path:

1. RTL8761, 3 internal wooden walls in the workshop, external - metal sheet.
2. Street - 200 meters
3. Another house, log, 1 wall, MJWSD05MMC.

Another thermometer, locked in an iron refrigerator:

---

Due to the long distances on my private property, Zigbee needs to be retransmitted to BLE.

[aptem334]

В будущем, если больше ничего не останется, можно преобразовать SJWS01LM в Zigbee ...
SJWS01LM невозможно разобрать, и любая ошибка в прошивке означает, что датчик выброшен в корзину.

Добрый день, в итоге удалось преобразовать в zigbee?

[evlo]

A bit offtopic, I do have quite a few WSD500A

It does say ts0201 as its zigbee model, but it looks rather different then both
https://pvvx.github.io/TS0601_TZE200/
https://pvvx.github.io/TS0201_TZ3000/

it is ZTU + CHT8305

it does have 3 test pins that would be enough for flashing

comparing to datasheet
https://developer.tuya.com/en/docs/Document/ztu-module-datasheet?id=Kamwy32jy50jp
One should go to gnd, but others others? To TX and RST?

TP1 is Uart_RXD
TP2 is Uart_TXD
TP4 is GND
I guess that means i would need to connect directly to SWS, VCC and GND on the tuya ZTU module to flash?

Do you think there is significant chance it might work with your TS0201 firmware?

---

zigbee2ble is coordinator for zigbee that zigbee devices pairs to?

[pvvx]

@evlo - pvvx/BLE_THSensor#3 (comment)

[ilgrank]

@pvvx : sorry to come at the 'custom firmware' topic again, but there seems to be another issue with using the standard firmware.
According to the OpenMQTTGateway devs,:

The SJWS01LM seems to only be supported by decrypting the encrypted BLE advertising data, along with the individual key.
https://custom-components.github.io/ble_monitor/by_brand#xiaomi
Decryption is currently not yet supported by OpenMQTTGateway

..so another reason to have a custom firmware would be to have the data advertised in unencrypted format, if I understand well

[pvvx]

SJWS01LM uses a primitive water sensor, low reliability. There is no point in considering such a sensor for an emergency system. This is a children's toy.

For normal operation of such sensors, OpenMQTTGateway must monitor the sequence of packet numbers, battery status, and have reliable constant reception on Bluetooth radio frequency channels.

[ilgrank]

Isn't a primitive sensor better than nothing? :)
Jokes apart, do you suggest any better BLE alternative? I own a couple of Shelly Flood, but they are wifi and their battery doesn't last very long alas..

[pvvx]

There is no alternative to BLE.
Not just the battery. But also in terms of range in LE Long Range, as well as in the absence of a coordinator.

The sensor itself, consisting of two contacts, is primitive and does not always work.
An analysis of the capacitance and resistance between the contacts is required.

To write a program for SJWS01LM there is an SDK from Telink.
And examples of the source code of supported thermometers are posted for everyone who wants to change them and supplement for SJWS01LM. The license allows you to copy and modify the codes without attribution or any links - Not GPLv3/GNU or other options requiring copyright..

[evlo]

Since we are suggesting, you can do diy with ie. optical flood/leak sensor (ie. https://item.taobao.com/item.htm?id=626837370107) and hct-08 or similar uart transceiver and hande the raw data on the device receiver is plugged in to.

Also since you have diy option for reed switch in the LYWSD03MMC firmware, would the to point flood/leak sensor, like this one https://item.taobao.com/item.htm?id=42418867871 work as a reed switch?

I know this is not an answer, but maybe this can help you find the solution, depends a lot on what exactly are your needs and environment.

I do not think the optical variant could work as reed switch.

[pvvx]

There has been a solution for a long time, but it requires 3 details:

1. Diode (several MHz)
2. Resistor
3. Capacitor

The program must be supplemented with a special function (developed a long time ago). The two sensor wires must be short and insulated. Sensitivity from several pF. That is, it “feels” the approach of a hand.
A complete analogue of https://github.com/rbaron/b-parasite is obtained (but with significantly lower consumption).

Can work through a plastic housing.

But each form of sensor requires adjustments due to different sizes, insulation and different parts.

[Ircama]

The SJWS01LM seems to only be supported by decrypting the encrypted BLE advertising data, along with the individual key.

It can be decoded: you simply need the bindkey.

You can test a preliminary version of the Python API, which also supports Xiaomi Mijia devices like SJWS01LM, by installing it locally.

The following program decodes and prints the first 20 BLE advertisements of one or more devices implementing the Xiaomi Mijia BLE advertisement protocol, detecting flood and battery data natively produced by the SJWS01LM sensor.

The bindkey can be obtained via TelinkMiFlasher.

import asyncio
from bleak import BleakScanner
from bleak.uuids import normalize_uuid_str
from functools import partial
from pprint import pprint
from atc_mi_interface import mi_like_format, atc_mi_advertising_format

bindkey = {
    "54:EF:44:C6:33:6B": bytes.fromhex("ff1b17f0a386d27d407529a9f0463653"),
    "54:EF:44:AA:BB:CC": bytes.fromhex("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"),
    # ...
}

async def ble_coro():
    count = [0]
    MAX_COUNT = 20
    stop_event = asyncio.Event()

    def detection_callback(count, device, advertisement_data):
        format_label, adv_data = atc_mi_advertising_format(advertisement_data)
        if format_label != "mi_like" or not adv_data:
            return
        mac_address = bytes.fromhex(device.address.replace(":", ""))
        print(
            f"{count[0]}. {device}. Format: {format_label}. "
            f"RSSI: {advertisement_data.rssi}."
        )
        atc_mi_data = mi_like_format.parse(
            adv_data,
            mac_address=mac_address,
            bindkey=(
                bindkey[device.address] if device.address in bindkey else None
            )
        )
        print(" ", atc_mi_data)
        flooding = atc_mi_data.search_all("^flooding$")
        battery = atc_mi_data.search_all("^battery_level")
        if flooding:
            print()
            print("Flooding:", flooding[0])
        if battery:
            print()
            print(f"Battery: {battery[0]}%")
        print('-' * 80)
        count[0] += 1
        if count[0] == MAX_COUNT:
            stop_event.set()

    async with BleakScanner(
        detection_callback=partial(detection_callback, count)
    ) as scanner:
        await stop_event.wait()
    print("Stopped")


asyncio.run(ble_coro())