Tasmota: Support for the LSC Door Sensor bases on RULES

[TimelessNL]

ISSUE DESCRIPTION - TROUBLESHOOTING

I've been testing Tasmota on a LSC Door Sensor, the device houses a ESP and TuyaMCU. But the protocol is incompatible with TuyaMCU for now. Therefor I implemented some rules to get the status of the 'reed switch' inside this unit.

rule1 ON Wifi#Connected DO backlog serialsend5 55 AA 00 01 00 00 00; delay 10; serialsend5 55 AA 00 02 00 01 04 06; delay 3; serialsend5 55 AA 00 05 00 01 00 05; ENDON

This does work and the MCU replies with the following:
Closed: 55aa000200000155aa0005000501010001000c
Open: 55aa000200000155aa0005000501010001010d

Therefor I used a 2nd rule to parse the response and trigger a (virtual) relay on a unused pin so the state is visible in the webui together with the fact that MQTT message is send to my domotica controller.

rule2 ON SerialReceived#Data=55aa000200000155aa0005000501010001010d DO POWER OFF ENDON ON SerialReceived#Data=55aa000200000155aa0005000501010001000c DO POWER ON ENDON

It seems to be an issue with the length of the string because if I use a rule with a shorter string aa0005000501010001010d if works just fine. but when I use 55aa0005000501010001010d the rules does not fire.

Could it be that there is a length limitation with the SerialReceived#Data?

REQUESTED INFORMATION

_Make sure these boxes are checked before submitting your issue. Thank you_

FAILURE TO COMPLETE THE REQUESTED INFORMATION WILL RESULT IN YOUR ISSUE BEING CLOSED

• [✔️] Read the Contributing Guide and Policy and the Code of Conduct
• [✔️] Searched the problem in issues (https://github.com/arendst/Sonoff-Tasmota/issues)
• [✔️] Searched the problem in the wiki (https://github.com/arendst/Sonoff-Tasmota/wiki/Troubleshooting)
• [⛔️ ] Searched the problem in the forum (https://groups.google.com/d/forum/sonoffusers)
• [✔️] Searched the problem in the chat (https://discord.gg/Ks2Kzd4)
• [✔️] Device used (e.g., Sonoff Basic): Sonoff Basic
• [✔️] Tasmota binary firmware version number used: 6.6.0.15
  
  
  
  • [⛔️ ] Pre-compiled
  
  
  • [✔️] Self-compiled
  
  
  • [✔️] IDE / Compiler used: 2.5.2
  
  
• [✔️] Flashing tools used: esptool (arduino studio)
• [✔️ ] Provide the output of this command: Backlog Template; Module; GPIO:

14:59:34 CMD: Backlog Template; Module; GPIO
14:59:34 MQT: stat/sonoff/RESULT = {"NAME":"LSC Door Senso","GPIO":[0,0,0,0,0,0,0,0,0,0,0,0,0],"FLAG":15,"BASE":18}
14:59:34 MQT: stat/sonoff/RESULT = {"Module":"1 (Sonoff Basic)"}
14:59:35 MQT: stat/sonoff/RESULT = {"GPIO1":"148 (Serial Tx)","GPIO2":"0 (Geen)","GPIO3":"149 (Serial Rx)","GPIO4":"0 (Geen)","GPIO14":"0 (Geen)"}

• [ ✔️] If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:
  See ISSUE DESCRIPTION

[arendst]

Glad you're looking into it.

Let me see what goes wrong with rule...

[arendst]

Quick fix. Change line 207 in xdrv_10_rules.ino from

  char rule_svalue[CMDSZ] = { 0 };

in to

  char rule_svalue[80] = { 0 };

and report back.

[TimelessNL]

I first though that it may have something to do with it being SerialSend5 and therefor HEX and the compare fails because of that. But even when I run SerialSend prior which should send a string the resulting SerialReceived should be as well. So I connected a FTDI to the RX/TX pins and started testing lengths until it stopped working. And once I used 55aa0005000501010001010d it stopped working

EDIT:
Ok, will do!

[TimelessNL]

@arendst Great! That quick fix did indeed work. I feel quite dumb now, I should have been able to spot that myself 😆. _But ok... self shaming aside_:
This config worked for for the Door Sensor:

rule1 ON Wifi#Connected DO backlog serialsend5 55 AA 00 01 00 00 00; delay 10; serialsend5 55 AA 00 02 00 01 04 06; delay 3; serialsend5 55 AA 00 05 00 01 00 05; ENDON

rule2 ON SerialReceived#Data=55aa000200000155aa0005000501010001010d DO POWER ON ENDON ON SerialReceived#Data=55aa000200000155aa0005000501010001000c DO POWER OFF ENDON

And the device publish it's MQTT message just fine. I first though that it did not work since the weblog does sometimes stop midway and does not show the MCU's response. But I guess that is just a refresh issue since the MQTT (which we need) message is published just fine 😄

[arendst]

Great! I will fix it now.

[TimelessNL]

Thanks, since this basically works for the sensor I have another question:
I'm going to test this RULE implementation the coming week. But what do you think: would it be feasible to integrate this support in TuyaMCU or not? The use case/implementation is completely different other than the fact that they both use a Tuya MCU'ish co-processor.

[arendst]

Well there are many different devices supported now by the tuya driver. Perhaps incorporating this sensor makes sense too.

@shantur could make it happen.

[ascillato2]

Closing this issue as it has been fixed. Thanks.

---

Support Information (Guide)

See Wiki for more information.
See FAQ for common questions/answers and links if none of your question is in the list.
See Chat for more user experience.
See Community for forum.
See Code of Conduct

[shantur]

@TimelessNL : This should be easy to implement in TuyaMCU.
Can you document the data sent to and fro from MCU with original firmware?

[TimelessNL]

I just found this documentation on a German forum: protocol.xlsx from this post.
Seems identical to my research and is quite detailed. Is this what you need?

Edit:
There's also a sequence to get original 'smart config' mode running. This is initiated by pressing a button connected to the MCU and if the ESP then replies with an appropriate response it says powered for quite a while. Maybe we can use that in our advantage and update/configure Tasmota in that period instead. That would be nice because otherwise we have to open the sensor each time we want to configure or update the thing. I'm quite busy next week but maybe I can find a time slot to get the exact message sequence.

[sevelen]

I can´t get a switch betwen On/Off. I take the latest repository and verifies the xdrv_10_rules.ino change. There after I set the GPIO´s, TX RX and two rules (and activate them) as in the description.

{"NAME":"LSC Door Senso","GPIO":[0,0,0,0,0,0,0,0,0,0,0,0,0],"FLAG":15,"BASE":18} {"Module":{"1":"Sonoff Basic"}} {"GPIO1":{"148":"Serial Tx"},"GPIO2":{"0":"None"},"GPIO3":{"149":"Serial Rx"},"GPIO4":{"0":"None"},"GPIO14":{"0":"None"}}

But the output is anytime the same. Any suggestions?

00:00:00 CFG: Loaded from flash at F6, Count 14 00:00:00 Project sonoff_Door_Sensor1 Sonoff1 Version 6.6.0.18(basic)-2_5_2 00:00:00 WIF: Connecting to AP1 xxx in mode 11N as sonoff_Door_Sensor1-5361... 00:00:04 WIF: Connected 00:00:04 HTP: Web server active on sonoff_Door_Sensor1-5361 with IP address 192.168.7.98 00:00:04 RUL: WIFI#CONNECTED performs "backlog serialsend5 55 AA 00 01 00 00 00; delay 10; serialsend5 55 AA 00 02 00 01 04 06; delay 3; serialsend5 55 AA 00 05 00 01 00 05;" 00:00:05 RSL: stat/sonoff_Door_Sensor1/RESULT = {"SerialSend":"Done"} 00:00:05 RSL: stat/sonoff_Door_Sensor1/RESULT = {"Delay":10} 00:00:06 MQT: Attempting connection... 00:00:06 MQT: Connected 00:00:06 MQT: tele/sonoff_Door_Sensor1/LWT = Online (retained) 00:00:06 MQT: cmnd/sonoff_Door_Sensor1/POWER = 00:00:06 MQT: tele/sonoff_Door_Sensor1/INFO1 = {"Module":"Sonoff Basic","Version":"6.6.0.18(basic)","FallbackTopic":"cmnd/DVES_AE74F1_fb/","GroupTopic":"sonoffs"} 00:00:06 MQT: tele/sonoff_Door_Sensor1/INFO2 = {"WebServerMode":"Admin","Hostname":"sonoff_Door_Sensor1-5361","IPAddress":"192.168.7.98"} 00:00:06 MQT: tele/sonoff_Door_Sensor1/INFO3 = {"RestartReason":"Power on"} 00:00:06 MQT: stat/sonoff_Door_Sensor1/RESULT = {"POWER":"OFF"} 00:00:06 MQT: stat/sonoff_Door_Sensor1/POWER = OFF 00:00:06 MQT: stat/sonoff_Door_Sensor1/RESULT = {"SerialSend":"Done"} 00:00:06 MQT: stat/sonoff_Door_Sensor1/RESULT = {"Delay":3}

[meingraham]

@sevelen

You have flashed sonoff-basic. Try upgrading to sonoff.bin

Backlog OTAURL http://thehackbox.org/tasmota/pre-2.6/sonoff.bin; Upgrade 1

[sevelen]

Not sure what i did wrong, after your advice i just get Connection refused but reachable by ping.

If I flash the file manually I can set the wifi but after the same connection refused.

[TimelessNL]

Did you set the correct baudrate? It should be set to 9600. And take note that the ESP is only poweredld for a limited amount of time.

[sevelen]

@TimelessNL Do you mean for flashing? Yes I did but same result. Or do i need to set something else by the my_user_config.h to get it working. Maybe someone has a full template or bin for me?

[TimelessNL]

No I mean during runtime. In the console type baudrate 9600 this is required by the MCU.

[sevelen]

Yes I try but without luck. The result is anytime the same as discribe above. I check the power value by the console and as well by iobroker where i get the MQTT data. It did not change.

{"NAME":"LSC Door Senso","GPIO":[0,0,0,0,0,0,0,0,0,0,0,0,0],"FLAG":15,"BASE":18} {"Module":{"1":"Sonoff Basic"}} {"GPIO1":{"148":"Serial Tx"},"GPIO2":{"0":"None"},"GPIO3":{"149":"Serial Rx"},"GPIO4":{"0":"None"},"GPIO14":{"0":"None"}}

{"Baudrate":9600}

{"Rule1":"ON","Once":"OFF","StopOnError":"OFF","Free":350,"Rules":"ON Wifi#Connected DO backlog serialsend5 55 AA 00 01 00 00 00; delay 10; serialsend5 55 AA 00 02 00 01 04 06; delay 3; serialsend5 55 AA 00 05 00 01 00 05; ENDON"}

{"Rule2":"ON","Once":"OFF","StopOnError":"OFF","Free":351,"Rules":"ON SerialReceived#Data=55aa000200000155aa0005000501010001010d DO POWER ON ENDON ON SerialReceived#Data=55aa000200000155aa0005000501010001000c DO POWER OFF ENDON"}

[shantur]

If any of you have Serial RX TX still connected , can you

1. Erase flash with esptool
2. install https://cdn.discordapp.com/attachments/490244847568158751/633324641884176394/firmware.bin
3. Select TuyaMCU module, wait for it to reboot
4. Enable weblog 4 from console
5. Do command TuyaMCU 51,20

See if power works.
If not, please collect logs

and Jump on Discord to discuss

[TimelessNL]

Ah @shantur you already implement this? Great! One additional thing I discovered. The MCU only responds when it has been triggered by the reed switch or push button. Otherwise it is in deep sleep to save battery power I guess.

[arendst]

And then there is this: https://www.letscontrolit.com/forum/viewtopic.php?t=6955#p38999. Apparently the power to the esp is controlled by the second microcontroller which makes deepsleep on the esp not needed.

I would like to have it verified though.

[Scoobler]

@arendst I can confirm that is exactly what happens.

There is some 'control' over how long the MCU keeps power on the ESP, this is done thorough serial messages.

From monitoring the stock firmware - when the sensor changes the MCU wakes the ESP. There is then a conversation along the lines:

ESP: Who are you
MCU: Product ID / Version
ESP: AP is configured _(No need for pairing mode - this message makes the MCU maintain power for around 5 seconds - you can pass further messages to extend this)._
MCU: OK
ESP: WiFi configured, but not connected
MCU: OK
ESP: WiFi Connected
MCU: Sensor state & Battery Level
ESP: Sent
MCU kills power to the ESP

One problem I was having _(using the rules in the first post above)_ was occasionally if the time taken to wake the ESP and boot tasmota, then connect to WiFi took more than the 5 seconds - the MCU would assume failure and power down.
I ended up having a Power1#Boot trigger to start the coms, i.e. AP configured, then another trigger when WiFi connected to mimic the rest of the conversation the two items have. I was going to see if stripping every extra item out of a firmware would speed up the boot up process a little, now @shantur is on with the proper solution, I will work with him.

[arendst]

Thx for the feedback.

[TimelessNL]

Yes that's correct. The MCU powers the ESP for +/-10sec after an event or shorter if 55 AA 00 02 00 01 04 06 is send after which it sends the reed switch status and powers down the ESP within 300mSec.

Edit:
Oh Scoobler already responded :)

[TimelessNL]

Did anyone already find the 'smartconfig' mode sequence using the button?

[sevelen]

Is it working by the new firmware.bin file for you? In my case same than yesterday the power did not change on/off

[TimelessNL]

I've not tested the provided .bin neither have I been home since last weekend. So I couldn't verify it yet.

[Scoobler]

I did try an earlier version, but the device left the network and entered pairing mode (MCU didn’t power down the ESP - monitoring the serial, the ESP was transmitting the ‘I’m pairing’ message to the MCU, Tasmota also wouldn’t accept the network config (or it did but was then being put back into pairing mode) so wouldn’t leave smartconfig mode).

I was waiting for some connectors to interrogate it more to find out what was going on and will get back to @shantur with findings, that was all on an earlier firmware, I think the linked bin came after that!

Also I did not erase flash before putting it on as I was doing everything OTA so could equally have been a ghost and not the new firmware!

[TimelessNL]

My idea was that we could ditch the 'smartconfig' mode and replace it with a longer lasting power mode, then we would be able to push OTA updates to these kind of devices because the normal time window is much to small.

@shantur could you link your repo where you did those changes that led to the provided .bin? I'm curious what you changed. Thanks!

[Scoobler]

This behaviour should be partially possible.

It is possible for the ESP to keep the MCU in a pairing mode, but I think it needs a periodic message from the ESP - hence the should be possible.

The problem that could come is I think the MCU has a timeout if it doesn’t get a periodic message - if the time it takes the ESP to download the minimal firmware, update, then download the full version and update is longer than the timeout - there is a chance the MCU times out and powers down mid update - hence it would need more investigation.

I know when the Tasmota firmware is in its standard form, not communicating with the MCU at all, holding on the reset button to enter pairing mode on the original device puts the MCU in pairing mode (originally that would keep the MCU/ESP awake for around 2 minutes, it would also send a serial message to the original firmware to tell it to enter pairing mode).
What I did notice was, if you then changed a setting in Tasmota which caused a reboot, the MCU would leave pairing mode early. This could be due to Tasmota outputting info on the serial as it boots and the MCU not understanding the messages gives up.
This could be another issue in the OTA update process, if we are relying on the MCU to keep things awake while the update process takes place and the ESP reboots after flashing minimal and then the MCU powers down.

There is a message the ESP can send, I don’t have it to hand at the moment but will post tomorrow for clarity, but it can keep the MCU in pairing mode for long periods - the firmware I loaded, which won’t accept WiFi details is sending the message to the MCU every second and the device stays awake. 10+ minutes till I had to give up and go out.

Lots to think about!

[TimelessNL]

Mmh... It seems that the MCU sends 55aa000200000155aa0003000002 when the button is held for 5sec and then stays in 'slow blinking' mode for at least a couple of minutes.

It seems that it does not only provide the reed switch status but also to tactile button status using the same set of commands.

See:

00:00:04 RUL: WIFI#CONNECTED performs "backlog serialsend5 55 AA 00 01 00 00 00; delay 10; serialsend5 55 AA 00 02 00 01 04 06; delay 3; serialsend5 55 AA 00 05 00 01 00 05;"
21:28:46 RSL: stat/sonoff/RESULT = {"SerialSend":"Done"}
21:28:46 RSL: tele/sonoff/RESULT = {"SerialReceived":"55aa000100247...."}
21:28:46 RSL: stat/sonoff/RESULT = {"Delay":10}
21:28:47 MQT: Verbinden...
21:28:47 MQT: Verbonden
21:28:47 MQT: tele/sonoff/LWT = Online (retained)
21:28:47 MQT: cmnd/sonoff/POWER = 
21:28:47 MQT: tele/sonoff/INFO3 = {"RestartReason":"Power on"}
21:28:47 MQT: stat/sonoff/RESULT = {"POWER":"OFF"}
21:28:47 MQT: stat/sonoff/POWER = OFF
21:28:47 MQT: stat/sonoff/RESULT = {"SerialSend":"Done"}
21:28:47 MQT: stat/sonoff/RESULT = {"Delay":3}
21:28:47 MQT: tele/sonoff/RESULT = {"SerialReceived":"55aa000200000155aa0003000002"}
21:28:48 MQT: stat/sonoff/RESULT = {"SerialSend":"Done"}

@Scoobler I think the normal 2min delay is more than enough to flash any OTA image. Most of the times it is within 16sec or so. I do compile my own images for these sensors so I not use the minimal in between. But the instructions could be to put the MCU in pairing mode each time a OTA update is attempted if the MCU powers down the ESP while Tasmota is starting. Once configured Tasmota does send "hey I'm connected" during boot, so that could cause the MCU to power things down. Not sure though.

[Scoobler]

That’s one of the messages I was referring to, that message could be used by the Tasmota firmware to get it to enter smart config mode for example.
Basically that is what the stock firmware does when it receives that message.

Alternatively it could simply tell Tasmota to reboot, but that would stop the pairing mode once Tasmota reboots as it outputs to serial as it’s waking up.

[shantur]

Here you go guys : https://github.com/shantur/Sonoff-Tasmota/tree/door-sensor

There is a way to keep ESP powered up while doing OTA. Currently my main aim is to fix the door sensor read, then i will implement the OTA and other functionality.
Whenever you guys have serial connection to it please jump on discord to discuss.

[TimelessNL]

Yeah true. We have to think about that I guess. Because it makes much more sense to make the button a 'power longer' rather than a 'reset' button. Since this is a periodic powered device other than normal devices that are powered constantly and don't need such a button.

[Scoobler]

Thanks @shantur.

The one behaviour I saw, was once Tasmota reboots, the MCU effectively leaves pairing mode quickly. While that shouldn’t be a problem as it happens after the firmware has loaded, if it’s OTA Magic doing a 2 part upgrade, it would mean after the first reboot, the MCU would leave the pairing mode so would no longer hold on power - it is this point where if the MCU waited 5 seconds for example before powering down, if the device had started part 2 of the upgrade power may get cut part way through!?

Currently soldering pogo pins as I type, unfortunately ready for tomorrow - it’s been a long day already!

[TimelessNL]

@Scoobler, I have one of my door sensor that still have their surgery wires attached. I'm currently on discord, so if you're also close to a computer we can then maybe discuss stuff together.

[TimelessNL]

Ok after testing @shantur 's branch I found these things.

When ESP is powered first and then the MCU everything seems to work as expected. the reed switch is found and changes it's status. But when the MCU powers the ESP itself after inserting batteries or applying 3.3v to the battery contacts I see continuous serial communication (FTDI LEDs constantly lit) and the webinterface is unreachable. So there is something wrong in the initial boot TuyaMCU communication I suppose.

[mainframecn]

I have one of these working, perhaps not the way most of you want to do this. I've attached the sensor to GPIO4 with a bridge and use to TUYA MCU module to keep it alive long enough to do some config. I guess this will reduce the battery life a bit.

The template i use: {"NAME":"LSC Door Senso","GPIO":[0,108,0,107,9,0,0,0,0,0,0,0,0],"FLAG":0,"BASE":54}

[oOPsychokillerOo]

@mainframecn
I have tested your solution but if the esp goes off and the state is on and you open the sensor the state will be on and not off if you close the sensor the state goes to off.

[timdgr]

How much time does this solution take to get a message in your system (like Domoticz) when you trigger the door contact? I tried with default SmartNodeRules firmware but it takes 5 seconds. Makes it useles for turning on a light.
I plan to do this way but then need another ESP as serial gateway. So more devices needed:
https://github.com/SmartNodeRules/Documentation/wiki/SampleESPNOW
Still looking for an easy way to get it working fast. Like to hear your experience

[haubke]

Is it working? If so dev branch or release?

[jpduhen]

The above discussion is interesting, but a bit to complex for a non-programmer like me. Someone got the LSC door-sensor working with Tasmota? Or is it already integrated in development 7.0.0.x?

[ptrooms]

Note my 2cts: The Tuya secondary MCU primarily listens to the ESP status received and interpreted as as Tuya-command message:

1. HeartBeat: 55 aa 00 00 00 00 ff (heartbeat, keep the esp8266 active, another 10-15seconds)
2. QueryInfo: 55 aa 00 01 00 00 00 (returns a 36 byte JSON product/id/key string {"p":"xxxxxxxxxxxxxxxx","v":"1.0.4"} )
3. QueryMode: 55 aa 00 02 00 00 01 (returns Esp8266 Co-operative ack 55AA0002000001)
4. setAP : 55 AA 00 02 00 01 00 02 (Led will blink fast 250ms, indicate Wifi-setup)
5. setSta : 55 AA 00 02 00 01 01 02 (Led will blink slow 1500ms, indicate Wifi-searched)
6. WifiCon: 55 AA 00 02 00 01 02 04 (Led goes off, indicate Wifi connected to MCU )
7. DhcpRec: 55 AA 00 02 00 01 03 05 ( Led remains off, indicate to MCU router is connected)
8. MqttSnd: 55 AA 00 02 00 01 04 06 (Cloud connected, report and poweroff esp8266)
   _Note: after command setAP of setSta, the MCU will keep esp8266 power-on for 30-45 seconds._

The last command, will cause that the MCU will report its Functional Dataproduct Id information such as
programmed sensor status; and/or battery status (if low). Thereafter it will power off the esp8266. Upon a next trigger it the MCU will switch is back on,

The PIR Alarm movement sensor then will do report, before it power off the esp8266 device.
-- 55AA0005000501040001000F (dpid 01, pir is activated )
-- _Note The PIR needs about 1 minute of no movement before it will re-arm itself for a Wifi session._

The DoorSensor - reedcontact- will do/report before it will power of the esp8266, either:
-- 55AA 0005000501010001000C ReedContact Open did01 fn01 Bool
-- 55AA 0005000501010001010D Reedcontact Closed dpid01 fn01 Bool
-- _Note TheDoorsensor is triggered on each Closed/Open contact._

In addtion I've seen:
-- 55AA 00050005030400010011 Battery status 00 dpid03 Enumerated to Good
-- 55AA 00050005030400010213 Battery status 02 dpid03 Enumerated to Low
... Note: I've planned to do some battery status tests. I presume 01 will be the "Fair" status.

The TuyaMCU module code, primaru focused on Dimmer, works great, specially the HeartBeat is very helpful. I think it must/can be finetuned to submodels of indicated Tuya MCU code. probelm here is that the MCU is specifc to a product and can be changed of reused in new products. Therefor, I wouild suggest a table approach Model 01 support reports a.b.c model 02 will only support an on/off. etc.etc.

Hope this helps in further analysis. For questions or followup, let me know.

Kind Regards / Peter

Grtz. Peter.

[shantur]

@ptrooms : have you tried backlog TuyaMcu 51,21 on latest build?
Couple of guys are using Tasmota on this sensor. Initially it was Tuya Dimmer and now it is generic to handle dimmer, relays, switches and battery powered sensors

[ptrooms]

@shantur; not yet apparently - TuyaMcu 51,21 - is just new/released. Got the code etc. Problem/challenge is OTA update will not work (properly) on Battery powered Tuya devices using 6.7.12/7.0.01. Later this week, I will rewire for execution. Thanks.
Will keep you posted.

update some hours later:
I think the new modification will also not properly work. The Tuya/Tasmota source is on its way but still based upon Dimmer and the like.
The only thing, i see is a start to implement more support for low-power devices which in this stage is not good enough for the DOOR en PIR sensor.

When these Battery-powered DOOR of PIR sensor are to be queried, the "xdrv_16_tuyamcu.ino" code not correctly NOR properly handle the TuyaMCU Report-responses.
For example the PIR-moved report of hex-sequence "55AA0005000501040001000F" is currently seen as TUYA_CMD_WIFI_RESET which is followed up by TuyaResetWifi for which Tasmota assumes an ordinary Wifi(re)setup.
However this, response ""55AA0005000501040001000F"" is not a WEifiReset BUT a Boolean status report for DpID 01 indicating the PIR sensor detected movement as reason for the Wifi Communication.

In summary for the Battery/Tuya devices we need a more specific approach as it will not follow the regular light/household appliances.

(I) rest assure this will be sorted out in the future when ẃe get more experiences for these devices. In the mean time, I've updated my own Tasmota-fork of the TuyaTasmota code which need more fineuning.

[ptrooms]

FwIw

Just flashed, wired, a new PIR sensor with Tasmota 7.1.

It is working "better", kudo's, compared to Tasmota version 6.7.1 It is now working as "Tuya"wit a resuilt that it switches off (to save battery) as soon, it comes online. This can be detected via MQTT messages.

After giving, "TuyaMcu 51,21" (as soon the device went active for not more then about 2-4 seconds), it nicely boots upon a longpress for searching an connecting the SSID and after a minute of (no movement) it can be triggerend again for a couple of seconds.

During (re)start, I got the following log:

    00:00:00 CFG: Loaded from flash at F8, Count 28
    00:00:00 QPC: Flag 0E
    00:00:00 SRC: Restart
    00:00:00 Project tasmota Tasmota Version 7.1.0(tasmota)-2_6_1
    00:00:00 SNS: Hardware Serial
    00:00:00 TYA: Request MCU configuration
    00:00:00 TYA: Send "55aa0001000000"
    00:00:00 CFG: Saved to flash at F7, Count 29, Bytes 4096
    00:00:00 TYA: Set WiFi LED 2 (-1)
    00:00:00 TYA: Send "55aa000200010204"
    00:00:00 {"TuyaReceived":{"Data":"55AA00010024xxx.xxx53","Cmnd":1,"CmndData":"xxx.xxx"}}
    00:00:00 TYA: MCU Product ID: {"p":"xxxxxxxxxxxxxxxx","v":"1.1.5"}
    00:00:00 TYA: Set WiFi LED 2 (-1)
    00:00:00 TYA: Send "55aa000200010204"
    00:00:00 {"TuyaReceived":{"Data":"55AA0002000001","Cmnd":2}}
    00:00:00 {"TuyaReceived":{"Data":"55AA0003000002","Cmnd":3}}
    00:00:00 WIF: Checking connection...
    00:00:00 WIF: Attempting connection...
    00:00:00 WIF: Connecting to AP1 PtrO SSIDx in mode 11N as xxxxxx-xxxxx...
    00:00:00 {"TuyaReceived":{"Data":"55AA0002000001","Cmnd":2}}
    00:00:01 WIF: Checking connection...
    00:00:01 WIF: Attempting connection...
    00:00:02 WIF: Checking connection...
    00:00:02 WIF: Attempting connection...
    00:00:04 WIF: Checking connection...
    00:00:04 WIF: Attempting connection...
    00:00:05 WIF: Checking connection...
    00:00:05 WIF: Attempting connection...
    00:00:06 WIF: Checking connection...
    00:00:06 WIF: Attempting connection...
    00:00:07 WIF: Checking connection...
    00:00:07 WIF: Connected
    00:00:07 HTP: Web server active on xxxxxx-xxxxx with IP address xxx.xxx.xxx.xxx

On mqtt I catched the following sequence:

nov 28 01:06:46 cmnd/sonoff-sw014/POWER (null)
nov 28 01:06:46 tele/sonoff-sw014/INFO1 {"Module":"LSC Tuya Pir3","Version":"7.1.0(tasmota)","FallbackTopic":"cmnd/DVES_XXXXXX_fb/","GroupTopic":"cmnd/tasmotas/"}
nov 28 01:06:46 tele/sonoff-xxxxx/INFO2 {"WebServerMode":"Admin","Hostname":"xxxxxx-sw014","IPAddress":"xxx.xxx.xxx.xxx"}
nov 28 01:06:46 tele/sonoff-xxxxx/INFO3 {"RestartReason":"Power on"}
nov 28 01:06:46 stat/sonoff-xxxxx/RESULT {"POWER":"OFF"}
nov 28 01:06:46 stat/sonoff-xxxxx/POWER OFF

Problem, remains, with these low battery devices, that it is impractical to have these configured via Wifi, let alone doing an OTA update. Thought the Tua MCU has some - yet not clearly documented - support for this. Some command allows a 60-90seconds sleep-timeout.
A bypass could be, to mount a small micro-switch that keeps the power (via battery/fet) on de esp8266.

In version 6.7.1. , I myself used the programmed 10 seconds heartbeat that I used to keep the device active, do things and request FnId/DpID reports which poweroff the device under control of MQTT .

Anyway, time to recap and leave it a while boiling. Other items, request my attention. In case of question or followup, let me know.

Regards, Peter

[RobvanSuilen]

I can confirm the ACTION LSC doorsensor working with 7.1 version of tasmota. I got it working under domoticz and with MQTT. This is not my own finding. More info on: https://www.letscontrolit.com/forum/viewtopic.php?f=5&t=6955&p=41132#p41028

[ptrooms]

Comfirmed with LSC DOOR and PIR.

Note: In order to allow for "online" configuration, while running on batteries, "simply" issue "Serialsend5 55 AA 00 02 00 01 00 02" command asap after it is initialized with Tasmota.
This Tuya-function (_Search AP_) allow approx 60-90seconds time before shutting down.
Normally, the device will be switched off within 10 seconds after it is activated and/or Tuya function _Cloud-Is-Active_ (55 AA 00 02 00 01 04 06)) is issued.
Perhaps this could be "built into" Tasmota/Tuya device code if/when a long (or short) reset-press has been received from the Tuya-MCU.

[RobvanSuilen]

I do find that when I, for example, switch a wall socket with the input of the doorsensor it takes about 5 seconds for the wall socket to switch after opening the doorsensor. Is this normal? Is it possible to speed this up?

[ptrooms]

@RobvanSuilen , things need time (Get wifi/ip/initialize/mqtt/domotica etc.etc.).
One could speed up things by fixing the IP address and/or let respond the wall-socket to the "LWT Online" (mqtt retain function) message ( and/or use the "POWER (null)" message ). Aside, one could exploit (not yet used/tested by me) the internal Rule engine .
Keep in mind that the PIR & DOOR sensor are primarily movement-sensors to detect movement and followup this by "Alarming" someone.

[jsolla]

Is there any final guide for this sensor? I managed to flash it and program the rules given here:
https://www.letscontrolit.com/forum/viewtopic.php?f=5&t=6955&p=41132#p41028
I can see it connecting to the MQTT server but I cannot see the sensor status info and I would like to have also the battery info if possible.

[NordRagnarok]

I have one of these working, perhaps not the way most of you want to do this. I've attached the sensor to GPIO4 with a bridge and use to TUYA MCU module to keep it alive long enough to do some config. I guess this will reduce the battery life a bit.

The template i use: {"NAME":"LSC Door Senso","GPIO":[0,108,0,107,9,0,0,0,0,0,0,0,0],"FLAG":0,"BASE":54}

Hi, can you explain how you flashed tasmota on this sensor? I'm trying to solder pins and it's not in pairing mode... connected GPIO0 to GND and the MCU RST to GND, but still it's not getting to pairing mode
What do you mean by "Use the TUYA MCU to keep it alive"?

[bjornvanalphen]

Hi all!
I'm a new at domotics and TASMOTA. I have been busting my head the past 2 weeks over this LSC doorsensor. I feel like I'm almost there but it also seems like I am stuck at the moment.
The doorsensor reports via MQTT when the reedswitch is toggled, but it seems to send the same message for opening and closing. I tried the "setoption66 1" hoping this solved my problem but it seems this setting is not stored: after reboot it is off again. Can someone help me out??
The console says (sorry I cannot align it wright):

00:00:00 CFG: Loaded from flash at F8, Count 44 00:00:00 Project tasmota Tasmota Version 7.1.0(tasmota)-2_6_1 00:00:00 SNS: Hardware Serial 00:00:00 WIF: Connecting to AP1 H369A7236BF in mode 11N as beneden/bijkeuken/achterdeur-36... 00:00:06 WIF: Connected 00:00:06 HTP: Web server active on beneden/bijkeuken/achterdeur-36 with IP address 192.168.2.16 00:00:06 RUL: WIFI#CONNECTED performs "backlog serialsend5 55 AA 00 01 00 00 00; delay 10; serialsend5 55 AA 00 02 00 01 04 06; delay 3; serialsend5 55 AA 00 05 00 01 00 05;" 00:00:06 RSL: stat/beneden/bijkeuken/achterdeur/RESULT = {"SerialSend":"Done"} 00:00:06 TYA: MCU Product ID: {"p":"i22freyypqdcirq3","v":"1.0.4"} 00:00:06 RSL: stat/beneden/bijkeuken/achterdeur/RESULT = {"Delay":10} 21:07:57 MQT: Attempting connection... 21:07:57 MQT: Connected 21:07:57 MQT: tele/beneden/bijkeuken/achterdeur/LWT = Online (retained) 21:07:57 MQT: cmnd/beneden/bijkeuken/achterdeur/POWER = 21:07:57 MQT: tele/beneden/bijkeuken/achterdeur/INFO1 = {"Module":"Tuya MCU","Version":"7.1.0(tasmota)","FallbackTopic":"cmnd/DVES_32EE1A_fb/","GroupTopic":"cmnd/tasmotas/"} 21:07:57 MQT: tele/beneden/bijkeuken/achterdeur/INFO2 = {"WebServerMode":"Admin","Hostname":"beneden/bijkeuken/achterdeur-36","IPAddress":"192.168.2.16"} 21:07:57 MQT: tele/beneden/bijkeuken/achterdeur/INFO3 = {"RestartReason":"Power on"} 21:07:57 MQT: stat/beneden/bijkeuken/achterdeur/RESULT = {"POWER":"OFF"} 21:07:57 MQT: stat/beneden/bijkeuken/achterdeur/POWER = OFF

@NordRagnarok:
I managed to flash the TYWE3S by soldering like this: connecting GPIO0 to GND before connecting the 3V3 worked for me...after that I used Tasmotizer
I think the message "Use the TUYA MCU to keep it alive" practically means you need to move the magnet every few seconds (after flashing); otherwise the MCU shuts down the ESP and you can only use the TASMOTA inferface for serveral seconds.

[florian-asche]

Hi all,

still try to work on this problem, regardless that this ticket is closed.

So, i used the esp with basic TuyaMCU Tasmota config, without any rule. I then have the issue, that the esp is booting, but no info data are reported by the mcu. Then it boots 2nd time and all info data are reported.

When i use this rule:
rule1 ON Wifi#Connected DO backlog serialsend5 55 AA 00 01 00 00 00; delay 10; serialsend5 55 AA 00 02 00 01 04 06; delay 3; serialsend5 55 AA 00 05 00 01 00 05; ENDON
the device is booting instant and reporting its door state data. But the battery info is missing. I did try to remove the last serialsend5, because i dont know, what it does. The "serialsend5 55 AA 00 02 00 01 04 06" by the documentation above should query for data and go to deepsleep.