Conbee II und deCONZ

[Beta-User]

oder eben per "sudo -u <xyz> deCONZ-GUI" deconz mit dem richtigen User ...

(Vorausgesetzt, sudo ist nutzbar).

[Benni]

Also braucht meine Debian VM eine Monitor Buchse. Jetzt muss ich nur noch verstehen, wie ich diese anlöte

Wenn ich das in der deconz-gui.service richtig sehe, dürfte das

Code Auswählen Erweitern


After=lightdm.service vncserver-x11-serviced.service


die Monitorbuchse, bzw. das Stück X zu sein, was es braucht!
Das scheint zu irgendeiner vnc-Installation zu gehören (RealVNC?). Mag sein, dass das bei Raspian mit dabei ist. Auf meinem nackten Debian 10 finde ich das ebenfalls nicht.

es braucht eventuell ein Stück X - bei raspbian-lite ist es da und bei deinem system nicht.

@Otto kannst du mal bei dir schauen, ob und wenn ja wo du das findest und zu welchem Paket das ggf. gehört?

Gruß Benni

[Otto123]

@spartacus Ich helfe beim löten
@Beta-User sudo braucht es normal nicht
@Benni ich bin schon fast auf dem Weg  muss nur nochmal was anderes machen. Ich melde mich ...

[Beta-User]

@Beta-User sudo braucht es normal nicht

Jein.
Wenn es per ssh stattfindet und der ssh-User auch der ist, der den "headless"-Service startet, ist alles gut.
Ist er es nicht, muss der Start mit dem richtigen User stattfinden. Bisher war ich der Ansicht, das ließe sich dann (nur?) über den sudo-Weg (iVm. mach es als ein bestimmter anderer USer) lösen. Kann aber sein, dass da eine Wissenslücke ist .

[Otto123]

@Beta-User mit der Erklärung / Präzisierung wirst Du Recht haben, scheinbar kommt ja das deconz setup aus einer Art Appliance Umgebung/Denke: Image läuft fertig, alles mit USERID=1000 ...
Aber wenn dann nicht nur mit sudo sondern mit sudo su username?

Einen Service in Richtung X11 kann ich nicht finden.  Ich dachte kurz: vielleicht liegt es daran, das der Pi je generell eine Grafikkarte hat? Aber dann bin ich hierauf gestoßen:
Ev. ist das die Erklärung?: Bei mir sieht es so aus

Code Auswählen Erweitern

cat /etc/ssh/sshd_config|grep X11
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#       X11Forwarding noIst das die "Buchse X11"?

[Beta-User]

Aber wenn dann nicht nur mit sudo sondern mit sudo su username?

Vorschlag war gewesen:

"sudo -u <xyz> deCONZ-GUI" deconz mit dem richtigen User

<xyz> sollte die Leerstelle für den User-Namen sein...

Code Auswählen Erweitern

X11Forwarding yes
Ist das die "Buchse X11"?

Nach meinem Verständnis: Ja. Was bedeutet: die ist erst vorhanden, wenn der betreffende ssh-Dienst _aktiv_ ist (nicht nur: prinzipiell verfügbar/aufrufbar).

Die jetzige Darstellung im Wiki finde ich übrigens komisch, da wird vorausgesetzt, dass deconz per service-file mit GUI bereits läuft. Das mag gehen, wenn man docker hat, "bare metall" klappt das mAn. nicht. (qed).

[Otto123]

Naja der jetzige Wiki Abschnitt ist meine Erkenntnis anhand meines Raspberry nativ und einem docker System von vor einem halben Jahr oder so.
Jetzt habe ich ja dazu gelernt und kann es ändern ergänzen erweitern
Ich meine, ich habe am sshd nichts gedreht, eventuell ist es bei einigen Systemen per default einfach so. Und dann geht das "bare metall" - bei docker ist der vnc server aktiv - das ist wieder etwas anders.

@spartacus kannst Du das mit dem sshd in deiner vm nachvollziehen?

[Beta-User]

Das mit dem Dazulernen ist bei uns allen so, die User-Abhängigkeit war mir so auch nicht direkt bewußt gewesen...

Jedenfalls bei Buster-x86 mußte die config angefasst werden.
Ich habe damals meine ersten Versuche unmittelbar nach der Anleitung bei ubuntuusers.de gemacht (nachzulesen im "updates via deconz"-Thread) und habe in der Rückschau auch Zweifel, ob eine parallele Pflege im Wiki wirklich sinnvoll ist, das veraltet halt auch schneller als man denkt und ist anscheinend auch sehr systemabhängig...

Nochmal aber der Hinweis: afaik braucht man jedenfalls nicht wegen irgendwelcher Updates die GUI-Version!

[Benni]

A propos "Dazulernen" ....

... habe die letzten Tage einiges neu dazugelernt und habe nun also meinen Conbee vom "alten" RasPi auf einen unprivilegierten LXC-Container auf meiner Proxmox VE umziehen können: Folgendes war dazu notwendig:

Einrichten eines unprivilegierten LXC-Containers (nesting=1) mit debian und minimal-Ausstattung auf diesem habe ich, wie weiter oben schon mal beschrieben deconz mittels apt installiert (s.a.: https://phoscon.de/en/conbee/install#ubuntu)
Folgende Pakete musste ich bei mir zuvor noch installieren: sudo, lsb-release und gpg. Weiterhin hat glaube ich initial noch usbutils gefehlt, was später noch gebraucht wird.
Die Debian-Version ist bei mir jetzt noch eine Buster-Version, da die deconz-Unterstützung derzeit offiziell nur bis Buster angegeben wird.

Wichtig! Wenn deconz so installiert wird, ist anschließend der deconz-Dienst noch nicht aktiviert und läuft auch noch nicht. Das ist ok, das machen wir erst viel später!

Auf dem Container habe ich mir 2 User eingerichtet, einen für mich selbst (benni / uid=1000) und einen für den Betrieb von deconz (deconz / uid=1001).
Meinem User habe ich per visudo (sudo visudo) sudo-Rechte ohne Passwort auf alles eingerichtet:

Code Auswählen Erweitern


benni ALL=(ALL:ALL) NOPASSWD: ALL


Den user deconz-User habe ich der Gruppe dialout hinzugefügt, obwohl das im Falle des Betriebs auf dem LXC-Container egal sein dürfte, da die Rechte auf das USB-Device für den Conbee nachher außerhalb der Containers auf dem Proxmox-Node erfolgt.

Code Auswählen Erweitern


sudo gpasswd -a deconz dialout



Vom alten Rechner habe ich mir die Config für den Conbee geholt.
Auf dem alten System habe ich übrigens alles unter dem User pi durchgeführt, der dort ebenfalls sudo rechte hat.

Die anscheinend einzige relevante Datei ist hier die Datei zll.db unter .local/share/dresden-elektronik/deConz im Home-Verzeichnis des Users, unter dem deconz dort läuft. Bei mir war das ganz klassisch der user pi (lief auf einem "Standard"-RasPi).

Rausfinden kann man das aber im Zweifelsfall mittels

Code Auswählen Erweitern


sudo ps aux|grep deCONZ


Ausgabe ist dann sowas in der Art

root          87  0.0  0.2   3872  2940 ?        Ss   17:03   0:00 /bin/bash /usr/bin/deCONZ-update2.sh
pi            88  0.0  4.6 402472 48436 ?        Ssl  17:03   0:13 /usr/bin/deCONZ -platform minimal --http-port=80
pi          2860  0.0  0.0   3088   880 pts/3    S+   17:54   0:00 grep deCONZ

Interessant ist die mittlere Zeile, das ist der deCONZ-Dienst und wie man vorne in der Zeile sieht, läuft der unter dem user pi.

Wie auch immer, ich habe mir die zll.db auf meinen lokalen Client kopiert. Eventuell ist es eine gute Idee, sich eine Sicherung des gesamten dresden-elektronik Ordners zu ziehen. Man weiß ja nie


Nach der Sicherung benötigen wir das alte System nicht mehr, zumindest was deconz anbelangt, also das alte System herunterfahren, bzw. den deconz service auf dem alten System herunterfahren und deaktivieren.

Code Auswählen Erweitern


sudo systemctl stop deconz


Am besten dann kurz prüfen, ob die Phoscon - App noch erreichbar ist.

Weiterhin habe ich auch die zugehörigen update und wifi Dienste, die bei mir dazu aktiv waren, heruntergefahren:

Code Auswählen Erweitern


sudo systemctl stop deconz-update
sudo systemctl stop deconz-wifi


Die Dienste habe ich dann auch direkt deaktiviert, damit sie nicht bei einem eventuellen reboot des RasPi wieder aktiv werden und möglicherweise dazwischen-funken:

Code Auswählen Erweitern


sudo systemctl deacitvate deconz
sudo systemctl deacitvate deconz-update
sudo systemctl deacitvate deconz-wifi


So weit so gut!

Bevor wir weitermachen gehen wir erst mal auf die Shell des Prodxmox-Node (am besten als root), an dem der Conbee nachher angeschlossen werden soll. Dort führen wir einmal lsusb aus um eine Liste der USB-Devices zu haben, bevor der Conbee dran ist, dann lässt sich der nämlich leichter identifizieren.

Code Auswählen Erweitern


lsusb


Ergebnis sieht dann in etwa so aus:

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Weiterhin schauen wir uns an welche ttyUSB* - Devices wir aktuell unter /dev haben

Code Auswählen Erweitern


ls /dev/ttyUSB*


Ergebnis sah bei mir so aus:

crw-rw---- 1 root dialout 188, 1 Jan 17 13:49 /dev/ttyUSB1

Dann den Conbee vom alten Rechner abziehen und an einen beliebigen USB-Port am Proxmox-Node anschließen und die letzten beiden Schritte wiederholen:

Code Auswählen Erweitern


lsusb


Ergebnis sieht dann in etwa so aus:

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 007: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)

Die letzte Zeile ist neu hinzugekommen, also muss das der Conbee sein (bei mir ein Conbee 1, kann sein dass es beim Conbee 2 anders aussieht)

Folgende Informationen benötigen wir für die weitere Konfiguration:

Zum einen die USB-Bus - Informationen, Sprich die USB-Bus-Nummer und die Device-Nummer auf dem Bus. Das ist in obigem Beispiel Der Bus 001 und dort das Device 007 -> Notieren! Brauchen wir nachher noch!

Zum anderen sehen wir hier auch die Vendor-Id und die Product-Id des Conbee das ist in der obigen Ausgabe in der letzten Zeile die 0403:6015, wobei der Teil vor dem Doppelpunkt die Vendor-ID ist (hier als die 0403) und der Teil nach dem Doppelpunkt ist die Product-Id (also die 6015) -> Notieren! Brauchen wir später!

Nun schauen wir an, welchen ttyUSB der Stick belegt, dazu

crw-rw---- 1 root dialout 188, 1 Jan 17 13:49 /dev/ttyUSB1
crw-rw---- 1 root dialout 188, 0 Jan 18 19:15 /dev/ttyUSB0

Aha! In meinem Fall ist also /dev/ttyUSB0 dazugekommen, das wird dann schätzungsweise zum eben neu eingestöpselten Conbee gehören (das legt übrigens auch der Zeitstempel nahe!)
Interessant ist außerdem die 188 -> Notieren! ....

Mit der weiter oben notierten Bus- und Device-Nummer (in meinem Beispiel 001 und 007) lassen wir uns das entsprechende Gerät unter dev noch auflisten

Code Auswählen Erweitern


ls -l /dev/bus/usb/001/007


Ausgabe müsste in etwa so aussehen:

crw-rw-r-- 1 root root 189, 6 Jan 18 17:11 /dev/bus/usb/001/007

Interessant ist dabei vor allem die 189 in der Ausgabe. -> Notieren! ....

Wenn wir gerade sowieso auf dem Proxmox-Node sind, passen wir dort nun die Konfigurationsdatei von unserem deconz-Container an.

Dazu benötigen wir die Container-ID, da die den Namen der Konfigurationsdatei darstellt. (Mein Container hat die ID 104 folglich heißt die Datei bei mir 104.conf)

Die Datei findet sich auf dem Node unter

Code Auswählen Erweitern


/etc/pve/local/lxc/<CONTAINER-ID>.conf


Editieren mit dem Lieblingseditor (nano / vim.tiny / ...)

Und nun fügen wir folgende Zeilen am Ende ein:

Code Auswählen Erweitern


lxc.cgroup.devices.allow: c 189:* rwm
lxc.mount.entry: /dev/bus/usb/001/007 dev/bus/usb/001/007 none bind,optional,create=file
lxc.cgroup.devices.allow: c 188:* rwm
lxc.mount.entry: /dev/ttyUSB0 dev/ttyUSB0 none bind,optional,create=file


Wichtig: Diese Zeilen sind nur für mein Beispiel passend. Hier müssen nun die notierten Werte aus den oben Erzeugten Ausgaben übernommen werden.

In die erste Zeile kommt die 189 (die aus der Ausgabe von ls -l /dev/bus/usb/001/007 kommt). Damit erlauben wir dem Container den Zugriff auf USB-Bus-Devices
In der 2. Zeile kommt 2 mal der Bus-Device-Pfad, genau so, wie er beim ls verwendet wurde, damit mounten wir das Bus-Device im Container genau unter den selben Nummern
In der 3. Zeile erlauben wir dem Container den Zugriff auf ttyUSB-Devices (die 188 kommt aus dem ls -l /dev/ttyUSB*)
In der 4. Zeile Mounten wir das ttyUSB0-Device unter demselben Namen im LXC-Container.

Die Änderungen speichern und den LXC-Container (nicht den Proxmox-Node) einmal neu Starten.

Jetzt überprüfen wir im LXC-Container, ob wir den Stick dort auch so Verfügbar haben, wie wir das in der Config-Datei angegben haben. Dazu melden wir uns auf der Konsole/Shell des Containers an und schauen, ob das Bus-Device dort vorhanden ist:

Code Auswählen Erweitern


ls -l /dev/bus/usb/001/007


crw-rw-r-- 1 nobody nogroup 189, 6 Jan 18 16:11 /dev/bus/usb/001/007

Sieht gut aus!
Dann ist hoffentlich auch das ttyUSB-Device da:

Code Auswählen Erweitern


ls -l /dev/ttyUSB*


crw-rw---- 1 nobody nogroup 188, 0 Jan 18 19:49 /dev/ttyUSB0

Sieht ziemlich gut aus!
Aber wir sehen hier, dass nur der Eigentümer und die Gruppe Zugriff haben, alle anderen (other) nicht. Leider ist der Eigentümer "nobody" und die Gruppe "nogroup". Das liegt daran, Die User/Gruppen und Berechtigungen vom Host-System nicht an den (unprivilegierten) Container weitergegeben werden können. Man könnte nun recht aufwändig die User und Gruppen mappen um das zu erreichen.
Einfacher ist es aber, auf dem Host-System auch "allen anderen" (other) den Zugriff zu erlauben. Das erreichen wir erst mal durch eine einfache Rechteanpassung auf dem entsprechenden Proxmox-Node:

Code Auswählen Erweitern


chmod o+rw /dev/ttyUSB0


Mal sehen, ob das auf dem Proxmox-Noder auch korrekt übernommen wurde:

Code Auswählen Erweitern


ls -l /dev/ttyUSB0


crw-rw---- 1 root dialout 188, 1 Jan 17 13:49 /dev/ttyUSB1
crw-rw-rw- 1 root dialout 188, 0 Jan 18 19:15 /dev/ttyUSB0

Sehr schön, ttyUSB0 darf nun von jedem gelesen und beschrieben werden. Im Moment ist das nur der Fall, so lange der Proxmox-Node nicht neu gestartet wird. Nach einem Reboot hätten wir wieder die alten rechte, also ohne Berechtigung für other.

Schauen wir kurz mal im Container nach, ob das dort durchgeschlagen hat:

Code Auswählen Erweitern


ls -l /dev/ttyUSB0


crw-rw-rw- 1 nobody nogroup 188, 0 Jan 18 19:49 /dev/ttyUSB0

Ta-daa! Prima, jetzt kann auch jeder User im Container von ttyUSB0 lesen und darauf schreiben. Brauchen wir für den Conbee beides


Damit diese Rechtezuweisung auf dem Proxmox-Node auch bei einem Systemneustart erhalten bleibt, bzw. dann wieder automatisch angepasst wird, habe ich eine udev-Regel eingerichtet.

Dazu habe ich auf dem Node Eine Datei unter

Code Auswählen Erweitern


/etc/udev/rules.d/


angelegt. Bei mir heißt die Datei schlicht 50-bbusb.rules mit folgendem Inhalt:

Code Auswählen Erweitern


SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", GROUP="users", MODE="0666"


In der Zeile müssen die weiter oben Ermittelten IDs für die Vendor-Id und die Produckt-Id eingetragen werden.
Damit werden die Rechte für das Device beim Systemstart auf den in Mode eingestellten wert (0666 -> rw-rw-rw).

Damit ist der Conbee dauerhaft an den Container durchgereicht.

Wichtig zu wissen: Wenn der Stick irgendwann umgesteckt wird, teilweise auch nur, wenn er aus und wieder neu eingesteckt wird, ändert sich u.U. die Device-Nummer (007) ggf. auch die Bus-Nummer (001). In diesem Fall muss die LXC-Container-Konfigurationsdatei entsprechend angepasst werden.

So jetzt erst aktivieren und starten wir im LXC-Container den deconz-Dienst:

Code Auswählen Erweitern


sudo systemctl enable deconz
sudo systemctl start deconz


jetzt müsste der Dienst laufen und zwar unter dem User mit der uid=1000 (bei mir ist das der User benni)

Code Auswählen Erweitern


sudo ps aux|grep deCONZ


root          87  0.0  0.2   3872  2940 ?        Ss   17:03   0:01 /bin/bash /usr/bin/deCONZ-update2.sh
benni         88  0.0  4.6 402472 48436 ?        Ssl  17:03   0:50 /usr/bin/deCONZ -platform minimal --http-port=80
benni       9779  0.0  0.0   3088   880 pts/3    S+   20:17   0:00 grep deCONZ

Dienst läuft, unter dem erwarteten User.

Jetzt habe ich in der Service-Datei des deconz-Dienstes 2 Dinge angepasst.
Zum einen die user-Id unter der der Dienst laufen soll. Bei den allermeisten Installationen dürfte der Standardwert mit 1000 passen. Auf einem RasPi ist das i.d.R der user pi.
Die 2. Anpassung war, dass ich das USB-Device, unter dem deconz den Conbee verwenden soll explizit angegeben habe, da die Autoerkennung einfach nicht funktioniert hatte.

Bei oben genannter aktivierung des Dienstes wird der Speicherort der Service-Datei ausgegeben:

/etc/systemd/system/multi-user.target.wants/deconz.service -> /lib/systemd/system/deconz.service

Es ist egal, ob über den symlink oder die Datei direkt editiert wird. Editiert werden muss allerdings mit root-Rechten (sudo)

Die Service-Datei sieht bei mir nach Änderung so aus:

Code Auswählen Erweitern


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

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

[Install]
WantedBy=multi-user.target


Die genannten Änderungen finden sich in den ersten beiden Zeilen in der Seciton [Service]

Um die Änderungen für systemctl zu übernehmen muss jetzt einmal

Code Auswählen Erweitern


sudo systemctl daemon-reload


ausgeführt werden.
Jettzt kann der Dienst neu gestartet werden

Code Auswählen Erweitern


sudo systemctl restart deconz


Bei mir müsste der Dienst nach der Änderung nun unter dem User deconz (uid=1001) laufen

Code Auswählen Erweitern


sudo ps aux|grep deCONZ


root          87  0.0  0.2   3872  2940 ?        Ss   17:03   0:01 /bin/bash /usr/bin/deCONZ-update2.sh
deconz        88  0.0  4.6 402472 48436 ?        Ssl  17:03   0:55 /usr/bin/deCONZ -platform minimal --http-port=80 --dev=/dev/ttyUSB0
benni      10727  0.0  0.0   3088   816 pts/3    S+   20:36   0:00 grep deCONZ

Das sieht gut aus und auch die device-Angabe (dev=...) wurde beim Aufruf übergeben.

Der Dienst wird nun nochmal gestopt:

Code Auswählen Erweitern


sudo systemctl stop deconz


Jetzt spielen wir die, vom Altsystem gesicherte zll.db im Container bei dem User ein, unter dem deconz läuft. Bei mir also kommt bei mir die Datei nach

Code Auswählen Erweitern


/home/deconz/.local/share/dresden-elektronik/deCONZ


So nun wird der Dienst wieder gestartet

Code Auswählen Erweitern


sudo systemctl start deconz


Das sollte es fast gewesen sein.

Wir können uns nun wie gewohnt auf der Phoscon-App auf Container per Browser anmelden.
Alle devices sollten dort sicht- und schaltbar sein.

Als letztes musste ich nun nur noch in meinem FHEM im deCONZ-Device in der DEF die IP-Adresse des LXC-Containers angeben.

Fertig!
Erfolgreich vom Pi nach LXC umgezogen, ohne dass irgendwas neu angelernt werden musste.

Btw.: Ich verwende ausschließlich die Headless-Variante von deconz. Die Gui-Variante habe ich noch nie benutzt oder benützen müssen.

Der Text ist nun doch etwas länger geworden, als ursprünglich gedacht. Es ist ja auch fast schon ein Tutorial geworden und wäre wahrscheinlich auch im Wiki gut aufgehoben. Mal sehen, mache ich vielleicht die Tage auch noch.

Jetzt bin ich jedenfalls erst mal meine Erkenntnisse losgeworden.

Die eigentliche Quint-Essenz für den Thread hier ist: die deconz-Config steckt in der zll.db

Vielleicht ist der Rest auch jemandem nützlich.

gb#

[Benni]

Der Text ist nun doch etwas länger geworden, als ursprünglich gedacht. Es ist ja auch fast schon ein Tutorial geworden und wäre wahrscheinlich auch im Wiki gut aufgehoben. Mal sehen, mache ich vielleicht die Tage auch noch.

Erledigt: Conbee/deCONZ im Proxmox LXC-Container (Tutorial)

gb#

[oelidoc]

Hallo,
habe auch lange gebraucht, bis ich meine deCONZ gui headless hinbekommen habe. Dieser Thread hat mir dabei sehr geholfen.
Aber m.E. ist der Einzeiler für Windows im ConBee Wiki falsch

Code Auswählen Erweitern

ssh -X <user>@<host> "export DISPLAY=%COMPUTERNAME%:0.0;sudo systemctl stop deconz; deCONZ --dev=/dev/ttyACM0;sudo systemctl start deconz"
Ohne viel Ahnung zu haben, glaube ich, dass es eigentlich

Code Auswählen Erweitern

ssh -X <user>@<host> "export DISPLAY=%COMPUTERNAME%:0.0;sudo systemctl stop deconz; deCONZ --dev=/dev/ttyACM0;sudo systemctl start deconz-gui" heißen müsste.
Vielleicht kann Otto das ja noch mal checken...
Gruß
oelidoc

[MadMax-FHEM]

Der Service für headless heißt deconz.

Was die Zeile (von Otto/Wiki) tut: stoppe deconz-service, starte "deConz-App" (für remote-X) und wenn das remote-X beendet ist, dann starte den deconz-service wieder...

Wenn deconz-gui gestartet ist, dann hat man keine headless Installaion von deconz laufen...

Und dann wäre ja schon der erste Befehl "falsch" : wo kein deconz (ohne gui) läuft, kann man es auch nicht stoppen...

Gruß, Joachim

[Jogi]

Hallo zusammen,
ich versuche auch schon eine Weile deconz headless über X11-Forwarding zu installieren, bekomme es aber nicht hin.
Ich habe mich an die folgende Vorgehensweise von Otto gehalten:
- VcXsrv auf Windows Rechner installiert.
- VcXsrv wird gestartet mit xlaunch - alles Standard lassen nur im letzten Fenster: "disable access control" aktivieren
- Beim Funktionstest bekomme ich folgende Fehlermeldung:

Code Auswählen Erweitern

C:>ssh -X pi@raspberrypi "export DISPLAY=%COMPUTERNAME%:0.0;xcalc"
pi@raspberrypi's password:
bash: xcalc: Kommando nicht gefunden.
Möchte ich Deconz headless aufrufen bekomme ich folgende Fehlermeldung:

Code Auswählen Erweitern

C:>ssh -X pi@raspberrypi "export DISPLAY=%DESKTOP-6TDI7PO%:0.0;sudo systemctl stop deconz; deCONZ --dev=/dev/ttyUSB0;sudo systemctl start deconz"
pi@raspberrypi's password:
Failed to stop deconz.service: Unit deconz.service not loaded.
bash: deCONZ: Kommando nicht gefunden.
Failed to start deconz.service: Unit deconz.service not found.

Vielleicht eine wichtige Info:
An meinen Raspberry Pi hängt ein USB Hub (mit separater Stromversorgung) an Port ttyUSB0 und daran hängt der Conbee 1.
Ich weiß nicht, ob das vielleicht das Problem verursacht.

Hat jemand eine Idee, wo mein Fehler liegt?

[Otto123]

Hi,

auf die Schnelle: das hier ist Unfug: %DESKTOP-6TDI7PO%
%COMPUTERNAME% ist eine Windows Umgebungsvariable, Windows löst diese auf - zu dem tatsächlichen Computernamen. Wenn Du das nicht willst muss Du einfach den Namen - ohne % Zeichen davor und dahinter schreiben.
Wenn der xcalc nicht gefunden wird, ist der bei Deiner Installation nicht dabei. Komisch, bei mir war das im Raspberry OS lite bisher immer dabei.

Die andere Zeile dient ja dazu, den normalen deconz service zu beenden, der läuft bei Dir scheinbar nicht. Ist denn deconz überhaupt schon installiert? Sieht mir nicht danach aus?  https://wiki.fhem.de/wiki/ConBee

Gruß Otto

[Jogi]

Vielen Dank für die Tipps, dann weiß ich wo ich ansetzen muss.

Update:
Ich stehe jetzt an diesem Punkt:
-deconz ist auf dem Raspi scheinbar installiert und läuft:

Code Auswählen Erweitern

ii  deconz                          2.14.01-raspbian-buster-stable      armhf

-Beim Test bekomme ich aber immer noch diese Fehlermeldung:

Code Auswählen Erweitern


C:\Users\JS>ssh -X pi@raspberrypi "export DISPLAY=%COMPUTERNAME%:0.0;xcalc"
pi@raspberrypi's password:
bash: xcalc: Kommando nicht gefunden.
Meine Recherche dazu hat diese Seite gefunden:
https://command-not-found.com/xcalc
Ich habe dementsprechend mit

Code Auswählen Erweitern

Sudo apt-get install x11-apps
installiert.
Aber scheinbar scheint xclac nicht, oder nicht richtig zu laufen.
Leider finde ich über die Google-Suche im internet auch keine -für mich- brauchbaren Tipps. Oder ich suche mal wieder falsch.
Hat jemand noch einen Tipp für mich? Sicher liegt der Fehler -mal wieder- bei mir, aber ich finde ihn alleine nicht.

Gruß,
Jogi