Yes, that’s the added checksum so make sure you’re writing those extra 2 bytes to flash too! Your FLW command above is 2 bytes short i.e. 000E1000 shoud be 000E1002
You can validate the checksum with this :
python rootfs_tool.py check newroot.bin
It should also work on rootfs.bin.
Thank you very much, you are my life saver. I just write the flash with 2 bytes more and it works!.
Hello,
I’m having an issue upgrading my device ncp firmware. I got the device from aliexpress and there all kind of issue to resolve. I’m now successfully got root access to the device and installed serialgateway. my device firmware is not quite as same as people in this thread yet it is similar in nature. I have to dump flash and rebuild rootfs then write back into the device’s flash inorder to get access to device’s root.
now I’m try to upgrade the ncp firmware but seem my ncp firmware is not EmberZNet version 6.5.0.0 but it is EmberZNet version: 6.2.3.0 build 204
bash-5.0# bellows -d socket://172.16.1.167:8888 info
[08:6b:d7:ff:fe:d3:19:87]
[0x0000]
[<EmberNetworkStatus.JOINED_NETWORK: 2>]
[<EmberStatus.SUCCESS: 0>, <EmberNodeType.COORDINATOR: 1>, EmberNetworkParameters(extendedPanId=8b:c0:51:2d:a2:d1:dc:6e, panId=0x5b9b, radioTxPower=13, radioChannel=20, joinMethod=<EmberJoinMethod.USE_MAC_ASSOCIATION: 0>, nwkManagerId=0x0000, nwkUpdateId=0, channels=<Channels.ALL_CHANNELS: 134215680>)]
[<EmberStatus.SUCCESS: 0>, EmberCurrentSecurityState(bitmask=<EmberCurrentSecurityBitmask.TRUST_CENTER_USES_HASHED_LINK_KEY|64|32|HAVE_TRUST_CENTER_LINK_KEY|GLOBAL_LINK_KEY: 244>, trustCenterLongAddress=08:6b:d7:ff:fe:d3:19:87)]
Manufacturer:
Board name:
EmberZNet version: 6.2.3.0 build 204
I try your script to upgrade the firmware with no sucess
bash-5.0# ./firmware_upgrade.sh 172.16.1.167 22 V7 ncp_firmware.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
Successfully flashed new EZSP firmware! The device will now reboot.
although the message shown sucess but bellows -d still show EmberZNet version: 6.2.3.0 build 204
Are there anything need to change on the upgrade process as it is not the same as from 6.5.5 to 6.7.8
*** Edit for Solution ***
@Ordspilleren I Alread upgrade it to 6.7.8 using upgrade_ncp.py. your script some how not work on my device not sure why but I did try it several times with no luck.
Thanks BTW.
Thanks anyway
Is it possible to re-flash the roots flash dump back to the device with the same process to flash new root fs on to the device. It seem my device having a really old version of the firmware and may r it’s software too. One ncp firmware still at 6.2.3 while people here got 6.5.5 as preloaded firmware. My ssh do not on port 2333 as you mentioned in the guide but instead at port 23 as standard ssh. What is the FLW command I may use to write the roots.bin back to the device. I will try to pair my device to the cloud to get updated version before freeing it from the cloud later
*** Edit for Solution on upgrade ncp firmware ***
I try your python scritpt upgrade_ncp.py and it works first try.
Thanks you. I will not upgrade my device image from tuya cloud so thanks anyway
Quick update from my Silvercrest experience:
Up until about a month ago I was running on a separate OS/Hassio combo (wanted to run stuff from a SSD on a PI3+ and at that time this was not properly supported).
The Silvercrest hack was executed as described and stuff started to work, but ONLY using Bellows. Not all devices were able to join properly however like the Xiaomi Lux device (I got it to join, but it did not work as expected).
So last month I switched to a Out-of-the-box HomeAssistant installation and voilá, no more issues!
My advise if you are not yet running a clean HomeAssistant setup and have the hardware to do that: go for a clean setup! Saved me a lot of frustration in the end 
Hello @bool2,
thank a lot for your work, much appreciated !
Here is my feedback after a couple of months running it.
I am experiencing some issues with the serialgateway process stopping working after many days (10, 14 days tipically) which required rebooting the gateway.
Today I had the same issue with ZHA not connecting to the gatweway (connection refused), so I SSH to it and verified that the /tuya/serialgateway process was not running.
After rebooting everything works fine for days.
Have anyone else had this issue? What do you suggest?
Thanks again!
If anyone interested I have solved updating tuya_start.sh in this way:
#!/bin/sh
while true; do
pgrep -x serialgateway >/dev/null
if [[ $? -ne 0 ]] ; then
echo “Restarting SerialGateway: $(date)” >> /var/log/serialgateway.txt
/tuya/serialgateway &
fi
sleep 30
done &
Good idea! My serialgateway restarted yet again this morning. I put in a Homeassistant automation to tell me if one of my devices is unavailable and notify me if that happens.
Great News, i have the key, now i follow the instructions from web page
from the line “## Customise running software on the gateway” onwards, its all double dutch
okay all Ive done it, and it only has taken 6mts.
Hi there!
In case anyone is interested in putting something usefull on the button press, it’s located on GPIO9.
I’ve just exported it using
echo 9 > /sys/class/gpio/export
After that I was able to track button press:
# while true; do cat gpio9/value; sleep 1; done
1
1
0
0
1
1
1
^C
#
i managed to get the root passwd, i can login with the root passwd
ifconfig reveals 192.168.1.42 as ip
but this command doesn’t work:
cat serialgateway.bin | ssh -p2333 [email protected] “cat >/tuya/serialgateway”
ssh: connect to host 192.168.1.42 port 2333: Connection refused
i can ping the gateway:
PING 192.168.1.42 (192.168.1.42) 56(84) bytes of data.
64 bytes from 192.168.1.42: icmp_seq=1 ttl=64 time=0.761 ms
64 bytes from 192.168.1.42: icmp_seq=2 ttl=64 time=0.654 ms
ssh doesn’t seem to be running?
nmap -sT -p- 192.168.1.42
Starting Nmap 7.70 ( https://nmap.org ) at 2021-06-17 13:45 CEST
Nmap scan report for 192.168.1.42
Host is up (0.029s latency).
Not shown: 65533 closed ports
PORT STATE SERVICE
6668/tcp open irc
12130/tcp open unknown
MAC Address: 18:69:D8:30:29:7F (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 35.86 seconds
Have you followed commands from this tutorial?
I just did and everything works.
but this command doesn’t work:
cat serialgateway.bin | ssh -p2333 [email protected] “cat >/tuya/serialgateway”
This command needs to be executed from a Linux/Mac machine which is able to ssh into the gateway. That’s the reason you need to sort out ssh first
PS when you sort out ssh then it is available at the normal ssh port 22
i am running all from a linux machine.
I portscan the ip adress on open ports with nmap, but the ssh port is not open on port 2333.
Thats why the connection is refused
I am getting the following error, can anyone help me? Thank you.
lidl_auskey_decode.py:
UnicodeDecodeError: 'ascii' codec can't decode byte 0x9b in position 0: ordinal not in range(128)
I am having the same issue. I have also run nmap against the device and I see the same 2 ports open as you.
Annoyingly, I did have access via SSH but it seemed to hang as I was transferring the serialgateway.bin across. I rebooted the device and I haven’t been able to access it since.
Do you think it is possible that they performed an OTA upgrade and switched off the SSH server?
I still have serial access and I would be really grateful of any pointers
I’ve just managed to restart the ssh server. Connected via serial, if you run:
cat /tuya/ssh_monitor.sh
you’ll see what looks like a script which puts dropbear to sleep for extended periods of time for each failed login. But at the end there is the command to fire up dropbear again:
/tuya/tuyadropbear -P /var/run/dropbear.tuya.pid -p 2333 -K 300 -T 1
I don’t know enough about these things to know what it does exactly, but I can SSH in again. @daniz - I hope this helps you too.
have already managed to complete the integration, it has been a difficult and long process, but I will be happy to help if I can.
thanks to all.
PD: English is not my native language, I am sorry for the inconvenience.
Hi All,
I have been running flashed lidl gateway for few weeks now. It goes offline every now and then (because I’ve setup an automation if the device goes offline). But The main problem is that I can’t change the Lidl E27 and GU10 bulbs colours. It shows the colour pallet but doesn’t do anything.
I am thinking to revert back to the factory firmware but I didn’t take the backup (for my sins).
Any ideas how to revert back to the lidl firmware?
Cheers