Beiträge von waki

    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
    Factory Reset
    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
    2019-10-24 12:22:40 MQTT2_DEVICE MQTT2_shelly4pro_3392AC power0: 0.00
    2019-10-24 12:22:40 MQTT2_DEVICE MQTT2_shelly4pro_3392AC relay0: off
    2019-10-24 12:22:40 MQTT2_DEVICE MQTT2_shelly4pro_3392AC power1: 0.00
    2019-10-24 12:22:40 MQTT2_DEVICE MQTT2_shelly4pro_3392AC relay1: off
    2019-10-24 12:22:40 MQTT2_DEVICE MQTT2_shelly4pro_3392AC power2: 1.27
    2019-10-24 12:22:40 MQTT2_DEVICE MQTT2_shelly4pro_3392AC energy2: 923
    2019-10-24 12:22:40 MQTT2_DEVICE MQTT2_shelly4pro_3392AC relay2: on
    2019-10-24 12:22:40 MQTT2_DEVICE MQTT2_shelly4pro_3392AC power3: 1.37
    2019-10-24 12:22:40 MQTT2_DEVICE MQTT2_shelly4pro_3392AC energy3: 932
    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.

    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.

    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
    MQTT2_FHEM_Server_172.16.5.24_52597                       cid             shelly4pro-3392AC                                           keepalive       60
    MQTT2_FHEM_Server_172.16.5.25_38389                       cid             shellyswitch-13478D                                           keepalive       60
    MQTT2_FHEM_Server_172.16.5.26_55964                       cid             shellyswitch25-00B43C                                           keepalive       60
    MQTT2_FHEM_Server_172.16.5.27_55463                       cid             shellyswitch25-00B67E                                           keepalive       60
    MQTT2_FHEM_Server_172.16.5.28_41090                       cid             shellyswitch25-E58416                                           keepalive       60
    MQTT2_FHEM_Server_172.16.5.29_57470                       cid             shellyswitch25-745A07                                           keepalive       60
    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:

    Zitat

    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.

    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.

    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.

    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.

    Zitat

    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

    Du hast mich erwischt. :)

    Ich kämpfe zur Zeit mit dem Modul ReadingsGroup, da ich auf einer Seite möglichst viel Info zusammenfassen will. So war ich blind und der Ansicht, dass Du diese Ansicht auch nur darüber hast realisieren können.

    Doch beim genauer hinschauen hast Du wohl das Attribut group verwendet. Doch die Lösung mit den Mehrfachicons wäre trotzdem interessant.

    Ich habe keine extra notify/doif. Es läuft alles über ASC.

    Wenn der Fahrbefehl für heute morgen kommt, dann dass das nächste polling anzeigt, dass der Rolladen noch nicht ganz oben ist. Dann dauert es je nach interval z.B. 60 Sekunden bis die Rückmeldung kommt, dass der Rolladen jetzt auf 100 (offen) steht. Dies wird dann von ASC als manuelle Fahrt gewertet. Bei shading in würde damit shading out verhindert.

    Es könnte sein, dass das Verhalten mit MQTT besser wäre. Ich hatte jetzt mehrere Wochen shelly-Modul und MQTT paralell laufen, aber bei dem ursprünglichen Problem mit den falschen Anzeigewerten hatte das nicht geholfen.

    Die 2.5er mit Version 1.5.3 machen das jetzt richtig, nur der 2er mit Version 1.5.2 nicht. Jetzt kann ich den probeweise auf MQTT umswitchen oder warten, ob die 2er auch noch die verbesserte Version bekommen.

    Ich habe jetzt die Shelly upgedatet und es ist viel besser geworden. Ich habe es ein paar Tage beobachtet und es sieht gut aus.

    Meine Shellys 2.5 sind auf 1.5.3 und zeigen prozentgenau den Stand, den sie anfahren sollten. Mein alter Shelly 2 hat sich nur auf 1.5.2 gezogen und macht noch kleine Probleme. Auch hier stimmt jetzt die Anzeige mit dem Soll überein, aber das ASC-Modul von fhem sieht kurz nach dem Ansteuern noch manuelle Fahrten und reagiert entsprechend.

    Ist Euch bekannt, warum es für die 2er kein update auf 1.5.3 gibt oder ob da noch etwas zu erwarten ist?

    Ich arbeite mit dem MQTT-Modul in fhem.

    Der empfängt alle 30 Sekunden den Status vom jedem Shelly. Das istmir zu viel Traffic.

    Du schreibts: "Shellys senden bei Änderung und/oder alle 30 Sekunden"

    Wo kann ich "oder" einstellen? Bei Änderungen und nicht alle 30 Sekunden wäre mein Wunsch.