Conbee II und HM-MOD-RPI-PCB

[topcrown]

Hallo,

habe leider in der Suche und durch Lesen von vielen Foreneinträgen weder mein Problem noch die Lösung dafür gefunden. Auch ist es wohl kein eigentliches FHEM-Problem. Da ich aber nicht mehr weiter weiß, dachte ich, ich schreibe mal einen Eintrag, in der Hoffnung, dass jemand vielleicht eine Idee hat.

Verwende FHEM schon seit Jahren erfolgreich und stabil - das ist wirklich das Beste an FHEM  - auf einem raspi 3 mit HM-MOD-RPI-PCB. Möchte nun auch gerne noch auf Zigbee erweitern und habe mir dafür den Conbee II besorgt.
Diesen USB-Stick habe ich nach Anleitung installiert. Er läuft auch und findet Hue-Lampen und XIAOMI-Sensoren, sowohl in deCONZ, als auch in Phoscon. Den Port habe ich auf 8091 geändert.
Unter der IP des raspi3 und des Ports konnte ich es auch erfolgreich in FHEM einbinden und kann dadurch über Alexa auch die HUE-Lampen steuern  , oder in FHEM die XIAOMI-Sensoren loggen.

Aber, das ganze funktioniert nur, so lange ich deCONZ explizit aufrufe und als GUI laufen lasse, also

Code Auswählen Erweitern

/usr/bin/deCONZ --http-port=8091

So bald ich aber deCONZ als Dienst starte, also

Code Auswählen Erweitern

sudo systemctl start deconz
verliere ich in FHEM die Verbindung zu meinem HM-MOD-RPI-PCB, sprich myHmUART:disconnected = 1!

D.h. deCONZ als Dienst belegt, oder schaltet ab(?) den UART, im Gegensatz zu deCONZ als GUI!? 

Für mich sieht bei den Schnittstellen aber alles gut aus:

Code Auswählen Erweitern


pi@raspberrypi:~ $ ls -l /dev/serial*
lrwxrwxrwx 1 root root  7 Dec  1 17:05 /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root  5 Dec  1 17:05 /dev/serial1 -> ttyS0

und

Code Auswählen Erweitern


pi@raspberrypi:~ $ ls -l /dev/serial/by-id/
total 0
lrwxrwxrwx 1 root root 13 Dec  3 18:58 usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2225162-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Dec  1 17:05 usb-SHK_NANO_CUL_868-if00-port0 -> ../../ttyUSB0


Wie gesagt, ist wohl kein eigentliches FHEM-Thema, aber vielleicht kann mir ja jemand einen Tip geben.

Vielen Dank schon mal im Voraus!

[Beta-User]

Vorab mal: Willkommen hier im Forum .

1. Idee: startet denn auch die minimal-Version mit demselben HTTP-Port? Was steht dazu in der service-Datei?

[Darkwing Duck]

Guten Morgen,

hast du den Dienst "deconz-gui" explizit gestoppt, bevor du "deconz" gestartet hast? Je nach Installation kann es sein, dass deconz-gui automatisch läuft (Siehe Doku). Ist nur ein Schuss ins Blaue, ob das mit deinem Problem zusammenhängen kann, überblicke ich nicht, aber das hat mir anfangs auch Kopfzerbrechen bereitet, bis ich kapiert habe, dass das zwei verschiedene Dienste sind.

[Beta-User]

2. Idee: "GUI" klingt auch verdächtig nach Modemmanager. Vielleicht spuckt der dazwischen? (OT-Hinweis: Server und GUI = Pfui! Nicht nur meine Meinung...)

[MadMax-FHEM]

Vorab mal: Willkommen hier im Forum .

1. Idee: startet denn auch die minimal-Version mit demselben HTTP-Port? Was steht dazu in der service-Datei?

Ich denke auch, dass das erst mal geklärt/verifiziert werden sollte...

War auch mein erster Gedanke:

bei manuellem Start wird ja explizit der Port 8091 mitgegeben (und damit versucht sich dann das HUEBridge-Device auch zu verbinden)

bei Start als Service wird (verm.) der Standardport (80) genommen (wenn nicht eben explizit im Start-Script oder anderer Konfiguration eingestellt)


Beim Standardport können dann 2 Probleme auftreten: deCONZ startet gar nicht -> Konflikt mit Apache (oder Apache startet nicht / je nachdem wer "zuerst kommt"   )...

UND: das HUEBridge-Device "findet" natürlich deCONZ nicht unter Port 8091...

Gruß, Joachim

[topcrown]

Vielen Dank, erstmal für den Willkommensgruß! Hatte bisher schon viel im Forum gelesen, aber noch nie selbst was geschrieben.

Und vor allem: Vielen Dank für die sehr schnellen Antworten! 

Zum Problem:

@Beta-User und MadMax-FHEM:

Ja, der Port ist auch bei deconz als Dienst von mir umgestellt:

Code Auswählen Erweitern


pi@raspberrypi:~ $ sudo systemctl start deconz
pi@raspberrypi:~ $ sudo systemctl status deconz
● deconz.service - deCONZ: ZigBee gateway -- REST API
   Loaded: loaded (/lib/systemd/system/deconz.service; enabled)
   Active: active (running) since Fri 2020-12-04 10:30:49 CET; 2s ago
Main PID: 7801 (deCONZ)
   CGroup: /system.slice/deconz.service
           └─7801 /usr/bin/deCONZ -platform minimal --http-port=8091

Dec 04 10:30:49 raspberrypi systemd[1]: Starting deCONZ: ZigBee gateway -- REST API...
Dec 04 10:30:49 raspberrypi systemd[1]: Started deCONZ: ZigBee gateway -- REST API.
Dec 04 10:30:51 raspberrypi deCONZ[7801]: This plugin does not support propagateSizeHints()
Dec 04 10:30:51 raspberrypi deCONZ[7801]: This plugin does not support propagateSizeHints()


Es ist ja auch so, dass FHEM bei beiden deconz auf Conbee zugreifen kann, aber HM-MOD-RPI-PCB bei der Minimalversion nicht mehr läuft, bzw. der Zugriff seitens FHEM darauf nicht mehr geht.
Und dieser Zugriff auf HM-MOD läuft ja direkt über UART, sprich ist in FHEM definiert als /dev/ttyAMA0.

@ Darkwing Duck
Ja, deconz als GUI läuft definitiv nicht:

Code Auswählen Erweitern


pi@raspberrypi:~ $ ps -aux | grep deconz
pi       32566  0.0  0.2   4272  2020 pts/0    S+   10:43   0:00 grep --color=auto deconz


Das was auch nach einem Stop des deCONZ Dienstes noch läuft ist:

Code Auswählen Erweitern


pi@raspberrypi:~ $ ps -aux | grep deC
root       458 10.9  9.9 153904 94196 ?        Ss   Dec01 431:21 /bin/bash /usr/bin/deCONZ-WIFI2.sh
root       470  0.0  0.3   6084  3748 ?        Ss   Dec01   3:09 /bin/bash /usr/bin/deCONZ-update2.sh
root     32687  0.0  9.7 153904 92528 ?        S    10:43   0:00 /bin/bash /usr/bin/deCONZ-WIFI2.sh
pi       32691  0.0  0.1   4276  1852 pts/0    R+   10:43   0:00 grep --color=auto deC


Damit geht aber der Zugriff auf HM-MOD...


@Beta-User:

Ja, klar, auf dem kleinen raspi läuft normalerweise keine GUI-Ausgabe. Der steht auch ohne Monitor auf dem Spitzboden. Für die Einrichtung des Conbee hatte ich aber deCONZ gestartet und die Fenster-Anzeige auf meinen Windows-Rechner umgeleitet (putty und Xming).


So sieht übrigens das ps aus, wenn deCONZ als GUI läuft:

Code Auswählen Erweitern


pi@raspberrypi:~ $ ps -aux | grep deC
root       458 10.9  9.9 154300 94424 ?        Ss   Dec01 433:14 /bin/bash /usr/bin/deCONZ-WIFI2.sh
root       470  0.0  0.3   6088  3752 ?        Ss   Dec01   3:10 /bin/bash /usr/bin/deCONZ-update2.sh
pi       23171  8.7  4.1 130964 39284 pts/0    Sl   10:56   0:02 /usr/bin/deCONZ --http-port=8091
pi       24087  0.0  0.2   4276  2016 pts/0    S+   10:56   0:00 grep --color=auto deC


[Otto123]

Hi,

offenbar zieht der deconz doch die Schnittstelle weg? Weil der prinzipiell auch mit der UART könnte?
So ähnlich wie hier? https://github.com/dresden-elektronik/deconz-rest-plugin/issues/979

Also dem Dienst explizit den Stick angeben?

Gruß Otto

[topcrown]

@Otto:

Ich denke der Gedanke kann stimmen!

Denn, wenn man deCONZ als GUI startet, kommt im Fenster als erstes die Auswahl, ob man sich zum ConBee (=USB) oder zum RaspBee (=UART-Modul) verbinden möchte.
Da stellt sich doch die Frage, woher weiß deCONZ als Dienst, was es ansprechen soll?

Bin schon am suchen in den /lib/systemd/system/deconz* Dateien...

[Otto123]

Na steht doch in meinem Link in der Art
ExecStart=/usr/bin/deCONZ -platform minimal --http-port=80 --dev=/dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_aaabbbcccddd-if00-port0

Du musst am besten eine ordentliche service Datei anlegen Beispiel https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file)

Ich glaube mit sudo systemctl edit deCONZ kannst Du da sogar direkt eine Kopie erstellen - bin nicht mehr ganz sicher.

Gruß Otto

[topcrown]

@Otto

Ja, genau, bis auf "--dev ..." hatte ich die /lib/systemd/system/deconz.service auch konfiguriert:

Code Auswählen Erweitern


pi@raspberrypi:~ $ more /lib/systemd/system/deconz.service
[Unit]
Description=deCONZ: ZigBee gateway -- REST API
Wants=deconz-init.service deconz-update.service
StartLimitIntervalSec=0

[Service]
User=1000
ExecStart=/usr/bin/deCONZ -platform minimal --http-port=8091
Restart=on-failure
RestartSec=30
AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_KILL CAP_SYS_BOOT CAP_SYS_TIME

[Install]
WantedBy=multi-user.target



Nach einiger Sucherei habe ich jetzt endlich die Optionen von deCONZ gefunden: https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/deCONZ-command-line-parameters

Diese habe ich dann systematisch durchprobiert und festgestellt, dass folgendes wunderbar funktioniert:

Code Auswählen Erweitern

pi@raspberrypi:~ $ /usr/bin/deCONZ --dev=/dev/ttyACM0 --auto-connect=1 --http-port=8091

Damit startet deCONZ im GUI-mode und verbindet sich direkt über ttyACM0 mit dem USB-Stick. In FHEM kann ich weiterhin alle Homematic-Geräte per HM-MOD steuern und dann auch die Zigbee-Geräte.

Aber, so bald ich deCONZ headless starten lassen will und dafür die Option "-platform minimal" zusätzlich angebe, funktionieren weder der USB-Stick noch der HM-MOD. Dabei ist es auch egal, ob ich deCONZ über die Commandline starte oder per systemd.

Für mich sieht es zur Zeit stark nach einem Bug in deCONZ aus. Dazu passen könnte auch die erst kürzlich, 12.11.20, vorgenommene Änderung in der Release v2.5.87: "Improve support for stable and dynamic device paths like /dev/ttyACMx and /dev/serial/by-id/ in deCONZ and GCFFlasher to prevent errors on USB re-enumeration."

Außerdem bekomme ich im headless noch eine seltsame Fehlermeldung:
"This plugin does not support propagateSizeHints()"

Werde dann mal versuchen, jemanden für deConz zu erreichen...

[Otto123]

Idee: Du hast -platform minimal  an erster Stelle der Parameter gelassen?

Nur als Hinweis: Eigentlich sollten die von der Installation gelieferten Unitfiles in /lib/systemd/system im Original bleiben.
Der vom System bevorzugte Weg wäre systemctl edit <unitname> der erzeugt einen Pfad in /etc/systemd/system und eine Datei override.conf unterhalb des neuen Pfades. Dort schreibt man nur die Änderungen gegenüber dem Original rein.
Oder man macht eine Kopie vom Original und editiert diese ... Es gibt dazu gute  Beschreibungen. 

ansonsten kann ich Dir wohl nicht weiter helfen, ich habe diese Schnittstelle nicht

[jhohmann]

Ich hatte früher auch das Problem, so dass ich sogar deconz in docker genutzt hatte. Jetzt geht es auch ohne docker.
Zuhause schaue ich nach, wie deconz bei mir jetzt gestartet wird. Habe gerade keinen Zugriff auf mein System.

[topcrown]

@Otto

Ja, tatsächlich habe ich die Optionen auch permutiert. Und es gibt anscheinend eine Abhängigkeit von der Position- einmal gab's sogar einen Segmmentation Fault! 

Vielen Dank für Deine Hilfe! 


@jhohmann

Das wäre natürlich super!

Benutzt du Conbee oder Conbee II?

[jhohmann]

Conbee ii, meine ich mich zu erinnern 

[jhohmann]

So, bin zuhause und kann nachschauen:
Ich editiere die Services, an denen ich Veränderungen vornehmen will, immer mit folgendem Kommando (hier deconz als Beispiel):

Code Auswählen Erweitern

systemctl edit --full deconz
Damit wird automatisch beim ersten Aufruf eine Kopie angelegt und die Änderungen werden auch automatisch nach dem Speichern refreshed, also der wenigste Aufwand.
Und hier der Inhalt von meinem deconz.service:

Code Auswählen Erweitern

[Unit]
Description=deCONZ: ZigBee gateway -- REST API
Wants=deconz-init.service deconz-update.service

[Service]
User=fhem
ExecStartPre=/bin/sleep 30
ExecStart=/usr/bin/deCONZ -platform minimal --http-port=8880 --ws-port=8887 --dev=/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2197709-if00
Restart=on-failure
StartLimitIntervalSec=0
RestartSec=30
AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_KILL CAP_SYS_BOOT CAP_SYS_TIME

[Install]
WantedBy=multi-user.target

Die Ports muss du für dich anpassen.
Wofür das AmbientCapabilities steht, kann ich nicht mehr sagen. Vermutlich war das bereits so drin.