Are you sure the gateway is in the same subnet?
You should use the connection: socket://ipaddress:8888 softwareflow / 115200 baudrate
on the gateway terminal connection you can see some logging when serialgateway starts.
Just a tip - dumping is much faster over TFTP. For that:
- set host ip to 192.168.1.1
- connect the gw by UART and ethernet, gw addr would be 192.168.1.6
- get into the bootloader prompt
- enter
flr 80000000 <hex flash offset> <hex length> - read the file on your host with
atftp -g -r test 192.168.1.6
It works because FLR command automatically exposes the loaded data over TFTP. Offsets and sizes for your convenience:
dev: size erasesize name offset
mtd0: 00020000 00010000 "boot+cfg" 0
mtd1: 001e0000 00010000 "linux" 20000
mtd2: 00200000 00010000 "rootfs" 200000
mtd3: 00020000 00010000 "tuya-label" 400000
mtd4: 00be0000 00010000 "jffs2-fs" 420000
1 Like
So damn me, the gateway was not working.
I tried everything again after you said the thing about the subnet(it is in a different subnet than ZHA, ZHA/HA is in docker subnet and the gateway in normal network) But something happened and now it is working. Lightbulbs are connecting.
Only the remote is not connecting yet(HG08376) so that will be a search how to get that working. But this is a step in the right direction already!
This fails for me, even tried disabling the commands over ssh, loged in on the ssh ports, ran all the commands local. No fix.
# ls -la
drwxr-xr-x 2 root 0 0 Jan 1 00:02 .
drwxr-xr-x 10 root 0 0 Jan 1 00:00 …
-rw-r–r-- 1 root 0 9304 Jan 1 00:02 firmware.gbl
-rw-r–r-- 1 root 0 222542 Jan 1 00:02 sx
# chmod +x /tmp/sx
# killall -q serialgateway
# stty -F /dev/ttyS1 115200 cs8 -cstopb -parenb -ixon crtscts raw
# echo -en ‘\x1A\xC0\x38\xBC\x7E’ > /dev/ttyS1
# echo -en ‘$CONFIGURATION_FRAME’ > /dev/ttyS1
# echo -en ‘\x81\x60\x59\x7E’ > /dev/ttyS1
# echo -en ‘\x7D\x31\x43\x21\x27\x55\x6E\x90\x7E’ > /dev/ttyS1
# stty -F /dev/ttyS1 115200 cs8 -cstopb -parenb -ixon -crtscts raw
# echo -e ‘1’ > /dev/ttyS1
# /tmp/sx /tmp/firmware.gbl < /dev/ttyS1 > /dev/ttyS1
Sending /tmp/firmware.gbl, 72 blocks: Give your local XMODEM receive command now.
Xmodem sectors/kbytes sent: 0/ 0kRetry 0: Timeout on sector ACK
Retry 0: Timeout on sector ACK
Retry 0: Timeout on sector ACK
ssh -oHostKeyAlgorithms=+ssh-dss root@yourip
does that work?
Does anyone has the default zigbee chip firmware to restore the gateway to default and use it with the cloud again ?
i cant “extract” the root pw it always says
Traceback (most recent call last):
File “C:\lidl_auskey_decode.py”, line 35, in
from crypto.Cipher import AES
ModuleNotFoundError: No module named ‘crypto’
i cant encrypt the key because the script dont work… but “crypto” is installed!!
@Chellux
I also had this, I believe the solution was to install PyCryptoDome. If I check my python venv for all the installed packages I get the following list, so with those packages the script should work:
Package Version
------------------ ----------
certifi 2023.11.17
charset-normalizer 3.3.2
crypto 1.4.1
idna 3.4
Naked 0.1.32
pip 23.3.1
pycryptodome 3.19.0
PyYAML 6.0.1
requests 2.31.0
setuptools 65.5.0
shellescape 3.8.1
urllib3 2.1.0
Thanks Paul, great work. I Cold easily follow your instructions, gained root access on the box.Box
I have trouble with sending your bin file via ssh. The error message is:
unable to negotiate with 192.168.x.x (the lidl box)
No matching host key type found. Their offer: ssh-rsa ssh-dss
Any clue what I can do to overcome this?
Modern ssh versions are stricter about the algorithms they will accept, and the router is using a less secure algorithm version.
Given that you own the device and the network, you can assume that this is not a big security issue and tell ssh to allow the old protocol:
ssh -o "HostKeyAlgorithms +ssh-rsa" zigbee-gw
You can add that into your ssh config file so it is used every time you connect to that hostname:
Host zigbee-gw
HostKeyAlgorithms +ssh-rsa
(replace zigbee-gw with the name or address of your router)
Thanks Chris, will give it a try this evening and “report” back
Great, big Thanks .
it worked as described
1 Like
I cost me hours today but I got, so I will you give 2 essential tips:
- to get to the bootloader prompt i any case
Do not supply the power via the 3,3V from the FTDadapter. Use a second cable to the micro USB connector
Connect your terminal to the device, unplug the power, press the ESC button, connect the power and release the ESC Button when you see the fist boot lines
- to be shure you get the right data for password recovery script
If you enter the FLR command be shure get a prompt for yes no and you have to type yes, If your terminal does something and you have not to type anything, you will get wrong data, use another terminal
Rainer
I’ve been following this guide as I’d like to get this device working with Zigbee2MQTT and I can get as far as Step 8 before running into issues. It’s working with ZHA as expected on port 8888 but trying to run the bellows script fail to connect (as shown below). Any support appreciated.
File "/usr/lib/python3.11/asyncio/selector_events.py", line 674, in _sock_connect_cb
raise OSError(err, f'Connect call failed {address}')
OSError: [Errno 113] Connect call failed ('192.168.1.106', 8888)
Edit: I noticed the errors were changing occasionally and so I fired the bellows info command 3-4 times and it eventually worked. Despite my better judgement I did the same with the firmware update which dropped a couple errors before finally working. All is now up-to-date and working well.
This was a very easy hack…if the serial to TTL adapter works 
However, I have 2 different models v1.0.2 and 2.0.1 (USB-C).
The older version shows up as a Tuya gateway immediately when it goes live but the USB-C version does not. I have not hooke up any of them fully in HA yet as i already have one Zigbee USB stick in the server and you can’t run two of them at the same time in the same system.
Both loads the serial server and the same applications are running in the background when I run “ps” but this behaviour in HA was different between the 2 units. They both were updated to latest Lidl firmware before the hack was applied and the version numbering was the same for both models…
Let’s see if both works when I get to my second location (in the end of the month) that is going to run one of these permanently.
The instruction is for a linux machine.
If you run windows then run this in a command prompt to install the missing crypto library.
py -m pip install pycryptodome
Another change in the writeup, if you run windows, is the “cat” command for the upload of the serial gateway binary, that shall look like this:
type serialgateway.bin | ssh -p2333 [email protected] “cat >/tuya/serialgateway”
Hi,
Can You (or anyone) share used programs and settings for serial connection. I have similar problem and I have tried couple of tools with Linux and Windows. With two USB-serial adapters (and 2 cables) I have also tried different speeds. I bought that gateway couple of months ago, but at least layout of PCB looks same as in pictures in hacking guides. Just thinking if COM settings are changed during time?
I used Putty for the serial comms.
Open device manager COM-section every time you plug in the RS232 to TTL converter to see which port to use. It may jump around…
Confirmed: Also the latest model with USB-C (v2.0.1 motherboard) works in HA after this hack.
I don’t know if I’m doing anything wrong but I have hacked the hub and have root access with the password. I can SSH into the gateway hub and open serial terminal.
When I use the Home Assistant app to log in to the gateway it wont connect, I can see in the serial terminal that it gets connected but then after a couple of seconds I get “Closing existing connection” in the serial terminal.
If I try to log in via browser with “ipaddress:8888” it just keeps on loading and loading but nothing happens, here I also see a connection in the serial terminal.
Any ideas? Or should I just buy a zigbee dongle and use my old small pc to host a HA server?
EDIT:
otherwise if anyone know how to reset everything back so i can use tuya/lidl app again