Zigbee2Mqtt Zigbee2Server nach Neustart mit allowed nicht erreichbar

flummy1978 · 05 Mai 2020, 23:37:30

Hallöchen,

ich hab da ein kleines Problem zu dem ich etweder zu doof war zu suchen, oder es einfach nicht das richtige gab .... ich finde da einfach nichts zu:

Ich habe einen Zigbee2Server und ein Zigbee2Mqtt angelegt und mit diversesten Zigbee und anderen MQTT Devices verbunden. Alles funktioniert soweit wunderbar. Auch die Geräte sind separat nochmal mit allowed abgesichert. Genau hier ist aber mein "Problem". Nach einem Neustart ist es manchmal so, dass die Zigbee Geräte nicht erreichbar sind (Ich kann die Steckdosen nicht steuern) - Ob die Geräte dann auch nichts senden können, bzw hier nichts ankommt, kann ich nicht direkt sagen weil ich fast immer beim Basteln neu starte-> Da teste ich es dann immer direkt und mal geht die steckdose mal nicht. Wenn nicht:
Einmal AEG .... (Ausschalten, Einschalten Geht wieder

) sudo systemctl stop zigbee2mqtt und sudo systemctl start zigbee2mqtt im Pi und schon läuft alles wie gehabt.....

Hat jemand eine Idee woran das liegen kann, bzw was ich tun kann um das zu verhindern ?

Ich habe das Gefühl dass Zigbee manchmal beim Neustart "zu schnell" ist und deshalb nicht richtig in das allowed kommt (ansonsten kann ich mir nicht erklären, warum es manchmal einwandfrei funktioniert )

Würde mich freuen, wenn da jemand einen Tipp für mich hätte

Vielen Dank im Voraus
Grüße
Andreas

rudolfkoenig · 06 Mai 2020, 09:34:34

Vielleicht steht im FHEM-Log ein Hinweis.
Wenn nicht, mag "attr global verbose 5" helfen.

Was bedeutet "nicht richting in das allowed kommt"?

Otto123 · 06 Mai 2020, 09:39:24

Hallo Andreas,

Zitatsudo systemctl stop zigbee2mqtt und sudo systemctl start zigbee2mqtt

klingt danach als ob dieser Dienst vor dem FHEM / MQTT startet.
Also würde ich im Unitfile (/etc/systemd/system/zigbee2mqtt.service) eine Verzögerung bzw. Abhängigkeit einbauen.
z.B mal probieren.:

Code Auswählen

[Unit]
...
After=fhem.service

Damit startet dann erstmal FHEM und danach der zigbee2mqtt

Gruß Otto

flummy1978 · 06 Mai 2020, 11:43:34

Guten Morgen,

vielen Dank für Eure bisherigen Antworten. Ich werde es auf jeden Fall mal umsetzen und testen (möchte nur ungern mein live System ständig neustarten, also gibt es erst beim nächsten Ausfall, den verbose 5 test)

Zitat von: rudolfkoenig am 06 Mai 2020, 09:34:34
Was bedeutet "nicht richting in das allowed kommt"?

Damit meine ich, dass ich vor dem allowed Einrichten für MQTT (und den Broker) keine Probleme damit hatte und es für mich also so aussieht als würde der zigbee service an allowed scheitern, obwohl korrekt eingerichtet ist und sonst normal läuft. Als ich es eingerichtet lief es ja auch von Anfang an und nach nem Neustart habe hab ich ewig gesucht bis ich durch Zufall drauf gekommen bin, dass ein aeg immer funktioniert.

@Otto: Deine Aussage (als Erfahrener Linux Mensch - ich bin da eher noch weniger als n Neugeborenes und copy und paste User

) würde ja meine Vermutung stützen und ist definitiv eine einfach Variante das zu testen.

Code Auswählen


[Unit]
Description=zigbee2mqtt
After=network.target
After=fhem.service

So müsste das dann aussehen ? Auch diese Variante kann ich erst nach mehreren Neustarts - weil der o.g. Fehler gefühlt nicht bei jedem Neustart auftrat.

Auf jeden Fall vielen herzlichen Dank Euch beiden .... Ich werde berichten

Viele Grüße
Andreas

Otto123 · 06 Mai 2020, 11:52:35

ich bin weit entfernt vom erfahrenen Linux Menschen

Ja, so war meine Idee, eventuell kann man auch noch zusätzlich in der Art eine Zeitverzögerung von wenigen sec (Beispiel 3) einbauen:

Code Auswählen

[Service]
...
ExecStartPre=/bin/sleep 3

ich bin nicht sicher wie schnell an das System "fertig" gemeldet wird

Aber vielleicht bin ich ja auch auf dem falschen Pfad ...

flummy1978 · 06 Mai 2020, 12:17:56

Hey,

Zitat von: Otto123 am 06 Mai 2020, 11:52:35
ich bin weit entfernt vom erfahrenen Linux Menschen

das nehme ich und schreibe das jedes Mal, wenn es für mich so aussieht, als würdest Du aus dem Kopf irgendwelche Hieroglyphen hervorzaubern

Mal im Ernst ... auch wenn ich in der Tat noch weniger Erfahrung hab was Linux angeht, so klingt für mich der Vorschlag schon nachvollziehbar und habs schon eingesetzt. Da ich heute auch wieder rumbasteln werde und ein DbLog Sync testen werde, bin ich mir sicher zwingt mich irgendwas bestimmt zu dem einen oder anderen Neustart
Ansonsten wird die zweite Variante getestet

Vielen Dank und
Grüße
Andreas

flummy1978 · 26 Mai 2020, 12:44:22

Aloha,

ich muss leider den Beitrag von "damals" nochmal nach oben ziehen....... $:-\$
Nun sind einige Wochen vergangen und in der Zwischenzeit gab es den einen oder anderen (selbstverschuldeten) Absturz oder auch normales Update.

Code Auswählen

[Unit]
...
After=fhem.service

Hat leider keine Besserung gebracht. Ich denke mal das würde IMMER funktionieren, wenn ich komplett neustarten würde. Aber in diesem Fall starte ich ja jeweils nur FHEM neu. D.h. der RasPi ansich stürzt ja nicht ab.
Nun stehe ich aber ehrlicherweise wie n "Ochs vorm Berg" weil ich absolut keine Idee habe, wie ich dem RasPi beibringen könnte, nach Neustart von Fhem (also auch im laufenden RasPi Betrieb) den Zigbee Service stop -> start ausführen könnte. Denn das ist genau das was ich manuell machen muss und schon läuft es.....

Würde mich freuen, wenn da jemand noch ne Idee hat

Edith hängt noch an: Hab grad das entsprechende Problem da und habe festgestellt, dass ich von der Steckdose aus schalten kann (Osram Smart+) und das Signal ankommt und verarbeitet wird. Wenn ich allerdings von Fhem aus schalte, kommt der "MQTT2_DEVICE REL_dev_Osram_plus on" Befehl zwar raus, aber sonst passiert nichts.

Viele Grüße
Andreas

MadMax-FHEM · 26 Mai 2020, 13:23:37

Notify auf global:INITIALIZED (das signalisiert den fhem Start) und dann den service restarten...

https://forum.fhem.de/index.php?topic=87503.0

Für den User fhem dann eine sudoers anlegen (Kopie der vorhandenen Datei für den User pi):

Code Auswählen


sudo cp /etc/sudoers.d/010_pi-nopasswd /etc/sudoers.d/010_fhem-nopasswd

und dann dort eben den User pi durch fhem ersetzen und dann noch entsprechend nur auf den benötigten Dienst einschränken...

Code Auswählen


sudo visudo -f /etc/sudoers.d/010_fhem-nopasswd

http://heinz-otto.blogspot.com/2017/08/raspberry-ausschalten-mit-fhem.html
https://forum.fhem.de/index.php?topic=95284.0

Gruß, Joachim

Otto123 · 26 Mai 2020, 13:45:46

Naja das wird etwas komplexer. Denn so würde er ja jetzt beim normalen Systemstart den zigbee erst nach fehm starten um ihn dann neu zu starten. Kann problemlos sein - mir wäre es unangenehm

Spontan (ins Unreine gedacht):
den normalen Zigbee start wieder deaktivieren
Beim Start von FHEM zigbee (re)starten (wie Joachim geschrieben hat)

Oder man müsste mal schauen ob systemd das besser kann (nachschauen ob fhem läuft) und bei Bedarf einen restart auslösen.

Oder man müsste nur eine unit (fhem) machen, dort im ExecStartPre zigbee starten und im ExecStartPost beenden.

Erste variante geht schnell? Letzte Variante braucht kein sudo ...

Gruß Otto

MadMax-FHEM · 26 Mai 2020, 13:47:53

Ja das mit Deaktivieren hatte ich auch schon überlegt bzw. wäre ja dann das Startscript mit dem Eintrag auf fhem warten nicht mehr nötig...

...aber da wollte ich mich nicht "einmischen"

Aber schadet so ein service-Restart!?

Wäre ja nur bei einem kompletten Reboot...

EDIT: bzw. statt restart bei dem Notify ein start!? Würde das nicht bei bereits laufendem Service ignoriert!? EDIT: Quatsch! Dann ist ja bei fhem Restart "essig"...

Gruß, Joachim

Beta-User · 26 Mai 2020, 13:50:14

Vielleicht wäre es zielführend, nicht an den Symptomen rumzudoktern, sondern erst nochmal zu beleuchten, warum da was passiert (oder eben auch nicht:

Zitat von: rudolfkoenig am 06 Mai 2020, 09:34:34
Vielleicht steht im FHEM-Log ein Hinweis.
Wenn nicht, mag "attr global verbose 5" helfen.

Was bedeutet "nicht richting in das allowed kommt"?

Denn entweder Rudi's Module machen da was nicht "richtig" (vermutlich eher: nicht fehlertolerant genug für z2m), oder auf der zigbee2mqtt-Seite ist was verbesserungswürdig, dann wäre kkoenk vermutlich froh, davon was zu erfahren...

(Wenn man es auf diese Weise löst, brauchen wir keine "Pillen für alle"...)

Otto123 · 26 Mai 2020, 14:08:19

Du hast natürlich Recht - aber
die "Pille für Alle" wäre in dem Fall:
Wie gehe ich mit einem Dienst/(oder was anderem) um den ich nur für FHEM brauche, der vorausgesetzt das schon etwas läuft (FHEM/mqtt2-Server)...
Starten und beenden "mit FHEM"

@Joachim: Machst Du früh dein Auto immer - an aus an - um dann loszufahren?

MadMax-FHEM · 26 Mai 2020, 14:10:27

Zitat von: Otto123 am 26 Mai 2020, 14:08:19
@Joachim: Machst Du früh dein Auto immer - an aus an - um dann loszufahren?

Naja der Vergleich ist schön (und mir schon klar) aber er hinkt ein wenig weil mein Auto in der Regel nicht dazu da ist durchzulaufen...
...und wenn dem so wäre würde es mir ein ab und an "Doppelstarten" schon mal verzeihen...

EDIT: bzw. andersrum könnte man ja auch statt einem fhem Neustart (wie oft soll das sein) halt auch einen Reboot machen und dann sollte ja auch jetzt schon alles gut sein

Gruß, Joachim

Beta-User · 26 Mai 2020, 14:54:39

Zitat von: Otto123 am 26 Mai 2020, 14:08:19
Wie gehe ich mit einem Dienst/(oder was anderem) um den ich nur für FHEM brauche, der vorausgesetzt das schon etwas läuft (FHEM/mqtt2-Server)...

Das ist ja grade der Punkt: eigentlich ist MQTT doch ein Netzwerkprotokoll, das auf Verbindungsabbrüche von beiden Seiten "angemessen" reagieren sollte - ganz egal, auf welcher Seite das Problem besteht. Und es ist doch egal, ob zigbee2mqtt nur für FHEM gebraucht wird oder noch für was anderes, oder?

Jedenfalls: diese "sytemd-Lösung" setzt voraus, dass es dieselbe HW ist, auf der alles läuft. Das ist bei nicht wenigen Usern grade nicht der Fall, von daher würde ich immer noch primär danach sehen, dass alles auf der Netzwerkebene sauber miteinander kommuniziert - unabhängig von der Startreihenfolge (auf einer Hardware)...

flummy1978 · 26 Mai 2020, 16:11:17

Holla,

Puuuhhh da geht man "mal eben" mit dem Hund raus, saugt und wischt die Wohnung und hat direkt mal eben 10 Beiträge Fachchinesisch zu lesen

Zunächst einmal vielen herzlichen Dank an Euch alle, dass Ihr Euch so intensiv um mein Problem bemüht. Ich versuche auf alles einzugehen:

MadMax & Otto: Das was Ihr da über RasPi (Linux) Autostart und Services erzählt ist für mich absolut unverständliches Wirrwarr. Wenn ich etwas davon umsetze, dann nur 1:1 nach Anweisung und weiss eigentlich kaum was ich da tue. Demnach kann ich natürlich nicht beurteilen was sinnvoll wäre und was nicht.

@Beta-User: Es macht schon viel Sinn nicht zu warten bis man ins Loch getreten ist und der Fuß nass ist, den man dann abtrocknen muss, sondern vorher das Loch beseitigen ... Soll heißen, der Vorschlag von Beta-User respektive Rudi macht schon am Meisten sinn. ALLERDINGS habe ich beim erstmaligem Test nichts gesehen, was auf ein "hängen" von Z2M schließen würde. Was mich wundert ist, was ich oben im Edit geschrieben habe: Empfangen ist kein problem. Nur den Befehl senden von FHEM aus (in dem Fall an eine Steckdose) - Macht er dann ohne Neustart nicht. Vielleicht kann ich das morgen nochmal umsetzen (heute schaffe ich es nicht). Wobei ich mir dann sicher bin, dass dann der Start ohne Probleme klappen wird ;(

Wenn ihr irgendwie Tipps habt wie / wonach ich explizit achten muss, versuche ich es. Es wäre für mich natürlich schon von größerer Bedeutung wenn nicht nur mein Problem erledigt ist, sondern vielleicht auch andere mit entsprechendem Problem das Ganze lösen könnten.

ZitatJedenfalls: diese "sytemd-Lösung" setzt voraus, dass es dieselbe HW ist, auf der alles läuft. Das ist bei nicht wenigen Usern grade nicht der Fall,

Wäre bei mir aktuell (noch) die Gleiche Hardware, aber wer weiß wie es später mal wird.

ZitatEDIT: bzw. andersrum könnte man ja auch statt einem fhem Neustart (wie oft soll das sein) halt auch einen Reboot machen und dann sollte ja auch jetzt schon alles gut sein

Absolut richtig, aber dazu habe ich einen Einwand:
Fhem Neustart: Update bei Fhem-> Aus Fhem heraus das Update, neustart wird sauber durchgefahren, DB wird gestoppt etc -> Test ob Zigbee geht -> geht .... weitermachen
Raspi Neustart: Update bei Fhem-> Aus Fhem heraus das Update, neustart wird sauber durchgefahren, DB wird gestoppt etc -> Test ob Zigbee geht -> geht nicht -> Console auf -> Zigbee Stop / Start -> weitermachen

Bei einem "richtigen Neustart würde das Sauber runter fahren entfallen und ich müsste in JEDEM Fall in die Console (also kein Unterschied zu jetzt)
Es bringt mich nicht um, aber ich weiß bei sowas immer gern, warum das passiert. Wenn es wer weiß wie umständlich ist das zu umgehen, lasse ich es und starte dann von Hand neu, aber manchmal ist die Lösung dann doch sehr einfach

Viele Grüße
Andreas