Frage zu Shelly4Pro und FHEM

  • Hallo 87insane,

    Du bist doch Spezialist für fhem und mqtt.

    Ich habe mit meinem Shelly 4 Pro an dessen Ausgängen die Ventile meiner Fussbodenheizung hängen ein neues Problem. Im log konnte ich bisher finden, dass:

    1. vom 16.10. 20:14 bis 17.10. 9:50 und

    2. vom 21.10 19:32 bis 22.10. 9:36

    der Shelly laufend Verbindung auf- und abbaut.

    Quote

    2019.10.22 09:33:56 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_172.16.5.24_58986/shelly4pro-3392AC left us (keepalive check)

    Diese Meldung kommt alle 30 Sekunden über den gesamten Zeitraum. Im fhem-device ist aber immer der kleine grüne Punkt an und im reading wird er als online geführt.

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

    Wenn ich per Browser diekt auf denShelly gehe, habe ich Verbindung und kann manuell schalten und sehe, dass WiFi RSSI: -65 dBm ist. (Erscheint mir OK).


    Kannst Du mir das erklären oder weitere Tests vorschlagen?


    cu

    Walter

    Edited once, last by 66er: Thema als eigenständiger Thread in Abstimmung mit @87insane ausgegliedert aus FAQ... ().

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


    Quote

    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!

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

    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.

  • Quote

    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.


    Quote


    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 ^^ :)

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


    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.

  • Quote

    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.


    Quote


    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.

  • Nein, ich erwarte von keinem, dass er in der Glaskugel liest. Aber gestern hatte ich keine Zeit mehr die Informationen zu sammeln.;)


    Es hat auch bis jetzt keine neuen Aussetzer gegeben, obwohl ich noch nichts geändert habe.


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

    2. Die MQTT-Einstellungen des Shelly (siehe Bild)

    3. Das list:

    Code
    1. MQTT2_FHEM_Server_172.16.5.24_52597 cid shelly4pro-3392AC keepalive 60
    2. MQTT2_FHEM_Server_172.16.5.25_38389 cid shellyswitch-13478D keepalive 60
    3. MQTT2_FHEM_Server_172.16.5.26_55964 cid shellyswitch25-00B43C keepalive 60
    4. MQTT2_FHEM_Server_172.16.5.27_55463 cid shellyswitch25-00B67E keepalive 60
    5. MQTT2_FHEM_Server_172.16.5.28_41090 cid shellyswitch25-E58416 keepalive 60
    6. MQTT2_FHEM_Server_172.16.5.29_57470 cid shellyswitch25-745A07 keepalive 60
    7. MQTT2_FHEM_Server_172.16.5.30_22793 cid shellyswitch25-E59DB7 keepalive 60

    4. Das list des Shelly 4 Pro:




    5. Meine Meinung zu dem qos-Vorgang kommt aus folgender Quelle:

    Quote

    The client that publishes the message to the broker defines the QoS level of the message when it sends the message to the broker. The broker transmits this message to subscribing clients using the QoS level that each subscribing client defines during the subscription process.


    QoS 1 - at least once

    QoS level 1 guarantees that a message is delivered at least one time to the receiver. The sender stores the message until it gets a PUBACK packet from the receiver that acknowledges receipt of the message. It is possible for a message to be sent or delivered multiple times.


    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.

    Files

    • MQTT.gif

      (58.1 kB, downloaded 7 times, last: )

    Edited once, last by 66er: Zitattext im Zitat-Tag plaziert ().

  • Hey,


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

    Quote

    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.

    Quote

    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.

  • Es ist wirklich spannend.


    Gerade habe ich die Situation, dass er wieder anfängt zu zicken. Da ich life dabei bin, kann ich jetzt sagen, dass die Weboberfläche erreichbar ist und ich dort auch schalten kann.



    2019.10.23 14:55:49 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_172.16.5.24_65484/shelly4pro-3392AC left us (keepalive check)

    2019.10.23 14:56:29 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_172.16.5.24_62878/shelly4pro-3392AC left us (keepalive check)

    2019.10.23 14:57:19 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_172.16.5.24_57423/shelly4pro-3392AC left us (keepalive check)

    2019.10.23 14:57:59 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_172.16.5.24_61905/shelly4pro-3392AC left us (keepalive check)

    2019.10.23 14:58:39 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_172.16.5.24_58236/shelly4pro-3392AC left us (keepalive check)

    2019.10.23 14:59:29 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_172.16.5.24_63897/shelly4pro-3392AC left us (keepalive check)

    2019.10.23 15:00:09 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_172.16.5.24_53486/shelly4pro-3392AC left us (keepalive check)

    2019.10.23 15:00:49 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_172.16.5.24_61050/shelly4pro-3392AC left us (keepalive check)

    2019.10.23 15:01:39 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_172.16.5.24_59094/shelly4pro-3392AC left us (keepalive check)

    2019.10.23 15:02:19 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_172.16.5.24_56237/shelly4pro-3392AC left us (keepalive check)

    2019.10.23 15:02:59 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_172.16.5.24_52092/shelly4pro-3392AC left us (keepalive check)

    2019.10.23 15:03:39 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_172.16.5.24_62058/shelly4pro-3392AC left us (keepalive check)

    2019.10.23 15:04:29 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_172.16.5.24_53628/shelly4pro-3392AC left us (keepalive check)

    2019.10.23 15:05:09 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_172.16.5.24_65430/shelly4pro-3392AC left us (keepalive check)



    Ich habe gerade festgestellt, dass zu dem Zeitpunkt, zu dem ich auf die Weboberfläche gekommen bin der Spuk aufgehört hat. Jetzt ist wieder Alles normal.


    Das Werksreset werde ich als nächstes probieren, wenn ich dazu komme.

  • Hey,


    vom verhalten her würde ich nach der Beschreibung weiter auf Shelly/mqtt Problem tippen. Also ist dein nächster Schritt, wenn auch doof weil gut verbaut, vermutlich die Lösung. Ich halte aber weiter an Hardware Reset fest. Ein Software Reset hilft bei vielen Geräten nur bedingt.


    Bin gespannt und bleibe auf Standby :)

  • So, ich habe mich jetzt zu meinem Shelly vorgekämpft und ihn resettet. Gemacht habe ich es nach Anleitung aus dem Lexicon durch langes Drücken auf das Display. (Dein 5-maliges Drücken ist dort nicht erwähnt !)

    Code
    1. Factory Reset
    2. If the web interface of the device cannot be accessed, settings can be brought back to defaults by pressing and holding the device button for more then 10 seconds or until the led light start flashing fast.

    Nach dem ersten Reset und dem Wiedereinbinden in mein Netzwerk mit fester IP hat er aber keinen Zugang zum Internet bekommen. D.h. er bekam keine Uhrzeit.


    Prozedur wiederholt. Jetzt kam Uhrzeit sofort und auch Anbindung über mqtt funktioniert, doch sendet keinen online-Status.

    Code
    1. 2019-10-24 12:22:40 MQTT2_DEVICE MQTT2_shelly4pro_3392AC power0: 0.00
    2. 2019-10-24 12:22:40 MQTT2_DEVICE MQTT2_shelly4pro_3392AC relay0: off
    3. 2019-10-24 12:22:40 MQTT2_DEVICE MQTT2_shelly4pro_3392AC power1: 0.00
    4. 2019-10-24 12:22:40 MQTT2_DEVICE MQTT2_shelly4pro_3392AC relay1: off
    5. 2019-10-24 12:22:40 MQTT2_DEVICE MQTT2_shelly4pro_3392AC power2: 1.27
    6. 2019-10-24 12:22:40 MQTT2_DEVICE MQTT2_shelly4pro_3392AC energy2: 923
    7. 2019-10-24 12:22:40 MQTT2_DEVICE MQTT2_shelly4pro_3392AC relay2: on
    8. 2019-10-24 12:22:40 MQTT2_DEVICE MQTT2_shelly4pro_3392AC power3: 1.37
    9. 2019-10-24 12:22:40 MQTT2_DEVICE MQTT2_shelly4pro_3392AC energy3: 932
    10. 2019-10-24 12:22:40 MQTT2_DEVICE MQTT2_shelly4pro_3392AC relay3: on

    Dies wird im Eventmonitor alle 30 Sekunden angezeigt, aber keine Info über online oder Firmware. Somit bleibt die kleine Anzeige rot.


    Das sieht jetzt auch nicht richtig gut aus.

  • interessant ist aber die erste runde wegen der Zeit. Wenn der shelly nicht raus kam, ist das schon merkwürdig. Hast du ne Firewall davor oder nutzt du simpel einen Provider Router und nichts spezielles?


    Das mit dem announce bzw mit dem Neustart ist aber ganz normal. Kein Grund zur Sorge.

  • Ich habe eine Firewall (Sophos UTM). Aber ich habe mit gleicher fester IP gearbeitet wie zuvor und beim zweiten Anlauf hat es funktioniert. Daher sehe ich keinen Grund, die Firewall zu belasten.

  • suche nur nach einem Grund. Ich weiß ja nichts über deine Fähigkeiten oder Kenntnisse. Deswegen muss ich natürlich auch (für dich) doofe fragen stellen. Stehe ja nicht selber vor deiner Hardware. Aber wir warten erst mal ab. Würde fast wetten, wird nun laufen. :)

    Hattest das ja quasi spätestens nach 48h. Bin gespannt.

  • Fühle ich mich ja wohl, das richtige gesagt zu haben.

    Gute Übersicht. Denke die sollte in den mqtt Bereich mit einer kleinen Erklärung. Ich liebe es, wenn die Leute nicht nur fordern, sondern auch selber aus interesse suchen und weiter kommen wollen. Mega Kompliment!

  • So, jetzt ist es wieder soweit. Gestern abend um 19:30 ging das ewige online:true - false wieder los und die Heizung wurde heute morgen nur bei einem Kreis eingeschaltet.

    Hast Du noch Ideen, was ich testen könnte oder soll ich das Gerät gleich reklamieren?