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.
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:
python3 (or higher).Thanks again guys!
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.
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
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.
Can you give a correct link to the update script?
And as far as I understood, ZHA integration on HA should be disabled during this procedure.
The latest are here:
You’ll need firmware_upgrade.sh and sx (plus the firmware file which needs to be downloaded separately). By the looks of it, the script will try and kill the serialgateway process that it used for the ZHA integration, so you shouldn’t have to disable the integration itself.
Got a new adapter. Now it is working.
Grabbed the root passwort and followed the guide.
Thanks for help.
Thank you very much @bool2 !
This is a very elegant and efficient hack. I managed to instantly free my Silvercrest Gateway using your method.
Now that i have this kind of network ZigBee gateway at hand (I actually have two), the thing I’m terribly missing is to be able to use 2 gateways (same LAN, different IPs) to configure two different ZigBee networks (on a sungle Home Assistant instance) : One for my flat (2nd floor) and one for my basement workshop/studio (underground) which are both linked with gigabit Ethernet but obviously not close enough to use one single ZigBee network/mesh.
From what I understand, this is a limitation in the Home Assistant zha implementation. IMHO, this would be a very powerful feature to have. I understand the feature doesn’t sound so critical considering most configurations use a USB ZigBee coordinator but with such a network enabled gateway, it just seems like it’s really a missing feature.
When using HA’s Xiaomi ZigBee Gateway integration, this is a built-in feature : I have two Xiaomi gateways, they both appear under the integration and have their “child” devices beneath them.
Thanks again for the brilliant work @bool2 !
Can anyone who has used this device comment on the latency?
I was considering it for light dimming and I need to know if the lights could be dimmed without any perceptible delay.
Really I am asking because from reading through the above it looks like the hub is integrated into HA by way of a serial to ethernet conversion on the HA side and the reverse on the hub and I wonder if that would introduce delay compared to a usb Zigbee device plugged directly into the HA server (which was what I was thinking of doing).
The reason a delay would matter to me is I would be driving this from digital input on an ESPHome device and I want to get the dimming while holding the button and stop when released, any perceptible delay would result in the light dimming past what was intended.
I will prob just give it a go anyway but would be nice if anyone had a view on it.
Thanks