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
Vielleicht steht im FHEM-Log ein Hinweis.
Wenn nicht, mag "attr global verbose 5" helfen.
Was bedeutet "nicht richting in das allowed kommt"?
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.:
[Unit]
...
After=fhem.serviceDamit startet dann erstmal FHEM und danach der zigbee2mqtt
Gruß Otto
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.
[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
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:
[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 ...
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 ;D
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
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.
[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
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):
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...
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
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
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
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"...)
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? ;D
Zitat von: Otto123 am 26 Mai 2020, 14:08:19
@Joachim: Machst Du früh dein Auto immer - an aus an - um dann loszufahren? ;D
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
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)...
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 :D
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
Hmm, wenn im FHEM-log nichts sinnstiftendes steht, wäre evtl. mal interessant, wie die z2m-Seite der Medaille aussieht. Also: steht da was im Log? Eigentlich müßte da dann irgendein abgewiesener Verbindungsversuch oä. zu sehen sein? (Ggf. auch da mal den verbose-Level hochdrehen).
Wenn auch da nichts zu sehen ist, ist das schwierig, aber evtl. wäre es wenigstens sinnvoll, einen issue/report bei github/z2m aufzumachen?
Hallo Andreas,
ich denke mir was aus, auch wenn es bloß ein würgaround ist für diesen Fall.
Brauch etwas Zeit.
Gruß Otto
Gelesen, nachgedacht - aber nicht geprüft:
Eine Zeile ergänzen
[Unit]
...
After=fhem.service
PartOf=fhem.serviceSollte eventuell das tun was Du erwartest :)
ZitatPartOf=
Configures dependencies similar to Requires=, but limited to stopping and restarting of units. When systemd stops or restarts the units listed here, the action is propagated to this unit. Note that this is a one-way dependency — changes to this unit do not affect the listed units.
When PartOf=b.service is used on a.service, this dependency will show as ConsistsOf=a.service in property listing of b.service. ConsistsOf= dependency cannot be specified directly.
Probier doch mal, wird schon schief gehen :)
Ob er wirklich zigbee2mqtt mit neu startet wenn Du fhem neu startest siehst Du ja am Status - neue PID :)
Gruß Otto
Hallo Ihr zwei,
Natürlich auch alle anderen :)
Zitat von: Beta-User am 26 Mai 2020, 16:30:23
Hmm, wenn im FHEM-log nichts sinnstiftendes steht, wäre evtl. mal interessant, wie die z2m-Seite der Medaille aussieht. Also: steht da was im Log? Eigentlich müßte da dann irgendein abgewiesener Verbindungsversuch oä. zu sehen sein? (Ggf. auch da mal den verbose-Level hochdrehen).
Hab auch das nochmal probiert indem ich zwei mal neu gestartet habe, und den Zigbee Log hab mitlaufen lassen. Dort kommt der Befehl dann scheinbar eben nicht an:
2020.05.27 13:05:20.319 5: POST /fhem?cmd.REL_dev_Osram_plus=set%20REL_dev_Osram_plus%20on&XHR=1&fwcsrf=csrf_573858891370129&fw_id=389 HTTP/1.1
Host: raspi:52704
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0
Accept: */*
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://raspi:52704/fhem?room=B%c3%bcro%20%2f%20G%c3%a4ste
X-Requested-With: XMLHttpRequest
Origin: http://raspi:52704
DNT: 1
Connection: keep-alive
Cookie: fhemCmdHistory=set%20WEBphone%20rereadicons%0Arereadcfg%0Areload%20flex.js%0Areload%20flexstyle.css%0Atrigger%20TK_EG_BD_FENSTER_RE%20state%20closed%0Adeletereading%20TK_EG_BD_FENSTER_LI%20state_FR%0Atrigger%20TK_EG_BD_FENSTER_LI%20state%0Asetreading%20Licht_EG_WZ_01_deckenfluter%20BH1750_Illuminance%2040200%0Ashutdown%20restart; flexFingerprint=418f79c2ac7054b78a472095d2a8877d
Content-Length: 0
2020.05.27 13:05:20.320 4: WEB_192.168.0.3_65306 POST /fhem?cmd.REL_dev_Osram_plus=set%20REL_dev_Osram_plus%20on&XHR=1&fwcsrf=csrf_573858891370129&fw_id=389; BUFLEN:0
2020.05.27 13:05:20.321 5: Cmd: >set REL_dev_Osram_plus on<
2020.05.27 13:05:20.322 5: brok_MQTT2: PUBLISH zigbee2mqtt/0x84182600000f37fd/set ON
2020.05.27 13:05:20.329 5: Starting notify loop for REL_dev_Osram_plus, 1 event(s), first is on
Sind dann die entsprechenden Zeilen die im verbose 5 Log. Ich sehe da soweit nichts, was da gegen sprechen würde, zumal zu diesem Zeitpunkt im Zigbee Log selbst eben einfach mal NICHTS steht. Schalte ich jetzt vom Device direkt aus, steht folgendes im Zigbee Log und das Gerät schaltet (auch in der FhemWEB UI und im Eventmonitor ist es ganz normal zu sehen):
Mai 27 13:16:52 fhempi npm[13594]: zigbee2mqtt:info 2020-05-27T11:16:52: MQTT publish: topic 'zigbee2mqtt/REL_dev_Osram_plus', payload '{"state":"ON","linkquality":26}'
So kann ich da erstmal nichts erkennen. Daher würde ich einfach mal auf Ottos Vorschlag zurück kommen:
Zitat von: Otto123 am 26 Mai 2020, 17:06:22
ich denke mir was aus, auch wenn es bloß ein würgaround ist für diesen Fall.
Ein Würgaround klingt für mich wie im Handwerk ein Provisorium und der passende Spruch dazu: Nichts hält länger / besser als ein Provisorium ;)
Nu mal im Ernst: Vielen vielen Dank fürs Gedanken machen.... Die Erklärung zu PartOf klingt plausibel, dass es das sein könnte was ich benötige. Ergo werde ich das einfach mal einfügen und teten :)
Viele Grüße
Andreas
Hallo,
wenn das mit dem PartOf funktioniert wäre das für mich relativ "sauber" - Abhängigkeiten gibt es überall mal und es wäre ein Weg es ordentlich zu lösen.
Was da im Log steht klingt für mich wenig nach mqtt ?
Nur noch mal laut gedacht: zigbee2mqtt ist doch ein mqtt Client? Der mqtt2server ist der broker.
Nach dem Neustart geht das "senden" an den Client nicht, d.h. der broker published und der client hört nicht zu, weil er die Anmeldung verschlafen hat?
Der Client sagt sich: der Broker wollte nicht, jetzt tue ich auch dumm?
So funktioniert doch mqtt nicht? Da finden die beiden ja bei einem ungeordneten Neustart nie zu einander?
Kann man eine Client vom Broker aus "einen Wecker" ans Ohr halten?
Gruß Otto
Zitat von: Otto123 am 27 Mai 2020, 15:30:41
Nur noch mal laut gedacht: zigbee2mqtt ist doch ein mqtt Client? Der mqtt2server ist der broker.
Nach dem Neustart geht das "senden" an den Client nicht, d.h. der broker published und der client hört nicht zu, weil er die Anmeldung verschlafen hat?
Der Client sagt sich: der Broker wollte nicht, jetzt tue ich auch dumm?
Genau. Eine der beiden Seiten verhält sich nicht "MQTT-like". Das ist der Punkt.
Das eigentliche Problem hat mMn. nichts mit Startreihenfolgen zu tun, es ist wichtig, dass wir das an anderer Stelle gelöst bekommen (ich habe nur nach flummy1978's logs auch weiter keine Idee, was schräg ist).
Was ihr mal noch testen könntet: mit "retain" senden, also an das Topic ein ":r" ranpappen.
Dann wäre interessant, ob es ggf. einfach zu schnell war und die Verbindung zu einem späteren Zeitpunkt dann wieder steht? Der M2Server hat wohl einen Timeout auf 1,5x der vom Client (z2mqtt) angekündigten Rückmeldezeit (für "last will"), es ist also eigentlich nur die Frage, ob es die gibt. Vieleicht haben auch beide Seiten ein unterschiedliches Verständnis davon, wann die Verbindung "tot " ist?
(Gibt es denn in der yaml eine Option, einen last will festzulegen? Sollte soweit ich mich entsinne in state stehen, oder?)
Jedenfalls meine ich, wir sollten ggf. mal Rudi fragen, ob er eine Idee hat. systemd ist jedenfalls weiter m.E. kein gutes Provisorium.
Da sind se wieder ... Hieroglyphen oder Chinesisches dem ich nicht folgen kann :o
Ich bin ehrlich, was den Teil angeht steh ich da jetzt wirklich wie n Ochs vorm Berg und hab da keine Ahnung von, aber vielleicht kann ich ja was tun um es zu verbessern:
ZitatWas ihr mal noch testen könntet: mit "retain" senden, also an das Topic ein ":r" ranpappen.
Wie genau mache ich das ? An den Set Befehlt pappen, also
off zigbee2mqtt/0x12345678900037fd/set OFF[color=red]:r[/color] oder bin ich da komplett falsch?
ZitatDann wäre interessant, ob es ggf. einfach zu schnell war und die Verbindung zu einem späteren Zeitpunkt dann wieder steht?
Als ich die Verbose 5 Geschichte gemacht hab, und bevor ich gestern Ottos Ergänzung eingepflegt hab, ging es ja von der Oberfläche aus nicht. Da habe ich es mehrmals getestet ich würde sagen ca. auch 15 Min später ging es immernoch nicht.
Zitat(Gibt es denn in der yaml eine Option, einen last will festzulegen? Sollte soweit ich mich entsinne in state stehen, oder?)
Äähhh ???
Mal ehrlich ich bin der Meinung ich komme in vielen Bereichen klar, aber in solchen Momenten wird mir doch klar, dass es maximal Grundlagen sind. Sobald es tiefer rein geht, isses vorbei ;D Daher danke nochmals für Eure Mühe und bisherige Hilfe :)
Viele Grüße
Andreas
Na dann entziffern wir die Hyroglyphen mal mit Hilfe der commandref (MQTT2_DEVICE):
Zitat
- setList cmd [topic|perl-Expression] ...
When the FHEM command cmd is issued, publish the topic. Multiple tuples can be specified, each of them separated by newline, the newline does not have to be entered in the FHEMWEB frontend. Example:
attr dev setList\
on tasmota/sonoff/cmnd/Power1 on\
off tasmota/sonoff/cmnd/Power1 off
This example defines 2 set commands (on and off), which both publish the same topic, but with different messages (arguments).
Notes:[...]
- [if the topic name ends with :r, then the retain flag is set
Ergibt
off zigbee2mqtt/0x12345678900037fd/set:r OFFDanke mal für die Rückmeldung, dass das nicht "selbstheilend" ist (15 Min sollten reichen).
Und ja: Das ganze Thema ist nicht wirklich einfach (das ist es nur, wenn es funktioniert, wie es sollte...). Grade deswegen ist es ja mMn. wichtig, eventuelle Schwachstellen aufzudecken.
Zu dem yaml: Gemeint ist die Konfigurationsfile von zigbee2mqtt, und "last will" ist eine "Spezialität" von MQTT. Ein Client kann ankündigen, wann er sich spätestens wieder melden wird, und der Broker wird angewiesen, eine entsprechend gekennzeichnete Message (erst) dann auszuliefern, wenn er das nicht tut (bei Tasmota geht dann z.B. das Device "Offline". Das ist aber wie gesagt keine direkte Nachricht vom Client, sondern eine Info vom Server, die bedeutet, dass sich der Client eben nicht "absprachegemäß" und rechtzeitig gemeldet hat).
Weitere Info dazu, ob und was man da einstellen kann, findet sich ggf. in der Doku des zigbee2mqtt-Projekts (ich habe das nicht mehr installiert und will das daher auch nicht selbst vertiefen).
EDIT: Vielleicht kannst du mal einen weiteren M2Server (ohne global) definieren, und dann mal testen, ob es ohne allowed klappt, dass sich beide Dienste wieder sauber verbinden (bei localhost macht allowed mMn. sowieso nicht den großen Sinn). Dazu eben einen anderen Port nehmen, z.B. 1884.
Hey,
vielen Dank für die Übersetzung der einzelnen Teile..... Ich muss mal schauen wie ich das Ganze umsetzen kann. Ich gehe aber mal davon aus, dass ich die Ergänzungen von Otto weg machen muss um sicher zu gehen, dass diese nicht dazwischen funken? Den Befehl dann zu ergänzen ist ja nicht das Problem.
Yaml hätte ich noch zugeordnet. LastWill im Bezug auf Zigbee auch noch, aber was damit umzusetzen, wie und warum ? ... da bin ich vollkommen raus ;(
ZitatUnd ja: Das ganze Thema ist nicht wirklich einfach (das ist es nur, wenn es funktioniert, wie es sollte...). Grade deswegen ist es ja mMn. wichtig, eventuelle Schwachstellen aufzudecken.
Immerhin, da bin ich jetzt wirklich beruhigt. Tatsächlich hatte ich am Anfang wohl das Glück, dass relativ viel / relativ schnell funktionierte somit hat mich das auch nicht weiter beschäftigt, wie kompliziert es im Hintergrund abgeht.
Was mich allerdings noch stutzig macht / interessiert sind folgende Punkte:
Zitat
1. (ich habe das nicht mehr installiert und will das daher auch nicht selbst vertiefen).
2. EDIT: Vielleicht kannst du mal einen weiteren M2Server (ohne global) definieren, und dann mal testen, ob es ohne allowed klappt, dass sich beide Dienste wieder sauber verbinden
3. (bei localhost macht allowed mMn. sowieso nicht den großen Sinn).
4. Dazu eben einen anderen Port nehmen, z.B. 1884.
1. Wie hast Du denn eine derartige (zigbee) Verbindung gelöst ? Ich habe gesehen, dass Du bsw. auch über die Aqara Taster nachgedacht hast, bzw diese testest ?
2. Puuuhh irgndwie hab ich vor sowas am live System immer etwas Respekt, weil dort ja der Stick drin steckt *lach*
- Wie genau sag ich dem Ding denn dem M2Server dass er jetzt auch auf zigbee2mqtt hören soll / muss ? und funktioniert dann der Rest denoch weiter ?
- Was meinst Du mit ohne global ?
Irgendwie werde ich so das Gefühl nicht los, dass die eigentliche Problematik an meiner Config liegt: Ich habe zigbee_bridge (MQTT2_DEVICE) und brok_MQTT2 (MQTT2_SERVER) und damit zu Punkt 3....
3. Grundsätzlich ja. Das war auch mein Gedanke. Denn Geräte die ich direkt an der Zentrale anlerne, müssen nicht auch noch local zusätzlich mit einem Passwort geschützt werden. ABER... als ich das allowed gesetzt habe und dort
validFor:WEB,brok_MQTT2 hinzugefügt habe (also meine Web Oberfläche und den M2Server dazu genommen habe) hat es logischerweise bei jeder MQTT Verbindung von Shelly / Tasmota etc Bereichen genauso ein passwort verlangt, wie bei den Zigbee Verbindungen. Das zum Laufen zu bekommen, war schon sehr sehr haarig, weil dort jedes Leerzeichen, Leerzeile wichtig sind, was ich bis dato von einer Config File nicht kannte......
4. Keine der Verbindungen zum Raspi geht über irgendwelche Standardports ;)
Viele Grüße
Andreas
Zitat von: flummy1978 am 28 Mai 2020, 12:31:00
1. Wie hast Du denn eine derartige (zigbee) Verbindung gelöst ? Ich habe gesehen, dass Du bsw. auch über die Aqara Taster nachgedacht hast, bzw diese testest ?
Siehe Signatur: via deconz (ohne docker, direkt über das Debian-Paket).
Zitat2. Puuuhh irgndwie hab ich vor sowas am live System immer etwas Respekt, weil dort ja der Stick drin steckt *lach* - Wie genau sag ich dem Ding denn dem M2Server dass er jetzt auch auf zigbee2mqtt hören soll / muss ? und funktioniert dann der Rest denoch weiter ?
- Was meinst Du mit ohne global ?
Das ist grundsätzlich auch gut so mit dem Respekt!
Du kannst mehrere MQTT-Server haben, und eben auch mehrere MQTT2_SERVER in einer Installation. Normalerweise macht man das via
define M2Server MQTT2_SERVER 1883 globalDas legt den Port fest und erlaubt (ohne allowed) Zugriffe aus dem lokalen Netz. Ergo macht
define M2Server2 MQTT2_SERVER 1884einen weiteren Serverdienst unter Port 1884 auf, der aber nur auf localhost hört. Das reicht dir hier ja, um Punkt 3 auf FHEM-Seite "abzufrühstücken"... (1884 ist nur ein Beispiel und kann auch hier beliebig gewählt werden, solange eben verfügbar/frei)
Dann mußt du nur auf der zigbe2mqtt-Seite eben den Port ändern (user/pw kannst du lassen, das wird afaik ignoriert, wenn nicht auf FHEM-Seite allowed für diesen Server im Spiel ist).
Ein weiterer Server (für localhost zugänglich) ist jetzt nicht das große Ding (unter Sicherheitsaspekten oder performancemäßig), und nach dem Testen auch schnell wieder gelöscht ;) . Daher also: keine Sorge...
Wieder etwas klarer?
Ich meine ich habe bisher viel darüber gelesen, aber noch nicht wirklich die Vorteile daraus erschlossen :-\
Warum einige auf deconz schwören und wiederum andere von zigbee2mqtt (z.B. wird bei Z2Mqtt scheinbar auch der von Dir gesuchte Taster unterstützt: WXCJKG13LM (https://www.zigbee2mqtt.io/devices/WXCJKG13LM.html) ) begeisterter sind, erschließt sich momentan noch nicht. Wäre das zu sehr offTopic?
Zitat von: Beta-User am 28 Mai 2020, 12:44:54
Ein weiterer Server (für localhost zugänglich) ist jetzt nicht das große Ding (unter Sicherheitsaspekten oder performancemäßig), und nach dem Testen auch schnell wieder gelöscht ;) . Daher also: keine Sorge...
Wieder etwas klarer?
Aber sowas von ::) Auf jeden Fall viel nachvollziehbarer für mich, als das Geschreibsel vorher von lastWill usw....
Um bei meinem Beispiel zu bleiben, würde jetzt
brok_MQTT2 (MQTT2_SERVER) bleiben und wäre somit mein "mqtt-außerhalb-von-zigbee" Server (global)
und es käme der
define brok_ZIGBEE MQTT2_SERVER 1884 dazu und wäre dann mein Server ausschließlich local für zigbee, richtig ?
Demnach müsste ich in der Zigbee2Mqtt config (yaml) theoretisch gar nichts ändern und könnte das PW drin lassen, sondern lediglich in der zigbee_bridge (MQTT2_DEVICE) das IODev von brok_MQTT2 in brok_ZIGBEE ändern, richtig ?
Damit wären es 2 M2Server. Der eine für alle MQTT Zugriffe von außerhalb und der andere für die localhost Zugriffe des Zigbee Sticks ?
Sofern ich das jetzt nicht falsch verstanden habe, wäre das jetzt wahrlich nicht sooo schwer
Vielen Dank für Deine Geduld und Hilfe 8)
VG
Andreas
Fast:
Was die yaml angeht, muß die auf den richtigen Port zeigen, sonst darf die bleiben, wie sie ist (ich würde aber den Stick "by-id" einbinden, damit es nicht zu Konfusion mit FHEM kommen kann (v.a. initiaUsbCheck), Anleitung steht auch bei zigbee2mqtt).
Das IO am MQTT2-Device zu ändern, schadet auch nicht, hatte ich übersehen ist aber v.a. für das Senden wichtig.
Was zigbee2mqtt vs. deconz angeht: Java per se ist mir irgendwie suspekt, und wenn mir was direkt nach der Installation bzw. zum Ende zwei mittelschwere Vulnerabilities aufzeigt, ist das ja nett, aber auch nicht das, was ich haben will. Dazu ist das updaten da speziell (mit docker evtl. etwas einfacher, aber trotzdem...). Also will ich das nicht auf meinem Server haben. Das lief erst auf einem eigenen Pi, und dann habe ich mir eben den ConBee II geholt samt deconz. Das läuft "ganz normal" und ist via apt-get-Mechanismen updatebar. Im Ergebnis ist mir das wichtiger als die Frage, ob ich (schon heute) alle Tastendrücke von einem Experimentierdevice bekomme oder nicht; früher oder später wird das funktionieren... (und ich habe den Eindruck, dass ich bei diesem Code für spezielle Sachen eher durchblicke als bei Java; ich muß schließlich nicht alles können...).
Ansonsten hat zigbee2mqtt den Vorteil, dass es MQTT ist (und ich zwischenzeitlich "halbwegs" weiß, wie man damit "hübsche"+funktionale Devices konfiguriert) und (mit der Bridge-Funktio)n alle zusammengehörenden Readings per se auch in einem Device landen (da ist HUEDevice teils etwas "strange" und macht z.B. 3 Geräte aus einer innr SP 120 (einen switch und zwei für die Strommeß-Werte). Dafür kann man mit deconz manche einfachen Dinge direkt und außerhalb FHEM konfigurieren, das ist ganz nett. Die Gruppenfunktion in z2m kam erst später dazu, das war früher auch nicht ganz so elegant wie bei HUEDevice (das andererseits für jeden Mist irgendeine Gruppe anlegt, die man dann in einen "interessiert mich nicht"-Raum verschieben darf).
Außerdem wollte ich das dann ausbauen, da schienen die früheren Begrenzungen bei z2m nicht optimal - zwischenzeitlich kann das auch mit dem ConBee II, und der hat wohl deutlich mehr Speicher als die CC-Chipsets. Ergo: nimmt sich nichts, ist eine Frage der Vorlieben. Zwischenzeitlich würde ich vermutlich mit dem Duo z2m+Conbee II@docker starten, aber nochmal umstellen (zum testen!) ist es mir nicht wert...
Aaaahhh sorry ... Ich hasse ja mein Alzheimer :( habs irgendwie total verpeilt, dass ich nicht mehr geantwortet hatte .... Aaaalso:
@Otto: Seit der letzten ergänzung SCHEINT es so zu sein, als dass es funktioniert. Ich habe jetzt nicht so ewig oft neu starten müssen, aber bisher ohne Ausschluss. Dennoch möchte ich den "Test" noch ausweiten und den Vorschlag von Beta-User testen.
@Beta-User: Den Stick ohne by-id einzubinden, habe ich zum Glück von Anfang an vermiden ;) Ich hab einfach an vielen Stellen gelesen dass es da oft Probleme gibt, also auch direkt von Anfang an vermieden.
Richtigen Port in der YAML ist klar. Wie Du ja schon sagtest, kann ich ja User und PW drin lassen, das wird ja ignoriert, wenn es nicht benötigt wird.
Vielen Dank auch für die Aufklärung was zigbee2mqtt vs. deconz angeht. Einzig eine Frage interessiert mich einfach aus reiner neugier:
Zitat von: Beta-User am 28 Mai 2020, 14:34:14
bzw. zum Ende zwei mittelschwere Vulnerabilities aufzeigt,
Da ich mich in der Richtung nicht so sehr auskenne. Welche sind das ? Wie (mittel) schwer sind diese ? Bzw wo / wie kann ich an Infos / Lösungen kommen .... ?
Ich werde berichten, wenn ich den Rest zu Ende getestet hab und damit dann auch Ottos Empfehlung länger lief.
Vielen Dank
und viele Grüße
Andreas
Zitat von: flummy1978 am 08 Juni 2020, 01:20:42
Vielen Dank auch für die Aufklärung was zigbee2mqtt vs. deconz angeht. Einzig eine Frage interessiert mich einfach aus reiner neugier:
Da ich mich in der Richtung nicht so sehr auskenne. Welche sind das ? Wie (mittel) schwer sind diese ? Bzw wo / wie kann ich an Infos / Lösungen kommen .... ?
Ich hatte das damals über den node-Installationsweg gemacht (also kein docker), und es gab eben diese Hinweise auf 2 vulnerabilities am Ende. Da ich traditionell alles lieber den "debian-way" machen will, hat mich das von vornherein einfach genervt, und auch updates waren damals nicht komfortabel (mit docker scheint das besser zu sein).
Näheres hat mich dann nach dem Umstieg zu deconz nicht mehr interessiert. Das ging und geht mittels apt-get, das ist mir einfach sympatischer...