No motion event sent after flahing my motion sensor #18
Comments
|
Long story short: once you flashed the PIR sensor you must arrange/ensure that the esp8266 firmware can communicate with the MCU-Pir controller. Remember here that the MCU controlled wait-periods before re-arming the sensor. As such the PiR is (and cannot be used as) not a realtime sensor. The MCU will power-up the esp8266-board when something is sensed by the PIR but only if the last active (esp8266) trigger was at least 60seconds ago (this re-arming will save battery power). The code flashed inside the esp8266 (ESPhome ?) must initiated WiFi connection and tell the MCU (using the Tuya protocol) for progress (1) Wifi connected, (2) DHCP is requested (3) IP-Address is received and (4) Get state after esp8266 is automatically powerdown. Note 1: Activity on Wireshark occur when and after the esp8266 power is activated by the MCU-controller and in turn can execute IP/TCP connectivity. |
|
Thanks for your reply ptrooms, I already try to wait more than 60 seconds to wake-up the esp8266 by motion, but nothing appears. How I can check if ESPHome communicates with the MCU? This repo didn't do that here : https://github.com/brandond/esphome-tuya_pir/blob/master/sb1_uart.h ? |
|
@sebastien247 Th sequence is started by inserting the batteries and forced by doing a long-press (to be sure use > 5 seconds). At the same time you should see something happening on Wifi, DHCP and/or (if wifi/dhcp succeeds) MQTT messaging (which require a connectable MQTT server) Simultaneously your could connect your RX/GND wires (only) of your USB/rs232 interface to either the TX of RX pin of the es8266 for monitoring (any)conversation. To keep the PiR silent, I use a wooden box to cover the PiR sensor. Covering with a thin paper/cloth will likely will pass infrared. I do not use or know indepth ESPhome. Keep in mind that "Tuya" is a widely used protocol to control and supports lots of of wired devices. Tuya also operates low-powerdevices which make them a bit tricky. I strongly recommend to monitor the rs232 during development of happy trouble shooting. Question: does the esp8266 print logic operates when you connect/power it via the usb (batteries removed) ? Elsewhere you may verify the ESPHome setting required to put the esp8266 into the PiR Tuya mode. |
|
@ptrooms Thanks for your response. I finaly found the problem, the MQTT was not connected, I wrote the ip with port like this : Also ESPHome Dashboard is not compatible with windows, that's why I have encountered difficulties to progress. Now my PIR reboot in loop, I try to push the button by a long and a very long press. but always the same think: |
|
@sebastien247 Perhaps your MQTT-server may have a Retained (last will) message for the "topic" that's is used... which is re-issed as soon the esp8266 connects to the MQTT server. If possible, monitor/clear/clean MQTT to ensure that message retainment is not playing a role. Best monitor MQTT * ( I use MQTT-explorer) to see what's done there. Note: keep in mind the're following sequences is to be walked and followed: Seen your log... I presume your ESPHome driven PiR sensor stucks in looping in stage "B" on esp8266 level. The executed Long-press will basically activating (one time only) "stage A" I suggest, you debug that initial stage B... I myself and I would do this while powering the esp8266 via the usb-cable (without batteries) and by this taking MCU out of the equation as this stage is not yet applicable. |
|
@ptrooms I also try to monitor serial but all output is unreadable. Putty Output: Note: I can't boot my PIR alimented only by 3.3v from rs232. I need to use the battery... |
|
@sebastien247 , better try hexmode and consider Teraterm which is more practical for HEX mode/display. Using Putty for serialising microcontrollers is no fun. It appears to me that your babble-fish is the "Product ID Handshake" of the Tuya conversation due to the "get device-id" request (Tuya command 0x55AA00010000 00 (from esp8266 to MCU), as the first communication step. The fact that you see multiple records, tell me that your "esphome" is apparently not seeing this or properly interpreting this as it re-issue "tell me who you are" command. The >> U▒*{"p":"Okurono2XLVRV0fB","v":"1.0.2","m":0}▒U▒U▒U▒U▒ftU▒eq << You should be able to power the esp8266 itself by the usb/cable, just like flashing. The purpose for this was solely checking out if the esp8266 is doing its thing. (connect wifi, acquire ip and start mqtt ). As you can see the "Okurono2XLVRV0fB" string the esp8266 seems to do its job (so far). Your next challenge is to let the esp8266 send the following commandcodes to the MCU: Command/Step 4 will let the MCU return the reason for its activation en implicitly power down the esp8266 in about 1-2 seconds. During that period the esp8266/esphome can tell "mqtt" that is had communication. Note: for the PiR device its obvious there was PiR-movement as this is the only reason why the PiR will (normally) be powered-up. Other devices, like doorcontact, can differentiate by door-close and door-open response. In addition, one could get a "battery status" response as as result of the long-press-reset-button action. |
|
@ptrooms Thanks again for your answer. With the result obtained I think I get only the communication from MCU to ESP8266 not the inverse. So it's complicated to understand these messages : |
|
@sebastien247 Consider also time stamping the loglines. As far as I know, Teraterm can do that. I do everything on Linux using other scantools/hardware. Consider to probe also the other serial wire, your trace now shows the TX wire of the MCU towards the RX wire of the esp8266. By that you can tell what the esp8266 is asking the MCU. As You can see, the trace story consist solely of the following (data returned by MCU) patterns:
Whatever the reason, the ESPHome firmware seems stuck into phase of interrogating the MCU and either not report or not progressing the MCU/PiR towards state Wifi connected, IP set and closedown message. I do recognize this (low-power device) method by which the esp8266 (esphome) can/will anticipate specific devices. As said before: for a successful operation one must arrange/force the earlier sequence. Without, the MCU considers that this initial- (reset) transaction failed and will - for battery safe reasons - never "arm" the PiR sensor and thus not power-up the esp8266. Question about your trace: was this after you executed the long press. |
|
@ptrooms I have not found the option to time stamp I don't remember. But with or without long press, the result seems to be equal. |
|
@sebastien247
Now some behavior to be sorted out:
The transaction-sequence in your logging, is repeating. The question is how much time is between those occurrences. Regarding time-stamping, check the Log/setting option. By this you/we can tell the time difference of each repeated sequence. Aside, I got a feeling that the problem is in ESPHome not sending the last-line state to MQTT. I presume you can confirm that the esp8266 connects to MQTT.. which s not to be confused as valid "sensor-reason" ... though the PiR can only do this if it was powered on. |
|
Hi, I flashed the LSC PIR (via serial port) and I see it connects to hass mqtt but the only msg I get is:
this is the config yaml: Also, when I'm connected via the seral port, I can see any logs in ESPHome-Flasher. Can you please help? |
|
Hi @ptrooms, You mention that you using it with tasmota, so I will appreciate it if you can help me to sort out the mess I created. Thanks in advance |
|
Hi @KirkKirk It's been a while to remember things back. My (I have 3) PIR sensors nicely operate under control of my Domotics (openHAB ) using Tasmota Tuya-device mode. You problem appears to me that your sensor stay (=hardwired) too long active for 2-3 minutes which results in a poor response. What I've done was first to get things flashed was powering the esp8266 directly (3.3V) while the PIR sensor was covered (to prevent MCU chip activation) and upload standard/generic Tasmota via serial connection. Thereafter things are are straightforward: when the PIR is activated, it will signal Wifi/MQTT on the defined topic which allows interaction to talk Tasmota 'tuyamcu sequences'. Starting here I deviate a bit from your approach. When I (my Domotics receives MQTT) detect that the PIR activates by receiving the ONline state, I will instruct immediately the MCU to end the established MQTT session by sending For all clarity, I'm oldskool and do not talk nor use the specific tuya-command sequences as are nowadays part of newer Tasmota versions which allows for example the auto-detection that simplifies the life of "ones" that do not can/want operate things on a basic level. I do not have the urge to change things (yet). My PIR devices run very old Tasmota (6.7.1) version and I will only update these, if really required. (Update is complicated as the hardware timeout of PIR sensors may interfere beyond functioning and I do not want to re-flash offline that require resolder and so on). Hope it helps to shine a light and no problem to discuss things further. |
|
Hi @ptrooms, Thank you heaps for your guidance. Serialsend5 55 AA 00 02 00 01 04 06 filled the gap missing and works fine now. cheers |
|
Great to read @KirkKirk it was useful. For the template, it is just a (positional) template that could sometimes ease, not really here, tasmota configuration: Note: as gimmick, I've added a DS18B20 sensor to the unused gpio14 pin of the PIR and by setting an extra Tasmota rule ("rule1 on Mqtt#Connected do status 8 endon"), I will also get the temperature in the returned "status8" message during time of movement detection. Have fun with detections. |
Hello,
I flashed my motion sensor and after the reboot, led are turned on for some seconds. But no movement seems to be detected because the blue leds stay off and I receive no event in ESPHome Dashbord. Also, in WireShark I see nothing sent from the Mac address of my ESP, expection for the wifi connection when the sensor is wake up by pushing the button.
NB1: Sorry for my English
NB2: I'm a noob with ESPHome
Thanks for your help.
The text was updated successfully, but these errors were encountered: