FHEM Forum

Hallo Leute,

ich habe nur eine Frage um etwas zu richtig zu verstehen.
Ich habe einen Conbee II Stick in meinem FHEM Raspi laufen. Das funktioniert hervorragend. Da das Linux Headless läuft kann ich deCONZ auf dem Raspi nicht starten. Jetzt habe ich testweise einen 2. Raspi mit graphischer Oberfläche aufgesetzt. Dort läuft deConz und ich sehe was in meinem Zigbee Netz so los ist.
Jetzt kommt meine Frage:
Ist es richtig das der Stick nur mit aktiver deCONZ Software arbeitet? Also wenn ich den Raspi neu starte und der Desktop zu sehen ist, das passiert weder bei FHEM etwas nocht wenn ich die Phoscon App nutze. Sobald ich deCONZ starte ist alles OK.

Und übrigens allen ein gutes und gesundes neues Jahr....

Du kannst sehr wohl deCONZ headless installieren!
(Nach welcher Anleitung bist du vorgegangen? Es gibt ja bei DE eine mit headless!)

Läuft bei mir (fast) schon immer headless.
EDIT: mal abgesehen von den ersten Versuchen vor X Jahren, da gab es noch kein headless... Aber sobald das als "beta" raus war hatte ich headless... :)

Und sogar auf dem selben PI wie fhem läuft. ABER: aufpassen wenn weitere USB-Sticks verwendet werden!
(gibt irgendwo hier einen Thread der erläutert was bei deCONZ eingetragen werden muss damit das dann keine Probleme macht)

Und: initialUsbCheck in fhem deaktivieren!
(schadet eh nicht das zu tun ;) )


Dann hast du deCONZ "irgendwo" laufen.
Du kannst dann mittels phoscon-App entsprechend deCONZ konfigurieren, neue Lampen, Sensoren, ... suchen/einbinden.

Eingebunden in fhem wird das dann als "HUE-Bridge" mittels HUEBridge-Device...

Dann kannst du Lampen mittels "autocreate" von deCONZ "holen", Sensoren (und ja Schalter sind auch "Sensoren" ;) ) musst du allerdings manuell in fhem anlegen.
Die ID die du brauchst kannst du aber beim HUEBridge-Device "holen".

Wenn du doch eine Oberfläche willst, also die deCONZ-GUI, dann geht das auch "nachträglich" bei einer headless Installation...

EDIT: ja, natürlich muss deCONZ laufen! Das ist vergelichbar mit der originalen HUE-Bridge. Die muss ja auch laufen ;) Wenn du da den Stecker ziehst ist auch nix mit ZigBee ;) Dort läuft halt die FW automatisch los. Sollte aber bei deCONZ auch sein/gehen! Erneut: wie hast du installiert? Nach welcher Anleitung? Weil eigentlich wenn es eine "vernünftige" Anleitung war (direkt Dresden Elektronik), dann sollte deCONZ automatisch starten! Und es sollte auch beschrieben sein, dass und wie es headless geht!

EDIT: https://www.phoscon.de/en/conbee2/install#raspbian danach habe ich headless installiert (den ersten Schritt [sudo gpasswd -a $USER dialout] habe ich allerdings nicht in meinen Notizen). Das sind mal meine Notizen:

wget -O - http://phoscon.de/apt/deconz.pub.key |            sudo apt-key add -
sudo sh -c "echo 'deb http://phoscon.de/apt/deconz \
            $(lsb_release -cs) main' > \
            /etc/apt/sources.list.d/deconz.list"
sudo apt update
sudo apt install deconz
sudo systemctl enable deconz
sudo systemctl disable deconz-gui
sudo systemctl stop deconz-gui
sudo reboot

EDIT: ist aber bis auf "enable deconz" und das deaktivieren der GUI identisch zur verlinkten Anleitung... Habe ja auch diese Anleitung genutzt ;)

Gruß, Joachim

Hallo Joachim,

ach so, auch bei der headless Installation läuft deCONZ ebenfalls, aber dann nur ohne graphische Oberfläche, sozusagen im Hintergrund?
Dann ist die deCONZ nur nicht Sichtbar und man kann die Verknüpfungen zwischen den Knoten nicht sehen?

Das bedeutet, es ist richtig das bei einer Installation mit Desktop die App immer geöffet sein muß?

Edit: Ach so, ja ich hatte die selbe Anleitung benutzt. Ist ja das Original vom Hersteller.

Gruß Holger

so einiges habe ich jetzt mehr verstanden.

Also, die Auflistung der Befehle hat mich zum spielen verführt.

Mit "sudo systemctl enable deconz" startet der Dient (wie zu erwarten) automatisch und ich muß die deCONZ App nicht mehr von Hand starten.
Mit "sudo systemctl disable deconz" startet der Dienst nicht beim Systemstart, erwartet aber, damit er arbeitet einen manuellen Start.

Ergebnis: Der normale Betrieb sollte über "sudo systemctl enable deconz" laufen. Dann ist eine graphische Ansicht aber nicht möglich.
Wenn man, warum auch immer, dem System bei er arbeit zuschauen möchte, muss per "sudo systemctl disable deconz" der autostart abgeschaltet werden. Dann ist es bei vorhandenem Desktop möglich die deCONZ App manuell zu starten und Knoten und Verbindungen zu sehen.

Hallo Holger,

naja, etwas umständlich und geht auch anders.

Also komplett headless und dann mittels -X ssh drauf verbinden...

Aber für den Einstieg isses so auch ok... ;)


Naja: also der Conbee II ist "nur" der Funk-Stick. Ohne weitere SW macht der nix ;)

Also deCONZ UND der Conbee II zusammen sind das ZigBee-Gateway.
Alternative: zigbee2mqtt zusammen mit dem Conbee II wäre dann ebenfalls ein ZigBee-Gateway. Einbindung in fhem dann eben mittels mqtt (wer hätte es gedacht ;) )...

deCONZ wird (wie je schon geschrieben) mittels HUEBridge-Modul eingebunden.

Nicht vergessen: attr httpUtils 1 (und evtl. noshutdown 1) Und nat. "Freigabe" auf dem deCONZ klicken (phoscon)...

Viel Spaß, Joachim

das ganz läuft bei mir auf einer Synology und damit per def "headless".
Ist doch von der Anlage Client-Server. Habe alles natürlich auch grafisch an meinem Notebook, von dem ich auf die Synology zugreife.

Hallo,
der Beitrag ist zwar schon etwas älter, aber ich muss hier noch mal nachhaken. Auf meiner qnap läuft deconz als Headless Version in einer Debian VM. Ich würde mich aber gerne irgendwie auf das graphische Interface von deconz verbinden. Am Besten von einer Windows Büchse aus. Muss ich auf der VM noch eine graphische Oberfläche installieren? Ich möchte natürlich die VM Ressourcentechnisch so klein wie möglich halten und nicht unbedingt eine Oberfläche installieren. Gibt es andere Möglichkeiten, die deconz-Oberfläche irgendwie über eine Remoteverbindung von einem Windows PC aufzurufen?

Danke und Gruß,
Spartacus

Sollte hier zu finden sein, was zu tun ist: https://wiki.fhem.de/wiki/ConBee

X11-Forwarding...

Sollte auch von Windows aus mit/auf eine Debian-Linux-VM gehen...

Gruß, Joachim

Hallo Joachim,

danke für die schnelle Antwort. X11,  da habe ich keine Erfahrungen mit. Welchen X11 Server kannst du empfehlen, der nicht so viele Ressourcen frist?
Spartacus

Keine Ahnung.

Ich habe Linux Desktop und da ist ja X11 "dabei" ;)

Folgendes steht im Wiki:

Zitat
X11 Server (Linux Desktop oder Windows VcXsrv, Xming; beides auf SourceForge.net verfügbar).

Gruß, Joachim

Hi Joachim,

sorry, dazu bin ich offenbar zu blöd! Ich verstehe deine Anleitung noch nicht!

Meine Situation:
Deconz läuft aktuell auf der Debian VM headless
Mein Client ist ein Windows PC mit putty.

Ich habe verstanden:

• Linux Desktop auf dem Debian System installieren (das ist dann das X11 Paket für die graphische Oberfläche, finde ich aber nirgendwo, auch nicht auf SourceForge.net)
• der deconz wird dann permanent in der gui-Version auf dem Linux System gestartet
• in der sshd_config gebe ich das X11 Forwarding frei (das habe ich gefunden)
• und mit putty kann ich mich dann auf das grafische Interface verbinden

Was hat es damit auf sich, das verstehe ich in diesem Zusammenhang auch nicht.
Einzeiler für Linux Desktop : ssh -X <user>@<host> sudo systemctl stop deconz; deCONZ --dev=/dev/ttyACM0;sudo systemctl start deconz

Einzeiler für Windows 10 : ssh -X <user>@<host> export DISPLAY=%COMPUTERNAME%:0.0;sudo systemctl stop deconz; deCONZ --dev=/dev/ttyACM0;sudo systemctl start deconz

Es ist ja nicht "meine" Anleitung ;)

Ich bin jetzt auch kein X11-Forward-Profi...

Aber:
Du brauchst KEIN putty, daher ja der Einzeiler für Windows (also schätze mal ab/für Windows 10, da ist ja ssh "eingebaut")

Dann: du brauchst nat. da wo du grafisch schauen willst ein X11 (so verstehe ich das)

Also wenn du ein Linux Desktop System hast, dann ist da (meist) X11 "dabei"...

Du hast ein Windows, da brauchst du dann eben noch ein X11 zum "Empfang" und zur "Anzeige" der "weitergeleiteten" X11-Grafik (wenn man so will)...
Als musst du wohl für Windows einen der genannten X11 installieren (da ich Linux habe kann ich dir da nicht helfen)...
Und dann einfach den Einzeiler in cmd "werfen"...

Habe es selbst noch nicht probiert, steht noch auf "ToDo" ;)

Aber drum ja X11-Forwarding, damit man eben KEIN grafisches System braucht, sondern eben weiterhin (eigentlich) headless ist... :)

Gruß, Joachim

Hallo Joachim,
ja ok. jetzt habe ich es halbwegs verstanden. Aber, was muss denn auf dem Debian Gerät installiert sein, damit ich mich mit dem Windows X-Server auf das grafische Display des Debian verbinden kann. Da muss doch auch irgendetwas grafisches laufen, oder reicht es einfach die deconz -gui auf der Debian Kiste zu starten?

Hier habe ich noch den Hänger!
Spartacus

Also so wie ich das lese:

X11 da wo du kucken willst, also deine Windows Büxe.
Dann den "Einzeiler" in cmd "werfen" -> ferig...

Wie geschrieben: noch nicht probiert...

Die andere Variante (die du wohl [immer] im Kopf hast) wäre ja:

Grafische Oberfläche dort wo deCONZ läuft (dann ja nicht mehr headless ;)  ) und dann halt sowas wie "remote Desktop" also z.B. vnc...
Aber das ist ja eine ganz andere Geschichte und will man ja gerade eben nicht (so ich das richtig verstehe)...

EDIT: so wie ich dachte. Die deconz-gui "App" (oder auch nur deCONZ) kann grafisch "forwarden" aber angezeigt wird es eben NICHT dort wo deCONZ läuft, sondern eben auf dem "Client", dort braucht es eben zur Anzeige ein X11
https://www.youtube.com/watch?v=FlHVuA_98SA
https://www.youtube.com/watch?v=MbzqosYgS_E

Gruß, Joachim

Hallo Joachim,

danke für deinen Support. Ich habe es jetzt verstanden, aber offenbar kann deconz kein grafisches Display zur Verfügung stellen. Ich bekomme auf dem Windows Rechner die Meldung,
qt.qpa.screen: QXcbConnection: Could not connect to display
Could not connect to any X display.

Die deconz gui krieg ich auch nicht aktiviert.

deconz-gui.service                                               disabled
deconz-homebridge-install.service                                disabled
deconz-homebridge.service                                        disabled
deconz-init.service                                              disabled
deconz-update.service                                            disabled
deconz-wifi.service                                              disabled
deconz.service                                                   enabled

Christian

Die Meldung bedeutet eher, dass eben LOKAL auf dem Windows Rechner kein X-Display gefunden werden kann an das weitergeleitet wird/werden kann/soll...

Ob man deCON-gui wirklich braucht weiß ich nicht.
Evtl. kann auch deCONZ selbst X-Forwarden und deCONZ-gui ist (nur) zur lokalen grafischen Anzeige (wollen wir ja nicht).

Hast du dort wo deCONZ läuft X-Forwarding aktiviert in der ssh?
(so verstehe ich das zumindest und ist auch in den verlinkten Videos zu sehen)

Gruß, Joachim

Also ich hab das jetzt auch mal ausprobiert und bekomme dieselbe Meldung...

Kann aber grad nicht viel weiter analysieren...
...muss ich leider verschieben.

Aber vielleicht meldet sich ja noch jemand, der es schon gemacht hat.

Ich glaube Beta-User hat auch in einem Thread mal erläutert (Schritt für Schritt?) wie es geht...

Gruß, Joachim

Hi Joachim,
schon mal vielen Dank bis hierher...ich spiele mal noch etwas weiter...

Also ich habe es jetzt laufen :)

Allerdings unter Linux...

Ich habe allerdings zuerst (ein Terminal remote per ssh eingeloggt) den deconz Service gestoppt (irgendwie hat das bei mir mit dem "Einzeiler" nicht geklappt)...

dann in einem 2ten Terminal (gut ich hätte mich wohl beim 1ten auch wieder ausloggen können, dachte aber ja ich müsste irgendwie den Service wieder starten) eben folgendes eingegeben:


ssh -X user@deCONZ-Server deCONZ --dev=/dev/ttyACM0

(vors. nat, dass /dev/ttyACM0 eben dein ConBee, RaspBee etc. ist)

Und: oh Wunder es ging die Grafik auf :)

Wie das aber mit Windows geht: keine Ahnung.

Evtl. eine Linux-VM und von dort aus?

Also du musst irgendwie das Dispay angeben, wie man das unter Windows rausfindet: leider keine Ahnung...

Gruß, Joachim

Hallo Christian,

steht eigentlich klar Schritt für Schritt im Wiki. (Die Anleitung dort ist von mir)
Der Einzeiler dort deaktiviert den deconz service  und startet den deconz-gui service.

Am Ende ist es die gleiche Binar Datei die gestartet wird nur mit unterschiedlichen Parametern.

Edit: Ich habe mal noch einen Hinweis im WIki eingefügt:

ZitatTipp für Windows Einsteiger: CMD Box aufmachen mit: Windows Taste + r und dann CMD enter. Programme wie den X11 Server muss man herunterladen und installieren.

Macht es das klarer?

Gruß Otto

Zitat von: Spartacus am 12 Januar 2022, 18:29:48
Aber, was muss denn auf dem Debian Gerät installiert sein, damit ich mich mit dem Windows X-Server auf das grafische Display des Debian verbinden kann.

Nichts! X11 geht ohne weitere Installation. Die grafik (nicht die Darstellung) macht ja der deconz service

Der Weg:
X11 Umleitung über ssh von debian auf Windows, dort läuft der X11 Server, der stellt alles dar.

Hallo Otto,

bei dem Einzeiler für Linux fehlen aber Anführungszeichen ;)

Also bei mir funktioniert es nur so:


ssh -X <user>@<host> "sudo systemctl stop deconz; deCONZ --dev=/dev/ttyACM0;sudo systemctl start deconz"


Ohne die Anführungszeichen VOR sudo... ging es bei mir nicht, da irgendwie versucht wird LOKAL den deconz Service zu stoppen, geht nat. nicht ;)

Und bei Spartacus wird das DISPLAY nicht gefunden, siehe Fehlermeldung: https://forum.fhem.de/index.php/topic,117470.msg1200177.html#msg1200177

Gruß, Joachim

Zitat von: Otto123 am 12 Januar 2022, 20:43:03
Nichts! X11 kann jedes Linux von Haus aus.

X11 Umleitung über ssh von debian auf Windows, dort läuft der X11 Server, der stellt alles dar.

Das denke ich ist ihm schon klar (jetzt)... ;)

Gruß, Joachim

Zitat von: MadMax-FHEM am 12 Januar 2022, 20:44:20
Und bei Spartacus wird das DISPLAY nicht gefunden, siehe Fehlermeldung: https://forum.fhem.de/index.php/topic,117470.msg1200177.html#msg1200177

Gruß, Joachim

Weil er keinen X11 Server auf dem Windows installiert hat?

Das mit den Anführungszeichen schau ich mir an. Aber eigentlich hatte ich alles getestet. Aber manchmal geht final was schief :)

Hallo zusammen,
der X11 Server läuft. Wird aber nicht gefunden. Ich habe Win11 installiert. Liegt es daran?
Christian

Zitat von: Otto123 am 12 Januar 2022, 20:48:35
Weil er keinen X11 Server auf dem Windows installiert hat?

Das weiß ich nicht aber ich habe versucht ihm das klar zu machen 8)

Zitat von: Otto123 am 12 Januar 2022, 20:48:35
Das mit den Anführungszeichen schau ich mir an. Aber eigentlich hatte ich alles getestet. Aber manchmal geht final was schief :)

Also bei allen meinen ssh-Remote-Aufrufen habe ich um die "remote auszuführenden Befehle" Anführungszeichen "drumrum"...

Bzw. habe ich das "Original" aus dem Wiki probiert: da kam eben deconz.system nicht gefunden (klar weil auf meinem Desktop-System läuft ja kein deCONZ)
Und dann mal "meine" Variante (weil ich eben dachte: da gehören doch Anführungszeichen drumrum): hat prompt geklappt :)

Klar, kommt vor!

Gruß, Joachim

naja wenn gehören die Anführungszeichen in beide Varianten. ssh ist ssh :) auch unter Windows.

Du hast ziemlich sicher Recht der String für Remote gehört in Anführungszeichen.

Zitat von: Spartacus am 12 Januar 2022, 20:51:03
Hallo zusammen,
der X11 Server läuft. Wird aber nicht gefunden. Ich habe Win11 installiert. Liegt es daran?
Christian

Was heisst nicht gefunden? Du musst den nur installiert haben, die Kommandozeile öffnet das Fenster.

Zitat von: Otto123 am 12 Januar 2022, 20:56:53
naja wenn gehören die Anführungszeichen in beide Varianten. ssh ist ssh :) auch unter Windows.

Jep, klaro. Aber bzgl. Windows bin ich ein "Doofie" ;)
Aber vermutlich nach dem export Display usw. :)

Zitat von: Otto123 am 12 Januar 2022, 20:56:53
Du hast ziemlich sicher Recht der String für Remote gehört in Anführungszeichen.

:)

EDIT: und jetzt halte ich mich raus... Kann bei Windows eh net wirklich helfen...

Gruß, Joachim

Hallo,
noch mal ich! Wie gesagt der X11 Server läuft auf der Windows Mühle. Die Frage ist nur, wie man den konfiguriert?

So habe ich es gemacht:

Ich kann mich nicht erinnern da irgendwas konfiguriert zu haben.
Du hast aber Windows, warum startest Du dann die Zeile für Linux  :'( :'( :'(

Äh, hast du auf Windows die Zeile für Linux eingegeben?

Es fehlt doch eben genau die Angabe des Displays!?

Du musst schon den Einzeiler für Windows nehmen, auf Windows ;)

EDIT: evtl. wäre auch gegangen den Haken bei: remote Programme ausführen etc., weil das willst du ja ;) Da weiß ich aber nicht wie das dann geht aber das wäre noch möglich dort eben den deconz-Service zu stoppen und deCONZ direkt aufzurufen (für X-Weiterleitung)...

EDIT: vermutlich fehlen dann aber bei dem Einzeiler für Windows aus dem Wiki noch die Anführungszeichen... ;)

Gruß, Joachim

Zitat von: MadMax-FHEM am 12 Januar 2022, 21:02:36

EDIT: vermutlich fehlen dann aber bei dem Einzeiler für Windows aus dem Wiki noch die Anführungszeichen... ;)

Gruß, Joachim

nachgerüstet :) im übrigen gehört der export Befehl remote nach Linux, nur die Variable %COMPUTERNAME% muss Windows ersetzen. :)

Zitat von: Otto123 am 12 Januar 2022, 21:10:27
nachgerüstet :) im übrigen gehört der export Befehl remote nach Linux, nur die Variable %COMPUTERNAME% muss Windows ersetzen. :)

Drum hab ich auch keinen Vorschlag gepostet ;)
War schon drauf und dran aber hab dann doch zurückgezuckt :D

Gruß, Joachim

So,
einen Schritt weiter. Habe nach der Installton des X11 Servers mal nen reboot gemacht. Jetzt läuft das WebGUI vom Deconz, aber es werden keine Devices gefunden.
Im TErmnalfenster tauchen Fehler auf:

libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast


ls -lha /dev/serial/by-id
usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2141320-if00 -> ../../ttyACM0
der Device PFad sollte doch stimmen, oder?

hast Du denn schon Devices angelernt? Das macht man mit der Phoscon App

Oder fehlt ihm jetzt sein Pfad und damit irgendwie die config?

Hi,
ja klar, da laufen ca. 30 Devices, die sehe ich auch in er Phoscon App!  Die Phoscon apop läuft aber nicht mehr, wenn ich das grafische deconz über ssh starte. Erst wenn ich deconz auf dem headless Debian stoppe und erneut starte, läuft auch phoscon wieder....dann ist aber das grafische deconz wieder weg.

Keine Ahnung, was das wieder ist.
Christian

Das ist so.

Du stoppst ja den Service, startest manuell deCONZ und danach wieder den Service...

Gruß, Joachim

ähm .. ich meine: alles die gleiche binary nur die Parameter sind anders und die phoscon app läuft immer. Also deConz startet den Webserver auf port 80
Muss man sudo deCONZ starten?

Hallo,
verstehe ich jetzt nicht! Wieso ist das richtig, dass das graphische <deconz die Lichter nicht mehr findet und die phoscon App tot ist?

Irgendwie ist das alles sehr merkwürdig. Wenn ich den Conbee auf der gleichen qnap mit einer Win10 VM verbinde findet das graphische Interface sofort alle Lichter und Schalter!

Ich brauche das grafische Interface nur, um die OTA Updates der IKEA Lichter einzuspielen. Das geht offenbar nur miit dem grafischen Interface.

ja ich vermute es liegt am Start, kann bloß gerade nicht wirklich praktisch testen.

wenn ich deCONZ in einer putty sessen starte, dann kommt wieder das kei X-Server gefunden. Kann man deinen Einzeiler-Windows Aufruf irgendwie manuell in einer putty session anstossen? Sorry, bin da leider nicht der Linux Fuchs!

Christian

schmeiss doch putty bitte weg, das macht doch der ssh Aufruf! Anstatt putty
ssh <user>@<host>

Du kannst auch folgendes versuchen. Zuerst den service ändern
ssh <user>@<host> systemctl stop deconz;systemctl disable deconz;systemctl enable deconz-gui;systemctl start deconz-gui"
dann
ssh -X <user>@<host> "export DISPLAY=%COMPUTERNAME%:0.0;deConz;"

Du kannst auch ssh -X <user>@<host> dann export DISPLAY=DeinWindowsName:0.0und den Rest per Hand machen.
Um meine Aussage mit gleicher binary und den unterschiedlichen parametern zu belegen:
systemctl cat deconz
systemctl cat deconz-gui

Wenn Du X Umleitung per putty machen willst kann ich Dir nicht helfen. Aber es ändert sich dadurch nichts.

Hi,
ja auch das führt leider nicht zum Erfolg. Für heute gebe ich auf. Vielleicht macht es Sinn einen Mini-Desktop auf der Debian-vm zu installieren und dann mit nem VNC draufzugehen. Die Frage die sich mir stellt ist sowieso, ob die Aktualisierung der IKEA Devices im Hintergrund weiteläuft, wenn der Windows X-Server beendet wird. Das ist ja das primäre Ziel. Das GUI braucht man m.E. auch, wenn man das Einschaltverhalten der Leuchten ändern möchte...Also um das GUI kommt man nicht herum....ich glaube der Aufruf "deCONZ --dev=/dev/ttyACM0" ist hier der Übeltäter. Hängt m.E. auch damit zusammen, dass ich einen USB passthrough mache und sich das irgendwie beißt Prinzipiell funktioniert es ja, der Coordinator taucht im Deconz auch auf, aber die Leuchten und Schalter sind dann futsch!

Alternativ:
Gibt es eine einfache GUI die mit wenig Ressourcen auskommt? Das Ganze läuft halt auf einer qnap unter Virtualisazion Station und RAM ist kostbar!

Christian

Bei mir ist/war der Service deconz-gui auch deaktiviert.
Ging aber ja trotzdem...

Gruß, Joachim

der deconz docker startet so, dass man mit vnc draufkommt. Da muss man mit dem service gar nichts machen. Aber ich glaube die starten da wirklich einen vnc Server mit.

So wie das auf der deconz setup seite steht, startet man deconz-gui service und ein Aufruf von deCONZ ist dann quasi die Oberfläche. Aber mag sein ich verstehe das falsch.

Ich hatte mir gemerkt: deconz nur einmal starten und so wird es sein. deCONZ muss dann entsprechend aufgerufen werden. Wenn man wirklich beides ständig braucht, besser docker nehmen? Ist einfacher als dieses gefummel.

Muss ich nochmal umbauen und testen, aber nicht heute.

Moin,

Docker würde ich gerne nehmen, aber da mein Smarthome in einem eigenen Subnetz läuft, nehme ich die  Virtualisation Station, da ich da die Möglichkeit habe, die Kisten in separaten Netzten zu betreiben. Die Docker Maschine läuft dann in meinem Admin LAN und das ist käse...Man kann das auch irgendwie umbauen, dass die Docker Maschinen in anderen Netzten laufen, aber das ist offenbar recht kompliziert und traue ich mich nicht so richtig ran. Ich klne jetzt erst einmal meine produktive VM und versuche das irgendwie zum Fliegen zu bringen.

Die VM hat auch noch einen Nachteil. Wenn der Conbee Stick rebootet wird, verliert die VM das per passthrough zugewiesene USB Interface und es muss in der Admin Konsole neu verbunden werden. Das scheint nen Bug in der Virtualisierung zu sein. Daher laufen FirmwareUpdates mit dem Conbee in der virtuellen Umgebung nicht. Das mache ich immer an einem Windows PC

Wenn jemand eine Idee hat, wie man einen Container in ein anderes Subnetz hängt, dann wäre ich für ein Howto dankbar.

Christian

Guten Morgen,

ich habe meine Stick an einen raspberry gesteckt und dort ist deconz installiert. Der Einfachheit halber sind die Dienste deconz und deconz-gui enabled aber nicht gestartet.
Ich bin über ssh verbunden (einfach ssh pi@raspberry ohne -X , geht einfach in der Ausführenzeile), auf meinem Windows 10 (LPK10) ist xlaunch (VcXsrv) gestartet (access control deaktiviert)
In der console gebe ich ein: export DISPLAY=LPK10:0.0
Ich kann auf die schnelle folgende Zustände berichten:
deconz gestartet: Phoscon App auf Port 80 erreichbar, wenn ich in der console deCONZ starte öffnet sich auf dem Windows das deconz gui Fenster - er kann sich aber nicht zum Stick verbinden, ich habe keine Anzeige von Geräten
deCONZ wird in der console mit ctrl+c beendet
sudo systemctl stop deconz;sudo systemctl start deconz-gui
deconz-gui gestartet: Phoscon App auf Port 80 erreichbar, wenn ich in der console deCONZ starte öffnet sich auf dem Windows das deconz gui Fenster - ich sehe alle meine Geräte
deCONZ wird in der console mit ctrl+c beendet
sudo systemctl stop deconz-gui
Kein service gestartet: wenn ich in der console deCONZ starte öffnet sich auf dem Windows das deconz gui Fenster - ich sehe alle meine Geräte. Die Phoscon App ist auf Port 80 erreichbar.
In allen Fällen steht in der Kopfzeile mein conbeeII Stick mit der Angabe /dev/serial/by-id/usb....

Also das wäre schon ein sinnvoller Betrieb, man kann per default den deconz-gui Service laufen haben und verbindet sich mit deCONZ bei Bedarf. Das ganze geht in Windows sicher in einer Batch Datei.

Nachtrag: .. und ich stecke meinen conbeeII Stick wieder an meinen odroid HC1 mit docker, starte den deconz Container und alles läuft.  :P ;D

Gruß Otto

Betr. das update-Thema: MWn. braucht man für updates gar kein deCONZ-GUI, sondern die files müssen einfach beim Start von deconz an der richtigen Stelle liegen, dann werden sie automatisch verteilt, kann sein, dass es einen "Anschubser" braucht (Knöpfe drücken bei Sensoren, Aktoren kurz stromlos machen).

(Ich habe das aber schon länger nicht mehr praktisch getestet bzw. verifiziert).

Hallo,
ich konnte deine Schritte nachvollziehen und ja, es startet auch das deCONZ gui. Ich sehe allerdings nur den Koordinator und keine Geräte. Was mir aber auffällt ist, dass offenbar eine andere Konfiguration angezogen wird. In der Phoscon App heisst mein ConBee II plötzlich PhosCon GW und ist unter Port 8080 erreichbar und nicht, wie mein ZigBee-GW unter Port 80. Offenbar gibt es doch einen Unterschied zwischen decon und deconz-gui. Wenn ich die deconz-gui stpooe und dann wieder die deconz starte, habe ich auch Phoscon wieder unter Port 80 und meinen korrekten Namen. Wo stelle ich das ein, dass beides mal die richtige Konfig gezogen wird?

Christian

Finde den Unterschied - siehe auch #42 ;)
sudo systemctl cat deconz-gui
sudo systemctl cat deconz

ich denke der entscheidende Hinweis muss in der service unit stehen ???

Hi,
also ganz ehrlich. Bis auf die Display Geschichte, sieht das für mich fast identisch aus.

# /etc/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=80
Restart=on-failure
RestartSec=30
AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_KILL CAP_SYS_BOOT CAP_SYS_TIME

[Install]
WantedBy=multi-user.target

# /lib/systemd/system/deconz-gui.service
[Unit]
Description=deCONZ: ZigBee gateway -- GUI/REST API
Wants=deconz-init.service deconz-update.service
After=lightdm.service vncserver-x11-serviced.service

[Service]
User=1000
Environment="DISPLAY=:0"
ExecStart=/usr/bin/deCONZ --http-port=80
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

Manchmal sieht man ja den Wald vor Bäumen nicht, aber für mich gibt es hier jetzt keinen Hinweis, warum phoscon plötzlich auf 8080 bereitgestellt wird.

Sehr eigenartig, aber mir fällt noch was auf

# /lib/systemd/system/deconz-gui.service
# /etc/systemd/system/deconz.service

Der eine service ist konfiguriert, der andere default. Mogelt sich da noch was dazwischen?

Bearbeite doch mal beide und speichere sie ab - in der Art (Zitat aus dem Wiki (https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file)))
unit file bearbeiten
Dieser Befehl editiert die (fhem.service) unit Datei mit dem Standard Editor (z.B. nano) und führt zum Abschluss auch ein daemon-reload durch.

sudo systemctl edit --full fhem
Tipp: Datei speichern ctrl+s und Editor verlassen ctrl+x

Interessanter Hinweis ist noch: Environment="DISPLAY=:0" - da kann man vielleicht was einfacher machen? ;D

...irgendwie habe ich den Eindruck, dass das Bearbeiten der service-Files nicht zielführend ist. Jedenfalls bei einem Linux-Laptop als "entferntem Darstellungsgerät" (ssh-Tunnel mit -X) reicht es, den (minimal-) Service zu beenden, und dann "deCONZ-GUI" aufzurufen, der Rest passiert automatisch...
Kann natürlich sein, dass man in einer virtualisierten Umgebung dann noch die Schnittstelle(n) mit angeben muss, aber das ist immer noch einfacher, wie die service-files zu bearbeiten, den daemon zur Aktualisierung zu bewegen und dann den service (anders) zu starten.

Bei mir auch so - aber bei spartacus ist irgendwas verbogen? Warum startet deconz-gui und manuell deCONZ den phoscon webserver auf Port 8080 wenn doch im service File was anderes steht? Ich kann das nicht nachvollziehen.
Nimmt er im Fall  unkonfiguriert -> /lib/systemd/system/deconz-gui.service noch eine andere config?

In der virtualisierten Umgebung hat man den Vorteil, das sich deconz in der Maschine nach herzenslust an den seriellen Schnittstellen vergehen kann. Es ist eh nur die eine gemappt. :) insofern kann der Aufruf ohne Parameter gut klappen

@spartacus: was sagt which deCONZ

...kann schon sein. Gab es nicht einen speziellen Editor für systemd-files...?

Wie dem auch sei: Wenn deCONZ-GUI nicht einfach per Kommadozeile gestartet werden kann, stellt sich die Frage, warum. Würde auf ein Rechteproblem tippen - der anmeldende User muss halt auf die USB-Schnittstelle zugreifen dürfen. (Das Problem hat man mit dem systemd-Weg nicht, da kann man den User anpassen, mir ist aber nicht klar, ob der (1000) dann auf den Bildschirm darf; vermutlich schon, da "Hauptbenutzer").

Hi,
ich habe das mit dem /lib/systemd/system/deconz-gui.service  hinbekommen, aber so langsam kriege ich eine Ahnung woran es liegen könnte. Mein ConBee hing früher auch an einem Raspberry und ich habe dann über "Backup und Restore"  die lichter einfach auf der neuen VM wieder eingespielt....

Jetzt habe ich gerade unter Phoscon ein Backup gestartet und er benennt die Datei automatisch wie folgt: raspbee_gateway_config_2022-01-13.dat

ich könnte jetzt einfach das Backup unter der GUI-Deconz Version wieder einspielen, aber ob das so eine gute Idee ist?

Spartacus

So benennt er die backups immer - auch bei mir  ::)
Schau nochmal in #54 da habe ich noch was editiert gehabt

Und die Daten die gezogen werden sind bei mir in beiden Fällen gleich.

Man kann AppdData konfigurieren, aber ist ja bei Dir nicht.
https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/deCONZ-command-line-parameters

starte doch mal mit /usr/bin/deCONZ --dbg-info=2

Ich tippe ja auf sowas in der Art-> ZCLDB init file /home/pi/.local/share/dresden-elektronik/deCONZ/zcldb.txt

Zitat von: Beta-User am 13 Januar 2022, 14:23:35
...kann schon sein. Gab es nicht einen speziellen Editor für systemd-files...?

Ja - wie ich schrieb sudo systemctl edit  ;D

Moin,
iso, ich habe jetzt den deconz-gui Service gestartet und dann über Phoscon einfach das Backup eingespielt und alle Lichter sind da, auch in dem GUI. Ich denke aber, ich muss mein System einmal komplett neu aufsetzten. Ein Image oder eine Art Appliance für den Conbee als  ESXi oder sonstige VM gibt es wohl nicht.

Wenn ich die Büchse jetzt neu starte, dann läd er ja wieder deconz und nicht deconz-gui. wenn ich
systemctl disable deconz
systemctl enable deconz-gui
dann neu starte, läuft gar kein deconz auf der Mühle. Offenbar crashed deconz-gui, wenn vorher kein export des displays stattgefunden hat.

Ach so, which deCONZ sagt in beiden Fällen /usr/bin/deCONZ

Naja ich befürchte das restore ist "selbstbetrug" - vorher war die (andere) config leer, jetzt ist sie gefüllt. Aber es werden wohl zwei configs sein.
Was ist mit dem Port der phoscon App?
die deconz-gui läuft bei mir genauso wie deconz - ein export des displays braucht es nicht extra ausßerdem steht der ja in der service-unit

Neu aufsetzen ist sicher ein guter Gedanke. Ein Image gibt es als SD Card Image für den raspberry, aber da sist ne andere Architektur wie Deine NAS? Ansonsten kann man ein Image schon in einer VM starten (https://heinz-otto.blogspot.com/2021/06/linux-image-in-hyper-v-starten.html). (Ich weiß: mein Link ist nicht Deine Umgebung aber vom Prinzip her.)

nochmal die Frage mal probiert?
/usr/bin/deCONZ --dbg-info=2

Übrigens: wenn man Environment="DISPLAY=DeinWindowsCOMPUTERNAME:0.0" in die service-unit deconz-gui schreibt, geht beim Start vom Service auf dem Windows PC die deconz gui an  ;D ;D ;D

Hallo,
zumindest weiß ich jetzt, wo der Port 8080 herkommt.

cat .local/share/dresden-elektronik/deCONZ/config.ini

da steht Folgendes drin:

[N00212effff05261a]
framecounter=52234616

[controller]
apsAcksEnabled=false
autoFetchFFD=true
autoFetchRFD=true
max-aps-busy-per-node=1

[discovery]
zdp\mgmtLqiInterval=180
zdp\nwkAddrInterval=0

[http]
appcache=true
port=8080

[nodelist]
geometry=@ByteArray(\x1\xd9\xd0\xcb\0\x2\0\0\0\0\0\x3\0\0\0\x1\0\0\0O\0\0\0\x13\                        0\0\0\0\0\0\0\0\xff\xff\xff\xff\xff\xff\xff\xff\0\0\0\0\0\0\0\0\x5\0)
state=@ByteArray(\0\0\0\xff\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\x3\x1\0\0\0\0\0\0\0\0                        \0\0\0\0\0\0\0\0\0\0\x2X\0\0\0\x6\0\x1\x1\x1\0\0\0\0\0\0\0\0\0\0\0\0\x64\xff\xff                        \xff\xff\0\0\0\x84\0\0\0\0\0\0\0\x6\0\0\0\x64\0\0\0\x1\0\0\0\0\0\0\0\x64\0\0\0\x                        1\0\0\0\0\0\0\0\x64\0\0\0\x1\0\0\0\0\0\0\0\x64\0\0\0\x1\0\0\0\0\0\0\0\x64\0\0\0\                        x1\0\0\0\0\0\0\0\x64\0\0\0\x1\0\0\0\0\0\0\x3\xe8\0\0\0\0\x64)

[nodeview]
sceneRect=@Variant(\0\0\0\x14\xc0\xe4\xff\0\0\0\0\0\xc0\xe4\xff\0\0\0\0\0@\xf4\x                        ff\0\0\0\0\0@\xf4\xff\0\0\0\0\0)

[otau]
fast-page-spacing=25
sensor-dont-start=true
sensor-restart=true
sensor-slowdown=10
slow-page-spacing=250

[remote]
default\ip=127.0.0.1
default\port=8080

[source-routing]
enabled=false
max-hops=5
min-lqi=130

[window]
geometry=@ByteArray(\x1\xd9\xd0\xcb\0\x2\0\0\0\0\0\b\0\0\0\x1f\0\0\x5\a\0\0\x2\x                        b7\0\0\0\b\0\0\0\x1f\0\0\x5\a\0\0\x2\xb7\0\0\0\0\0\0\0\0\x5\0)
state="@ByteArray(\0\0\0\xff\0\0\0\0\xfd\0\0\0\x1\0\0\0\0\0\0\x1\x82\0\0\x2H\xfc                        \x2\0\0\0\x2\xfc\0\0\0;\0\0\x2H\0\0\0t\x1\0\0\x1a\xfa\0\0\0\x3\x2\0\0\0\x5\xfb\0                        \0\0\"\0S\0o\0u\0r\0\x63\0\x65\0R\0o\0u\0t\0i\0n\0g\0\x44\0o\0\x63\0k\0\0\0\0\0\                        xff\xff\xff\xff\0\0\0\xd7\0\xff\xff\xff\xfb\0\0\0\x18\0N\0o\0\x64\0\x65\0L\0i\0s                        \0t\0V\0i\0\x65\0w\0\0\0\0\0\xff\xff\xff\xff\0\0\0Y\0\xff\xff\xff\xfb\0\0\0\x16\                        0\x42\0i\0n\0\x64\0\x44\0r\0o\0p\0\x62\0o\0x\0\0\0\0\0\xff\xff\xff\xff\0\0\x1\x3                        0\0\xff\xff\xff\xfb\0\0\0\x18\0N\0o\0\x64\0\x65\0I\0n\0\x66\0o\0\x44\0o\0\x63\0k                        \x1\0\0\0\0\xff\xff\xff\xff\0\0\0;\0\xff\xff\xff\xfb\0\0\0\x1e\0\x43\0l\0u\0s\0t                        \0\x65\0r\0I\0n\0\x66\0o\0\x44\0o\0\x63\0k\x1\0\0\0\0\xff\xff\xff\xff\0\0\0Y\0\x                        ff\xff\xff\xfb\0\0\0\x1a\0S\0T\0\x44\0O\0T\0\x41\0U\0P\0l\0u\0g\0i\0n\0\0\0\0\0\                        xff\xff\xff\xff\0\0\x1\xa3\0\xff\xff\xff\0\0\x3x\0\0\x2H\0\0\0\x4\0\0\0\x4\0\0\0                        \b\0\0\0\b\xfc\0\0\0\x1\0\0\0\x2\0\0\0\x1\0\0\0\x16\0m\0\x61\0i\0n\0T\0o\0o\0l\0                        \x42\0\x61\0r\x1\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0)"

Na das ist ja ein spannender und lernender Thread geworden :)

Jetzt denke ich, wenn Du mal rm -R .local/share/dresden-elektronikmachst verhält sich dein Aufruf deCONZ ordentlich?

Hallo,
noch nicht so ganz! Wenn ich deCONZ erneut starte, legt er es wieder an.

Und dann habe ich plötzlich zwei GWs. :-(

Sag ich doch: Du hast zwei configs ... ich weiß nur noch nicht wie man die findet...

Hallo,

so, ich habe jetzt ein nacktes Debian genommen und die Kiste neu aufgesetzt und zwar exakt so, wie auf der CnoBee Seite unter Raspberry beschrieben. Wenn ich dann das GUI smit deCONZ starte, startet das Webinterface, aber er connected nicht den Stick.

enable ich wieder den deconz-gui service, dann habe ich wieder zwei Konfigurationen.

Hat also nichts gebracht.
Christian

NACHTRAG: Sobald ich die deconz-gui starte, habe ich wieder Port 8080

Ich starte deconz-gui gar nicht.

Hab auch laut DE per apt installiert...
Zusätzlich aber bei mir stehen, den deconz-gui Service zu disablen.

Bei mir ist dann Phoscon (do der "Asp-Nam") über Port 80 erreichbar...

Und mit dem korrigierten Einzeiler für Linux komm ich auf die grafische Oberfläche mit all meinen Geräten...

Halt bare metal auf einem PI3B mit RaspBee Aufsatz...

Ich gab ja noch wo einen ConBee II liegen, mal sehen...

Gruß, Joachim

Hi,
ja das klaGui startet bei mir jetzt auch.  Die Sache mit der config.ini habe ich gelöst. Nachdem ich sowohl im UserHome und unter dem Root User die Verzeichnisse gelöscht habe, wurden diese beim restart neu angelegt. Und auch mit dem richtigen Port.

rm -R .local/share/dresden-elektronik

allerdings, verbindet sich der grafische Deconz nicht mit dem Stick

Ich bin gerade zufälligerweise auch mit Conbee/deconz zu Gange, da ich meinen letzten verbleibenden RasPi noch loswerden will. An dem hängt nämlich aktuell noch der Conbee-Stick.

Ich hatte da auch so ein paar verwirrende Momente und eventuell sind die gewonnen Erkenntnisse ja auch für andere nützlich:

Ich habe also testweise mal die aktuelle Software auf einem neu eingerichteten LXC-Container mit nacktem Debian auf meinem Proxmox VE installiert, und zwar nach Anleitung von der DE-Seite: https://phoscon.de/de/conbee2/install#ubuntu

Das hat auch fast auf anhieb geklappt, ich musste lediglich noch die Pakete gpg, lsb-release und sudo installieren, die waren im LXC-Container-Image nicht dabei.

Zuvor hatte ich auch noch einen separaten User dconz angelegt, da ich den Dienst nachher unter diesem User laufen haben möchte. Die Installation selbst habe dann direkt unter diesem User (hatte dafür sudo-Rechte) durchgeführt schließlich den den Service ("deconz") enabled.

Btw.: der Service als "deconz" ist für den Headless-Betrieb gedacht und als "deconz-gui" eben für die Desktop-Variante.

Das erste was mich gewundert hat, nachdem ich auf die phoscon-App auf der neuen Maschine bin ist, dass er die ursprüngliche, also noch aktive Installation auf dem RaspPi direkt als Gateway gefunden hat, mit allem drum und dran. (Der RasPi befindet sich im selben Netzwerk, wie der LXC-Container)

Dann habe ich mich auch mal auf die Suche nach den Configs gemacht (bevor ich diesen Thread entdeckt habe) und habe die dann weder unter /etc oder unter den usern deconz, oder root gefunden.
Gefunden habe ich sie letztendlich unter dem user benni. Den hatte ich noch vor dem deconz user eingerichtet.

Ein kurzer Check hat dann gezeigt, dass der deconz-Dienst auch unter dem User benni läuft. Anscheinend ist fest der User mit der ID=1000 in der Service-Datei eingetragen. Das ist halt der erste User der in einem neuen System angelegt wird.

Ich habe dann anstatt den User deconz in der Service-Datei eingetragen, den Dienst neu gestartet und siehe da, jetzt läuft er unter dem gewünschten User und unter dem wurde nun auch neu die Config angelegt.

gb#

Hallo zusammen,

zunächst noch einmal vielen, vielen Dank für die Unterstützung und auch vielen Dank an Benni für den ausführlichen Bericht.
Die Sache mit dem User habe ich noch nicht begriffen, wo genau hast du den User geändert? In der deconz?


....
[Service]
User=1000
Environment="DISPLAY=:0"
.....

Aber nichts desto trotz. Mein Problem kriege ich nicht in den Griff. Das GUI startet, aber verbindet sich nicht mit dem Stick. Wenn ich den deconz  Service beende, den deconz-gui  Service nutze, dann verbindet sich das das GUI mit dem Stick. Das Problem dabei ist nur, dass ich das GUI ja nur zeitweise über eine ssh benötige. Und im headless Betrieb kommt der deconz Dienst nicht von alleine hoch. Ich denke nicht, dass man beide Services enablen kann, also deconz und deconz-gui.
Wahrscheinlich muss ich doch eine vm mit einem desktop installieren...

Spartacus

Die Lösung ist alles sauber zu konfigurieren, z.B. nur den deconz-gui service laufen lassen und dann bei Bedarf mit dem xlaunch verbinden. Das funktioniert bei mir einwandfrei.

Dein Problem jetzt ist ja, dass der deconz-gui service nach wie vor nicht richtig läuft!?

Ich wiederhole mich: EINEN Service laufen lassen (zwei oder mehr gehen nicht) deCONZ ist dann nur ein Client und verbindet sich zum deconz-gui. Oder den deconz-gui service mit dem rcichtigen Eintrag konfigurieren und sich direkt verbinden.

Wenn man deconz laufen lassen will, kann man den beenden und dann deCONZ starten. Würde ich aber nach jetzigen Erkenntnissen nicht machen.

Das Problem bei Benni versteh ich so, dass es mehere User mit einer jeweiligen .local/... Konfiguration geben kann. Der Befehl id auf linux Ebene gibt Auskunft über die User und deren IDs :)

Gruß Otto

Hallo Otto,
ja, der deconz-gui Service läuft nicht. Weder auf dem "alten" noch auf dem neu installierten Gerät. Und ja, den deconz-gui habe ich als einzigen Service enabled. Beim Start des Headless Servicers sheint der zu crashen....warum auch immer. Zumindest ist er nicht da. Wenn ich den export display Befehl eingebe und dann den deconz-gui dienst starte, bzw den deCONZ, dann läuft es.

Ich benötige aber einen laufenden deconz auch ohne das ich mich mit der gui verbinde. Und das ist grad mein Problem. Warum startet der deconz (mit dem Zusatz -platform minimal) aber der deconz-gui nicht.

Ich kann auch in der deconz das -platform minimal weglassen, dann crashed der dienst auch. ...das ist das Probelm und ich hab keine Idee, woran das liegt.

Hast Du mal den Environment Eintrag in der deconz-gui.service unit richtig gesetzt? Startet dann der Service?

Würde immer noch bedeuten, das der deconz-gui service crashed wenn das Display (Windows PC) beim Start nicht da ist. Das wäre blöd. Dann müssen wir uns anschauen wie das mit dem vnc server ist. Läuft ja im Docker - kann kein Hexenwerk sein.
Aber nicht mehr heute :)

Hi,
sorry, was genau meinst du damit?
wo muss ich was setzen?
in der deconz-gui steht:
Environment="DISPLAY=:0"

deconz-gui.service:
[Unit]
Description=deCONZ: ZigBee gateway -- GUI/REST API
Wants=deconz-init.service deconz-update.service
After=lightdm.service vncserver-x11-serviced.service

[Service]
User=1000
Environment="DISPLAY=:0"
ExecStart=/usr/bin/deCONZ --http-port=80
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

Genau den Eintrag so setzen wie im Dialog:
Environment="DISPLAY=DeinComputerNameOderIP:0.0"

Hi,

naja, der Computername ist weder in der deconz-gui noch in der deconz-gui.service. Das kann ich noch mal machen, aber wie gesagt, das GUI startet ja auch, aber er findet den Stick nicht!

Wie vermutet, das bringt nichts deconz-gui startet nicht. Kann man da nicht in ein log gucken? Beim systemctl start deconz-gui kommt keine Meldung.

wahrscheinlich fehlt auf meinem Debian irgendein Stück Software..aber was?

ich noch mal.

ich habe mal Folgendes eingegeben, vielleicht kann da jemand etwas gravierendes erkennen:



systemctl status deconz deconz-gui
deconz.service - deCONZ: ZigBee gateway -- REST API
   Loaded: loaded (/etc/systemd/system/deconz.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2022-01-13 22:45:11 CET; 8min ago
Main PID: 375 (deCONZ)
    Tasks: 4 (limit: 1149)
   Memory: 52.2M
   CGroup: /system.slice/deconz.service
           └─375 /usr/bin/deCONZ -platform minimal --http-port=80

Jan 13 22:45:11 conbee systemd[1]: Started deCONZ: ZigBee gateway -- REST API.
Jan 13 22:45:12 conbee deCONZ[375]: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-christian'
Jan 13 22:45:12 conbee deCONZ[375]: libpng warning: iCCP: known incorrect sRGB profile
Jan 13 22:45:13 conbee deCONZ[375]: This plugin does not support propagateSizeHints()
Jan 13 22:45:13 conbee deCONZ[375]: This plugin does not support propagateSizeHints()
Jan 13 22:45:15 conbee deCONZ[375]: This plugin does not support propagateSizeHints()

● deconz-gui.service - deCONZ: ZigBee gateway -- GUI/REST API
   Loaded: loaded (/etc/systemd/system/deconz-gui.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

Jan 13 22:53:27 conbee systemd[1]: /etc/systemd/system/deconz-gui.service:10: Unknown lvalue 'StartLimitIntervalSec' in section 'Service', ignoring

ich verweise nochmal auf #47:
deconz Service läuft deCONZ starten, er verbindet sich nicht zum Stick.
deconz beendet, deconz-gui (muss enabled sein!, deiner ist deaktiviert) gestartet, deCONZ läuft wie gewünscht.

Der Eintrag StartLimitIntervalSec ist in der deconz-gui an der falschen Stelle. Ist bei mir auch so aber scheinbar nicht das Problem.

Zitat von: Otto123 am 13 Januar 2022, 22:09:35
Das Problem bei Benni versteh ich so, dass es mehere User mit einer jeweiligen .local/... Konfiguration geben kann. Der Befehl id auf linux Ebene gibt Auskunft über die User und deren IDs :)

Die Configs, die von deCONZ verwendet werden sind halt immer unter dem der User abgelegt, unter dem der Dienst läuft. Das macht ja auch mehr oder weniger Sinn.
In der Service-Datei (bei mir die deconz.service) kann man statt der uid auch einfach den Usernamen (also bei mir deconz) eintragen, damit er den richtigen nimmt.

gb#

Edit:
Das mit dem deconz-User ist aber eine Spezialität, die v.a. mich betrifft. Bei den meisten Anwendern dürfte das mit der uid 1000 passen. Insbesondere bei einer RasPi-"Standard"-Installation sollte das der user pi sein.

Hallo zusammen,

@ Benni:
ja, danke für das Update

@Otto:
ich bin jetzt verwirrt!

• Wenn ich deconz enable, dann fährt mein Headless-System hoch und ich kann von jedem Browser auf phoscon zugreifen. fhem kann die angemeldeten Lichter steuern
• Wenn ich den deconz-gui service enable, dann fährt mein Headless System zwar hoch, aber ich kann phoscon nicht erreichen; fhem kann keine Lichter steuern.  Wenn ich dann auf der Konsole deCONZ zu Fuß starte, verbindet er sich mit dem Stick und alles läuft[, Phoscon ist erreichbar/li]
  

Ich hatte verstanden, dass das Zigbee-GW auch ganz normal im Headless Betrieb funktioniert, wenn ich anstelle des deconz-Service den deconz-gui Service aktiviere, sodass ich bei Bedarf über meinen PC das GUI starten kann.

Wenn der "enable"  deconz-gui - Service zwingend eine deCONZ GUI benötigt, bringt mir das nichts, da ich ja keine permanente ssh Verbindung von einer Windows Kiste auf den Zigbee Server mache.

Wie gesagt. Wenn ich den deconz Service disable, dann die deconz-gui-Service enable und über ssh den deCONZ starte, läuft das auch bei mir. Sobald ich aber das Fenster vom XLaunch schließe, ist der Zigbee-Server tot und die Lichtsteuerung auch.

Meine Erwartungshaltung ist, dass ich auch mit dem deconz-gui - Service einen normalen Headless-Betrieb realisieren kann und bei Bedarf mich mit einem PC auf das GUI schalte.

Was ist hier nun korrekt?

Christian

...bin ja immer noch der Meinung, dass man für den temporären Start der GUI-Version kein service-file-Getausche vornehmen sollte.

Der "Trick" scheint zu sein: deconz merkt sich beim jeweiligen User die Einstellungen. Ergo muss man beim Start der GUI-Version ggf. darauf achten, dass man sich entweder mit dem passenden User anmeldet, oder eben per "sudo -u <xyz> deCONZ-GUI" deconz mit dem richtigen User startet. Viel mehr sollte es nicht sein...

Zu deinem Sprachgebrauch: enable - startet den Dienst nicht, es aktiviert ihn! systemctl enable ist Voraussetzung für ein systemctl start.

wenn ich deconz beende und dann deconz-gui starte läuft ganz normal phoscon. Du behauptest das funktioniert bei Dir nicht. Also bei mir kann auch deconz-gui (anstatt deconz) normal laufen und ich verbinde mich bei Bedarf.
Ich habe es auf einem raspbian-lite system getestet, das ist ohne gui aber vielleicht im Gegensatz zu deinem "vorbereitet"?

Ich behaupte nach wie vor: der interaktive Aufruf von deCONZ hat zwei Funktionen / Betriebsmodi:
gar kein service läuft: der Aufruf von deCONZ wirkt als das Program schlechthin.
deconz-gui läuft: der Aufruf von deCONZ wirkt nochmal wie ein Art GUI und verbindet sich zum deconz-gui Service (so sieht es zumindest in meinen Test aus)
deconz läuft: der Aufruf von deCONZ ist nutzlos

So, nochmal anders kann ich es nicht beschreiben  :-X

@Beta-User

Zitat von: Beta-User am 14 Januar 2022, 13:29:09
...bin ja immer noch der Meinung, dass man für den temporären Start der GUI-Version kein service-file-Getausche vornehmen sollte.

das verwirrt mehr als es erklärt  ::)

Hi Otto,

dann müssen wir uns darauf konzentrieren, warum der deconz-gui bei mir nicht startet.

Um es noch einmal abzusichern:

auf der Headless Konsole:

systemctl disable deconz
systemctl enable deconz-gui

jetzt sollte nach einem Neustart doch ein deconz Service laufen, richtig?

Und eben dieser Service läuft nicht, auch nicht,  wenn ich systemctl start deconz-gui erneut eingebe.

Zitat von: Spartacus am 14 Januar 2022, 13:40:46
jetzt sollte nach einem Neustart doch ein deconz Service laufen, richtig?

...wo ist der "Bildschirm" dazu? Es gibt kein laufendes "X", da nicht per ssh verbunden...

Nochmal meine 2ct: Das enable/disable ist nicht zielführend, weil es das Verhalten beim Systemstart beeinflußt!

In der sytem-File stehen doch auch nur ein paar Parameter, die man besser direkt per Kommandozeile mitgibt, nachdem man den headless-Dienst bewußt und ausnahmsweise beendet hat.

Hallo,
also dann jetzt doch! Der deconz-gui - Service setzt zwingend eine GUI voraus! Das würde das Verhalten erklären, warum er nicht im headless Betrieb startet.

Christian

Zitat von: Spartacus am 14 Januar 2022, 13:48:23
also dann jetzt doch! Der deconz-gui - Service setzt zwingend eine GUI voraus!

Nein. Er braucht ein erreichbares X (=auch für den User zugelassenes). Das ist nach meinem begrenzten Verständnis der Materie was anderes...

Und es geht um das Programm deCONZ-GUI, das ist nicht zu verwechseln mit dem service, der (auch) dieses Programm aufruft!

Zitat von: Spartacus am 14 Januar 2022, 13:40:46
Und eben dieser Service läuft nicht, auch nicht,  wenn ich systemctl start deconz-gui erneut eingebe.

steht dazu was in journalctl ?

Ja es wird wohl so sein - es braucht eventuell ein Stück X - bei raspbian-lite ist es da und bei deinem system nicht. Da habe ich keine Idee zu - außer es so zu machen wie im deconz docker: eine tinyvnc Server dazu zu starten und der macht das X ;) muss man sich im deconz docker abgucken.

Zitat von: Spartacus am 14 Januar 2022, 13:48:23
also dann jetzt doch! Der deconz-gui - Service setzt zwingend eine GUI voraus! Das würde das Verhalten erklären, warum er nicht im headless Betrieb startet.

Nein, nur ein Stück X - quasi eine Monitor Buchse aber keinen Monitor :)

Zitat von: Beta-User am 14 Januar 2022, 13:43:36
...wo ist der "Bildschirm" dazu? Es gibt kein laufendes "X", da nicht per ssh verbunden...

Bei meinem raspbian-lite funktioniert genau das. Ohne ssh -X startet der Service

Schnelle Lösung für Spartacus!
Ist genau der Einzeiler aus dem Wiki: deconz normal laufen lassen, bei Bedarf beeenden, gui machen (phoscon läuft weiter ok wird einmal neu gestartet), gui beenden deconz wieder starten - fertig.
Das lässt sich übrigens "per doppelklick" in der Konfig von xlaunch erledigen!

Das ging ja bloß nicht wegen Deiner verkorksten extra user Konfig!?

Moin,

cool! Wir scheinen der Sache näher zu kommen. Also braucht meine Debian VM eine Monitor Buchse. Jetzt muss ich nur noch verstehen, wie ich diese anlöte :-)

Aber theoretisch müsse es doch auch so gehen.

• Headless Server booten (systemctl enable deconz)

    will man jetzt die GUI über XLaunch, dann

• deconz-Service beenden (systemctl stop deconz)
• Bildschirm extortieren: export DISPLAY=Pille:0.0
• Programm deCONZ starten
• mit GUI arbeiten

...dann XLaunch beenden

• deconz-Service starten( systemctl start deconz.)

und das dann irgendwie über den ssh-Befehl automatisieren.

Zitat von: Spartacus am 14 Januar 2022, 14:07:22
und das dann irgendwie über den ssh-Befehl automatisieren.

Das wäre dann (sollte) der Einzeiler aus dem Wiki sein ;)

Zumindest bei mir unter Linux (also "empfangender" Desktop X11) geht das genau so...

Gruß, Joachim

Hallo Joachim,

ja, das habe ich auch probiert, aber das funktioniert noch nicht korrekt. Ich nehme mal an, man muss deCONZ dann unter dem richtigen User starten, oder die ssh Verbindung mit dem User aufbauen, in dessen Kontext die headless Version läuft. Da bin ich mir nicht so sicher, ob ich das immer korrekt gemacht hatte. Das werde ich noch mal testen...

Allerdings wäre das nur ein Workaround, da man den deconz-Dienst ja kurzzeitig beendet. Cooler wäre es schon, wenn man sich mit dem GUI auf den laufenden Dienst hängt!

Christian

Zitat von: Beta-User am 14 Januar 2022, 13:29:09
oder eben per "sudo -u <xyz> deCONZ-GUI" deconz mit dem richtigen User ...

(Vorausgesetzt, sudo ist nutzbar).

Zitat von: Spartacus am 14 Januar 2022, 14:07:22
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


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.

Zitat von: Otto123 am 14 Januar 2022, 13:52:46
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

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

Zitat von: Otto123 am 14 Januar 2022, 15:36:08
@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 ::) .

@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 (https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Access-deCONZ-GUI-in-headless-setups):
Ev. ist das die Erklärung?: Bei mir sieht es so aus
cat /etc/ssh/sshd_config|grep X11
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#       X11Forwarding noIst das die "Buchse X11"?

Zitat von: Otto123 am 14 Januar 2022, 16:19:17
Aber wenn dann nicht nur mit sudo sondern mit sudo su username?

Vorschlag war gewesen:

Zitat von: Beta-User am 14 Januar 2022, 13:29:09
"sudo -u <xyz> deCONZ-GUI" deconz mit dem richtigen User

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

Zitat

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).

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?

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!

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:

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.


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


sudo ps aux|grep deCONZ


Ausgabe ist dann sowas in der Art

Zitat
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.


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:


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:


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.


lsusb


Ergebnis sieht dann in etwa so aus:

Zitat
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


ls /dev/ttyUSB*


Ergebnis sah bei mir so aus:

Zitat
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:


lsusb


Ergebnis sieht dann in etwa so aus:

Zitat
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

Zitat
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


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


Ausgabe müsste in etwa so aussehen:

Zitat
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


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


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

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


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:


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


Zitat
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:


ls -l /dev/ttyUSB*


Zitat
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:


chmod o+rw /dev/ttyUSB0


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


ls -l /dev/ttyUSB0


Zitat
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:


ls -l /dev/ttyUSB0


Zitat
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


/etc/udev/rules.d/


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


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:


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)


sudo ps aux|grep deCONZ


Zitat
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:

Zitat
/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:


[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


sudo systemctl daemon-reload


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


sudo systemctl restart deconz


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


sudo ps aux|grep deCONZ


Zitat
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:


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


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


So nun wird der Dienst wieder gestartet


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#

Zitat von: Benni am 18 Januar 2022, 21:52:02
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) (https://wiki.fhem.de/wiki/Conbee/deCONZ_im_Proxmox_LXC-Container_(Tutorial))

gb#

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 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 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

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

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:
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:
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?

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

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:
ii  deconz                          2.14.01-raspbian-buster-stable      armhf

-Beim Test bekomme ich aber immer noch diese Fehlermeldung:

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 (https://command-not-found.com/xcalc)
Ich habe dementsprechend mit
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

In der neuesten Deconz Version hat sich einiges geändert. Unter anderem werden Rollladenschalter jetzt als 'Blinds' statt als 'Switches' erkannt und sind dann aus FHEM heraus nicht mehr steuerbar.
Gibt es ein Update für das Modul oder hat sonst jemand eine Idee?

Das bezieht sich bisher nur auf die Beta (2.24.x). In der stable ist noch alles gleich. Also 2.23.2

Weiß einer ob der ConbeeIII stick compatibel mit dem ConbeeII ist?
Also Backup des II auf den III flashen und funktioniert dann?
Phoscon App scheint ja die gleiche zusein.

Edit: Hab es jetzt doch selbst heraus gefunden.
https://phoscon.de/de/conbee3/upgrade (https://phoscon.de/de/conbee3/upgrade)
geht wohl so easy

ZitatEdit: Hab es jetzt doch selbst heraus gefunden.
https://phoscon.de/de/conbee3/upgrade
geht wohl so easy

Nach dem Wechsel von ConBee II auf ConBee III wie in dem Link beschrieben, wird in Phoscon der ConBeeIII als Gateway korrekt angezeigt, und alle Devices sind auch in Phoscon vorhanden. Aber von meinen 54 deConz Devices hat bei mir nur 1 Bewegungsmelder funktioniert. Die anderen Sensoren waren alle ausgegraut (also nicht erreichbar) angezeigt. Weder Plugs, Switches noch die Ikea Blinds liessen sich bedienen. Von den Bewegungsmeldern hat nur einer auf motion reagiert (also ich spreche hier nur von Phoscon Webinterface, wo man motion/noMotion erkennen kann). Trotz mehrmaligem restart des deConz services, hat sich das nicht geändert.
Ich bin erstmal wieder auf den ConBee II zurück, damit funktioniert wieder alles wie vorher.

PS: Unter https://phoscon.de/de/conbee3/install#ubuntu findet man die Installationsanleituing für den ConBee III, da gibts unter Ubuntu noch eine zusätzliche UDEV Regel zu erstellen, auch das hat nicht geholfen.

Hi,
laut Phoscon-Support ist die deCONZ-version 2.24.x Voraussetzung für den ConBee III-Stick.
Damit funktioniert die Migration von ConBee II nach ConBee III bei mir jetzt mit dem ConBee III Stick wie folgt:
- Deconz update auf v2.24.2 (Siehe https://github.com/dresden-elektronik/deconz-rest-plugin/releases)
- Der Anleitung von https://phoscon.de/de/conbee3/upgrade folgen

Damit werden bei mir alle Devices erkannt. Bei einigen Sensoren und Tastern muss man einige Minuten warten, bis das nächste Protokoll gesendet wird. Nur OSRAM Plugs musste ich neu anlernen. Das ging aber, ohne den OSRAM plug in FHEM oder Phoscon zu löschen (Name bleibt erhalten sowohl in FHEM als auch in Phoscon, und das Device bleibt in FHEM erhalten). Einmal in Phoscon "anlernen"drücken, und dann den OSRAM Plug knopf solange gedrückt halten bis das Relais 2 x klickt. 

Gruss, Jamo