Neo Coolcam PIR Coprocessor Support #306
Comments
What do you mean by that? Also, from the config it looks like you haven't tried pin 16 yet. The PIR sensor is pretty likely connected to pin 16 as that's the pin that supports waking from deep sleep.
So the ESP crashes after exactly 60 seconds? That's weird.
No |
|
Also, I don't think there's any great support for deep sleep at the moment, is there? As far as esphomelib is concerned, it's just another powerup; the only difference is the reset reason, right? Also, iirc GPIO16 has to be wired up to the reset pin in order to be used as a wakeup timer, right? All it does is pull GPIO16 low when the deep sleep time expires, at which point the system powers up again with all memory reset as if from a cold boot. There are other low-power modes available that keep memory and wifi available, but they're not likely to get you the power efficiency you're looking for on a battery powered unit like that. |
https://esphomelib.com/esphomeyaml/components/deep_sleep.html
That's if you want to it in wakeup "timer" mode. But I think in this case the product is designed in such a way that the RST pin is pulled high by the PIR directly, so the ESP will boot up exactly when the PIR sensor activates.
except for RTC memory, which esphomelib uses as a store for all of its persistent data with ESP8266s. But I think for this application persistent data isn't required anyway? |
|
By 'great support' I meant there wasn't any special handling for deepsleep wakeup. The sleep itself is definitely well supported - but when it boots it still has to go through the whole init, associate, dhcp, connect to mqtt, etc process as if it were a cold boot. There are no shortcuts or speedups. Any handling of determining a sensor wakeup vs timer wakeup would need to be done manually, correct? |
I forgot GPIO16, true. I believed like @brandond that it was connected to the reset pin and just doing its magic and I just have to fetch some output signal tu use it in HA
no it doesn't crash. It's the standard behaviour of the PIR and it seems it is realized in hardware that it goes into deepsleep after 60 seconds. if you put your ear next to the board it's probably realized with some electric coil or inductor.
|
To wait for the boot process is a general problem of the esp module used here. the vendor seems to circumvent the problem in prolonging the PIR signal with some kind of timer or filter. |
|
After the last test GPIO16 itself is also giving no signal, too. |
|
I just ordered one off AliExpress since it seemed like an interesting piece of hardware, and I've been meaning to play with PIR sensors anyway. Won't be here for about a month though :) I've got a logic analyzer so at the very least I should be able to do some tracing on the stock firmware. |
|
I'm interested in this discussione because I have 2 PIR sensors. |
|
My device just came in. Haven't got much further than cracking it open and putting a barebones esphomelib firmware on it, which was pleasantly easy to do given the exposed vias. I have a sneaking suspicion that the secondary MCU controls both the LEDs and the PIR, and the ESP is only woke if some internal threshold is triggered on that side. Other bits of stock functionality like blinking the LEDs at powerup, illumining them when the button is held down, etc all seem to work even with alternate firmware loaded. If that's the case, there's probably some additional firmware running on there. It seems to persist even if the ESP flash is rewritten, which is good - but we're probably going to have to figure out how to talk to it if we want the chip to get woken up. Hopefully it's as simple as just pulling up a pin at the right time and not a whole complicated serial protocol, although there do appear to be another set of clock and data pins along the edge of the board... |
|
The pictures don't do this board justice - it's tiny. I've got as far as figuring out that the SB1 'Sleepy Bee' chip is wired up to the external reset pin on the ESP8266. I can confirm that GPIO16 is not wired up to the reset pin, so there's no way for the ESP to wake itself. I can also confirm that the SB1 pulls the external reset pin low after about 110 seconds, so clearly there's some sort of deadline in play. I'm unable to get the unit to wake from motion, so I'm guessing the SB1 is expecting the ESP to do some sort of setup that's not occurring, but I can't find anything else that's wired up between the two chips. I'll keep poking at it, but this is a weird one. |
|
I managed to kill the ESP core - the SB1 still blinks the LEDs and such but I can't even get the ESP into the bootloader. That's probably the end of my physical exploration of the board - I'll see if I can figure anything out from the flash dump I grabbed, but I'm not optimistic. Pity, it'd be such a great device if we could just figure out what that other core wanted. |
|
Real pity you managed to kill it. Or was it only temporary? I thought I killed mine once, then reflashed the original firmware though getting an error but it worked miraculously. |
|
I was messing around with it while powered up and accidentally shorted the external reset pin to 3v3 instead of ground for a couple seconds, after that I can't get anything at all from the ESP - scoping the serial pins shows some output on boot but the timing is all off. Pretty sure I fried something :) I might try removing the SB1, there are apparently four pads under the corners that I can't hit with a probe. I'm also playing with decompiling the firmware with ScratchABit, but I'm having a hard time figuring out how to load the bits of dumped firmware into the tool and haven't made any meaningful progress. |
|
Update: I was able to find another set of connections after decapping the SB1. Using your picture above as a reference, all the via pads above the notch go to the ESP8266, and are labeled intuitively. You can flash firmware over RXD0 and TXD0 by holding GPIO0 to ground as usual. GPIO2 puts out the usual bootloader serial messages at 76923 baud, PLUS a bunch of debug messages from the Tuya firmware. The pads below the notch are for 3v3 and ground, plus another set labeled TDX and RXD. These go to the same pins on the ESP8266 as the RXD0 and TXD0, but on the other side of a pair of resistors. Also on the other side of the resistors are two pins at the top right of the SB1; Multifunction IO P0.4 and P0.5 according to the datasheet. The ESP8266's reset pin is down on the bottom at SB1.5, also connected through a set of resistors. The pins at the far bottom of the board go to the C2 Debug Clock and Data pins on the SB1, which could be interesting if anyone really wanted to get into figuring out what it was doing; it's basically a proprietary bidirectional JTAG protocol. Interestingly, the board has a 26MHz crystal on it, instead of the more common 40MHz - probably to further reduce battery usage. This might have contributed to my confusion when troubleshooting esphomelib on the board, as there are some things that aren't clocked properly if you compile for the wrong frequency. Anyways, my board is definitely dead. Knowing what I know now I will probably order another one and see if I can get some logic analyzer traces off the SB1 side of the RXD/TXD pins while running the stock firmware. Also, the stock firmware seems to run fine on another ESP board I had sitting around. I never actually used the Tuya app to set it up, and I threw away the instructions, so if anyone has any tips on how to use the app to configure it, that might be useful while I wait for the new sensor to come in. |
So what is the setting I have to set here in esphomeyaml? Or does it only matter for external debugging? |
using the tuya app is quite easy. you just have to create an account and then add a device. for the pir you have to add "other devices" then it searches for the pir, otherwise its just telling me its not a zwave (guess what...) |
|
I'm waiting on my replacement devices to get in; in the mean time I've been playing with the PIR firmware flashed to a development board. Unfortunately I can't get the Tuya app to pick it up. After the normal boot messages on GPIO2, it just sits there sending out a fixed sequence on UTX0 at 9600 baud, at alternating 1 second/2 second intervals. I'd love to get it registered with Tuya and see if this changes. At the very least it's something to look for once I get the new devices in. FWIW, here's the boot log: |
|
That could be the connection sequence, have a look here. |
|
Oh, tuya-convert is just what I've been looking for. Might save me some soldering in the future. I might grab my rPi and see if I can get it running on there. Nor sure how the pairing works, but the fact that my AP is dual-band with a 5.8ghz preference and the app says it only supports 2.4gh may be breaking it. Could also be that the firmware is looking for some handshake from the SB1 to go into pairing mode though, since it has no direct connection to the button on the board that's used to put it into that state. |
|
Same here, awesome work! I'll also close this issue because this is primarily a bug tracker. Discussion can however of course continue here. |
|
New devices arrived. Was able to capture some useful data going back and forth between the ESP8266 and the SB1 at 9600 bps during complete configuration steps, using both SmartConfig and SoftAP modes. So far I've seen: The product ID and version check always happen first, followed by status updates as the device brings up the network stack. The ESP8266 will stay online for about two minutes waiting to connect or be configured. If the ESP8266 sends an all-clear message (wifi up, IP up, MQTT up), it will get powered down about 3.5 seconds later if the SB1 has nothing for it to do. If the SB1 has a motion event, the response to the all-clear will be immediately followed by a motion event sequence. The ESP is powered down immediately after acking the motion event. A summary of the boot process (with both traffic between the ESP and SB1, and log messages) is here: https://gist.github.com/brandond/9c88b9ca204ec3152b8078c47db4c484 |
|
This is great work. |
|
I should be able to write a pretty basic UART component to talk to the SB1, but first we need to move the standard serial logging output to GPIO2 to free up GPIO1 and GPIO3. I'll probably put in a PR to allow for setting an option in the logger component to do that, unless @OttoWinter has a different preference. Once that's done, I'll put together a UART component to talk to the SB1. That would include:
|
|
That would be gorgeous. I'm happily testing it when its done. Unfortunately programming itself is not one of my skills. |
|
I ordered one of these a few weeks ago (arriving today) hoping to "decloud" it with tuya-convert but obviously the SB1 throws a spanner in the works, I'm happy to offer what ever help or testing I can, please hit me up if theres something I can do to help. I've now had intruders in my backyard twice in a month and wanted to deploy at least 4 of these! After reading this I'd be fairly confident that I could wire the "motion" LED to a GPIO and GPIO16 to RST to bypass the SB1... thoughts? |
|
The traces on this thing are tiny, I would not plan on rewiring anything. The LEDs are controlled by the SB1, and flash in predetermined patterns - slow blink when configuring in AP mode, fast blink when configuring via SmartConfig, long blink when motion detected followed by a single short blink when the motion has been transmitted to the server, etc. All of this is coordinated by the status messages send back and forth via the UART. |
|
If you wanted a challenge, you could dump out the flash on the SB1 and reprogram that thing, though. Then you could do whatever you wanted with the LEDs and power state on the ESP. |
|
Hi @brandond, I push the button to enable fast-blinking and I launch the OTA update but after it fail. concerning the second question, into the pir.yaml file I have set the log level to 'info' but if I analyze the mqtt message send to my broker, I see a debug mqtt message. thanks |
|
What do the MQTT logs say while you're doing the OTA update? If it's not timing out there should at least be progress messages. All logs sent via MQTT go to the 'name/debug' topic regardless of their severity, That's just the default log topic, you can change it if you don't like it. Reducing the log level actually compiles out messages of a higher level, so (for example) at INFO level the firmware will not contain any DEBUG or VERBOSE level messages. |
|
Hi, to flash via USB I use GND and V (3.3) Pin. [0;33m[W][ota:420]: Timeout waiting for data
|
I haven't flashed mine yet; I have been doing some captures off the stock firmware so I can make sure I document it properly. I don't usually solder on to these though, as the components are so fine; instead I try to get them going with a set of clip or pincer probes from my logic analyzer. It looks identical to yours, except all the pads are in good shape. If that GPIO0 pad is really hosed, you might see if you can get tuya-convert working. You'll need to have an esphome firmware ready to go, and replace the tasmota binary that comes with it. |
I've tried to get it updated with tuya-convert, unsuccessfully. Might try again as I have a feeling that it's because the timing issue you mentioned before. |
|
@ciscozine the below pinout shows you where GPIO is on the ESP8266EX chip, its pin 15. I was hoping the resistor close by that side of the chip may be connected to GPIO0 but its not. You may be able to get it to boot by using a sewing needle/pin to ground it but you may need 2 pairs of hands to get it all done.
|
|
@mplinuxgeek Thanks! thanks |
|
Tuya convert doesn't seem to be working because the pir goes back to sleep once the connection is established.. which is strange because I would imagine it can stay awake during a normal ota upgrade. Is there a way to send the initial firmware from brandond to it when it is in the slow flashing AP mode? I also can't seem to flash it using the pins. |
|
I hope my question is not offtopic; have you got suggestion for a door sensor managed via mqtt? Thanks |
I don't plan on continuing with these wifi motion and PIR sensors, they were a cool toy but don't respond fast enough for me, I have purchased a CC2531 and flashed it with Z Stack to use as a generic zigbee2mqtt gateway and have started with some Xiaomi Zigbee sensors. |
|
There's about a 3 second delay before the event hits MQTT, which is fine for me. Unfortunately the limited battery life makes them unsuitable for high traffic areas. I think I might like the door sensor more than the PIR, just because I suspect it will last longer. |
|
@brandond I'm finding anywhere from 3 to 10 seconds and they often don't capture motion, I am using one to trigger lights at my front door and it often completely fails to trigger. |
|
Some of mine seem to get stuck after a while and stop detecting until I reset them, while others have been running fine for weeks. They're all within 20 feet of my AP so I don't think it's a signal issue, and I have no reason to think that the code that interacts with the SB1 is at fault... but I didn't run them with the stock firmware long enough to see if they have the same issues with different code on the ESP. |
|
I still can't even manage to flash them.. I have three and they all time out on the flash procedure. I've been at it for days and can't figure out what's wrong. Tried all sorts of power supplies. |
Finally managed to flash both units with CP2102 USB to TTL adapter. FTDI232 adapter was not working. Hopefully will help someone. |
Great news.. CP2102 is on order :) I'm wondering what the most efficient way would be to disconnect the SB1; I'd like to hook the pir up to a permanent power source, hopefully that would make it more reliable but I would need to stop the SB1 from powering down the board. |
|
So these things barely last 3 days on brandond's firmware without getting confused and becoming unresponsive. I have them hooked up to a 3.3v adapter, no need to save battery. I would like to prevent the coprocessor from pulling the reset and keeping the board alive. I could probably do that in a physical way by removing the connection, or making sure the coprocessor does not get the final mqtt ack? Not sure how to approach either of those solutions, could anyone advise? |
|
For me it's working stable for almost a month now, on battery though :) |
Brandons code will no longer work, you'll have to treat this board like a ESP8266 after and chances are the modification will be irreversible. You would be better off looking at alternate products like Xiaomi motion sensors with a CC2531 USB dongle. |
|
You'd have to completely rewire the thing if you cut out the coprocessor. The ESP doesn't do anything except handle external connectivity - the PIR and Reed sensors (on the door sensor) are all wired into the SB1. |
|
Bit offtopic, but Is there anyone willing to solder and flash a door sensor for me? I've ruined two pieces now and was unable to solder it (my hands are too shaky)? I'm willing to pay the sensor, the postage and the fee of the soldering/flashing. Reason: the place I want to use the sensor has only wifi coverage (from an access point), but no power outlets, etc that's why I'm forced to use wifi door sensor. |
|
@LouiS22 if you can't modify them yourself consider Zigbee instead, a CC2531 USB dongle and either a Xiaomi motion or IKEA motion sensor would be suitable alternatives and don't require power outlets. See https://www.zigbee2mqtt.io for more info. |
|
FYI for anyone still following this thread - I've just updated the code to work with 1.13, and confirmed that it works great with Arduino framework 1.5.1. Door sensors should also be working. |
|
This is great, thanks @brandond . Before I found this thread I found https://docs.tuya.com/en/mcu/mcu-protocol.html - it looks to be documentation of the serial protocol, you likely have found it but didnt see mention on this thread. |
|
That's awesome @BestEnemies, I'd not turned that up. Having access to that doc might help me fix some of the lingering issues I've had with the reverse engineered protocol. It's simple enough that I was able to get it working on my own, but I didn't quite know for sure what some of the messages meant. Occasionally I've of my devices (not the same one, just one at random) will drop off the network until I reset it; I'm not sure if it's the device, my code, or the framework that's to blame. |
|
@BestEnemies I finally got a chance to look through that protocol spec page. It seems to document a different version of the protocol than these devices are using - in particular all the examples show the MCU sending version 3 messages, while the version field sent by all the devices I've used is set to 0. Critically, the command word values used are different, as are some of the payloads for the common command words.
|
I recently ordered one of these NEO Coolcam PIR WIFI sensors .
The PIR itself is quite handy and small (sized like a golf ball).
When you take it apart you find a ESP8266EX and a lot of pinholes to connect to. Have a look at forum diskussion here.
The standard software is placed in the tuya/smart life universe and the PIR supports IFTT. Some sellers mention amazon alexa and google home support, but that is not integrated (yet?).
The original behaviour of the PIR is to detect movement, give a signal with the integrated LED's when movement is detected and return to deep sleep if there isn't any movement for 60 seconds.
when connecting the marked pins it is possible to flash the pir and extract the original firmware.
the esphomeyaml I created so far looks like this:
With that configuration boot-up is working, mqtt is working wifi-OTA is working.
So far none of the GPIO's was sucessful in keeping it alive or sending a signal. Exactly after 60 seconds the PIR is dead and has to be repowered manually.
So I think I have to figure out how to get the signal after deep sleep wake-up (that has to happen without programming I think).
Would it be wise to set the GPIO's to OUTPUT mode?
Any ideas how to procede?
The text was updated successfully, but these errors were encountered: