Support for door and motion sensors with secondary MCU

[ciscozine]

Hi, recently I have bought a door sensor (tuya) https://www.aliexpress.com/item/NEO-Home-Door-Window-Detector-WiFi-App-Notification-Alerts-Battery-Operated-Home-Security-Sensor/32967720305.html

I tried to flash firmware using tuya-convert (I use kali 2018.2) without good result. Below the log

==> smarthack-wifi.log <==
wlan0: STA bc:aa:a2:95:6d:ff IEEE 802.11: authenticated
wlan0: STA bc:aa:a2:95:6d:ff IEEE 802.11: associated (aid 2)
wlan0: AP-STA-CONNECTED bc:aa:a2:95:6d:ff
wlan0: STA bc:aa:a2:95:6d:ff RADIUS: starting accounting session 4151C1BB1D2BB9E7
wlan0: STA bc:aa:a2:95:6d:ff WPA: pairwise key handshake completed (RSN)

==> smarthack-web.log <==

URI:/gw.json?a=s.gw.token.get&gwId=87532803c2956dff&other={"token":"00000000","region":"EU","tlinkStat":{"configure":"smartconfig","time":6,"source":"ap","path":"broadcast"}}&t=12&v=3.0&sign=f83c136be9c465f95989693af7652
Answer s.gw.token.get
[I 190312 15:33:10 web:2162] 200 POST /gw.json?a=s.gw.token.get&gwId=8753280dc2956dff&other={"token":"00000000","region":"EU","tlinkStat":{"configure":"smartconfig","time":6,"source":"ap","path":"broadcast"}}&t=12&v=3.0&sign=f83c136bf465f95989693af7652 (10.42.42.21) 5.79ms

URI:/gw.json?a=s.gw.dev.pk.active&et=1&gwId=8753280dc2956dff&other={"token":"00000000"}&t=7&v=3.0&sign=9438b3d84c9ae20cf480c9577212
Answer s.gw.dev.pk.active
READ GW ID 87532803bcddc1156dff
TRIGGER UPGRADE IN 10 SECONDS
Trigger upgrade in 10 seconds
[I 190312 15:33:11 web:2162] 200 POST /gw.json?a=s.gw.dev.pk.active&et=1&gwId=87532803bc2956dff&other={"token":"00000000"}&t=7&v=3.0&sign=9438b3d8ae6a2820cf480c9577212 (10.42.42.21) 24.04ms

==> smarthack-mqtt.log <==
1552419191: New connection from 10.42.42.21 on port 1883.
1552419191: New client connected from 10.42.42.21 as 87532803bcddc1156dff (c1, k30, u'87532803bcddc1156dff').
1552419191: Will message specified (107 bytes) (r0, q1).
1552419191:     tuya/smart/will
1552419191: Sending CONNACK to 87532803bcddc1156dff (0, 0)
1552419191: Received SUBSCRIBE from 87532803bcddc1156dff
1552419191:     smart/device/in/87532803bcddc1156dff (QoS 0)
1552419191: 87532803bcddc1156dff 0 smart/device/in/87532803bcddc1156dff
1552419191: Sending SUBACK to 87532803bcddc1156dff

==> smarthack-web.log <==
d59ec0f8937237d94e5d3d4788f04
b'2.1937834e5d3t5inCMDHpcJKQpxfOe2RbeJQPxFBvAcLbx4Es/FVgQ9YdTD2tlt9gq09JF2v6zJsm5uMafEvnzLLz/1MQ4v2+CvyUSGTLmhyo5mQxHdg4SXZL9kLEC9aqKXAOwI'

==> smarthack-mqtt.log <==
1552419201: New connection from 127.0.0.1 on port 1883.
1552419201: New client connected from 127.0.0.1 as P1 (c1, k60).
1552419201: No will message specified.
1552419201: Sending CONNACK to P1 (0, 0)
1552419201: Received PUBLISH from P1 (d0, q0, r0, m0, 'smart/device/in/87532803bcddc1156dff', ... (147 bytes))
1552419201: Sending PUBLISH to 87532803bcddc1156dff (d0, q0, r0, m0, 'smart/device/in/87532803bcddc1156dff', ... (147 bytes))
1552419201: Socket error on client P1, disconnecting.
1552419237: Client 87532803bcddc1156dff has exceeded timeout, disconnecting.
1552419237: Socket error on client 87532803bcddc1156dff, disconnecting.

==> smarthack-wifi.log <==
wlan0: AP-STA-DISCONNECTED bc:aa:a2:95:6d:ff
wlan0: STA bc:aa:a2:95:6d:ff IEEE 802.11: authenticated
wlan0: STA bc:aa:a2:95:6d:ff IEEE 802.11: associated (aid 2)
wlan0: AP-STA-CONNECTED bc:aa:a2:95:6d:ff
wlan0: STA bc:aa:a2:95:6d:ff RADIUS: starting accounting session 4151C1BB1D2BB9E7
wlan0: STA bc:aa:a2:95:6d:ff WPA: pairwise key handshake completed (RSN)
wlan0: AP-STA-DISCONNECTED bc:aa:a2:95:6d:ff
wlan0: STA bc:aa:a2:95:6d:ff IEEE 802.11: disassociated
wlan0: STA bc:aa:a2:95:6d:ff IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

What I wrong? Thanks a lot Fabio

[brandond]

The problem is that these devices power down as soon as they connect to MQTT and receive the puback; it's part of their power saving functionality. Whatever firmware upgrade commands you're going to send need to happen before that or you've missed the window. Not sure how to accomplish that exactly though.

[ciscozine]

Yes it would be interesting find a solution to avoid the power down.

[brandond]

What is the normal workflow for pushing a firmware update? It seems like that needs to happen BEFORE the MQTT step, otherwise the device will go to sleep.

[ciscozine]

So do you think there is no solution to use mqtt? thanks

[brandond]

I'm sure it's possible, you'd just have to catch the Tuya cloud doing it to know how.

[Scoobler]

Just as a possible note to help others here, I’ve flashed 5 door sensors, the trick to keep them awake for flashing by changing the door contact state every few seconds (must be changed at least, less than every 6 seconds) by waving the magnet back and forth past the device. Doing that will keep telling the onboard MCU it needs power on to send out its message.

Note: the stock Tasmota doesn’t do much just now as these devices have a second brain like a lot of new Tuya items - there is some work and currently beta testing a Tasmota release which does work with these low power devices.

[barrymossel]

Just as a possible note to help others here, I’ve flashed 5 door sensors, the trick to keep them awake for flashing is changing the door contact state every few seconds (must be changed at least less than every 6 seconds) by waving the magnet back and forth past the device. Doing that will keep telling the onboard MCU it needs power on to send out its message.

Note: the stock Tasmota doesn’t do much just now as these devices have a second brain like a lot of new Tuya items - there is some work and currently beta testing a Tasmota release which does work with these low power devices.

Did you flash them through tuya-convert? Or through an FTDI? As this does not seem to work for me through tuya-convert. I am just sitting there looking silly ;-)

[ptrooms]

This thingy will/can likely not be flashed through TuyaConvert code. I had to use the hardware flash method, which is standard and imho far more easy to do.

No need to desolder anything. Remove batteries, open the device, connect rs232-3.3.v-gnd-tx-rx to the piggyback print, keep io0-GND (low during flash). In addition, I also had to apply-HIGH to the EN-chippin.Thereafter reset into flashmodus is by connecting RST for about 2 seconds to GND of and you go. Possibly one need to re-reset (RST2GND) if the flashtool continuous to searching for connect

When ready, Test/configure can be done by disconnect io0 and powering buy the rs232 cable.

[barrymossel]

This thingy will/can likely not be flashed through TuyaConvert code. I had to use the hardware flash method, which is standard and imho far more easy to do.

No need to desolder anything. Remove batteries, open the device, connect rs232-3.3.v-gnd-tx-rx to the piggyback print, keep io0-GND (low during flash). In addition, I also had to apply-HIGH to the EN-chippin.Thereafter reset into flashmodus is by connecting RST for about 2 seconds to GND of and you go. Possibly one need to re-reset (RST2GND) if the flashtool continuous to searching for connect

When ready, Test/configure can be done by disconnect io0 and powering buy the rs232 cable.

You say connect? You mean solder, right? My soldering skills aren't suitable for soldering those little pads unfortunately...

[ptrooms]

This thingy will/can likely not be flashed through TuyaConvert code. I had to use the hardware flash method, which is standard and imho far more easy to do. No need to desolder anything. Remove batteries, open the device, connect rs232-3.3.v-gnd-tx-rx to the piggyback print, keep io0-GND (low during flash). In addition, I also had to apply-HIGH to the EN-chippin.Thereafter reset into flashmodus is by connecting RST for about 2 seconds to GND of and you go. Possibly one need to re-reset (RST2GND) if the flashtool continuous to searching for connect When ready, Test/configure can be done by disconnect io0 and powering buy the rs232 cable.

You say connect? You mean solder, right? My soldering skills aren't suitable for soldering those little pads unfortunately...

Not sure what your solder competence is but the pads, approx 1mm square, are fairly easy to solder with an average tip or get some assistance. Just for reference, I've attached a picture of the piggyback-print that is used in both doorsensor and PIR. See attache picture.

[ptrooms]

Just found out: One can also keep the sensor active for at least 45-60 seconds active by "telling" the MCU , that de ESP8266/Wifi is actively searching for an AccesPoint. This is accomplished by sending Serialsend5 "55 AA 00 02 00 01 00 02"

This command is best to be done via MQTT (or perhaps as websequence) and try/do this (if needed multiple) at the right time, just after the esp8266 is active/initialized and BEFORE the MCU will take down the Esp8266/WiFi. Once the command is received and processed by Tasmota, it is formwarded to the MCU that will keep the esp8266/WiFi active for 30-60seconds (once per power-up session).

Myself, using the new firmware, will do serialsend5" of the above - a couple of times after each-other to be sure - as soon as I see the that the PIR/DOOR sensor has contacted the MQTT server. mosquitto_pub -t cmnd/tasmota/serialsend5 -m '55 AA 00 02 00 01 00 02'

However, I think/feel that this best is to be controlled by/within the TuyaMCU driver code itself. One could do this by keeping the MCU at least this period alive in absence of any (mqtt) retained (POWER OFF) message. By this one could control if the door-sensor/pir power remains active by simply issueing regular "power on/off" message sequences.

The MCU does also recognize a long-press which leads to the Tasmota-Wifisetup whose sequence will (currently) be prematurely shutdown because the MCU,, without heartbeats or ap/wifi mode command - will shutdown the esp8266 about 5-10seconds is was after power-up. By using the "mqtt serialsend5" trick this can be circumvented.

Note: as said before one the sensor is fed with "give me the report" (serialsend 55 AA 00 02 00 01 04 6), the sensorMCU will produce its FnId/DpId report and shutdown chip-power after 3-4 seconds. During this time, it is assumed that the esp8266 has sent its messages.

Hope this helps and for followup/questions, let me know.

Regards, Peter

[bartowl]

Hi. I don't know it it helps, but once the device subscribes to the topic, MQTT broker makes sure that it receive all messages sent to it (according proper QoS value, like 1). Then, when the device wakes up, pings the broket it will deliver everything that went on the topic when the device was not there. So - once the device receives PUBACK and goes to sleep it is enough to send the OTA request to proper topic. Once the device wakes up, it will receive it, as it will be resent by the broker until the subscribed device confirms its receipt. (at least for qos=1). So much theory, but it might help I hope.

[karlitos]

I spend hours trying to flash tasmota to the LSC Motion Sensor - the one from the image above. Without any Luck. I tried even with 3,3V on the EN pin and GND on pin 15, also with applying GND to the reset pin ... no luck at all.

At some point the LED on the device was flashing very fast (faster than in the pairing mode) when inserting the battery, I was worried that my soldering and wiring efforts made some damage. Then, I was somehow able to use the tuya-convert and flash tasmota to the device. I wasn't able to reproduce it any time after - with any combination of pressing or holding the device button.

So in the end I have tasmota on the device, but it stays online only for around 10-15s, so I was not even able to set up the the Wifi. I will try to disable the MCU by soldering a wire to MCUs reset pin as described in the Wiki an connecting it to the ground.

Maybe it would be possible to use the tasmota compiler to create a tasmota version which would be sending some serial commands to keep the ESP online when we shorten some GPIO pins.

[ptrooms]

Keep in mind that the power (and led) of the sensor is controlled (master) via de MCU that communicates with the esp via the TX/RX pins. Due this, there is NO way how Tasmota/firmware can override this. Hardware modifications, are possibly but in this case you will have to take/bypass the MCU out of service-functions. In this case it is far more easier to buy a esp8266 sensor only module.

The only wayi keep the esp8266 active via "software" is instructing the MCU to keep power active via heartbeats and/or faking device timeperiods (aka, let think MCU the esp is busy looking for wifi and/or router/dhcp acquire)

The red-led, controlled by the mcu and not the esp, flashes fast when MCU assumes (as told by) the esp is busy searching for Wifi/AP and slow when the MCU (is told), the esp is momentary busy acquiring router/dhcp.

If required to keep the sensor active AFTER and once it is power-triggered using Tasmota; one have a couple of options to do this via the Tasmota rule engine after/when Wifi is connected. Myself, I control the powerstate via (in my case OpenHab) as soon as I receive the "Online"-state of the sensor.

As said, one can also try to issue the keep-active states via native Rule triggering.
For example, rules that triggers on state: "Mqtt#Connected" state and/or "Rules#Timer=1" expiration that will send an appropriate "serialsend5 xxxxxxxx" command towards the MCU.

These initial rules, can be set en send via mqtt as soon the device is connected to wifi/mqtt. Some of the MCU commands via send by Tasmota are:

• heartbeat: serialsend5 55 aa 00 00 00 00 ff
• keep the sensor 45-60 seconds power connected: serialsend5 55 aa 00 02 00 01 02 04
• report state to mqtt & immediately poweroff with: serialsend5 55 AA 00 02 00 01 04 06

As with everyhing, use your imagination for solving things in a different way. In case you do not have mqtt lying around, one could even send the commands via http/web/curl etc.etc. connection, optionally as one long-string using backlog. For all this, see https://github.com/arendst/Tasmota/wiki/Rules

The only challenge is Tuya timing. As soon the Tuya device comes online, meaning wifi connected, you have about 10 seconds to fire-off/issue/set the Rule commands. Over here, using my OpenHab controller, I simply listen when the Tuya-sensor comes online via mqtt etc.etc.

Regarding your "idea", a kind of init.d, , is actually asking the Tasmota-developers to allow device specific precompiled initialisation rules. On its own, this is fine but do realise that this is virtually impossible (not the least in firmware sizing), seen the tons of devices Tasmota supports.

If you do need to keep the sensor active but "ignore" lowpower mode, simply activate it as Tuyamodule only and DO NOT activate lowpower mode (which will switch-off < 10seconds). The native Tuya device (dimmer) module, will afak issue heartbeats every 10 seconds.

Hope this helps for an idea mindset.

[brandond]

I'll add to the above that even with sending heartbeats and claiming to still be connecting to wifi, the MCU will put the ESP to sleep after about 110 seconds. There's no way at all to stay powered up indefinitely.

[karlitos]

Just a hint that mit help others not only to flash Tasmota to their devices but also with the configuration afterward. Since the MCU usually powers-off the ESP by cuting-off its power, as long as you provide 3,3V from any external source to the VCC pin, the ESP will stay alive the whole time.

Regarding the LSC motion sensor - there are some solder pads on the bottom of the board.

I soldered a small wire to the 3,3v pad and then connected it to the VCC pin of the ESP by securing it with a piece of tape. The ESP stays alive and I was able to configure it for as long as needed. Afterward I left the wire hidden in the case of the sensor with the one end still soldered to the board for future use

[kueblc]

For those familiar with these devices, would it be worthwhile to add the keepalive message to our intermediate firmware? Unfortunately I do not have any devices like this so it will be difficult for me to test, but if someone would like to work with me on this I can certainly implement a periodic serial message in the upgrade firmware.

[ptrooms]

@kueblc: I wonder if this really adds something. For something else, I've also thought this over a couple of thimes.

The question is: Why keeping/doing an heartbeat if the purpose of low-power is to read the reason for sensor-activation and preserving power by keeping the power-on-time as short as possible ?

The fact that some have difficulties in configuring during the very narrow time-frame in LowPower mode is merely a matter of approach. It is fairly easy to configure things in the right order and steps. When one need to configure Tasmota, setting, one must first instruct the MCU not to poweroff..... which is accomplished by heartbeats and/or telling the MCU, the ESP it is busy doing Wifi/AP/Router search mode etc.

To update any Tasmota setting of a Tuya battery device: (re)Configure the sensor first as ordinary Tuya device, by deactivating low-power mode (TuyaMcu 51,0 = delete) and let Tuya reboot. Then (re)trigger the sensor which will then go into default heartbeat mode during one can reconfigure whatever. Let the device reboot, retrigger and set it into Low_power mode (like TuyaMcu 51,21). After it is restarted, one is back on track. During heartbeat mode, one could also swithc the MCU into Wifi/AP timeperiod which allow about a 40-50seconds. Instructions are best given via MQTT as Web/Api-access during Low-Power mode is difficult to timely accomplish. As one know, giving the commands directly via connected TX/RX wires is not possible as the MCU sitting on these.

From a development point of view, I wonder how you/one will implement or control such a "heartbeat" control on user-request setting as Tasmota function...... This, as LowPowermode which simply let the device close-out power asap with a "04 06" (signoff) message. Imho it is much simpler to deactive low-power mode first by mqtt, which result in the same. Te biggest problem is of course, the differnet steps have to be done in 2 or more sessions...... because the sensor battery sensor will surely reboot during change or due to timeout.

A way of doing might be (re)using the generic "POWER ON/OFF" state als state for LowPower mode control yes/no. Also because "Power On,Off" mode has no real function withing Tasmota for battery sensors. However, for this.... one must change the sequence how Tasmota initializes its core...... which first process the "POWER ON" state from MQTT following it up by including sensor-modules in its function loop like TuyaMcu. Tasmota is doing a continuous round-loop of its functions. It will starts with its core functions, including Mqtt communication BEFORE it will re/act on any device-sensor specific state. Convincing developer to change this behavior in favor of Tuya will be difficult. Specially as there's a simple bypass: just deactivate Tuya-low-power as action first and restart in native Tuya mode.

Hope this helps in very interesting discussion.

[Scoobler]

@kueblc if I’m completely honest, I don’t think it would help all that much, if at all.

There are a few reasons, most, although not all the MCU’s have a maximum amount of time they keep power on, heart beat or not, it’s normally the same amount of time the MCU keeps power on when you enter pairing mode (circa 90 seconds) - for this reason it’s probably easier to manually put the device into pairing mode.

The other reason it may not be needed, when the ESP flashes a bit of firmware, it reboots and spits a load of info out on the serial line, the MCU interprets (or more like misinterprets) that as a failure to pair so prematurely ends the ‘keep awake while pairing’ mode - that would mean if someone has managed to flash Tuya-convert by using the standard pairing method, once the interim firmware is on, the esp reboots and the info goes out, the device powers down. The user would have to wake it again so may as well do it by entering pairing mode, they can then flash Tasmota.

The reason setting up the device becomes difficult once Tasmota is on there, every time you save some settings Tasmota has a tendency to reboot to activate the changes, out goes that info from the ESP so MCU powers down.

As mentioned once Tasmota is flashed and in low power mode, coming out of low power TuyaMCU mode just keeps power on longer because Tasmota stops trying to do what it is meant to do in the way the MCU was designed to be communicated with. Last time I spoke with the developer working on TuyaMCU for Tasmota (it was a while ago) he was intending to capture the ‘pairing mode’ message from the MCU to put Tasmota into its WiFi config mode which on reflection could hinder setting up the device after Tasmota is finally on there.

If you do still want to tinker adding serial messages and heart beats let me know and I’ll email you over the TuyaMCU lower power protocol, it lists the different messages passed back and forth between the MCU and the ESP.

[brandond]

You can also find protocol docs here: https://github.com/brandond/esphome-tuya_pir/blob/master/README.md#serial-protocol-overview

[me-processware]

i figured out that when you bypass q1 it also stays on maybe usefull to use with a small powersupply instead of batterys

[GijsTimmers]

So I'm having this issue, too. Can somebody explain to me the steps I have to undertake to properly flash this movement detector? There is a lot of information in this thread and I have little experience.

[rockstar2020]

i figured out that when you bypass q1 it also stays on maybe usefull to use with a small powersupply instead of batterys

Hello, I'm using my motion sensor with an external power supply and it's working fine but my challenge is to keep it awake all the time to avoid delays in sending mqtt messages upon motion sensing. Can you explain what exactly you did with q1? What do you mean by bypassing q1?

Much appreciated it Cheers

[rockstar2020]

So I'm having this issue, too. Can somebody explain to me the steps I have to undertake to properly flash this movement detector? There is a lot of information in this thread and I have little experience.

Hi, You just need to follow the basic instructions given on Tasmota's github page to flash your ESP8266 board. All you have to do is to locate the 3.3v, TX, RX and GND pins on your board and have basic soldering skills.

https://github.com/arendst/Tasmota/wiki/Flashing

Also this link was very helpful for me to flash my motion sensor: https://community.home-assistant.io/t/tuya-pir-sensor-tasmota-questions/164237

You will have very little luck to use Tuya-convert method to flash a battery powered Tuya device.

Hope that helps Cheers

[me-processware]

i figured out that when you bypass q1 it also stays on maybe usefull to use with a small powersupply instead of batterys

Hello, I'm using my motion sensor with an external power supply and it's working fine but my challenge is to keep it awake all the time to avoid delays in sending mqtt messages upon motion sensing. Can you explain what exactly you did with q1? What do you mean by bypassing q1?

Much appreciated it Cheers

just short q1 like i did in the picture (the second brain of this unit powers the tuya on when needed but it is impossible to configure the device in 18 seconds) so i quit the tuya devices because they are not as usefull as i thougth to be i switched to zigbee (zigbee2mqtt with Texas Instruments CC26X2R1) and xiaomi aqara devices they run years on 3v battery and are very quick and small

[rockstar2020]

Thanks a lot! I have several ESP8266 based tuya devices and I'm very happy with it using with my homeassistant setup. But I'll try the zigbee device you recommend though. Thanks again Cheers

[Scoobler]

Not tried leaving the ESP powered, but do the messages work as expected with the ESP always on? The 2nd brain has a ‘chat’ with the ESP (Tasmota), it wakes the ESP then asks if its connected, when the ESP responds to say it is, it sends the message to say motion for example, also battery level too. The trouble could be Tasmota used some of the boot up, connect to WiFi and finally connect to MQTT as the triggers for starting parts of the conversation with the 2nd brain. For example in the early stages, when the ESP connected to the MQTT it would then ask the 2nd brain for the sensor state and battery voltage. If the ESP is always on, does the messages still come through as expected of always powered?!

By all means for setting up the device config, but not sure how it would react if always powered on.

Get Outlook for iOShttps://aka.ms/o0ukef

---

From: mehdiheidari notifications@github.com Sent: Wednesday, February 26, 2020 10:50:02 PM To: ct-Open-Source/tuya-convert tuya-convert@noreply.github.com Cc: Scoobler jamienwood@hotmail.com; Comment comment@noreply.github.com Subject: Re: [ct-Open-Source/tuya-convert] Support for door and motion sensors with secondary MCU (#135)

Thanks a lot! I have several ESP8266 based tuya devices and I'm very happy with it using with my homeassistant setup. But I'll try the zigbee device you recommend though. Thanks again Cheers

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fct-Open-Source%2Ftuya-convert%2Fissues%2F135%3Femail_source%3Dnotifications%26email_token%3DAAF4SPQFWSRGGPYS6HFVJSLRE3WZVA5CNFSM4G5PBJR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENCGKDI%23issuecomment-591684877&data=02%7C01%7C%7Cc80cf0594a3140d0dae608d7bb0e37a3%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637183542036821816&sdata=dI%2BaR2iHJUjhDO5D23T88FSLf2w4wSq%2B1MVqkjDpEBg%3D&reserved=0, or unsubscribehttps://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAF4SPSKDV74HLZ2QVEIVZDRE3WZVANCNFSM4G5PBJRQ&data=02%7C01%7C%7Cc80cf0594a3140d0dae608d7bb0e37a3%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637183542036821816&sdata=iWmzX8akrc0qdZJ%2BFXbCE48DkjuY5UiTVnWqCJjO8J0%3D&reserved=0.

[rockstar2020]

Looks like the my motion sensor's board is different so couldn't find and bypass q1 as you did. But I did find a 3.3v and directly connected it to ESP's VCC pin which did the trick to keep the ESP always on but nothing gets communicated from MCU unit when motion is detected. In other words it didn't serve the purpose. Cheers

[GijsTimmers]

I managed to do it, too. Just solder the 3.3V wire and GND wire to the chip, that makes the chip powered 24/7. Then just flash it with tuya-convert following the instructions.

Very easy actually

The GND wire should be soldered on the right (it got detached before making the photo)

[Grui]

hello, do you know where to solder a 3,3v power supply regarding my door sensor chip ? Thanks

EDIT: (ok I know, the chipset listed in the above message is the same one ;) )

[zarath]

I've added a reed contact between the 3.3V from the regulator to the esp of the LSC movement sensor. So I can use the magnet of the mounting plate to bridge constant power to the esp for configuring and flashing. With the battery enclosure attached, the sheet metal ensures that the contact wouldn't be engaged when mounted to the wall. Watching WiFi's routers log for the MAC of the sensor joining ensures fastest response to detected movements.

Reed contact is fixed to case with a drop of hot glue.

[zarath]

In fact I don't see this topic as an actual issue. I think it should be moved to a wiki topic, where solutions for integration of this kind of low power devices can be documented.

[64n35h4]

For those familiar with these devices, would it be worthwhile to add the keepalive message to our intermediate firmware? Unfortunately I do not have any devices like this so it will be difficult for me to test, but if someone would like to work with me on this I can certainly implement a periodic serial message in the upgrade firmware.

I have a few of these, I could help if still needed

[lennartonis]

I managed to do it, too. Just solder the 3.3V wire and GND wire to the chip, that makes the chip powered 24/7. Then just flash it with tuya-convert following the instructions.

Very easy actually

The GND wire should be soldered on the right (it got detached before making the photo)

Gijs, What configuration did you put into the motion sensor. I was able to flash it using ESP home. It is only connecting when i put 3.3V and GND to the refferred pins. When motion is detected WiFi is enabled for about 5 seconds and then turned off again. I am trying to configure it using MQTT. Can you point me in the right direction or share your configuration?

[GijsTimmers]

Lennar,

After connecting the referred pins, I flashed Tasmota to this device. But I would advice you not to flash Tasmota to this device. What it does now basically, the first chip detects movement. The second chip (the Tasmota chip, ESP8266) powers up and connects to Wifi. This will take about 5 seconds. The device is not reachable over the network until those 5 seconds have passed. After a short while, the first chip sends the power off command to the Tasmota chip, so it gets shut down. No matter what you do on the second chip.

So I would advice against flashing Tasmota on this device. Perhaps ESPhome or ESPeasy is a better solution indeed. Because AFAIK, with those solutions, you can write the code on your computer and then flash that to the device. For instance: "on Sensor1 ON send MQTT" And it doesn't need to load the full Tasmota firmware.

Hope this helps. FWIW, I threw this device away and use a GPS app on my phone for presence detection right now.

[bartowl]

Well - Tasmota does support Rules as well. I do not see any benefit from using ESPEasy over Tasmota. And as tasmota uses MQTT messages sent to device while it is in sleep won't get lost. You cannot tell that for ESPEasy when contacting over HTTP. I would stick with Tasmota. See TuyaMCU Module especially designed for this type of devices. I don't know it ESPEasy has something similar...

[GijsTimmers]

@bartowl Yes that's right. Didn't think about that. You might try to get Tasmota to send a MQTT message right after booting using a rule. However, bear in mind that such a solution will still take a few seconds before your light gets switched on (or whatever you want to use it for). For me that's way too long.

[bartowl]

The boot-up time of tasmota indeed takes a couple of seconds before it connects and is al up and running. If ESPEasy is faster here for you then sure. For me it works, as those 2 seconds I can live with. In addition tasmota can instruct the main CPU to keep power for up to around 1 minute on, by telling it it is waiting for wifi or mqtt connection. For me this was always enough and I had bad stability experience with ESPEasy and the reliability of communication convinced me for Tasmota. It works very well for me and I can fully trust that ESPeasy works folly for you. Good there is choice and great people who wrote both those firmwares!

[tbrasser]

Maybe this can help: https://github.com/brandond/esphome-tuya_pir

[bit-user]

I soldered a cable to 3.3V and GND, then I put the sensor into flashing mode (fast blinking LEDs). But as soon as I start the flashing (./start_flash.sh), the LEDs stop blinking and nothing happens. The flashing software shows the following:

Starting smart config pairing procedure Waiting for the device to install the intermediate firmware Put device in EZ config mode (blinking fast) Sending SSID vtrust-flash Sending wifiPassword
Sending token 00000000 Sending secret 0101 ................ SmartConfig complete. Auto retry in 2s. ................................................................................................................ Device did not appear with the intermediate firmware Check the *.log files in the scripts folder Do you want to try flashing another device? [y/N] N

And nothing happens.

Does anybody know what's going on here?

[bit-user]

Nobody any idea? :(

[ptrooms]

Nobody any idea? :(

Perhaps the device is already "flashed" with something and therefore no longer responding in/for Tuya flashing method. Also I've heard rumors that the manufacturer may block the Tuya-flash method on newer devices or the initial firmware may have been replace once it has connected the Chinse-Cloud that provisions the functionaty. The latter may apply when one bought a returned/resealed shopitem.

Myself always flash the device always directly (using an USB3.3V/RS232 cable connecting Tx/RX/IO0@gnd with power directly to the TYWExx piggymodule) as it keeps me away from all kinds of intermittent errors.

[bit-user]

Interesting, thanks a lot @ptrooms , you may be right! Would you suggest ordering a USB-TTL converter and following the instructions described here: https://github.com/brandond/esphome-tuya_pir#initial-flashing ?

[ptrooms]

@bit-user In any case, an USB-TTL (use .set one to 3.3Volt) is always handy, it does also allows to monitor the TX/rs232 messages.

The're numerous ways in flashing the esp8266 chip. As I always compile things myself, I prefer use the Arduino work environment loaded with the esp8266 libraries and by that nicely offers the integrated upload firmware facility. Others may use esphome and I think the most universal one is the straightforward Python/esptool command. https://github.com/espressif/esptool That tool also offers al kinds of checks and even erasing/reset firmware etc.cetc.

The most important part is to force the esp8266 into flashmode which is best done by directly connecting the GPIO0 to GND and then power (by connecting the usb cable into the PC). During flashing, the gpio0 may remain to gnd. See elsewhere for better instructions.

In my case, I flash everything using Tasmota. Once an esp8266 device has the Tasmota-code digested, I continue to update/flash OverTheAir using Wifi. This will of course not work with so-called low-power'ed device like the PIR/DOOR sensor which only power the esp8266 chip for a short/limited amount of time. That's also the reason why I like the cable method.

[bit-user]

That's a super comprehensive walkthrough, thanks @ptrooms ! I just ordered a USB to TTL converter. You are right, for 10 bucks, it's totally worth it :)

And I will look into the ESPtool as well!

[henkiejan1]

I have also buyed a movement sensor from Action try to flash it. And off course did not work and i think i understand after reading this topic.

1. The power control is managed by the MCU chip of the movement sensor.
2. It did not send a singal or something but just powered on the ESP8266
3. The ESP8266 connect quick to the wifi
4. The movement MCU chip cut off the power to the ESP8266

A solution described here:

1. You could hardwire the power to the ESP8266 on the VCC and GND pin so the ESP8266 is up for as long as needed.
2. You could flash eventually the ESP8266 with Tuyaconvert
3. But when you disconnect the VCC and GND it works again on the movement MCU. For tasmota it´s to short to connect to wifi and send something to MQTT.
4. You could bypass to power the ESP8266 conscientiously but don´t get info about movement because normally is movement singal just by power on the ESP8266?

So maybe when you hold the ESP8266 contineu powered on. You should rewire the movement MCU power on what goes now to the ESP8266 VCC pin to a GPIO pin? And then make a rule that when the GPIO pin is high it generates a movement singal to MQTT?

I do not understand a lot about things like these but try to understand what happen and what could maybe do.

[seemebreakthis]

I have the exact same PIR sensor as the one @bit-user has, judging from the picture of the board.

It took me days before I finally succeeded in flashing tasmota and making it functional (and no I ended up not using tuya-convert at all). So I'd like to post a brief walkthru on how I did it, for those (like me) who have no prior experience on using tasmota / flashing a battery-powered PIR device / both.

Background Info (skip to below if you are only interested in setting up this thing):

Given my complete lack of experience on anything tasmota related, I can only suspect this is not a typical flashing and configuration of a tasmota device. It seems the core functionality is totally controlled by the MCU and there is no sensor, button, LEDs connected directly to the ESP8266ex within the device. This is probably why any usual step(s) to detect GPIOs and setting up templates are simply inapplicable here.

This link provides a good read on how the ESP communicates with the MCU. Take a look if interested, although there is no need to use any of the commands there. And we are flashing Tasmota, not ESPHome.

Prerequisites (some are optional but strongly recommended)

• CH340G (or any type of) USB - TTL Serial Cable. The one I have has leads that will make it really easy to connect to a breadboard.
• Breadboard - makes it way easier to connect GPIO0 to ground (more on that below), and for connecting the wires in general
• A bunch of 'breadboard grab probes / hooks' - something like the type I have, that makes the job of connecting the CH340G cable leads to this particular device really easy. Otherwise you are essentially looking at some very precise soldering... next to impossible for amateurs like myself.
• Tasmotizer
• This Tasmota firmware. I would just download the plain ol tasmota.bin. This one has proven to work. I also tried some other ones like tasmota-battery.bin in the daily build site that you'd have thought would be more appropriate, or some of the other scaled down ones that I have seen some others recommend for battery powered devices, but most of them just don't work, for me anyway.
• Putty. Useful for validating correct wiring

Flashing the device

1. Open the device (two screws to unscrew). You will find the board is attached and soldered to the half sphere case. No need to take it out by soldering.
2. Take a look at this diagram to take note of 5 connection points - GND, TxD0, RxD0, GPIO0, and 3.3V. If your board looks very different then you should probably not continue. My connections look like this picture

3. Connect your CH340G leads to these connection points - GND and 3.3V are self-explanatory (don't use the 5V!!), TxD goes to RxD of the CH340G, and vice versa. GPIO0 also connects with GND (this puts the device in 'flash' mode). You should not plug the CH340G into your computer just yet.
4. Disconnect just the 3.3V from the PIR board, then plug in the CH340G. Then run Putty, with serial connection session selected and baud rate = 74880. Then start session which should give you a blank terminal screen as you have not plugged in the 3.3V.
5. Now plug in the 3.3V. If your putty terminal shows something like 'ets Jan 8 2013,rst cause:1, boot mode:(1,6)' and nothing else then congrats, you have successfully done the wiring and ready for flashing tasmota.
6. Quit putty, and start tasmotizer. While the board is still powered and with GPIO0 still connected to GND, pick the tasmota.bin file as the firmware. If you want, check 'Backup Original Firmware' just in case you ever want to fallback. Now 'tasmotize' !
7. The whole process doesn't take long (a little longer if you backup your original TUYA firmware). Maybe 2 minutes max. You will see the progress bar making its way to the finish line right away. Once done it will say ''Flashing successful! Power cycle the device."
8. Now disconnect the GPIO0 from GND (the GPIO0 connection is no longer needed). Unplug 3.3V, then replug 3.3V to restart the device in non-flash mode.
9. Your tasmotizer is still needed for one more step - at this moment press 'Send Config', and you will see a screen with 2 sections that should be enabled if not already: Wifi and Module/Template. Check both. In Wifi, enter the SSID & password for the device to connect to your network, and for Module/Template, press the Module radio button, then pick "Tuya MCU" from dropdown list.
10. Hit "Save". Tasmotizer will now populate your device with these parameters. It takes literally one second before it says something like "Succeeded. The device will now restart" or something like that. You are done. Keep the wires connected, you will now be able to use your browser to access the (newly flashed !) main tasmota menu of the device. If you are quick enough to find its IP address, that is. Your router DHCP should have the info you need. Your device will probably self power off after maybe 2 minutes (takes longer to self-shutdown as it has not been configured yet), in which case unplug the CH340G cable from the computer then plug it in again to give yourself another 2 minutes. Don't do the '3.3V reset' anymore like you did above. For some reason once tasmota is flashed you need to totally disconnect both GND and 3.3V for the device to do a full power cycle.

Configuring the device

1. At this point your TxD and RxD connections are no longer needed as all the config will be done through the browser. But if you want to see the terminal output (which is mostly the same as the browser console output anyway), keep them connected, use Putty, and set baud rate to 115200.
2. Like I said above, I have found most of the components (well it boils down to the LED and the IR sensor) to be attached to the MCU not the ESP8266ex. This is my understanding of the situation from what I have observed anyway as it explains why the numerous experimental commands I sent to this thing is met with essentially no change in behaviour. So config in this sense is to tell the MCU that the ESP has been setup correctly to connect with the wifi network, and the device is ready to be put into 'normal operation' mode. That's it. No other config is / should be / can be done. If you are thinking to control the LED to light up whenever you want, sorry you are out of luck.
3. The following assumes like me, you have no prior knowledge of Tasmota. So this includes a quick walkthru of the essential sections, and please just skip to a subsequent point if you get bored
4. At this stage the device is still not put into 'normal' mode. It will still auto-power-down, but it takes longer (2 minutes?) before it stops responding. And there is a way to make it a little longer than that, which should be more than enough to complete the configuration or to just take a look around.
5. The way to validate 'awake' state is to go to console menu item, then in the console screen, enter the command 'state' and see if it responds. If no response or you cannot even enter the console screen, it is time to unplug / re-plug the CH340G, assuming you are still using it as the power supply to the device. Then you will get another 2 minutes to try talk to the device.
6. So now we are ready to do our configuration. Before going any further, this is the page from which I got the config info. Turns out this PIR sensor responds to the same commands. Also refer to this page for a detailed description of each command listed below if interested.
7. Before doing anything else you will probably want to buy some more time before self-power-down kicks in. Go to Console and issue this command: SerialSend5 55AA000200010002. Anecdotal observation suggests this command can be used once per 'active session', that is, before you have to power cycle. This gives you maybe one more minute each time to do the rest of your setup.
8. Oh, also, each command you enter (except for the SerialSend5 55AA000200010002 above) gets written into permanent flash storage as soon as it is issued. So the commands will survive a power cycle.
9. You will want to configure the MQTT server. MQTT setup is beyond the scope of this discussion, so I will tell you all I did here was entering the host IP of my MQTT broker in Config -> MQTT Config. This is already sufficient for my own needs (I am not using hass.io).
10. Now go back to the Console, and issue the following commands:

• SetOption1 1
• SetOption65 1
• SetOptoin66 1
• SwitchMode 1

These commands basically will get the device ready to send out MQTT messages, and to accept info from MCU and pass them along as MQTT messages, etc etc.

11. Also issue the following commands:

• Rule1 ON TuyaReceived#Data=55AA00050005030400010213 DO publish2 stat/%topic%/BATT high ENDON ON TuyaReceived#Data=55AA00050005030400010112 DO publish2 stat/%topic%/BATT medium ENDON ON TuyaReceived#Data=55AA00050005030400010011 DO publish2 stat/%topic%/BATT low ENDON
• Rule1 1

These two commands allow MQTT on low battery to be sent. I haven't tested this yet, as I don't have any batteries on the cusp of depleting to work with.

12. Finally we are reaching the point of no return. Once this command is issued, your device will begin normal operations. i.e. your web tasmota environment will basically stop working as the device will turn itself off in a split second once motion is detected and MQTT is sent. But you can only test for normal MQTT operations ONCE this command is issued:

• TuyaMCU 51,21

So if you want to navigate around a little further before you are done exploring, don't issue this just yet.

Final Notes

So... that's pretty much it ! And yes even in console before you put the device in 'normal' mode, you can get info on the MQTT topics that the publisher (i.e. the device) will use. It will be something like tele/tasmota_XXXXXX/RESULT for motion detection events, and some other topic (such as stat/tasmota_XXXXXX/YYYY) for other stuff that I am not really interested in. When I run mosquitto_sub to extract from my own MQTT broker, I get info from tele/tasmota_XXXXXX/RESULT with no problem.

Good luck !

Follow Up after 10 days of usage

I have learned a bit more on the MQTT contents sent from this sensor.

First off, forget about the rule1 above regarding battery. This particular PIR sensor model isn't compatible with this rule. No need to set it at all. Instead, in your MQTT subscription, look for the content "6604000103" in the stat/tasmota_XXXXXX/RESULT topic for battery low warnings.

For that matter, the MQTT will have "6501000101" within its message (also topic stat/tasmota_XXXXXX/RESULT) when it detects motion.

So, set up your listener, look for these MQTT contents, and you are all set to react to events triggered by your sensor.

One more note - I have seen twice so far where the PIR sensor will stay online forever and burn battery power. Both times when I restart my MQTT broker, but the issue is not reproducible every time, meaning most of the time the sensor will act normally once again once the MQTT broker comes back online. So even if this problem is intermittent, if nothing is done and we let it stay online, the battery will be completely drained pretty fast.

So I have this RULE setup which will hopefully mitigate the potential issue (can't test it fully yet, because again the problem cannot be 100% reproduced):

• RULE1 on system#boot do RuleTimer1 300 endon on rules#timer=1 do tuyamcu 51,21 endon
• RULE1 1

No harm done anyway even if this isn't the final solution. Will see what happens.

Follow Up after 60 days of usage

First off, getting rechargeable batteries for these suckers definitely help. I wouldn't say they are particularly power hungry, but for the sensors located where people tend to move around a lot, the repeated triggering do add up to drain the battery more quickly. And from where I am, these CR-123A batteries are not overly easy to come by and the ones that are for sale tend to be on the shelves for sometime already (as there's not a lot of demand). I think that adds to the premature draining / shortening of lifespan of these batteries. This plus the apparent issue where sometimes when your network isn't up and running when the device is looking for the MQTT server, I have found the sensors to periodically get confused and remain powered on until battery is depleted. Which brings me to the next point:

Made a change on RULE1 and I believe now the sensor will now reset itself periodically when it gets stuck because the network is unreachable etc etc:

• RULE1 on system#boot do RuleTimer1 90 endon on rules#timer=1 do backlog tuyamcu 51,0 ; delay 20 ; tuyamcu 51,21 ; delay 20 ; restart 1 endon
• RULE1 1

Follow Up after 150 days of usage

Probably the final update - kept experimenting until the sensor doesn't all of a sudden drain all of its battery anymore. This latest rule has been giving me 2+ weeks of non-stop usage and still going strong (and I place these devices in living room etc with lots of activities when someone is home). This verses about 1 week max before making this rule change.

(Good thing I have re-charagable batteries so even without this rule I was able to save money by simply replacing / recharging)

• RULE1 on TuyaReceived#Data=55AA00EE0001F1DF do backlog tuyamcu 11,0 ; delay 20 ; restart 1 endon
• RULE1 1

Don't know why this works actually. As I tried to find out what dpid 11, 51, and others do but I could never figure out. Only came to this through trial and error. But it has been working at least for my model and I am not going to change anything that works.

Follow Up after 200 days of usage

Definitely the final update. The new rule works perfectly. And I have since found out the rechargeable batteries I use for these sensors last only about 10 - 12 days before recharging is needed, in environments with lots of motion throughout the day.

Also, turns out the charge depletes very quickly for these batteries once voltage starts dropping ever so slightly (mine are 700mAh batteries). So in my MQTT subscription, I had to change from "6604000103" to "6604000101" in the stat/tasmota_XXXXXX/RESULT topic for battery low warnings.

Once the warning starts firing I have maybe a few hours only before the sensor dies completely.

[ptrooms]

Good and detailed write up. Specially the "rule-up" as this makes the PIR-sensor more autonomous.

The battery-rule is more-or-less, useless as the battery test by the MCU is only executed at initial start, just after one will insert batteries en execute the long-reset to start things.

As you, I use an external power-supply (a 5V USB on the battery pins can just nicely do the job), as the batteries in normal (even in lowpower-mode) usage with only a couple of activations per day, will else empty in just a couple of weeks to months.

In deviation, I do not use Tasmotizer etc.etc but directly write using the esp8266 development tooling with its own the "binary file" (usually some python programmed) uploader that can also be used stand-alone. The whole trick with this PIR/DOOR sensor is to understand - as you do - the "Tuya" interference.

Aside from everything, the PIR (and DOOR) sensor are nice gadgets but in respect tot use, a bit too complicated as (near to) real-time response is very difficult to achieve. There's a 5 to 10 seconds delay before a trigger "signal" will reach a HomeAutomation system. Usually too long for light-operations etc.etc.

The PIR sensor itself has also a builtin "quirk", requiring a 1 minute absence of movement before it will ready again. This (MCU controlled battery-saver) behavior make it virtually a bit useless to sequenced movements other then something was (being) moved.

[seemebreakthis]

The battery-rule is more-or-less, useless as the battery test by the MCU is only executed at initial start, just after one will insert batteries en execute the long-reset to start things.

... wow this is kind of silly then ! haha yes then the battery detection is pretty useless. You also mentioned the battery will last only several months. I guess I will find out for sure soon. Hope it will last longer than just a few months, otherwise I will need to change batteries all the time.

As you, I use an external power-supply (a 5V USB on the battery pins can just nicely do the job), as the batteries in normal (even in lowpower-mode) usage with only a couple of activations per day, will else empty in just a couple of weeks to months.

... not really, I was using external power just to set things up. Now the device is back at its cage with a battery inserted to keep it going.

Aside from everything, the PIR (and DOOR) sensor are nice gadgets but in respect tot use, a bit too complicated as (near to) real-time response is very difficult to achieve. There's a 5 to 10 seconds delay before a trigger "signal" will reach a HomeAutomation system. Usually too long for light-operations etc.etc.

I am using it to trigger alarms for my home security system rather than home automation. So a few seconds won't hurt in my case as my cam is on 24 x 7 recording anyway. I just need to have (among other things) a motion detection log.

The PIR sensor itself has also a builtin "quirk", requiring a 1 minute absence of movement before it will ready again. This (MCU controlled battery-saver) behavior make it virtually a bit useless to sequenced movements other then something was (being) moved.

Yeah I noticed that too. But no big deal for me...

[seemebreakthis]

3. But when you disconnect the VCC and GND it works again on the movement MCU. For tasmota it´s to short to connect to wifi and send something to MQTT.

Not true. (I am referring to the 'Too short to connect and send out MQTT / receive MQTT' part)