Topics for MQTT

[MarkM500]

Hi,

thanks for your firmware. After some problems with connecting to my door sensor (your connection plus connection EN to VCC, internal memory 2MB and not 1MB) I could flash your firmware and read the old firmware. I took this one: https://de.aliexpress.com/item/1005001622897859.html?spm=a2g0s.9042311.0.0.27424c4dWHObjA

But now I have some Nerd-Problems to get the door sensor into my homebridge... The sensor is heard from my mosquitto as doorwindowsensor_7374616 (p2, c1, k15).

The sensor has open/close state plus 3 Battery states. But also with note red or MQTTthing in homebridge I have to know the Topics, or? Or is the topic always the same: doorwindowsensor_7374616?

Installed also MQTTExplorer: Here I see following: {"error":"Unknown MCU command: 55 aa 00 05 00 08 67 02 00 04 00 00 00 64"} and {"error":"Unknown MCU command: 55 aa 00 05 00 05 65 01 00 01 01"}

Thanks for your help Mark

[moesfeld]

Hi, i also had issues with version 1.20 and MQTT. It would keep posting "Query state of MCU..." on the topic "door" (which is what i configured). But no posting on "door/sensor/properties" You should see the correct topic when inspecting "devices/sensor" payload. I flashed 1.18 and everything seems to work fine now.

[christian-nils]

Aaah! Thank you!

I just realized that I had the same issue with 1.2. Flashing back to 1.18 solves the "Query state of MCU..." issue. Since I am using another sensor, I do have Unknown MCU command, but at least I get some data published on MQTT when the sensor is activated.

[christian-nils]

Alright, so after some late-night battles with my Cleverio door and window sensor (tywe3s 2MB module), I finally get something working. I had the same problem as you, @MarkM500, the device status serial packet did not correspond to the original sensor used by @klausahrenberg.

For instance, my sensor returns:

55 aa 00 05 00 12 65 01 00 01 01 66 01 00 01 01 67 02 00 04 00 00 00 64

Which was not a known MCU command by the original firmware:

https://github.com/klausahrenberg/WDoorSensor/blob/40ce4850703ebc9f44253cba54a8b7762cf43eca/WDoorSensor/src/WDoorSensorDevice.h#L115-L130

In that packet, you can read the status of the 3 sensors:

• 65 01 00 01 01: door switch open | 65 01 00 01 00: door switch closed
• 66 01 00 01 01: tampered switch open | 66 01 00 01 00: tampered switch closed
• 67 02 00 04 00 00 00: battery level

So for you, it should be similar. Where one packet corresponds to one of the properties:

• 55 aa 00 05 00 05 65 01 00 01 01: seems to be related to your open/close state
• 55 aa 00 05 00 08 67 02 00 04 00 00 00 64: seems to be related to your battery level

So to make it work you would need to edit the file WDoorSensor.h and decode those packets in the method processCommand (when the commandByte == 0x05).

Regarding the issue with MQTT. It was a bit of a struggle for me to configure it with Home Assistant. So I had to modify the WNetwork.h header in the WAdapter (https://github.com/klausahrenberg/WAdapter) library. My changes were the following:

1. Remove the Last Will message (to do not overwrite my sensors state when the sensor goes into deep sleep)
2. Separate the "alive" key of the mqtt packet from the sensor data. So I have two MQTT topics now: 1) doorwindowsensor/sensor/properties (sensor data), and 2) doorwindowsensor/sensor/availability (sensor wifi connected).

My Mosquitto MQTT broker is configured with the retention option so I can get the last state of the sensor whenever I subscribe to the sensor topic.

Does that help?

[kotXio]

@christian-nils thank's for sharing this details. I also just got an (tywe3s 2MB module), with v1.20 binary, and have an issue {"notice":"Query state of MCU..."} How did you debugged the string which you sensor return? I also would like to check it on my side. Could you please share you changes or maybe even binary, I would like to test it.

UPD: with v1.8 I'v got {"error":"Unknown MCU command: '55 aa 00 00 00 01 01'"} the funny thing, that one time at first start I received: {"idx":"door001","ip":"192.168.32.196","firmware":"1.18","open":true,"battery":"high"} :-O

[christian-nils]

I personally used an old Saleae Analyser to listen to the Serial traffic. So I could read what the TYWE3S and the MCU were communicating. But if you change this line:

https://github.com/klausahrenberg/WDoorSensor/blob/40ce4850703ebc9f44253cba54a8b7762cf43eca/WDoorSensor/src/WDoorSensorDevice.h#L36

To true, you should read all the MCU packets that the TYWE3S receives on your MQTT broker.

I will share my code, I'll let you know when this is up on my repository. The issue that I have at the moment is the reconnection to Wifi that takes 12-14 s every time the sensor is woken up. I believe that is linked to the issue discussed there -> https://www.esp8266.com/viewtopic.php?f=28&t=2430.

[kotXio]

Thanks for the hints. I have tried to build this project with Arduino IDE without luck, but have installed Platformio for Atom and everything went smooth, more or less ))) I Will try to play with it in the meantime. For me v 1.20 all of the time return Query state of MCU... v 1.18 works but not properly, it could return battery status and status when opened, right after the device worked up from sleep with 5s pressing button. but only one time :( then it only sent general messages to devices. So it could be that something not OK in MCU, or corresponding to MQTT broker logs (about broken connections), not enough time to deliver messages. Or something else ))

[kotXio]

I would like to leave here my option, it could help someone lease. I had no luck with erasing flash or upload firmware from the beginning. As usual, GPIO needs to be pulled to the GND. But in my case, it was also needed to pull RST to GND when you power ON the device and release it when you start to connect to the device with esptool.py.

[kotXio]

I have tried the solution from https://www.esp8266.com/viewtopic.php?f=28&t=2430 With some adjustments connect to Wifi takes 3-5s and MQTT 1-2s.

But now I've got the issue that probably data from MCU not ready at the moment (need to investigate).

[christian-nils]

Nice! Would be nice if you could share your changes to reach 3-4s.

Unfortunately I fried two of my sensors... I still don't understand why, so I cannot test at the moment my firmware changes. I will get more sensors and hope that I don't kill them too :)

[christian-nils]

I have pushed my modifications on GitHub now https://github.com/christian-nils/CleverioDoorSensor. For the MCU commands, you can see the main changes at this link: https://github.com/christian-nils/WDoorSensor/commit/8ee3f516393400d7754b2fed1af59b53511d9a3b#diff-a348507c6a89920c6a4bf14edd17cc341fd0fa8537561b10e7dcd81e077942ee

To fix the MCU query issue, I just reverted the changes in WDoorSensor.cpp to the 1.18 version (https://github.com/christian-nils/WDoorSensor/commit/8ee3f516393400d7754b2fed1af59b53511d9a3b#diff-928c53453c51d20bd9dda5996bf92b95cfad890b62ee7fb5009893e91d9e2c61)

[christian-nils]

I have tried the solution from https://www.esp8266.com/viewtopic.php?f=28&t=2430 With some adjustments connect to Wifi takes 3-5s and MQTT 1-2s.

But now I've got the issue that probably data from MCU not ready at the moment (need to investigate).

I had this issue when I activate the debugging option (in WDoorSensor.cpp). To make sure to have the message on time, I needed to set it to false.

[klausahrenberg]

i also had issues with version 1.20 and MQTT. It would keep posting "Query state of MCU..."

Issue is solved in v1.22. Debug mode was still enabled in v1.20. Please be aware that a complete reconfiguration of settings (incl. network settings) is necessary. Network classes (my WAdapter project) changed a lot. For WDoorSensor this has no functional impact, but requires reconfiguration.

[kotXio]

Nice! Would be nice if you could share your changes to reach 3-4s.

Unfortunately I fried two of my sensors... I still don't understand why, so I cannot test at the moment my firmware changes. I will get more sensors and hope that I don't kill them too :)

I will back at my workplace in a couple of days, then will share my changes to speed up the wifi connection.

[christian-nils]

i also had issues with version 1.20 and MQTT. It would keep posting "Query state of MCU..."

Issue is solved in v1.22. Debug mode was still enabled in v1.20. Please be aware that a complete reconfiguration of settings (incl. network settings) is necessary. Network classes (my WAdapter project) changed a lot. For WDoorSensor this has no functional impact, but requires reconfiguration.

Thank you very for the update, highly appreciated! I'll check it later!

[christian-nils]

Nice! Would be nice if you could share your changes to reach 3-4s. Unfortunately I fried two of my sensors... I still don't understand why, so I cannot test at the moment my firmware changes. I will get more sensors and hope that I don't kill them too :)

I will back at my workplace in a couple of days, then will share my changes to speed up the wifi connection.

Thanks! Maybe @klausahrenberg has fixed that with 1.22. I'll check if I find time and report back! :)

[kotXio]

@christian-nils All right, I have a couple of minutes, the changes are small, I can write them down here ;) WAdapter/WNetwork.h

Remove WiFi.disconnect(); because it will reset internal stored WiFi settings, which we need for fast connect after wake up line 51

//WiFi.disconnect();
WiFi.setAutoConnect(true);
WiFi.setAutoReconnect(true);
WiFi.persistent(true);

line 168 should be something like this..., so we check if ESP already stored WIFI settings, we don't need to do WIFI.begin() at all ESP already has it. And we run wifi_station_set_auto_connect(true); after we connected to WIFI to store used settings. (Not sure about ESP32, have no tested, but for ESP8266 works well)

if (WiFi.SSID().length() == 0) {
   #ifdef ESP8266
   //Workaround: if disconnect is not called, WIFI connection fails after first startup
   WiFi.disconnect();
   WiFi.hostname(this->hostname);
   #elif ESP32
   WiFi.mode(WIFI_STA);
   WiFi.setHostname(this->hostname);
   #endif
   WiFi.begin(getSsid(), getPassword());
   wifi_station_set_auto_connect(true);
}

[christian-nils]

Super, thank you very much for sharing your changes. I will try that as soon as I get new sensors :)

[kotXio]

I finally found that for my case it is some problem with the MQTT push logic in the firmware. (I am getting MQTT status in 25s, or even never, but /device help topic coming very quick).

So, I attached a sniffer for TX from ESP and another for TX from MCU. The state of the sensor (open/close) coming shortly from MCU, but for some reason sending it via MQTT take a long time.

Just for test purposes, I have hardcoded to send open/close status with the /device help topic and then disconnect. So far, it works fast, I am getting status in 2-3s now )

Need to debug with time, it seems something not triggered properly to publish MQTT status when the device status is ready.

[christian-nils]

Oh, that is strange. I hope you'll find the issue. On my side, I am waiting some ESP12F to replace the TYWE3S that I fried...

[muammersayar]

Hi everyone. I was bought TYWE3S from Tuya and STC8F1K08 mcu from a chinese company. I will try to programming arduino pro mini as work as tuya door sensor mcu if I don't find a bin file for STC8F1K08. And I'm not a professional for programming. Which files should I use for mcu programming and otherwise arduino pro mini? @klausahrenberg @christian-nils @moesfeld @kotXio @MarkM500 @

[muammersayar]

And additionally how can I change led bylink time when the door state changed? I want to increase led bylink about 10 seconds if it's fit for sleep rules.