Conbee II und deCONZ

[Spartacus]

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?

[Spartacus]

ich noch mal.

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

Code Auswählen Erweitern


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

[Otto123]

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.

[Benni]

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.

[Spartacus]

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

[Beta-User]

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

[Otto123]

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 

@Beta-User

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

[Spartacus]

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:

Code Auswählen Erweitern

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.

[Beta-User]

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.

[Spartacus]

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

[Beta-User]

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!

[Otto123]

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.

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

...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!?

[Spartacus]

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.

[MadMax-FHEM]

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

[Spartacus]

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