I have a couple of devices that are supported by Zigbee2mqtt but not supported by ZHA. How can I request them for support? Z2M has a procedure for that. What about ZHA?
I guess you could raise a ticket on Github here, requesting support is added for those devices…(checking first, that they aren’t already in the works…
1 Like
Hi guys,
Quick question regarding the physical connection to the J1 connector of the Silvercrest gateway. Paul’s article describes that the J1 pinout is as follows:
Pin 1 = Vcc (3.3V)
Pin 2 = Ground
Pin 3 = U2 Serial TX
Pin 4 = U2 Serial RX
Pin 5 = ZigBee module ARM Debug SWDIO
Pin 6 = ZigBee module ARM Debug SWCLK
I currently assume that pin 1 is the one closest to the center of the board (please correct me if I’m wrong 
)
Question: Which J1 pin should I connect to which FTDI FT232RL adapter pin?
The pinout labels are on the bottom of the board next to the test pads. To be sure I tested continuity from the test pads to the header but they are in the same order as the jumper pins. I dont know which pin is outside or inside, I just closed up my gateway again. Write it on a post-it inside in case you ever need to hook it up again.
edit: so tx goes to rx, rx to tx and gnd to gnd. Powering from external adapter is easier to cycle while keeping the UART open so leave the 3v3 unconnected. Be sure the configure the FTDI for 3v3 logic.
Hey,
I have the same issue. I receieve the linux terminal, but Keyboard is not working properly. Which UART USB connector are you using?
That’s probably a faulty converter or faulty cable, or bad soldering. The issue has gone when I replaced the converter.
I’ve got the full access using this one:
https://www.aliexpress.com/item/32827321415.html
P.S.
You don’t need to plug 3.3v. Actually Rx, Tx and GND is enough. You can get power from USB connection. Just plug Rx, Tx and GND first and prepare the system. Then start the hub plugging USB cable to it.
If you turn back the board, you can spot Rx, Tx, GND makers and leads to the connector.
Okay, works without 3.3 V. But still no Keyboard input. Which terminal emulation are you using? PuTTY?
It doesn’t really matter. I’ve already told you where the problem is.
- bad soldering
- bad wires
- bad converter
If you’re sure about the connections then also check your terminal software has disabled hardware flow control.
You can test your serial port by temporarily joining Rx/Tx together. You should see what you type echoed back to you. Once you have a working serial port then move on to the device.
Guys, thanks for all the help! Managed to get everything working and first observation is that this setup is way more stable than my Zigbee2MQTT (with cc2531) integration. Couple of tips/notes for people who stumble upon this thread:
- As mentioned by Berend, Connect GND to GND, TX to RX, RX to TX and VCC to VCC (3V).
- Regarding the serial console, I’ve used Minicom (useful started guide). You can disable hardware and software flow in the configuration.
- You need to run Paul’s script with
python3(or higher). - Robert’s post seems to be very important, pairing devices became significantly easier when the gateway was on channel 11 and TX power was set to 18.
- In order to get Aqara and Lidl remotes to work with clicks/actions/etc, you need to analyze events in HA. This guide did the trick.
Thanks again guys!
2 Likes
Nice summary.
Should I connect the Vcc pin to my serial port?
In general, I would recommend not connecting Vcc on a USB serial port unless, for some well-known and documented reason, it’s required by your serial port. There are a couple of reasons for this:
-
On some of those USB-to-Serial port devices, Vcc can be at +5V. If you connect that by accident to a 3.3V device there’s a good chance you’ll break your device and let out the magic smoke!
-
Even if it’s the correct voltage, it’s usually a bad idea to shove power into a PCB without making sure that it’s designed to be powered that way. At best it’ll work anyway, at worst you’ll let out the magic smoke and it’s usually not required anyway so best not risk it.
Debugging ports (JTAG, et al) are a little different - they often use the Vcc pin as a reference - but if you’re using those you probably already know that.
I hope that’s helpful for those starting out in the world of device hacking.
1 Like
It’s a great difference from CC2530/31’s that’s for sure.
But it’s hard to beat Zigbee2MQTT with CC2652R (zzh! from Electrolama).
Nice summary!
Only thing I did different was powering the device from the USB, it allowed me to reboot it faster and easier, rather than pulling one wire and coming all out 
Thanks @bool2 very inspiring
1 Like
Did anybody try to update the flash using the guide in this PR: https://github.com/banksy-git/lidl-gateway-freedom/pull/5/files ? I can’t get the LIDL doorbell to generate notifications in HA and I’m hoping this will fix it.
Note: I also had issues generating the ESC key in the serial console because of the 3.3v connected to the USB to SERIAL bridge. Disconnecting the 3.3v pin fixed this.
Author of the PR here. I have been running the new firmware for about a day now, and everything seems to be working flawlessly. I can’t rule out any potential problems, but it seems promising so far.
I would be very interested in feedback on the script, and whether it also works for some of you guys. If it doesn’t for some reason, I will update it asap.
As far as the LIDL doorbell goes, I am pretty sure this is not supported by ZHA yet. Someone requested support for it here: https://github.com/zigpy/zha-device-handlers/issues/759.
Hello, @Ordspilleren
Thanks and good job on upgrading the firmware,
I tested but I don’t understand what’s going on
$ ./firmware_upgrade.sh 192.168.10.53 2333 NCP_UHW_MG1B232_678_PA0-PA1-PB11_PA5-PA4.gbl
[email protected]'s password:
[email protected]'s password:
[email protected]'s password:
Sending /tmp/firmware.gbl, 1434 blocks: Give your local XMODEM receive command now.
Xmodem sectors/kbytes sent: 0/ 0kRetry 0: Got a1 for sector ACK
Retry 0: NAK on sector
Retry 0: Got a1 for sector ACK
Retry 0: NAK on sector
Retry 0: Got a1 for sector ACK
Retry 0: Timeout on sector ACK
Retry 0: Timeout on sector ACK
Retry 0: Timeout on sector ACK
Retry 0: Timeout on sector ACK
Retry 0: Timeout on sector ACK
Retry 0: Timeout on sector ACK
Retry 0: Timeout on sector ACK
Retry 0: Timeout on sector ACK
Retry 0: Retry Count Exceeded
Transfer incomplete
Successfully flashed new EZSP firmware! The device will now reboot.
Can you try the version of the script in this commit instead? The process is a bit different and requires a third-party Python tool. You might also have to change the SSH port in the script.
If this works, it means that the current script can’t enter the bootloader correctly on the stock gateway, so I might have to revert to the old method.
EDIT: I found the problem. I have updated the script and guide accordingly. Please try this new version, hopefully it works
Thanks for your work and clear explanations. It seems the sure way to go is to use zigbee2mqtt instead of the ZHA; however, I’m not sure I can integrate it with the current serial bridge, do you have this info?
Another approach will be to try and do a PR in ZHA and HA, do you have experience with this? Wondering if there is a straightforward template explaining this to become few hours or it is a maintainer task only?
I do not understand, I tried again and it works very well, mystery!
Thank’s for your contribution @Ordspilleren 
Sending /tmp/firmware.gbl, 1434 blocks: Give your local XMODEM receive command now.
Bytes Sent: 183680 BPS:6710
Transfer complete
Manufacturer:
Board name:
EmberZNet version: 6.7.8.0 build 373
Sounds great! In the meantime I found a possible cause for the problem you experienced. I have updated the script and guide accordingly.
@stefand Unfortunately, I don’t have experience with adding new ZHA devices.