Ever since Google announced they were murdering the Nest Protect, I’ve been looking out for another smoke detector, and dreaming about something that was open and could have things like motion sensors added to it. In the meantime, I needed some smoke detectors for the office, so I settled on the “Kidde Smart Smoke & Carbon Monoxide Detector & Indoor Air Quality Monitor, WiFi”. This smoke detector is actually better in a number of ways to the Nest Protect. The Kidde Integration, although cloud-based, is solid, and works well. I do miss the motion detection of Nest Protect, though.
After getting these new smoke detectors up and running, I noticed in the “Device Info” the hardware was “WD-ESP32”.
So I bought one to tear apart. It had a few security bits, but was not difficult to tear into.
Upon revealing the motherboard, there was an empty header labeled “SERIAL”. I soldered three pins to this.
From the left, the pins are TX, RX, and GND. Using a 2.5V serial to USB adapter at 19200 bps gets you debug that looks like this:
I:47,At:80
>Drift Comp Slope =84
>CAV Max Limit =8D
>CAV Min Limit =21
>
APP Power Delay
SND PWR_On, Soft_RST or Bat_ACT
>V:553?
>V:475?
>V:413?
>*CB RX-RDY*
>CT:Err
>CT:0C 00
>V:363?
>
No COMM Status Received
*CB BSY*
>
>Sta-1B
>PCon-3C
>
>FW Ver 1.10.00
>R:0
>RF Module FW Version - 0.0
>CT:Err
>CT:60 00
>t:729,Avg t:729,DegF:72
>S:55
>
APP Power Delay
32Khz XTAL Stable
>*CB BSY*
>CT:Err
>CT:0C 00
>V:161
>C:0
>V:156
>C:0
>Start Voice Timer 5 Min-
>Network Err Code - 36
>SND Network Error
>
No COMM Status Received
V:152
>C:0
>Connection Lost
>V:146
>C:0
>V:143
>C:0
>t:728,Avg t:729,DegF:72
>S:55
>Press Button to Silence
>V:140
>C:0
>V:138
>C:3
>
APP Power Delay
V:135
>C:7
>V:134
My mistake was to tear into the esp32 daughter-board before trying the serial debug. The esp32 daughter-board goes on top of the mainboard and connects to a power header and a square 4-pin header (JP1) that I wrongly assumed was simple serial. It is not, and I’ve been unable to determine what it is.
The daughter board has a number of empty headers and test points.
It can be pulled off completely and powered via a USB serial board. At J3 there is access to GPIO0 for pulling low and flashing along with GPIO35 (RX) and GPIO35 (TX). You can see these contacts in the picture above. GPIO0 is upper right corner, GPIO34 is lower right corner, and GPIO35 is lower middle out of the six contacts on J3.
HOWEVER, after dumping the flash, and attempting to erase and write a new flash, I quickly discovered Kidde has blown the following fuses via “espfuse summary”:
DISABLE_DL_ENCRYPT = True
DISABLE_DL_DECRYPT = True
DISABLE_DL_CACHE = True
Which means my esp32 daughter-board is bricked. I’m debating whether to buy another Kidde to experiment with. It would seem to me that the only possibility at this point for non-cloud local esphome access would be to monitor what is coming off the debugging serial port. In that case, the native esp32 daughter-board would still be talking to the mothership.
The other possibility is desoldering the ESP32-WROOM chip and replacing it, but I’d prefer to determine how JP1 is communicating first. If it is some proprietary baloney, replacing the esp32 would be a waste of time.
I assumed originally that the esp32 was the center of the smoke detector, but instead it is simply communicating status and user operation back and forth. It is likely that these smoke detectors would not be underwritten by insurance if it was any other structure. In spite of the status of the detector going low when there is no esp32 daughter-board or Internet connection, the main part of the detector still continues to do its base operations.
There is also considerable space inside the housing of the detector that could be utilized for a second esp, which simply uses the smoke detector as a power supply, from which other sensors could be attached to. Unless someone else has a breakthrough on decoding the communication from the main board to the esp32, I think I may try this direction next.