SwitchBot Contact Sensor Counters

[DigiH]

SwitchBot Contact Sensor activity counters added

Checklist:

• The pull request is done against the latest development branch
• Only one feature/fix was added per PR and the code change compiles without warnings
• I accept the DCO.

[DigiH]

Waiting for verification with device …

@evlo @masfernandez any chance you can test and verify this on an ESP32 with OpenMQTTGateway with your SwitchBot Contact Sensor?

Thanks

[masfernandez]

@DigiH Why you in hurry? the code is unfinished. I still have to decode PIR and HALL information, but I'm not having much time.

I will let you know when it's done properly.

Regards,
MA

[DigiH]

@DigiH Why you in hurry? the code is unfinished. I still have to decode PIR and HALL information, but I'm not having much time.

Not in a hurry, but was more directed at evlo who mentioend that he wanted to have the ability to register the push button on contact sensor, so getting this functionality into the next release of Decoder would be nice.

PIR and HALL should already be fully implemented in the current version of the decoder, unless it is not working properly for you.

[evlo]

Do i need to build the development branch and flash it using serial or is there some easier way?

Update: I think I understand now - gateway and theengs are different theengs.

[DigiH]

Do i need to build the development branch and flash it using serial or is there some easier way?

I can kick off a test build run, which you can then upload through the web install page. Still needs your ESP32 being hooked up to the PC though.

Would that work for you?

Alternatively you could build and upload the development branch and just change the decoder URL in platformio.ini from
decoder = https://github.com/theengs/decoder.git
to
decoder = https://github.com/DigiH/decoder#SBCS-counts

[evlo]

If you could just attach bin that I can flash onto esp32 dev board that would be easiest for me.

[DigiH]

If you could just attach bin that I can flash onto esp32 dev board that would be easiest for me.

I'll start off test builds, with bins and web upload available then - takes about an hour to run … updating here when they are ready

[DigiH]

@evlo

The test binary can be installed through the web upload at
https://docs.openmqttgateway.com/dev/upload/web-install.html

Please chose the esp32dev-ble-datatest

Or the direct binary download at
https://github.com/1technophile/OpenMQTTGateway/raw/gh-pages/dev/firmware_build/esp32dev-ble-datatest-firmware.bin

After the upload to your ESP32 please follow the initial WiFi and MQTT credential set-up
https://docs.openmqttgateway.com/dev/upload/portal.html#wifi-and-mqtt-configuration

[evlo]

{"id":"FA:4D:5F:*","mac_type":1,"adv_type":0,"manufacturerdata":"6909fa4d5fbae6abf90c067c08374f","rssi":-96,"servicedata":"64005700067c08374f","servicedatauuid":"0xfd3d","brand":"SwitchBot","model":"Contact Sensor","model_id":"W120150X","type":"CTMO","acts":true,"cont":true,"contact":"closed","movement":false,"lightlevel":"dark","scopetested":false,"in_ct":1,"out_ct":0,"push_ct":15,"batt":87}

open close and few presses

{"id":"FA:4D:5F*","mac_type":1,"adv_type":0,"manufacturerdata":"6909fa4d5fbae6ab020c0031002514","rssi":-94,"servicedata":"640057000031002514","servicedatauuid":"0xfd3d","brand":"SwitchBot","model":"Contact Sensor","model_id":"W120150X","type":"CTMO","acts":true,"cont":true,"contact":"closed","movement":false,"lightlevel":"dark","scopetested":false,"in_ct":0,"out_ct":1,"push_ct":4,"batt":87}

---

---

---

PIR:

{"id":"CC:B9:92:*","mac_type":1,"adv_type":0,"manufacturerdata":"6909ccb9925f320fa21c0735","rssi":-88,"servicedata":"738064073609","servicedatauuid":"0xfd3d","brand":"SwitchBot","model":"Motion Sensor","model_id":"W110150X","type":"CTMO","acts":true,"cont":true,"movement":false,"led":false,"sensingdistance":"short","lightlevel":"dark","batt":100}

[DigiH]

Thanks a lot @evlo,

The push_ct should count up with every push and rotate between 0-15. Hopefully responsive enough for your desired push recognition.

This will also propagate into the Theengs Gateway HA add-on

[evlo]

i know this is not the correct place to post this, but for PIR if "led":false is not about actual state of the led, but whether i have set led to light up on motion detection, then it should be true and not false.

[DigiH]

is not about actual state of the led, but whether i have set led to light up on motion detection, then it should be true and not false.

Let me quickly double check this decoding …

I followed the official SwitchBot API
https://github.com/OpenWonderLabs/SwitchBotAPI-BLE/blob/latest/devicetypes/motionsensor.md

so for your PIR case above
"servicedata":"738064073609"
Byte[5] - bit[5] = 0
which should be Bit[5]:LED state 0:disable 1:enable, i.e. "led":false

But that doesn't mean that in the offical API there couldn't be a typo, if you think it should be different for you.

Do the remaining Byte[5} settings correspond with what is set for your PIR?

Bit[3:2]: Sensing distance 00:Long 01:Middle 10:Short 11:Reserve
Bit[1:0]: Light intensity 00:Rserve 01:dark 10:bright 11:Reserve

[evlo]

yes,
distance and light is correct

[DigiH]

yes,
distance and light is correct

but you have set the LED state to ON in the preferences, so it is showing wrong, following the documentation, and should likely be reversed, right?

Could you just do a quick test by setting LED to OFF in the SwitchBot app and see what is decoded then?

[evlo]

yes, that is what I was just trying out :)

1. I set it to OFF in preferences - still decoded as "led":false
2. I set it to ON in preferences - still decoded as "led":false

I even tried triggering motion so the led does turn on, it does, but it still just returns false (or in the graph it says raw value 0 all the time)

Also if i set indicator light to off in switchbot app, LED does not turn on when motion is detected

[DigiH]

• I set it to OFF in preferences - still decoded as "led":false

• I set it to ON in preferences - still decoded as "led":false

Then I am wondering if they might have swapped the IOT (which is not currently included in the decoder) and LED state in the documentation.

Could you post the MQTT output with all the data again please for both LED state ON and OFF, so that it will be apparent in the data which bit is actually the LED state?

[evlo]

on

{"id":"CC:B9:92:5F:32:0F","mac_type":1,"adv_type":2,"manufacturerdata":"6909ccb9925f320fa71c00d1","rssi":-77,"servicedata":"73806400d109","servicedatauuid":"0xfd3d","brand":"SwitchBot","model":"Motion Sensor","model_id":"W110150X","type":"CTMO","acts":true,"cont":true,"movement":false,"led":false,"sensingdistance":"short","lightlevel":"dark","batt":100}

off

{"id":"CC:B9:92:5F:32:0F","mac_type":1,"adv_type":2,"manufacturerdata":"6909ccb9925f320fa71c00e5","rssi":-76,"servicedata":"73806400e509","servicedatauuid":"0xfd3d","brand":"SwitchBot","model":"Motion Sensor","model_id":"W110150X","type":"CTMO","acts":true,"cont":true,"movement":false,"led":false,"sensingdistance":"short","lightlevel":"dark","batt":100}

[DigiH]

now that is weird, as the supposed LED bit - Byte[5] - bit[5] - did not change with the LED settings change, with the whole Byte[5]Bit[7-4] being 0 in both cases.

Could well be because of an incorrect documentation, or some firmware glitch in the encoding - I assume you have the latest firmware on your PIR?

[evlo]

I do. d1 - e5 - something did change, so at least that :)

11010001
11100101

so alt least 3 bytes did change
this is just hex to bin, i did not take time to read trough https://github.com/OpenWonderLabs/SwitchBotAPI-BLE/blob/latest/devicetypes/motionsensor.md

[DigiH]

So unless it might take a while before the LED settings change is being included in the advertised servicedata I think it can only be a erroneous documentation or advertising encoding fault.

d1 - e5 - something did change, so at least that :)

Again, according to the documentation this octet and the preceding one should be part of the

PIR UTC | Since the last trigger PIR time

So I would assume this time part would be different with every single braodcast received.

[evlo]

So wonderlabs are actually doing the communication differently then what is advertised?
Probably 0x02 Get device basic information command in the documentation, that also mentions led.

[DigiH]

As a last test, would you mind also changing the settings for sensingdistance and shine a bright light on it for the Light intensity?

[evlo]

{"id":"CC:B9:92:5F:32:0F","mac_type":1,"adv_type":2,"manufacturerdata":"6909ccb9925f320fab2c002f","rssi":-88,"servicedata":"738064002f02","servicedatauuid":"0xfd3d","brand":"SwitchBot","model":"Motion Sensor","model_id":"W110150X","type":"CTMO","acts":true,"cont":true,"movement":false,"led":false,"sensingdistance":"long","lightlevel":"bright","batt":100}

[DigiH]

Probably 0x02 Get device basic information command in the documentation, that also mentions led.

This part is only available by connecting and reading, not in the scope of Decoder, but still possible with OpenMQTTGateway with the READ command.

[DigiH]

{"id":"CC:B9:92:5F:32:0F","mac_type":1,"adv_type":2,"manufacturerdata":"6909ccb9925f320fab2c002f","rssi":-88,"servicedata":"738064002f02","servicedatauuid":"0xfd3d","brand":"SwitchBot","model":"Motion Sensor","model_id":"W110150X","type":"CTMO","acts":true,"cont":true,"movement":false,"led":false,"sensingdistance":"long","lightlevel":"bright","batt":100}

So everything else looks fine, just the LED settings state is not correctly advertised, at least not according to the documentation.

Thanks for pointing this out! It will need further investigation and communication from SwitchBot to see what the issue is.

[evlo]

I think it is quite minor thing, but I do not know how other use this thing, personally if switchbot would make option for remote advertise key presses would be much more (even monetarily :D ) appreciated by me then fixing the led status.

[DigiH]

I think it is quite minor thing, but I do not know how other use this thing, personally if switchbot would make option for remote advertise key presses would be much more (even monetarily :D ) appreciated by me then fixing the led status.

I have seen the issue you logged about it, and I know of others contacted them about it, so hopefully this will be implemented with a future firmware update - and is then also being documented correctly ;)

Thanks again for your verification of the Contact Sensor Counters here.