New G6L board (TUYA compatible version)

[szymucha94]

Just bought the only available G6L doorbell in Poland.

It seems that it has CBU TUYA-compatible MCU. Does ESPHome support CBU chips?

Cheers,
Szymon

[pauln]

From the Tuya CBU datasheet, it looks like it's a Beken BK7231N, which isn't (officially) supported by ESPHome at present.

There's a draft PR to add support via the LibreTuya project; I'm not sure what the current status is, but if you read through the comments on that PR and the LibreTuya documentation, you might enough information to try flashing it (if you're willing to risk making the doorbell useless if it doesn't work... I'd suggest checking if it's possible to dump and restore the original firmware before you try flashing custom firmware, unless you don't mind completely breaking the doorbell if something goes wrong / it doesn't work yet). You'd also need to determine which pins to use for the remote_receiver and remote_transmitter configuration, as I don't expect they'd match the ESP32 pins.

[szymucha94]

You know what... I just bought zigbee illuminance sensor to report doorbell's LED activity to HA. I guess it's the easiest way to get what I need :)
I can just mention that I've captured traffic generated by the base and it's all encrypted. Tuya API browser also doesn't report doorbell's local key. I guess at this moment there are no dummy cloud projects that would allow keeping the wifi connection up and decryption of this traffic to work locally with the stock firmware.

[pcmester]

You know what... I just bought zigbee illuminance sensor to report doorbell's LED activity to HA. I guess it's the easiest way to get what I need :) I can just mention that I've captured traffic generated by the base and it's all encrypted. Tuya API browser also doesn't report doorbell's local key. I guess at this moment there are no dummy cloud projects that would allow keeping the wifi connection up and decryption of this traffic to work locally with the stock firmware.

You can get full local control of the device with the localtuya HA integration, this works way better than with the Xiaomi Cloud-tied board, here are the props you can get/set via the cloud API and locally:

"functions": [
     {
       "code": "doorbell_ring_value",
       "dp_id": 2,
       "type": "Integer",
       "values": "{\"unit\":\"\",\"min\":1,\"max\":40,\"scale\":0,\"step\":1}"
     },
     {
       "code": "doorbell_volume_value",
       "dp_id": 3,
       "type": "Integer",
       "values": "{\"unit\":\"\",\"min\":0,\"max\":8,\"scale\":0,\"step\":1}"
     },
     {
       "code": "alarm_propel_switch",
       "dp_id": 6,
       "type": "Boolean",
       "values": "{}"
     }
   ],
   "status": [
     {
       "code": "doorbell_ring_value",
       "dp_id": 2,
       "type": "Integer",
       "values": "{\"unit\":\"\",\"min\":1,\"max\":40,\"scale\":0,\"step\":1}"
     },
     {
       "code": "doorbell_volume_value",
       "dp_id": 3,
       "type": "Integer",
       "values": "{\"unit\":\"\",\"min\":0,\"max\":8,\"scale\":0,\"step\":1}"
     },
     {
       "code": "alarm_propel_switch",
       "dp_id": 6,
       "type": "Boolean",
       "values": "{}"
     },
     {
       "code": "doorbell_call",
       "dp_id": 10,
       "type": "Integer",
       "values": "{\"min\":1,\"max\":255,\"scale\":0,\"step\":1}"
     }
   ]

To get the local key, you can use the Tuya API browser, by sending a Get device details in the API browser.

[szymucha94]

@pcmester I've tried that already and tuya api browser did not return local key. Unless something changed in recent firmware releases. Do you own such doorbell? Which FW do you have?

[szymucha94]

Anyway, just tested it myself. They must've changed something because local key is clearly available now. Just added the device to HA. I hope it doesn't disconnect from wifi every 15 minutes when blocked from WAN :)
(edit: nope, it doesn't disconnect. It works fully offline).
One more note about this Beken SoC: it has the infamous mechanism that results in wifi MAC address being changed every device reboot. Which makes wifi bl*cklisting hard as MAC is unpredictable. I hope that this project will eventually be built using OpenBeken (https://github.com/openshwprojects/OpenBK7231T_App)

Thanks @pcmester!

[pcmester]

Anyway, just tested it myself. They must've changed something because local key is clearly available now. Just added the device to HA. I hope it doesn't disconnect from wifi every 15 minutes when blocked from WAN :) (edit: nope, it doesn't disconnect. It works fully offline). One more note about this Beken SoC: it has the infamous mechanism that results in wifi MAC address being changed every device reboot. Which makes wifi bl*cklisting hard as MAC is unpredictable. I hope that this project will eventually be built using OpenBeken (https://github.com/openshwprojects/OpenBK7231T_App)

Thanks @pcmester!

I am glad that I was able to help. Yes, the MAC thing was a terrible headache for me, I could not connect it via the app because of that, but apparently it does not change much, I have like 3 slightly different MAC for the device, but not more. Once it is connected to the AP, it keeps the same address (at least I hope so).

I haven't tried to set different chimes for different buttons, maybe the API cannot do that locally, and also I have no clue what the alarm_propel_switch does, it seems unavailable to me from HA. At least volume control works, and of course, the button press gets reported as an integer, which the older, Xiaomi versions could not do without ESPHome. One thing that doesn't work for me is the chime settings, because if I set it in HA, it clearly changes it, but when I press the buttons, they don't have the chime what I applied from HA.

[szymucha94]

Anyway, just tested it myself. They must've changed something because local key is clearly available now. Just added the device to HA. I hope it doesn't disconnect from wifi every 15 minutes when blocked from WAN :) (edit: nope, it doesn't disconnect. It works fully offline). One more note about this Beken SoC: it has the infamous mechanism that results in wifi MAC address being changed every device reboot. Which makes wifi bl*cklisting hard as MAC is unpredictable. I hope that this project will eventually be built using OpenBeken (https://github.com/openshwprojects/OpenBK7231T_App)
Thanks @pcmester!

I am glad that I was able to help. Yes, the MAC thing was a terrible headache for me, I could not connect it via the app because of that, but apparently it does not change much, I have like 3 slightly different MAC for the device, but not more. Once it is connected to the AP, it keeps the same address (at least I hope so).

I haven't tried to set different chimes for different buttons, maybe the API cannot do that locally, and also I have no clue what the alarm_propel_switch does, it seems unavailable to me from HA. At least volume control works, and of course, the button press gets reported as an integer, which the older, Xiaomi versions could not do without ESPHome. One thing that doesn't work for me is the chime settings, because if I set it in HA, it clearly changes it, but when I press the buttons, they don't have the chime what I applied from HA.

alarm_propel_switch (when configured as binary_sensor) returns either true or false, where true means that someone clicked the battery-less button, and false means that button is unpressed. You can use it for automations.

[pcmester]

Anyway, just tested it myself. They must've changed something because local key is clearly available now. Just added the device to HA. I hope it doesn't disconnect from wifi every 15 minutes when blocked from WAN :) (edit: nope, it doesn't disconnect. It works fully offline). One more note about this Beken SoC: it has the infamous mechanism that results in wifi MAC address being changed every device reboot. Which makes wifi bl*cklisting hard as MAC is unpredictable. I hope that this project will eventually be built using OpenBeken (https://github.com/openshwprojects/OpenBK7231T_App)
Thanks @pcmester!

I am glad that I was able to help. Yes, the MAC thing was a terrible headache for me, I could not connect it via the app because of that, but apparently it does not change much, I have like 3 slightly different MAC for the device, but not more. Once it is connected to the AP, it keeps the same address (at least I hope so).
I haven't tried to set different chimes for different buttons, maybe the API cannot do that locally, and also I have no clue what the alarm_propel_switch does, it seems unavailable to me from HA. At least volume control works, and of course, the button press gets reported as an integer, which the older, Xiaomi versions could not do without ESPHome. One thing that doesn't work for me is the chime settings, because if I set it in HA, it clearly changes it, but when I press the buttons, they don't have the chime what I applied from HA.

alarm_propel_switch (when configured as binary_sensor) returns either true or false, where true means that someone clicked the battery-less button, and false means that button is unpressed. You can use it for automations.

Ohh, thank you very much! I have just realized that I don't have a binary sensor at all, and the integer based doorbell_call cannot be used alone for automation.

[pcmester]

Interesting, it does not work for me, the binary_sensor is always unavailable. What firmware version have you set it up with? 3.3 or 3.4? And have you updated the device in the Tuya Smart app to the latest version?

[szymucha94]

wow, turns out I'm stupid :D
Just checked, and this switch controls/reflects app setting "APP message push". I got confused during the night since I just tested the button once and combined it with WAN access changes.
I will play with DID 10 tho.

[pcmester]

Yes, that switch changes the push notification setting. DID 10 sort of works, it shows the last button press (if you have multiple buttons, it changes accordingly), but if you have only one, then it is constant, so cannot be used for automation this way. I have tried with When the doorbell_call (DID10) status changes, but nothing happens, because of its constant nature.

Also, even though you can set the volume, and it seems like it changes it, but actually, it does not work, nor the alarm sound. It play the new volume and the new alarm, but when you trigger it with the button, it reflect the setting you had in the app.

[szymucha94]

what kinda worked is:

Simple automation can set this "last id call" to 255 every time doorbell base sets it to expected "1". This way value "1" can act as a trigger for other automations. I hope the device doesn't reset it from 255 without button press... maybe it won't if I disable WAN for it :)

[szymucha94]

after 15 minutes it still works.

[pcmester]

Thank you, this trick works really well. An another thing that can be done, is that we allow 0 as the value of the Last button ID, and therefore 255 is not needed, but we can set it to 0 which does not exists. Now, the question remains that how can the ring chime and volume setting be "enforced" by HA, and the button-tied chime and volume settings which options seemingly aren't offered by the API browser.

Edit: 0 won't work, the doorbell does not like it. After HA sets the state, the bell return the status as 1, so it changes back to 1 in HA too. 255 is fine.

[szymucha94]

it's risky, because MCU program may not expect it to be 0 (variable types?), so personally I'll leave it as 255

Edit: you were faster :)

[szymucha94]

Turns out this doorbell was not blocked from WAN... Standard rules that are rejecting all packets coming from specific MACs and IPs somehow did not work for this one device (maybe it uses multiple MACs in ethernet frames despite keeping one for active WiFi connection?). Now I've sniffed that doorbell talks to ec2-35-156-44-172.eu-central-1.compute.amazonaws.com and I've set this hostname to static non-existant IP in local network. I'm right now testing if doorbell will restart every 15 minutes like almost all IoT devices do these days. Hopefully not because it takes more than 40 seconds for it to reconnect which creates kinda big windows for it to not report in with button call. Not to mention that when HA initializes DPs it makes sound on the doorbell base ;)
Also increased TCP SYN and rejects are now generating useless traffic on wifi... it'd be still ideal to have ESPhome or some other replacement for it.

[pcmester]

Turns out this doorbell was not blocked from WAN... Standard rules that are rejecting all packets coming from specific MACs and IPs somehow did not work for this one device (maybe it uses multiple MACs in ethernet frames despite keeping one for active WiFi connection?). Now I've sniffed that doorbell talks to ec2-35-156-44-172.eu-central-1.compute.amazonaws.com and I've set this hostname to static non-existant IP in local network. I'm right now testing if doorbell will restart every 15 minutes like almost all IoT devices do these days. Hopefully not because it takes more than 40 seconds for it to reconnect which creates kinda big windows for it to not report in with button call. Not to mention that when HA initializes DPs it makes sound on the doorbell base ;) Also increased TCP SYN and rejects are now generating useless traffic on wifi... it'd be still ideal to have ESPhome or some other replacement for it.

On my side, everything works without WAN access, no reboots so far.

[plantroon]

I definitely tried localtuya back in the day, and it definitely didn't work for me, I don't remember why. So it works now? I can have the doorbell locally on stock firmware without internet access? :)

I have 2 doorbells, one is still on stock firmware and I was using it to catch missed button presses of esphome-flashed receiver vs the stock firmware one. Everything works fine now, so this would be interesting to add one more doorbell to my HASS at some other place without destroying its case :D

[szymucha94]

I definitely tried localtuya back in the day, and it definitely didn't work for me, I don't remember why. So it works now? I can have the doorbell locally on stock firmware without internet access? :)

I have 2 doorbells, one is still on stock firmware and I was using it to catch missed button presses of esphome-flashed receiver vs the stock firmware one. Everything works fine now, so this would be interesting to add one more doorbell to my HASS at some other place without destroying its case :D

yeah, it works just fine for 2 weeks now. Just get the local tuya key and configure it according to structure quoted above :)

[spupetic]

I am trying to make this custom component work on the CBU (BK7231N) running ESPHome via LibreTiny. Everything works, except the remote receiver. The log says, that Remote Receiver Signal starts with a HIGH value. Usually this means you have to invert the signal using 'inverted: True' in the pin schema!, but when I invert it, nothing changes, still no button presses in the log. I have tried setting the log level to very verbose, that does not help either.

[szymucha94]

I am trying to make this custom component work on the CBU (BK7231N) running ESPHome via LibreTiny. Everything works, except the remote receiver. The log says, that Remote Receiver Signal starts with a HIGH value. Usually this means you have to invert the signal using 'inverted: True' in the pin schema!, but when I invert it, nothing changes, still no button presses in the log. I have tried setting the log level to very verbose, that does not help either.

Don't you have to pair remote button first after reflash?

[spupetic]

I am trying to make this custom component work on the CBU (BK7231N) running ESPHome via LibreTiny. Everything works, except the remote receiver. The log says, that Remote Receiver Signal starts with a HIGH value. Usually this means you have to invert the signal using 'inverted: True' in the pin schema!, but when I invert it, nothing changes, still no button presses in the log. I have tried setting the log level to very verbose, that does not help either.

Don't you have to pair remote button first after reflash?

The pairing process works using the dumper, I should be able to catch the button's ID, and then add it to the config. That part does not work for me though.

[szymucha94]

@spupetic did you happen to fix this issue? I'm considering flashing esphome to have the invalid MAC address fixed.

[spupetic]

@spupetic did you happen to fix this issue? I'm considering flashing esphome to have the invalid MAC address fixed.

Unfortunately, no. And the problem is, that I don't really know, what the exact problem is. The doorbell chips work well under ESPHome from the Tuya board, if I connect them to an ESP-based board, not just the 32 but the 8266 too. So I guess that libretiny does something different than the original ESPHome, but I haven't seen any progress with this on that side.

[szymucha94]

@spupetic did you happen to fix this issue? I'm considering flashing esphome to have the invalid MAC address fixed.

Unfortunately, no. And the problem is, that I don't really know, what the exact problem is. The doorbell chips work well under ESPHome from the Tuya board, if I connect them to an ESP-based board, not just the 32 but the 8266 too. So I guess that libretiny does something different than the original ESPHome, but I haven't seen any progress with this on that side.

Meh, that's a bummer.
Which ESP32 did you use? Do you know pinout and which pins of cbu need to be connected to effectively replace mcu? I've got a spare esp-wroom-32d on hand, so I could use it.

[spupetic]

@spupetic did you happen to fix this issue? I'm considering flashing esphome to have the invalid MAC address fixed.

Unfortunately, no. And the problem is, that I don't really know, what the exact problem is. The doorbell chips work well under ESPHome from the Tuya board, if I connect them to an ESP-based board, not just the 32 but the 8266 too. So I guess that libretiny does something different than the original ESPHome, but I haven't seen any progress with this on that side.

Meh, that's a bummer. Which ESP32 did you use? Do you know pinout and which pins of cbu need to be connected to effectively replace mcu? I've got a spare esp-wroom-32d on hand, so I could use it.

The remote receiver is on P8, the transmitter is P26 and the two LEDs are P28 and P7 on the CBU. Take a look at the LibreTiny documentation of the CBU board to make the connections. I simply soldered wires onto the CBUs exposed pads, I have not removed it. I have not used or tested the buttons. I think you can use the pins written in this code, but other can work as well.

[szymucha94]

@spupetic did you happen to fix this issue? I'm considering flashing esphome to have the invalid MAC address fixed.

Unfortunately, no. And the problem is, that I don't really know, what the exact problem is. The doorbell chips work well under ESPHome from the Tuya board, if I connect them to an ESP-based board, not just the 32 but the 8266 too. So I guess that libretiny does something different than the original ESPHome, but I haven't seen any progress with this on that side.

Meh, that's a bummer. Which ESP32 did you use? Do you know pinout and which pins of cbu need to be connected to effectively replace mcu? I've got a spare esp-wroom-32d on hand, so I could use it.

The remote receiver is on P8, the transmitter is P26 and the two LEDs are P28 and P7 on the CBU. Take a look at the LibreTiny documentation of the CBU board to make the connections. I simply soldered wires onto the CBUs exposed pads, I have not removed it. I have not used or tested the buttons. I think you can use the pins written in this code, but other can work as well.

Thanks. I guess stealing 3.3V from doorbell's mobo for the new wroom while powering whole thing up with 230V was not such a brilliant idea. Killed doorbell, both MCUs and UART bridge :D
Ordered esp32 powered g6l. Hopefully it works stable with repo's program.

[spupetic]

@spupetic did you happen to fix this issue? I'm considering flashing esphome to have the invalid MAC address fixed.

Unfortunately, no. And the problem is, that I don't really know, what the exact problem is. The doorbell chips work well under ESPHome from the Tuya board, if I connect them to an ESP-based board, not just the 32 but the 8266 too. So I guess that libretiny does something different than the original ESPHome, but I haven't seen any progress with this on that side.

Meh, that's a bummer. Which ESP32 did you use? Do you know pinout and which pins of cbu need to be connected to effectively replace mcu? I've got a spare esp-wroom-32d on hand, so I could use it.

The remote receiver is on P8, the transmitter is P26 and the two LEDs are P28 and P7 on the CBU. Take a look at the LibreTiny documentation of the CBU board to make the connections. I simply soldered wires onto the CBUs exposed pads, I have not removed it. I have not used or tested the buttons. I think you can use the pins written in this code, but other can work as well.

Thanks. I guess stealing 3.3V from doorbell's mobo for the new wroom while powering whole thing up with 230V was not such a brilliant idea. Killed doorbell, both MCUs and UART bridge :D Ordered esp32 powered g6l. Hopefully it works stable with repo's program.

I have been doing the tests from DC power, so I have not used the wall plug that times. I don't know what went wrong there, but getting a compatible board is certainly an easier, but more expensive route.