Problem with deconz on openhabian

Hi all,

it´s my first post here, so at first sorry, if I miss something.

I used deconz with raspbee 2 on openhabian without problems - until yesterday.
We had a power breakdown, and after reboot openhabian won´t find the deconz-gateway. By checking the service, I got this:

openhabian@openhabian:/tmp $ sudo /bin/systemctl start deconz.service
openhabian@openhabian:/tmp $ sudo /bin/systemctl status deconz.service
● deconz.service - deCONZ: ZigBee gateway – REST API
Loaded: loaded (/lib/systemd/system/deconz.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: signal) since Thu 2024-02-08 12:15:43 CET; 8s ago
Process: 2780 ExecStart=/usr/bin/deCONZ -platform minimal --http-port=8081 --ws-port=8081 (code=killed, signal=ILL)
Main PID: 2780 (code=killed, signal=ILL)
CPU: 964ms

I suppose, that “code=killed, signal=ILL” isn´t so good?

What had I done to solve this?

  • stop and start service (more than one time)
  • remove and new install of deconz
  • new install of raspbee 2, as described here on phoscon.de
  • searching on internet without success

Do you have a hint for me, what´s going wrong here?

Best wishes and thank you

Veikko

No idea, but you can try to launch deconz in command line, with debug enabled > deCONZ command line parameters · dresden-elektronik/deconz-rest-plugin Wiki · GitHub

It’s not the same error message, but you are sure you haven’t 2 deconz instance ? the headless + the desktop one ?

You haven’t an old zigbee backup ? if the problem is caused by a problem in database.

Else need to get more information from crash report.

Hi Smanar,

thanks for your answer.

Trying deCONZ running in debug-mode goes to

openhabian@openhabian:~ $ /usr/bin/deCONZ --dbg-info=2 > debug.txt
qt.qpa.xcb: could not connect to display
qt.qpa.plugin: Could not load the Qt platform plugin “xcb” in “” even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb.

Aborted

I don´t understand the message. What application I have to reinstall?

I think, that I don´t have 2 deconz instances. There is no desktop on the raspberry pi. How could I check this?
Can this command make it clear?

openhabian@openhabian:~ $ ps -ef | grep deconz
openhab+ 28075 27399 0 19:07 pts/0 00:00:00 grep --color=auto deconz

Of course I make automated backups every week as described in openhabian manual. I tried to restart it from the backup - raspberry didn´t did anything :-(. No message, no possibility to connect via ssh. Murphys law, I think.

Have a nice evening.

Veikko

It’s because you are trying to run the desktop mode, add -platform minimal

/usr/bin/deCONZ -platform minimal --dbg-info=2 --dbg-error=2

Sorry, I should have said first.
I don’t think you have 2 deconz instances running according to your request, generaly we are checking both service

$sudo systemctl status deconz
$sudo systemctl status deconz-gui

But you have nothing running on your host ATM.

By backup I mean “zigbee network backup” using phoscon, to restore the zigbee database if this one was corrupted.
But now afer reflexion, it’s something to try, when you have removed deconz, you have removed the database too ?

Your raspbee is reconised ?

GCFFlasher_internal -l

Hi Smanar,

here the last page of deCONZ in debug-mode. Hope it helps.

11:50:01:965 DB PRAGMA freelist_count: 0
11:50:01:966 DB file size 188416 bytes, free pages 0
11:50:01:966 DB PRAGMA user_version: 9
11:50:01:966 DB cleanup
11:50:01:966 DB create temporary views
11:50:01:967 DB view [0] created
11:50:01:967 DB view [1] created
11:50:01:967 DB view [2] created
11:50:01:968 DB view [3] created
11:50:01:968 sql exec SELECT apikey,devicetype,createdate,lastusedate,useragent FROM auth
11:50:01:968 sql exec SELECT key FROM config2
11:50:01:968 sql exec SELECT key,value FROM config2
11:50:01:968 sql exec SELECT key,value FROM userparameter
11:50:01:968 sql exec SELECT * FROM groups
11:50:01:968 sql exec SELECT * FROM resourcelinks
11:50:01:968 sql exec SELECT * FROM scenes
11:50:01:968 sql exec SELECT * FROM rules
11:50:01:969 sql exec SELECT * FROM schedules
11:50:01:969 sql exec SELECT * FROM sensors
11:50:01:969 sql exec SELECT * FROM gateways
11:50:01:999 [INFO] - Setting environment variable ‘TZ=:/etc/localtime’…
11:50:01:000 sql exec SELECT sid FROM sensors
11:50:01:001 Started websocket server on 0.0.0.0, port: 443
11:50:01:002 create default username and password
11:50:01:004 [INFO] - Found file containing button maps. Parsing data…
11:50:02:022 [INFO] - Button maps loaded.
11:50:02:024 found node plugin: /usr/share/deCONZ/plugins/libde_rest_plugin.so - REST API Plugin
11:50:02:026 OTAU: image path does not exist: /root/otau
11:50:02:026 found node plugin: /usr/share/deCONZ/plugins/libstd_otau_plugin.so - STD OTAU Plugin
11:50:02:082 dlg action: Read binding table
11:50:03:055 COM: /dev/ttyAMA0 : : (0x0000/0x0000)
11:50:03:055 COM: /dev/ttyS0 : : (0x0000/0x0000)
11:50:03:055 dev /dev/ttyS0 (/dev/ttyS0)
11:50:03:056 auto connect com /dev/ttyS0
11:50:03:057 UPNP socket not bound, state: 0
11:50:04:226 API error 1, /, unauthorized user
This plugin does not support propagateSizeHints()
11:50:04:665 [Master] read param with arg 0x18
11:50:04:665 [Master] read param with arg 0x13
11:50:04:665 [Master] read param with arg 0x13
11:50:04:665 [Master] read param with arg 0x13
11:50:04:725 COM: /dev/ttyAMA0 : : (0x0000/0x0000)
11:50:04:725 COM: /dev/ttyS0 : : (0x0000/0x0000)
11:50:04:725 dev /dev/ttyS0 (/dev/ttyS0)
11:50:04:725 Device firmware version 0x26690700 RaspBee II
Illegal instruction

Systemctl:
openhabian@openhabian:~ $ sudo systemctl status deconz
● deconz.service - deCONZ: ZigBee gateway – REST API
Loaded: loaded (/lib/systemd/system/deconz.service; enabled; vendor preset: enabled)
Active: inactive (dead) (Result: signal) since Thu 2024-02-08 19:01:29 CET; 1 day 16h ago
Process: 27816 ExecStart=/usr/bin/deCONZ -platform minimal --http-port=8081 --ws-port=8081 (code=ki>
Main PID: 27816 (code=killed, signal=ILL)
CPU: 961ms

openhabian@openhabian:~ $ systemctl status deconz-gui
● deconz-gui.service - deCONZ: ZigBee gateway – GUI/REST API
Loaded: loaded (/lib/systemd/system/deconz-gui.service; disabled; vendor preset: enabled)
Active: inactive (dead)

Feb 10 11:47:20 openhabian systemd[1]: /lib/systemd/system/deconz-gui.service:11: Unknown key name 'Sta>
Feb 10 11:52:33 openhabian systemd[1]: /lib/systemd/system/deconz-gui.service:11: Unknown key name 'Sta>

/REST API
service; disabled; vendor preset: enabled)

system/deconz-gui.service:11: Unknown key name ‘StartLimitIntervalSec’ in section ‘Service’, ignoring.
system/deconz-gui.service:11: Unknown key name ‘StartLimitIntervalSec’ in section ‘Service’, ignoring.

(sorry for bad format. I´m not so familiar with linux command line.)

And GCFFlasher:

openhabian@openhabian:~ $ GCFFlasher_internal -l
no devices found
Path | Serial | Type
------------------±------------±--------------

Have a nice weekend and thanks for your help!

Veikko

Hi, which platform is this, 32-bit or 64-bit Raspberry Pi?
Also which version of deCONZ?

There were a few SIGILL bugs in the past but to my knowledge these are all fixed in recent versions.

And it seem the OS don’t see the Raspbee ?

openhabian@openhabian:~ $ GCFFlasher_internal -l
no devices found

Are you sure about your serial configuration ?

Good morning,

referred to the openhabian documentation, it is 64-bit.

openhabian@openhabian:~ $ dpkg -s deconz
Package: deconz
Status: install ok installed
Priority: optional
Section: non-free / misc
Installed-Size: 37560
Maintainer: Manuel Pietschmann mpi@dresden-elektronik.de
Architecture: armhf
Version: 2.25.3
Depends: libqt5core5a, libqt5network5, libqt5widgets5, libqt5gui5, libqt5serialport5, libqt5websockets5, libqt5sql5, libqt5qml5, libcap2-bin, sqlite3, lsof, curl
Suggests: udev
Description: Zigbee monitoring and control.

Serial configuration:
I did as described on phoscon.de:

  1. Zugriffsrechte der seriellen Schnittstelle für Nutzer setzen
 sudo raspi-config

Interface Options → Serial Port

  • Would you like a login shell accessible over serial? → No
  • Would you like the serial port hardware to be enabled? → Yes

Hinweis: Die Zugriffsrechte werden erst nach einem Neustart aktiv.

┌──────────────────────────────────────────────────────────┐
│ │
│ The serial login shell is disabled │
│ The serial interface is enabled │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
└──────────────────────────────────────────────────────────┘

So I suppose, the OS should see the Raspbee??

Veikko

Huu, yes, It can’t explain the crash, but you need to see the raspbee using

# GCFFlasher_internal -l
GCFFlasher V3_17 (c) dresden elektronik ingenieurtechnik gmbh
Path             | Vendor | Product | Serial     | Type
-----------------+--------+---------+------------+-------
/dev/ttyAMA0     | 0x0000 | 0x0000  |            | RaspBee 

You just have a power break ?
Can try the reboot request to test

sudo GCFFlasher_internal -r

openhabian@openhabian:~ $ GCFFlasher_internal -r RaspBee
missing -d argument
openhabian@openhabian:~ $ GCFFlasher_internal -r -d RaspBee
command reset timeout
openhabian@openhabian:~ $ GCFFlasher_internal -l
no devices found
Path | Serial | Type
------------------±------------±--------------
openhabian@openhabian:~ $ GCFFlasher_internal -r -d /dev/ttyAMA0
command reset timeout
RaspBee reset failed
openhabian@openhabian:~ $ GCFFlasher_internal -l
no devices found
Path | Serial | Type
------------------±------------±--------------
openhabian@openhabian:~ $

So I did some tries without success :-/.
Is it possible, that the OS has a problem with ALL devices? Maybe this could explain, that the automated backup doesn´t run?

Veikko

What are you calling all device ?
But yes an issue on the OS itself is more probable than something break on the Raspbee after a simple power break

“all devices”

To summarize my observations:

  • deconz-Service don´t run and can´t be started.
  • As I recognized today, other services don´t run, too (I found it for frontail.service (web-based log-viewer). It don´t run, it can´t be started.
  • Openhabian itself is running without problems.
  • Automated backups didn´t work (see description some posts before). I´m not able to find a mount point for the backup-SD. I know, that some months ago a start from the backup wasn´t a problem, but now it is.
  • Raspbee isn´t recognized from the OS.

Because of this observations, I suppose, there could be a general problem with device handling. Please don´t blame me, if I am wrong. I´m more an end user on linux.

I don´t want to make a new install of openhabian, because I learned, that on linux all problem could be solved :-). But I´m ending with ideas :-(.

Veikko

And hard to test the raspbee without a second Raspberry.
Your OS on SD card or SSD ? to try fastly with a fresh OS ? On another SD card ofc.

Can you try a connection test with following command:

GCFFlasher_internal -d /dev/serial0 -c

If it works it should print out some packets that are received from the firmware.
Note that deCONZ must not be running while doing this.

(The /dev/serial0 should be a symlink to the /dev/ttyS0 device name)

Hi Smanar and manup,

OS is on SD-Card. I have another SC-Card available, so a fresh OS could be an alternative. But I´m frightening for configuring openhabian again :-). But to say it clearly - it would be possible.

openhabian@openhabian:~ $ GCFFlasher_internal -d /dev/serial0 -c
packet: 8 bytes, 0701000800AA0000
packet: 8 bytes, 0702000800AA0000
packet: 8 bytes, 0703000800AA0000
packet: 8 bytes, 0704000800AA0000
packet: 8 bytes, 0705000800AA0000
packet: 8 bytes, 0706000800AA0000
packet: 8 bytes, 0707000800AA0000
packet: 8 bytes, 0708000800AA0000
packet: 8 bytes, 0709000800AA0000
packet: 8 bytes, 070A000800AA0000
packet: 8 bytes, 070B000800AA0000
packet: 8 bytes, 070C000800AA0000
packet: 8 bytes, 070D000800AA0000
packet: 8 bytes, 070E000800AA0000
packet: 8 bytes, 070F000800AA0000
packet: 8 bytes, 0710000800AA0000
packet: 8 bytes, 0711000800AA0000
packet: 8 bytes, 0712000800AA0000
packet: 8 bytes, 0713000800AA0000
packet: 8 bytes, 0714000800AA0000
packet: 8 bytes, 0715000800AA0000
packet: 8 bytes, 0716000800AA0000
packet: 8 bytes, 0717000800AA0000
packet: 8 bytes, 0718000800AA0000
packet: 8 bytes, 0719000800AA0000
packet: 8 bytes, 071A000800AA0000
packet: 8 bytes, 071B000800AA0000
packet: 8 bytes, 071C000800AA0000
packet: 8 bytes, 071D000800AA0000
packet: 8 bytes, 071E000800AA0000
packet: 8 bytes, 071F000800AA0000
packet: 8 bytes, 0720000800AA0000
packet: 8 bytes, 0721000800AA0000
packet: 8 bytes, 0722000800AA0000
packet: 8 bytes, 0723000800AA0000
packet: 8 bytes, 0724000800AA0000
packet: 8 bytes, 0725000800AA0000
packet: 8 bytes, 0726000800AA0000
packet: 8 bytes, 0727000800AA0000
packet: 8 bytes, 0728000800AA0000
packet: 8 bytes, 0729000800AA0000
^C
openhabian@openhabian:~ $

I breaked it here. It lasts some seconds from one line to the next, so for the output it lasts ca. 10 minutes.

Thanks for your help.

Veikko

The output looks correct and communication between GCFFlasher and RaspBee works.
Could it be that OpenHab is not configured to use the right device path?

Good morning,

how can I find out, which device path OpenHab uses?
My observations:

  • Until power lost OpenHab worked correctly - no problems with RaspBee. I could use a connected power switch. Reading and setting commands: both worked.
  • After the power lost I couldn´t reconnect to the RaspBee.
  • I tried to make a new installation of RaspBee (as described here on phoscon), and I made a new installation of the deconz-binding (via Openhabian-Config).
  • I don´t realized errors in logs or so on (Maybe I didn´t watched the right places?).
  • Raspbee isn´t recognized (see above).

As Smanar wrote, that testing a raspberry without a second raspberry is hard: Could it help to use a Linux-virtual-machine on a windows host?

Veikko

You can try to run deconz with a specified device path

/usr/bin/deCONZ --dev=/dev/serial0 -platform minimal

Hm, no success:

openhabian@openhabian:~ $ sudo /usr/bin/deCONZ --dev=/dev/serial0 -platform minimal
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to ‘/tmp/runtime-root’
libpng warning: iCCP: known incorrect sRGB profile
This plugin does not support propagateSizeHints()
This plugin does not support propagateSizeHints()
This plugin does not support propagateSizeHints()
Illegal instruction
openhabian@openhabian:~ $

Veikko

Hmm dang that’s weird, there should be no illegal instruction fault in v2.25.3 :thinking:

This can only debugged via GDB. I’d would be super helpful if you can debug with the following commands:

sudo apt install gdb

gdb --args deCONZ --dev=/dev/serial0 -platform minimal

GDB opens and loads deCONZ, now type:

r and hit enter (r means run)

deCONZ should now crash as above…

Type bt and hit enter, this gives us a backtrace where we should see what crashes.