Beiträge von 87insane

Hey,

kein Problem. Hauptsache wir bekommen es am Ende zum laufen, wie du es magst

Zitat

1. Ob ich die Weboberfläche während dieser Aussetzer erreicht hätte, kann ich nicht sagen, weil ich es erst hinterher bemerkt habe.

Okay - Wie kannst du dann wissen ob nicht doch geschaltet wurde? Das verstehe ich nicht. Ist kein Vorwurf, versuche nur, ohne es selber zu sehen, das auch zu verstehen.

2. Sieht okay aus. Hier können wir noch ein wenig testen und probieren (aber siehe 5).

3. In allen Shellys ist 60 eingestellt. Sehe ich als gut an und das können wir streichen.

4. Auch gut, in meinen Augen.

5. Hier reden wir vermutlich aneinander vorbei.

Zitat

Da die Blockade zum Zeitpunkt meines Webzugangs schon vorbei war, hätte doch mindestens noch ein Versuch des Einschaltens erfolgen müssen, da das PUBACK packet nicht da war.

Ein klares nein, in meinen Augen. Du hast Clean Session aktiv. Wenn die Verbindung abbricht, werden bei der neuen Verbindung noch offene Nachrichten der alten Session verworfen.

Man könnte nun mit Retain und LastWill noch ein wenig zaubern aber das bringt uns nicht an ein sauberes Ziel. Du willst zuverlässig arbeiten und da würde ich sehr ungern "prutschen".

Nach wie vor denke ich das eine der beiden Seiten blockierte. Hattest du das schon oft?

Da es gerade läuft.... Am besten mal FHEM Update, danach Neustart von deinem FHEM ggf. auch mit Hardware. Dann nochmal beobachten. Sollte das nochmal passieren (keepalive check), bitte direkt versuchen ob das Gerät tatsächlich noch im WLAN ist. Es könnten zwei Dinge sein. WLAN oder MQTT Probleme. Ich weiß, das hört sich nun erstmal nicht so toll an aber vermutlich wäre nach einen Werksreset des Shelly, alles super. Ich selber gehe von MQTT und nicht WLAN Problemen aus. Es bleibt also spannend.

Nachtrag:

Hab das selber komplett vergessen aber das Template für den 1PM geht auch auf dem Plug S. Ist sogar dafür gedacht.

Ich selber finde das schöner und würde das nehmen. Aber das ist wirklich Geschmackssache!

Da ich davon ausgehe, dass dies hier als gelöst zu betrachten ist, setze ich das mal so ein bei mir. Sollten Folgefragen auftauchen, einfach melden. Ich denke aber von deinen Erzählungen her, kannst du das sicher.

Viel Erfolg

achso... Die ip kommt nach Neustart des Shelly oder aber wenn man ein announce sendet.

Nehmen kannst du das Template ruhig.

Schönen Tag dir.

Hey und guten Abend Helmut,

vermutlich hast du shellyplug gewählt?

Was vermisst du bzw was wünscht du dir denn?

Ps: Im fhem FAQ siehst du eine kleine übersicht meiner shellys. Plug s in dem Bild sind: Wasch Maschine, Arbeitszimmer pc musik, Garage Licht rechts und die Pool Pumpe. Zum normalem Plug hat der Plug S noch Energie Daten und Temperatur.

Zitat

Zur editierten Frage von oben, woher ich weiß, dass er nicht geschaltet hat. Das sehe ich auf der Weboberfläche des Shelly.

Also hast du in diesem einen Moment auch das Web-IF des Shelly erreichen können. Und dort hast du gesehen, dass alles aus ist.

Zitat

Zu qos: Ich habe es so verstanden, dass der mqtt-Server die qos-Einstellung des Client übernimmt und dann auch so lange sendet bis er Erfolg hat.

Naja aber wenn eine der beiden Seiten blockiert, können beide senden wie sie wollen. Am Ende passiert nix.

Es gilt bei jedem MQTT Gerät: Zuerst wird eine Verbindung aufgebaut, danach können Nachrichten gesendet aber auch empfangen werden. Mir scheint es als ob bei dir etwas blockiert.

Hatte ja einige Dinge, die leider vorher geprüft werden müssen, geschrieben. Bevor z.B. kein Bild der MQTT Einstellungen hier ist, kann ich schlecht sagen ob das okay ist. Dazu kommen noch die ganzen anderen Fragen.... Ist nicht böse gemeint, aber das ist gerade Glaskugel raten.

Zitat

Danke, ich werde es noch beobachten und dann die Schritte durchführen. (Gerät ist nicht so leicht zugänglich. zugebaut !).

SW Reset wäre ein Anfang und neu anlegen via autocreate in FHEM. Aber leider keine Garantie.

Zitat

Was ich bei mqtt nicht verstehe: Laut Definition von qos=1 soll der Befehl so lange wiederholt werden, bis ein positives Feedback kommt. Dann müssten doch auch im log die set-Befehle zu sehen sein.

Naja.. Wenn z.B. dein Server blockiert, kann der Shelly so oft senden wie er will. (Beispiel mit dem Telefon-Anruf).

Hier muss man die Seite (Sender/Empfänger) beachten. MQTT abonniert Nachrichten. Es gibt so gesehen kein "set QOS -tollesFeedback". Der Shelly meldet sich am Server an und teilt ihm mit wie er Nachrichten versenden wird. Es gibt noch einige Dinge die wir testen können - z.B. LWT usw. Aber am besten fangen wir erstmal oben an

Hey waki,

das ist nun echt ein wenig Arbeit.

Es gibt ein keepalive Request der nicht durch geht aber das Gerät ist online..hmmm...

1. Interessant ist ob das Gerät in dem Zeitraum, indem FHEM den Request sendet und nix bekommt, wirklich via Webinterface erreichbar ist. Das wäre die erste Prüfung.

2. Am besten mal ein Bildchen deiner MQTT Einstellungen des Shelly.

3. keepalive Einstellungen deines MQTT2 Servers in FHEM bzw. Was FHEM denkt, wie das Gerät eingestellt ist. list TYPE=MQTT2_SERVER cid keepalive

Hinzu (würde ich) den Shelly einmal komplett Resetten. Nicht via Software sondern HW-Seitig. (5 mal Taste drücken Methode)

Ich habe x Shellys und dieses Phänomen noch nie gehabt. Zu meinen Shelly kommen noch y andere MQTT Geräte. Mein FHEM läuft auf einem Raspi 3.

Hast du weitere Geräte mit diesem Problem? Was sagt dein LOG zu diesem Shelly ggf. noch?

Am Ende ist so, dass der Shelly dem Server sagt, wie hoch oder niedrig seine keepalive Zeit ist. Die kleine grüne Lampe reagiert auf das Reading (online true/false). Bei mir gibt es Shellys die in der Tat mal aus dem WLAN fliegen aber das liegt daran, das ich welche im Garten habe und ich aktuell einen AccessPoint zu wenig habe. Also mein WLAN geht einfach nicht weit genug. Diese werden dann auch direkt als offline angezeigt.

Um es dir selber einfacher zu machen, fang am besten mit dem Reset des Shelly und dem neu anlegen des Gerätes in FHEM an. Sollte das wirklich nicht klappen. Bitte die ganzen anderen Punkte abarbeiten und ein List des betroffenen Gerätes anhängen.

PS: Beim anlegen des Gerätes in FHEM - BITTE AUTOCREATE nutzen und nicht von Hand anlegen.

Zitat

PPS: Trotz QOS = 1 wurden aber die Ventile am Morgen nicht geschaltet.

QOS 1 ist in dem Fall aus Sicht des Shelly. Auch wenn er immer und immer wieder senden will, aber nicht durch kommt (warum ist ja noch zu klären), ist das leider so. So als ob du bei mir anrufst und es ist immer besetzt. Du probierst es immer wieder da QOS1 aktiv ist aber ich bleibe besetzt.

Wovon ist abhängig ob die Ventile schalten sollen? (ggf. finden wir eine bessere Lösung)

Woher weißt du sicher, das diese nicht geschaltet hatten?

Egal ob positiv oder negativ - Bitte Feedback Danke!

Okay das geht natürlich alles wie du magst...

Shelly wacht auf > MQTT Server bekommt die Infos > notify/doif/mswitch usw (wie du magst eben) > und dann weiter an deine Push App.

Vom Gedanken her sind sogar weniger beteiligt. Zumindest was Latenzen angeht. Hinzu ist die Cloud (ohne es böse zu meinen) sicher öfter offline als dein FHEM System.

Wenn es irgendwo hängt, melde dich und da bekommen wir sicher das hin.

Anbei mal ein kleines Beispiel:

defmod NameVomNotify notify GerätAufDasEsReagierenSoll:ReadingDesGerätes:.(WasImReadingStehenSollDamitReagiertWird) set DeinWhatsAppGerät Nachricht....

Ist bei mir original um mein Soundsystem mit Strom zu versorgen:

defmod n_az_pc_musik notify kai_pc:soundsystem:.(on|off) set MQTT2_shellyplug_s_7AE167 $EVTPART1

Würde das versuchen in die FAQ einzubringen.

Die frage wäre dann, wenn ich das jetzt richtig verstehe, instand eine Info von verschiedenen Dingen zu bekommen?

Will das nur korrekt aufnehmen und hoffe korrekt gelesen zu haben, dass es am ende eigentlich nur darum ging? Am ende sollst du ein gutes ergebnis haben und nichts aufgezwungenes. was die URL angeht könnte man das aber als Boni mit rein bringen. Das wäre natürlich nice to have

dann Idee, wireshark. Die Daten daraus dann nutzen oder wenn hilfe benötigt, hier rein setzen. An einem Ergebnis bin ich auch interessiert

Gegen mqtt spricht aber nix. Deine einzige bedingung war sofortige Info, wenn was ist. Das kann fhem auch. Ich selber bekomme für alles mögliche ne push Nachricht. Klingel, Trockner, Wasch Maschine usw.

Diese Infos kommen je nachdem was das ist auch bei meiner Freundin an. Zb leere Batterien kommen auch, aber nur an mich. Tauschen tu eh nur ich die.

Anbei mal ein Bild...

Ahhh.. Okay...

Also Neustart.

Du nutzt Shelly mit dem Modul und nicht MQTT. Da du zusätzlich in der Shelly eigenen Cloud verweilen magst. Aus reiner Neugier - warum? Alles was in FHEM ist kannst du über diverse Wege auch mit Alexa und co nutzen und dazu auch von außen schalten.

Dann bleibt ja nur noch der Weg zu schauen wie du diese report_url nutzen kannst. Einfachste Weg, wäre echt einfach mal zu schauen wie der Flood die URL haben will (wireshark).

Würde das übernehmen, wenn ich einen hätte.

pah entwickelt das Modul aber auch immer weiter und weiter. Der "faule" Weg, wäre warten. Das ist aber kein schöner Weg

Danke für die Blumen, dafür ist das Forum ja da

sieht von lesen her gut aus. Hab selber leider keinen Flood u kann deswegen nicht testen.

Vermutlich wäre es super einer der HM/FHEM Kollegen hier her zu holen. Denke das die eh schon eingebundenen Geräte auch direkt übernommen werden können.

Hey und guten Morgen!

Okay - das ist verständlich. Naja du könntest FHEM direkt mit dieser URL informieren aber das ist in meinen Augen kein eleganter Weg.

Zum einen bräuchtest du, um nicht deine Daten im Netzwerk zu streuen und ggf. gegen die Cloud (ich weiß nicht ob diese, die Info auch bekommt), eine eigene und ungesicherte http/web Instanz. Das geht relativ einfach ist aber so lala (wie ich finde).

Einen anderen Weg hast du selber ganz gut beschrieben. Ich gehe davon aus du hast deine HM Komponenten eh in FHEM? Wenn ja müsste du ja auch die z.B. Flood dort übernehmen können.

Thema report_url ist leider nicht dokumentiert. Ich sehe auch nur, dass was du bereits gefunden hast. In welcher Form da etwas hin und her gesendet wird, könntest du ggf. gegen testen. Ich würde einfach mal irgendwas eintragen und mit wireshark mit loggen. Danach siehst du wie und wann diese URL etwas versucht. Im besten Fall bekommst du direkt alle Angaben.

Also das du HM in FHEM einbinden kannst, weiß du sicher. Da gibt es auch Doku ohne Ende. Ich selber habe immer nur Testweise mal HM mit drin gehabt und würde da ggf. etwas nicht korrekt deuten oder erklären. Meine Shellys gehen alle direkt nach FHEM.

Ich kann mir aber vorstellen, wie oben schon angeschnitten, das du alle Komponenten, die in deinem HM Modul hängen, auch an FHEM melden kannst. (https://wiki.fhem.de/wiki/HomeMatic)

Es gibt also mehrere Wege. Ich selber würde aus Interesse auf jeden Fall mal mit wireshark den Verkehr mitlesen. Lösen (wenn möglich) würde ich dies aber vermutlich, da eh schon vorhanden, mit Anbindung HM->FHEM. Warum? Weil eine zusätzliche URL auch wieder zusätzlich Saft zieht. Auch wenn dies minimal sein wird.

Gruß,

Kai

okay..dann hat der Fragesteller aufgrund fehlenden Backups nun 2 Möglichkeiten.

1. warten bis ne bin da ist

2. noch einen plug s besorgen und ein Backup ziehen. Danach neu flashen.

Ich habe zwar vertrauen in die Community aber will die sn meiner nicht rsus geben. Auch wenn ich die nur offline nutze. Da ich selber nicht weiß, wie man die sn direkt raus nehmen kann, hab ich keine weitere idee. :-/

was meinst du damit @66er ?

Waren die nicht auch mal bei höle der Löwen? Meine da klingelt was.

das ist echt frech!

400w ist auch geil. Hoffe das niemand den Kram gekauft hat.

Hey zusammen,

hast du mal mit einem MQTT Explorer oder so geschaut was die Shellys so im Netz versenden?

Generell sollte der Shelly eine V3 Anfrage senden. Diese muss dann von deinem Broker auch beantwortet werden. Ich selber nutze keinen mosquitto Broker aber das ist am Ende des Tages egal.

Sende mal ein Bild von den Einstellungen die du im Shelly vorgenommen hast. Natürlich das Passwort (wenn aktuell drin) nicht in Klartext.

Hey bombardi ...

da dies eine Übertragung (egal wie) wäre, die über das Endgerät angestoßen werden müsste, müsste Alterco da Hand anlegen. Was spricht hier gegen MQTT? Ich selber habe keinen Flood / H&T usw. Der Door Sensor z.B. ist für mich interessant und ich werde ihn auch noch bestellen. Allerdings würde ich hier auch MQTT verwenden wollen.

Die Aufgabe, wäre ja zu wissen, wann das Gerät aufwacht. Das wiederum ist sehr Geräteabhängig. Das könnte FHEM also ohne Info nicht wissen. Wenn das Gerät aber aufwacht und über die bereits vorhandenen Wege wie MQTT einfach diese Info weiter gibt, wäre ja alles da.

Kannst du deinen Wunsch ggf. etwas weiter aufschlüsseln? Bisher gibt es für solche Zwecke ja nur MQTT und CoAP.

PS: Danke für die Blumen. Aber das hier wird nur so gut, wie wir alle Fragen stellen und diese beantworten. Deswegen auch ein Danke an Dich, als ersten Frage-Steller

Hatte das so ähnlich schon bei YouTube gesehen. Danke für die gute Beschreibung. Echt genial. Du hast einmal umgelenkt, richtig?