Support for Sonoff D1 Dimmer

[klotzma]

Have you looked for this feature in other issues and in the docs?

Yes

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is.

I cant't find a Template for this Device.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Sonoff has released a new dimmer, the Sonoff D1 dimmer. Is Tasmota compatible with this dimmer, if not, is it possible to add it?

Thanks Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered. Only Support. Additional context
Add any other context or screenshots about the feature request here.

(Please, remember to close the issue when the problem has been addressed)

[cdntinker]

The 433 MHz chip seems to talk to yet another MCU (an Eastsoft ES7P001FGSA) which talks to the BB10. So, it seems to be entirely separate from the ESP8285. This seems to indicate that the RF controls should operate the device independently to the WiFi controls.

[robbz23]

I have to agree with you that the 433 chip seems to talk to the bb10 directly. What you want to do would require new firmware for the bb10, this is doable since there are other projects that already doing this now. https://github.com/Portisch/RF-Bridge-EFM8BB1 I am not sure how hard it will be to reverse engineer the existing code though.

@digiblur or @Gravitate1 If you already have tasmota running on one, did you try the pwm profile? Does it work?

[Gravitate1]

I tried PWM but it didn't have any affect, which is not surprising if the BB10 is controlled via serial. I was able to turn the light on and off directly (but not dim) by connecting an unused pin from the ESP chip to the "Contol" pin of the header and switching that on and off.

[Gravitate1]

Just a quick update... I had time to try flashing that backup firmware @digiblur kindly provided... and it works! I guess there isn't a unique ID hard coded into the firmware after all.

When I get chance, I will try and sniff out the serial comms going from the ESP to the BB1.

[thxthx0]

Hard coded is the ESP chip ID (=second half of the MAC address)

and I think there will be a problem when the firmware is flashed to another ESP chip that isn't registered in eWeLink cloud.

btw. sonoff_d1_backup.bin on a WemosD1 sends @9600 Baud:

AA5501010001090C
AA55010000010002
AA55010100010609
AA55010000010002
AA55010000010002
AA55010000010002
AA55010000010002
...

[digiblur]

Figured it was almost like a TuyaMCU style config.

[Gravitate1]

I am unsure if I am doing this correctly but...

The Tx lead from my PC to the Rx of the ESP (and Tx of the BB1). The Rx lead from my PC to the Tx of the ESP (and Rx of the BB1).

I then set my port monitor to a Baud rate of 9600 8N1.

When I switch the light ON via the app, I get: AA 55 01 04 00 0A 01 64 FF FF FF FF FF FF FF FF 6C

When I switch it OFF, I get: AA 55 01 04 00 0A 00 64 FF FF FF FF FF FF FF FF 6B

When I set it to 1%, I get: AA 55 01 04 00 0A FF 01 FF FF FF FF FF FF FF FF 07 AB 55 FD F7 FF FF F5 01 FF FF FF FF FF FF FF FF 09

When I set it to 6%, I get: AA 55 01 04 00 0A FF 06 FF FF FF FF FF FF FF FF 0C AB 55 FD F7 FF FF F5 06 FF FF FF FF FF FF FF FF 0E

When I set it to 100%, I get: AA 55 01 04 00 0A FF 64 FF FF FF FF FF FF FF FF 6A AB 55 FD F7 FF FF F5 64 FF FF FF FF FF FF FF FF 6C

Hope this helps.

[kugelkopf123]

Hard coded is the ESP chip ID (=second half of the MAC address) ...

@thxthx0 Great idea! Flashing the fw on a wemos to analyse the serial data! 👍🏻

_{Sent with GitHawk}

[robbz23]

I did this last night and got the same values as @gravitate. This was by connecting tx - rx and rx - tx on J04. Which should be transmitted from esp to bb10. The interesting part was when I connected it up vice -versa and pushed buttons on the remote I saw the same commands but this time they were coming from the BB10 and going to the esp. It confused me at first then made sense. Since the 433 remote talks to the BB10 there has to be a way for the ESP and eventually the app to know that the state has been changed with the remote. I was not able to send commands to bb10 and have it change the light though which was disappointing. I guess the next step is to backup my firmware and load tasmota and try to send these commands through the serial.

[Gravitate1]

Thanks @robbz23 for confirming. I tried sending the commands through the serial and it didn't work, however, I am not sure that I did it correctly. Can the same Tx/Rx pins be used? Do we need to change the pins which are used for flashing? Or do we keep the standard Tx/Rx pins for flashing, cut the tracks between the ESP and the BB10, then join two unused pins to the BB10 instead?

[Drew765]

I think you guys are definitely on the right track with replicating the serial coms coming from the ESP. The programming on the BB1 includes some pretty important component preservation code, like the zero crossing detection that only modifies the dimming triac control input while the AC sine wave is at the zero volt crossing point of its wave path. The serial ESP inputs are the best way. Tasmota can do this (with some effort), but you guys look like you're on the right track. I have one of these modules coming, so hopefully I can assist soon, unless you guys figure it out before!

[sandeep-ma]

Just for kicks, I connected the D1 low voltage ESP board to the RobotDyn dimmer module. CONTROL to PWM and ZERO-CROSS to Z-C. Neither board has power, so I had to use my own 3.3V and GROUND power supply for both. Amazing, the lamp on/off and brightness controls worked successfully from the eWeLink app

I am still looking for someone to guide me on how and where to send 3.3V pulses or steady voltage from a capacitive touch module to control on/off and dimmer functions on the D1.

FYI, this is the touch switch I typically use with Sonoff basic https://www.ebay.ca/itm/50Pcs-TTP223-Touch-Key-Module-Capacitive-Settable-Self-lock-No-lock-Switch-Board-/312984381801?oid=332356436142

[cdntinker]

Won't know much for controlling it directly until we figure out how to Tasmotize it...

But (at least on the one in front of me...) S1 is an un-populated pushbutton between GPIO0 & GND, TP0 connects to GPIO0, TP6 connects to GPIO2, TP4 connects to GPIO4 & TP5 connects to GPIO5. So LOTS of choices...

[sandeep-ma]

Won't know much for controlling it directly until we figure out how to Tasmotize it...

But (at least on the one in front of me...) S1 is an un-populated pushbutton between GPIO0 & GND, TP0 connects to GPIO0, TP6 connects to GPIO2, TP4 connects to GPIO4 & TP5 connects to GPIO5. So LOTS of choices...

Thank-you sir, you made my day! S1 it is! The GPIO0 terminal of S1 (the one that is farther away from the LED) is normally at 3.3V and sending a ground pulse to it toggles the lamp between on and off. This is with ewelink firmware, of course. And the state is also updated in the remote app. I assume that holding the ground for a few seconds would send the switch into discovery mode also, but I did not try that.

So now I am all set to add capacitive touch local control to all the 10 D1s that I purchased and install them all over the house. FYI, I use decora blanks and glue the touch switch behind them.

d1_touch.mp4.zip

[robbz23]

Do we need to change the pins which are used for flashing? Or do we keep the standard Tx/Rx pins for flashing, cut the tracks between the ESP and the BB10, then join two unused pins to the BB10 instead?

Because you are listening in between 2 devices, tapping in with Rx/Tx will only allow you to see half of the communication. So if you put your Rx on the J04 Tx you should be listening in on what the ESP is sending to BB10. You would also be transmitted to the Esp if you send a command. I would think that is you send a command in this direction it should be updated on the app.

If you switch them though so your Rx is Rx on J04 you should be listening in on what the BB10 is sending back to the Esp. And this is how you can send commands to the bb10 to hopefully adjust the dimming levels.

[Gravitate1]

Thanks @robbz23 but I think you miss understood my question. I actually meant without tapping them with an external device. Instead, I was asking if we need to use different pins for Tx/Rx if we are sending the commands directly from the ESP using custom firmware.

P.S. When I tried what you suggested - swapping the Tx/Rx lines and sending the command from an external board, the light did not respond, but I am unsure why.

[kugelkopf123]

I would suggest to disable the ESP Chip while doing this. As far as I can see from the Pictures, its the Resistor right next to the C from C29, thats the Pullup for the "EN" Pin from the ESP Chip. So, if that Pin is connected to GND, the ESP is Off. Then retry sending stuff via the extern Wemos.

[Drew765]

@Gravitate1 & @robbz23 Could you tell me what baud rate you sniffed those serial coms with? Also, the two data packets listed, I'm assuming the first line was from the ESP Tx to the BB10 Rx, and the second line was the data going back the other direction, like a confirmation packet?

[robbz23]

@Drew765 9600 Baud. I am not sure exactly what the message was because it seemed that when I had it hooked up one way I got a lot more bytes compared to the other way. But what I think is happening is that when makes changes in the app the ESP sends the message to the BB10 and dimming is adjusted. However, if you make the change with the remote, the BB10 gets the info from the 433 mcu and now needs to tell the ESP so the change can be reflected in the app. This is where I got the exact same message that @Gravitate1 posted.

[Gravitate1]

Mine was 9600 also. I dont think the second line is data going back in the other direction because in order to receive that, wouldn't I have to swap my Tx and Rx lines?

[Drew765]

Still messing around with mine here. Something I want to try but can't (I don't have the RF remote), is to flash the ESP8285 chip with something (I'd use ESPhome) and set the serial logging to 'Very Verbose'. That way when using the RF remote you're getting direct feed back from the BB10 chip to the ESP8285 and can view it in the IDE/logger. Still leaves some data out, but might be somewhat illuminating...

[robbz23]

Well, I had some very good progress tonight. First I continued to monitor traffic with the default firmware using both the app and the remote. I was able to confirm the values being sent over the serial lines both from ESP and BB10. It seems no matter what side is updating the dimming status they both use the same commands to notify the other side that it has changed. For example, if you change it in the app it will send that over to the BB10 and if you change it with the remote the same data gets sent back to the ESP.

Then I flashed Tasmota and used the SerialSend5 command in the console to send over the messages that I had read earlier and they worked! I am able to turn the light on and off, and adjust the brightness by sending different values. Not only that but when I adjust the light with the remote it sends back that data to Tasmota. The BB10 and 433 part work just like we figured and they are unchanged by Tasmota. Here is a sample of what I did with the console.

00:17:59 CMD: Baudrate 9600
00:17:59 SER: Set to 8N1 9600 bit/s
00:17:59 RSL: stat/tasmota_D9E56D/RESULT = {"Baudrate":9600}
00:25:32 CMD: SerialSend5 aa550104000a0122ffffffffffffffff29
00:25:32 RSL: stat/tasmota_D9E56D/RESULT = {"SerialSend":"Done"}
00:26:35 CMD: SerialSend5 aa550104000a0122ffffffffffffffff2a
00:26:35 RSL: stat/tasmota_D9E56D/RESULT = {"SerialSend":"Done"}
00:26:35 RSL: tele/tasmota_D9E56D/RESULT = {"SerialReceived":AA550104000005}
00:28:58 CMD:  SerialSend5 aa550104000a0101ffffffffffffffff09
00:28:58 RSL: stat/tasmota_D9E56D/RESULT = {"SerialSend":"Done"}
00:28:58 RSL: tele/tasmota_D9E56D/RESULT = {"SerialReceived":AA550104000005}
00:29:12 RSL: tele/tasmota_D9E56D/RESULT = {"SerialReceived":AA550104000A013CFFFFFFFFFFFFFFFF44}
00:29:43 RSL: tele/tasmota_D9E56D/RESULT = {"SerialReceived":AA550104000A0101FFFFFFFFFFFFFFFF09}
00:29:53 RSL: tele/tasmota_D9E56D/RESULT = {"SerialReceived":AA550104000A0164FFFFFFFFFFFFFFFF6C}
00:30:02 RSL: tele/tasmota_D9E56D/RESULT = {"SerialReceived":AA550104000AFF1EFFFFFFFFFFFFFFFF24}

The codes are like what @Gravitate1 posted earlier always starting with AA550104000A then 00 or 01 for on/off and the next digit is a percentage of brightness. The only part I don't know how to figure out is the last 2 digits which are some sort of checksum. If I didn't enter them correctly it didn't work. You can also see that I got several AA550104000005. I got 5/sec when I was monitoring the default firmware, but it looks like tasmota just prints one then ignores them.

So who can code this up for us? I am afraid it would take me forever to figure it out.

[Drew765]

That's awesome mate! I just haven't had time to do anymore yet. Did you figure out the last two digits to send with the command by guessing, or just from sniffing them?

[robbz23]

The ones I have so far are from sniffing, but it looks to be similar to CheckSum8 Modulo 256 from this page https://www.scadacore.com/tools/programming-calculators/online-checksum-calculator/. However, the ones I calculate are one digit higher. Checksum 8 Module 256 is to add all bytes together and take the mod with 256. --Edit I tried it again but by adding a 01 on the end of all the bytes and it matches for all 8 examples I tried.

I should explain about the log that I pasted earlier. You can see from 00:25:32 to 00:28:58 I am sending commands from Tasmota console. After that, I am using the remote to adjust the light and the BB10 is updating the esp of the new status value.

[Drew765]

Nice, great job. Sounds like Sonoff were trying build a little Enigma. 😉 I was thinking about it and went off on some weird tangent about ASCII to Hex bytes representing an MAC address, glad you figured it out so quickly. Guess it's time now to start thinking about Arduino code to create the proportional control. Will probably try '[AnalogInOutSerial]' function maybe, with math functions for the 0-255 conversion to 0%-100% dimming, and another math function for the checksum.

[nemerdaud]

Hello, guys. I'm trying to flash my board and help programming this new Sonoff D1 board to be compatible with Tosmota, but I didn't have success on it. After putting the board in programming mode (GPIO 0 <-> GND) the ESP doesn't respond to esptool.py uploading the tasmota firmware. @Gravitate1, did you have success flashing tasmota in this board ? If so, is there some different procedure than the regular one for ESP8266 ? My connection diagram is: GPIO 0 (aka TP0) <-> GND E-TX (from J4) <-> FTDI RX E-RX (from J4) <-> FTDI TX 3v3 (from J4) <-> 3.3V (external power supply) GND (from J4) <-> GND (from FTDI) <-> GND (external power supply)

The esptool return "Timed out waiting for packet header" all the time.

[Gravitate1]

@nemerdaud Actually, no. I flashed it with ESPHome. However, I also had problems at first. I was powering the board and then grounding GPIO 0. To make it work, I had to ground GPIO 0 BEFORE powering up the board.

Why are you using an external power supply rather than just using power from the ftdi?

[nemerdaud]

@Gravitate1 , I'm using an external power supply because the 3.3V from my ftdi dont have power enought to start the board properly. Even having 3v3 at the source, when wired to the board, the level drops to 1v2 and even the serial port doesnt open. I will try buy another ftdi to see if it's not the problem.However, with external power supply and thi ftdi I could sniffed the serial line between ESP & BB10 and confirmed your log.

[nemerdaud]

By the way, I'm attaching a picture of my wiring on Sonoff D1.

[kugelkopf123]

@nemerdaud Like what @Gravitate1 says. Pull GPIO0 to GND before powering up the device with 3,3V. Hold it to GND for 1-2 more seconds after powering up then its not nessessary anymore. Another possibility is to pull GPIO0 to GND and "push" the reset Button. Idk if "TP3" is connected to EXTRST from the ESP8285. Its hard to see on pictures. If you connect ExtRST to GND for a second its reseting. But I would suggest to do it with the power up method. By the way, some FTDI Adapter have GPIO0 and RST Pins attached. That makes it more easy to do this whole flashing process.
By the way, nothing wrong with an external powersupply. Its important to have a common GND.

[nemerdaud]

@kugelkopf123, I really tried all these options, but without lucky. :-(. I'm a little bit frustrated, I admit, but i wont give up ! By the way, TP3 is connect to EXTRST then, when grounded, the ESP resets as you said. I will try other versions of esptool.py, changing baud or a new FTDI. Maybe the problem can be outside...

[nemerdaud]

I was thinking... as bb10 is connected in the same serial, maybe it could be dirtying the line among the flashing. Makes sense?

[kugelkopf123]

I was thinking... as bb10 is connected in the same serial, maybe it could be dirtying the line among the flashing. Makes sense?

Hm. Don't know. I dont have this device. But Im pretty interested in this process. Just for the sake, have you tried to switch RX/TX lines?

[nemerdaud]

Yes, I tried to switch, but doesnt work either. But now, I really believe the problem flashing ESP8266 of this board it's because of the BB10 linked on it. I was researching for EFM8BB1 (BB10 - Buzy Bee v.1) trying to find a way to disable it but, in the end, I found this page: https://www.itead.cc/blog/hacking-the-sonoff-rf-bridge-433. The boards are very similar, using the same strategy: an ESP8285 to Wifi & Control and an EFM8BB1 to control the power devices linked by Serial/UART. In the hack cookbook, he says "Finally, an SPDT switch that controls the communications between the ESP8285 and the EFM8BB1. The communication is done via serial (RX and TX) and that could be a problem when trying to flash a new firmware. Moving the switch to the OFF position you effectively disconnect the communication between both microcontrollers.". For this board (sonoff-rf-bridge-433), Sonoff provided a switch to turnoff the communication between the Chips, but for Sonoff D1, it didnt ! However, I think the S1 label is the way to do that. It's missed the switch, but the pads are still there.

[digiblur]

I flashed this several times with the pin header and just touching a wire to GPIO 0.

[nemerdaud]

@digiblur, sorry to ask, but are you connecting in this way: GPIO 0 (aka TP0) <-> GND (before power up and until 2 seconds after) E-TX (from J4) <-> FTDI RX E-RX (from J4) <-> FTDI TX 3v3 (from J4) <-> 3.3V FTDI GND (from J4) <-> GND FTDI

Just to be make sure we are talking about the same procedure.

[kugelkopf123]

@nemerdaud hm.. Dont think so. In the pictures from your link, the TXRX lines are connected through this switch, thats right. But as far as i can see it in the pictures from the D1 that isnt the same. I think the "S1" is more some kind of Pulldown GPIO0 Button. Another possibility could be, to desolder the resistors on the RX/TX lines that goes to the BB10.

[digiblur]

Yep. That's the procedure I use. Held 4 jumpers in with a pin header and touched GPIO 0 to gnd for a few seconds during power up.

[nemerdaud]

@kugelkopf123, that's it. You were right: S1 is a kind of pulldown to GPIO0, and desoldering the resistor isolate ESP8285 from EFM8BB1. And finally i could have my Sonoff D1 board flashed as I was suspecting. Thank you for the tips, @kugelkopf123. But, in the end, i really don't know why someones can flash without disconnect EFM8BB1 from Serial. Maybe is a different version of the board. Now I will research about how to flash without desolder the resistors :-D. But was a great victory. Thank you guys.

[nemerdaud]

I found a way to FLASH without desolder the resistors from Serial/UART lines. Background: the ESP8285 and EFM8BB1 talk each other over RX/TX and, in my case, when I tried to flash the ESP8285, the EFM8BB1 responds in the middle of the firmware's upload process causing it to fail. Taking off resistor of RX & TX lines solve me the problem with noise, but its a very tough proceduce since the smd resistors are tiny. This is the EFM8BB1 MCU: The pin 5 (RSTb) is an active-low reset (according to the datasheet) and it's connected to the C2CK (at J1 row) pad in the board. Then, I was able to ground this pad safely and powering up the board in programming mode, the flashing occurred without problems. That's it. I think it's the easier way to flash, if you have problems with EMF8BB1's noise like me.

[digiblur]

Does the OTA switch do anything. I know I flashed and backed up mine about 5 or 6 times without doing any hardware mods.

[nemerdaud]

For me, OTA switch do nothing. I'm tried a lot of variations. By the way studing other Sonoff DIY boards I found information about OTA Switch/Jumper that is used for enable REST API of the board to get easy to integrate with other automation solutions. However, even turning on OTA, the RESP API was not available and don't help me with the Flash. But @digiblur, I think that the user could try the regular procedure like you and if he has problems, ground the C2CK disabling EMF8BB1 and for sure will flash it. Maybe the difference should be in the FTDI hardware, or Sonoff D1 hw version and so on. The only thing regarding this I Know is that was only possible to flash the board disabling (in some way) the EMF8BB1 MCU.

[robbz23]

I had no problems flashing with the resistors in place. I removed the top low-voltage board from the high voltage board and powered it with my usb/serial convertor a 3.3v. I was able to back it up and flash it with Tasmota with this configuration. It also made it easy to try to monitor the serial lines without having mains to worry about.

[Gravitate1]

I did exactly the same as @robbz23. Except for foolishly not backing up the original firmware... @robbz23 what software do you use to do the backup?

[robbz23]

I can't find the exact guide that I used but it was similar to this. The one I had earlier also included a command so you could read what size of flash the chip uses. But in our case its 1M. https://community.blynk.cc/t/how-to-backup-restore-official-firmware-on-any-espressif-esp8266-esp32/34309

[arendst]

I'll try to writeup some driver using the info from here https://github.com/arendst/Tasmota/issues/7598#issuecomment-587207331

[arendst]

The D1 is currently in backorder so it'll take some time until I have one. In the meantime I try to patch some kind of driver, as many already found out, based on the RF bridge.

[robbz23]

The D1 is currently in backorder so it'll take some time until I have one. In the meantime I try to patch some kind of driver, as many already found out, based on the RF bridge.

That would be great because I looked at the code this week and I had no idea how to start with this. Pardon my ignorance here but isn't the design and function much closer to Tuya or Exs Dimmer? Both of these talk to a MCU over serial to change dimming. Unfortunately for us, it seems the esp chip doesn't get any information about rf codes that it receives. I believe that the 433 codes are handled by MCU and then it updates only the current dimming status.

Let me know when you have something to test. I have no problems uploading code and playing with it.

[arendst]

All itead RF devices work that way. They just send the result of their RF command to the esp8266 for status update to their APP.

All Tasmota itead RF devices work this way too. So it is different from Tuya and Exs and luckily for us we do not have to bother about Rf translation and stuff.

Have a look at the Sonoff Rf or 4CH devices; they perform well with Tasmota while Tasmota has no clue about the Rf part.

Stay tuned for a simple driver accespting (MQTT) commands and reporting state changes either from Rf or Wifi.

[arendst]

Try latest Sonoff D1 driver.

To use you must compile yourself enabling define USE_SONOFF_D1 in my_user_config.h

Then select module "Sonoff D1" from the drop down module selection screen.