tuya-convert
tuya-convert copied to clipboard
ct-Open-Source
Support for door and motion sensors with secondary MCU
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
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.
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.
I'm sure it's possible, you'd just have to catch the Tuya cloud doing it to know how.
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.
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 ;-)
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.
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...
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.
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
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.
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.
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.
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.
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
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.
@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.
@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.
You can also find protocol docs here: https://github.com/brandond/esphome-tuya_pir/blob/master/README.md#serial-protocol-overview
i figured out that when you bypass q1 it also stays on maybe usefull to use with a small powersupply instead of batterys
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.
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
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
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
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
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 [email protected] Sent: Wednesday, February 26, 2020 10:50:02 PM To: ct-Open-Source/tuya-convert [email protected] Cc: Scoobler [email protected]; Comment [email protected] 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.
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
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)
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 ;) )
