After a reinstall of an original Pi Zero with Trixie, the RaspBee II isn’t reliably detected. It worked fine until reinstalling. Phoscon says “Firmware Not connected”. Firmware is the latest.
sudo GCFFlasher_internal -l Path | Serial | Type ------------------+-------------+--------------- /dev/ttyAMA0 | | RaspBee
…is in /boot/firmware/config.txt (even though the Zero v1 doesn’t have BT). Serial login shell is set to no and serial port hardware is set to enabled.
Only one service is running. I’m running the system headless.
So the hardware is actually working, the non-visible serial number in the console is not an error, and the problem is probably related to me trying to restore the zll.db database manually after the Phoscon upload wasn’t working at all.
And debugging tells me, when restoring the “new” (empty) zll.db and then trying to import the old backup, that the reason it didn’t work is that I’m getting a segmentation fault when trying to import:
21:53:27:162 neighbor 0xCC86ECFFFEBC0C33 is unknown child 21:53:27:232 neighbor 0x00158D0006B22A01 is unknown child 21:53:27:302 neighbor 0x00158D00078D6A7B is unknown child 21:53:27:372 neighbor 0x00158D0007903F18 is unknown child 21:53:27:589 CTRL skip creating node 0xCC86ECFFFEBC0C33 while permit join is disabled 21:53:28:068 CTRL skip creating node 0x00158D0006B22A01 while permit join is disabled Segmenteringsfel
(“Segmenteringsfel” is Swedish for “Segmentation fault”)
Purged the deconz-qt6 package and removed all config, reinstalled, and re-imported the backup. Segmentation fault again and the preceding lines are not related, I guess.
If you restart from scratch, without using your backup (It’s the backup created with Phoscon ?), all is fine, the firmware number is visible on Phoscon ?
It’s not a new Raspbee, you have just updated the OS ?
What is your actual deconz version ? (Some old version have the Segmentation fault)
So on clean installation, all is working, and you loose the “firmware number” in phoscon after installing your backup ?
For information inside the backup (it’s just an archive) you have the network setting, but this is stored too on the gateway, so if you keep the same, it will be unchanged, and the device database (the zll.db file)
Honneslty I have doubt on your database backup status.
I have never see issue with user using a backup from another deconz version yet. Even if the Segmentation fault need to be avoided by the software.
How many device have you ? Not another backup to test ?
No, you can ignore the first couple of posts (which likely stemmed from me trying to move the database manually). The problem now is a segmentation fault in the import of the old backup.
The backup DAT file (which in reality is a zip) is structurally OK and the TAR inside too. The JSON file inside that also looks OK, so that leaves the SQLite database integrity; however, it passes a PRAGMA integrity_check so it’s fine, too. At least structurally.
I don’t have another backup and the controller is in a different physical location which makes it awkward to re-pair the (very few) devices, which otherwise would have been the natural “fix”. However I’m guessing the import shouldn’t segfault in any circumstances
It should be possible to just replace the zll.db with the backup, but then the “networkKey” (and possibly “tcLinkKey”?) present in the JSON needs to be put in… somewhere. Can’t find the code for the import on github though.
No, there is no problem, you can replace only this file.
networkkey and tcLinkKey are network setting, so stored in the ini file in the backup, and stored direclty in the gateway.
Sometime thoses setting can be corrupted too, but they primarily cause connection problems.
For the moment you are alone on this version, perhaps it can be easier to remove a part of the zll.db file to avoid the issue and not restart from scratch ?
