Beiträge von Frank Berges

    Vielleicht hilft es deinen Config Check etwas anzupassen:

    Ja das mit dem Config hatte ich auch als Fehlerquelle angesehen und habe darum eine Verzögerung eingebaut :

    Das führt dazu das eine weitere Bearbeitung erst nach 3000ms weitergefügrt wird.

    Ohne das läuft das Script fast nicht an.

    Ich habe auf einem i4 ein Script laufen das im Normalfall auch immer funktioniert.

    Ab und an steht das Script auf Stop und nach einem erneuten Start per Weboberfläche läuft es wieder.

    Das Script steht auch auf Autostart und sollte bei Spannungsausfall eigentlich auch sofort wieder laufen (nach Test macht es das auch).

    Ich vermute das der MQTT-Server ab und an nicht erreichbar ist (Warum auch immer er ist Intern im ioBroker).

    Das sind aber nur Vermutungen und ich finde den Fehler nicht.

    Hier das Script das Tastendrücke auf den Eingängen Zählt, diese an den MQTT weiter gibt und der Zähler kann vom MQTT beeinflusst werden.

    Könnt Ihr Euch das bitte mal ansehen und Möglicherweise findet Ihr da Verbesserungen so das das Script nicht auf Stop geht.

    Sonst kontrolliere ich das per Blockly ob es läuft und starte es auf dem Wege wieder Neu.

    Das ist aber eigentlich nur eine Übergangslösung und keine Problemlösung.

    mfg

    f.b.

    So das mit dem RSSI hat funktioniert.

    Das bleibt auch nach Stromausfall auf den -55 stehen.

    Erst versindet sich der i4 mit der Box und hat dann -70.

    Nach einiger Zeit ("interval":60) sucht er sich dann den -39 also den nächsten AP zur kommunikation aus.

    Das funktioniert auch nach 5 Versuchen zuverlässig und die Konfigutation -55 bleibt erhalten.

    Jetzt mal zum Script das ich laufen habe.

    Kann es sein das Das bei einem Stromausfall und wenn es den MQTT nicht oder noch nicht erreichen kann Stoppt und nicht wieder anläuft?

    Wenn das so ist, was kann ich dagegen machen ?

    Der MQTT läuft gesichert über eine USV aber wenn mal eine Sicherung raus fliegt und ein AP oder ein Switsch keinen Strom bekommt ist er nicht mehr erreichbar und dann muss das Script eigentlich neu Starten oder am laufen bleiben.

    hab jetzt nicht alles Durchgelesen, aber gib jeden AP einen eigenen Namen in der FritzAnsicht, dann im Shelly anpassen

    Das habe ich jetzt nicht verstanden.

    Ich habe ein Mash mit einem SSID der stellt sich dann bei Allen AP auf diesen SSID ein.

    Da kann ich dann keine sonstigen Nahmen vergeben.

    Der Seperate WLAN-Zweig hat einen eigenen Wlan-Kanal und einen Eigenen SSID und ist somit aus dem Mash.

    Wenn ich jedem AP einen eigenen SSID gebe, so habe ich kein Mash und muss also alles Händisch anpassen also jeden Wlan Teilnehmer dem jeweils nächsten AP-SSID zuordnen.

    Meintest du das ?

    so, die Gen2 machen das bei -80 !

    Hallo Andreas

    DANKE für die Info.

    JA der Stand bei :

    Code
    {"ap":{"ssid":"ShellyPlusI4-B8D61A8A2474","is_open":true, "enable":false, "range_extender": {"enable":false}},"sta":{"ssid":"Strommix-SH","is_open":false, "enable":true, "ipv4mode":"static","ip":"192.168.2.155","netmask":"255.255.255.0","gw":"192.168.2.1","nameserver":"192.168.2.1"},"sta1":{"ssid":null,"is_open":true, "enable":false, "ipv4mode":"dhcp","ip":null,"netmask":null,"gw":null,"nameserver":null},"roam":{"rssi_thr":-80,"interval":60}}

    Werde den jetzt mal auf -55 stellen und mal schauen ob es dann besser wird.

    Ich hoffe das bleibt dann bis zum umkonfigurieren oder Werksreset so stehen.

    Also neuer Versuch mit Neuen Parametern.

    Ich verwende ebenfalls iobroker und darin den MQTT Adapter. Einen Mosquitto extra auf den Raspi spielln ist unnötig.

    Hallo

    So noch vielen Versuchen, bin ich nun auch der Meinung das Das kein Problem vom MQTT-Intern-ioBroker oder MQTT-Mosquito ist.

    War aber eine Möglichkeit, jetzt ist alles wieder so wie gehabt intern.

    Nächste Versuchsreihe um dem Problem auf die Schliche zu kommen.

    Vorher noch mal die Konstellation, Fritz-Mas mit zig Teilnehmern(vergleichbar mit dem was 66er gepostet hat) dann eine alte Fritzbox als Repeaer konfiguriert angeschlossen über Kabel an das Restliche Netz.

    Darauf mit einem Anderen Wlan-Kanal eine Andere SSID,

    2xi4 (mit Scripten) und 4xDimmer2 in dem Separaten Bereich.

    Das läuft zu 100% Stabil über Monate.

    Jetzt habe ich erst den ersten und dann den zweiten i4 aus dem Bereich wieder in des Mash genommen.

    Das lief jetzt auch über Wachen stabil.

    Vor einigen Stunden habe ich alle Router und Repeater neu gestartet (Vergleichbar mit einem Stromausfall).

    Alles lief hoch ohne Probleme nur die Beiden i4 die ich Rüber geholt habe hatten sich mit einer Entfernten Box verbunden und nicht an den Daneben liegenden Repeater (möglich das auch Andere Shellys schlecht verbunden sind das habe ich aber mal vernachlässigt).

    Weiterhin waren bei den beiden i4 die Scripte gestoppt.

    Also Gut dachte ich, die i4 Spannungslos gemacht und etwas warten und wieder eingeschaltet und siehe da Script bei einem Gestopt (Also kein Neustart obwohl der Haken gesetzt ist ) der Andere OK.

    Verbunden waren sie wieder mit der Box und nicht mit dem Daneben liegenden Repeater.

    Jetzt habe ich die beiden i4 wieder in den Seperaten Bereich konfiguriert und dort den Gleichen Versuch (Netz ein/aus) gemacht mit dem Erfolg alles OK.

    Das habe ich mehrfach gemacht und alles blieb OK.

    Jetzt die i4 wieder in das Mash und siehe da sie verbanden ich mit dem Repeter und nicht mit der entfernt liegenden Box.

    Der RSSI zum Repeter ist -39dBm und zur Entfernt liegenden Box ist -72dBm.

    Kann es sein das die i4 oder Alle Shellys eine Vorliebe für Boxen und nicht für Repeter haben?

    In den Scripten die auf den i4 laufen wird mit dem MQTT Daten ausgetauscht, kann es sein das bei einem Fehlenden MQTT die Scripte gestoppt oder durcheinander geraten ?

    Das ist das Script das auf den Beiden i4 läuft.

    Icht's aufregendes und eigentlich läuft das wenn es in dem Bereich ist gut.

    Ich denke mein Problem sind 2 Probleme, erst mal das mit den Shellys und dem mash und das Andere mit MQTT,Neustart und meinem Script.

    Ich bin ratlos und lasse das Alles erst mal in dem Seperaten Bereich denn das scheint ja zu laufen.

    Das ist alles Gleich eingestellt.

    Das es bei dir nicht ist, könnte an der Kombination bei mir liegen.

    Ich Kommuniziere nur über MQTT mit dem ioBroker und den MQTT werde ich von ioBroker-Intern auf Mosquitto umstellen was aber etwas dauern wird da ich ca. 1 Woche nicht dazu komme.

    Das ist zwar nur ein fischen im TZrüben aber einige haben Probleme mit dem Internen MQTT sind sind auch auf den Mosquitto umgestiegen.

    Meine Anderen Shellys die im Restlichen Netz hängen machen das ja auch nicht, da sind auch i4 und dimmer2 drin nur das die keine Scripte haben und nur bei Bedarf mit dem ioBroker reden.

    Also seltener als die im WLAN-Subnetz.

    An der Kommunikation der Bewegungsmelder (zu viele und zu schnell aufeinanderfolgend) kann ich auch ausschließen da die Steinel auf 1minute Impuls eingestellt sind.

    Beides läuft wie schon geshrieben mit aktueller Fritz-Firmware, also >7.29, bei mir fehlerfrei.

    Wie Schubbie schon schrieb: Wie bitte soll eine Fritzbox einen Shelly reseten?

    Ist ein übergeordnetes System im Spiel?

    Tja das dachte ich auch.

    So bald ich die Shellys in das Mash einbaue habe ich Probleme auch wenn ich von der Insel die Firmwareversion erhöhe habe ich Probleme.

    Das hört sich Dumm an und Unlogisch ist aber so.

    Das mit dem Übergeordneten System was meinst du damit ?

    Da ist nur der ioBroker, PC's, Handys, Alexas, Switsche, Fotovoltaik, Ikea-Hub (Von meiner Tochter), Synology NAS, ESP32 Eigenendwicklungen, Miele-Waschmaschine, Fernseher, Satreceiver usw. mit im, Netz.

    Die bleiben bei dem Firmwarewechsel der Fritzbox eigentlich Konstant und dürften davon nichts mitbekommen oder mitspielen.

    Ich mache das kleine Grüne Männchen an dem Zusammenspiel von Firmware >7.29 und den Shelly i4 und Dimmer2 fest.

    Ich habe das Grade noch mal versucht und die Fritzbox mit der neuen Firmware bestückt.

    Ergebniss ist die Shellys löschen die Scripte und 1 Dimmer und 1 i4 gehen in den Werksreset. (SCH....)

    Das hat keine 1/2h gedauert bis Probleme auftraten (Werksreset, Script Stopp oder weg).

    Zurück zur Version 7.29 und alles läuft wieder wie gewohnt (Hat es Gestern den ganzen Tag und die Nacht auch ohne Probleme.

    Das ist also reproduzierbar wenn auch nicht zu verstehen.

    Noch mal, auf den Shellys läuft ein Script das über MQTT (Alle meiner Shelly laufen über MQTT) mit dem ioBroker quasselt. Der ioBroker quasselt zurück und bestückt die Dimmer mit kommandos auch über MQTT.

    Als MQTT dient der ioBroker also kein Anderes System.

    Das ist die Einzige Stelle in meinem System bei der das so ist, der Rest ist Standard ioBroker erhält Infos und gibt Kommandos an die Shellys oder die z-Waves.

    Sollte eigentlich kein Hexenwerk sein, bis jetzt wahr es auch immer der an der Tastatur der Dummes gemacht hat.

    Meine Aussenbeleuchtung ist das Sorgenkinnd.

    Die Funktion:

    Ich habe 5 Lichtquellen (über Dimmer2, 4 Taster an i4, 3 Bewegungsmelder über i4.

    Mit den Tasten Steuer ich (1 Tastendruck 5min Licht, 2 Tastendruck Dauerlicht, 3 Tastendruck aus).

    Bewegungsmelder erzeugt ein 5min Licht.

    Die i4 steuern die Tastendrücke und erhalten vom ioBroker die Infos über die Bewegungsmelder.

    Der ioBroker macht die Tastenauswertung sowie die 5min Licht und das Licht (an,aus, Leuchtkörper überwachung) sowie die Tag Nacht auswertung.

    Ist sicher kurios läuft aber sehr zuverlässig und hat den WAF bestanden.

    Vorher war das alles mit einer Simens logo gebaut, die mir dann aber abgeraucht ist (Altersschwäche) und ich dachte i4, Dimmer2 und fertig, der ioBroker läuft eh.

    Was ich jetzt mehr habe ist eine Nachtbeleuchtung der Haustür, langsames an und ab Dimmen, Leuchtmittelüberwachung ist eine Schöne Sache aber zu welchem Preis.

    Das mir das so viele Probleme beschert hätte ich nicht gedacht.

    Ich würde daher aus meiner Erfahrung sagen, dass es kein WLAN-Problem oder Problem der FritzBox sein kann.

    Wurden die Shellies mehrfach hintereinander vom Strom getrennt?

    Das muss ein Problem der i4 und dimmer2 in Verbindung mit einer Fritz Firmware >7.29 sein.

    Irgend was macht da Probleme ?!?!

    Die Shelldy sind ununterbrochen am Netz.

    Auch ich habe schon mehrfach wie Du auch umgestellt und Shellys Elternlos gelassen, die haben sich sofort wieder eingereiht wenn alles wieder so wahr wie Sie das erwartet haben bis jetzt wahr alles dem User zuzuschreiben wenn mal was nicht lieft.

    Jetzt sitzt er da und macht ein Dummes Gesicht und freut sich das es mit der 7.29 läuft.

    Die 7490 ist eigentlich Überflüssig und sieht Sch... aus.

    Hilft nur weil sie ein WlanSubnetz aufbaut

    Stoppen die Scripte denn, wenn IPs nicht erreichbar sind?

    Mir erschließt sich leider immer noch nicht, wie eine FritzBox ein Script aus einem Gerät löschen können soll, bzw. wie sie dieses resetten können soll.

    Wenn du jetzt wieder upgradest wäre es ein großer Aufwand? Jetzt weißt du ja, was zu machen ist. Tritt der Fehler dann wieder auf, und das nur bei der Laborversion, dann würde ich mich an AVM wenden, denn dafür ist die Laborversion ja da.

    Das hat mich Gestern mehrere Stunden gekostet die 7490 hatte mich ausgesperrt und ich musste mir erst mal ein Telefon besorgen GRRRRR um Werksreset machen zu können.

    Das währe dann das Gleiche wie gestern nur mit dem Vorteil das ich wüste was zu tun ist.

    Nur mehr Erkenntnise als jetzt hätte ich nicht, denn schau mal in den Anfang dieses Bereiches da hatte ich das auch schon nur noch nicht die Erkenntnis das es auch einer Firmware >7.29 liegt.

    Was soll ich denen Antworten , die werden sagen das liegt an den Shellys, die sind nicht Kompatiebel, so eine Diskussion ist Müssig.

    Für Konkrete Antworten fehlen mit Kentnisse und Analysen aber wie machen und was kann man daraus sehen?

    Dafür bin ich sicher kein Fachmann.

    Die Scripte sind was Das Fehlermanagement betrifft etwas Dümmlich. Die merken das nicht.

    Das würde den Stop erklähren aber keinen Werksreset oder löschung der Scripte.

    Die 1200 AX könnten auch per Beta versorgt werden, was eventuell Sinn machen kann , damit alles auf selben Stand ist.

    Hast du vielleicht den DHCP-Server auf der 7490 eingeschaltet gelassen?

    Das erklärt jedoch nicht die gelöschten Scripte und den Werksreset. Bei den Gen1 Shellies ist dieses durch Einschalten der Spannungsversorgung und 3x Taster innerhalb der ersten Minute betätigen oftmals erklärt. Macht der i4 dieses auch und du hast versehentlich einen Reset durchgeführt?

    Der DHCP ist bei der 7590 an, bei der 7490 war er bei beiden Firmwaren aus.

    Die Funktion 3xTasten bei den i4 habe ich ausgeschaltet (Das hatte ich schon und hat mich Tage gekostet).

    Die 1200AX auf die Beta kann ich machen ist aber unnötig und sicher nicht die Ursache.

    Also ich habe eine 7590 Firmware 7.51-104921 Beta mit DSL am Internet.

    Mehrere 1200AX Firmware 7.39-1104706 Beta über Kabel angeschlossen.

    Eine 4040 Firmware 7.51-104930 Beta über Kabel angeschlossen.

    Bei All dem läuft ein Mash mit festem Kanal und einem SSID.

    Fast Alle Geräte haben eine Feste IP die Shellys sowiso-

    Daran sind 95% aller meiner Geräte angemeldet Shelly, PC, Alexa usw.

    So weit so Gut alles läuft (Auch die TRV).

    Jetzt kommen die Problemkinder.

    Alle hängen an der 7490 Firmware 7.29 die ist über Kabel an der 7590 angeschlossen.

    Die 7490 hat einen Anderen SSID als der Rest und läuft auf einem Anderen Wlan-Kanal.

    An dem WLAN der 7490 hängen 4xShelly i4 und 4 x Dimmer2.

    Somit sind die eigentlich vom Rest Wlan mässig abgekoppelt.

    Auf den i4 laufen scripte die über MQTT mit dem ioBroker kommunizieren und auch von da Befehle bekommen.

    Das alles funktioniert einwandfrei.

    Mein Fehler war es auf die 7490 die Firmware 07.51-104919 aufzuspielen (War eigentlich ein Versehen) aber das führte dazu das ein Script auf Stop stand und bei 2 i4 waren die Scripte gelöscht und einer wahr auf Werksreset.

    Dann alles wieder zurück und die 7.29 drauf die 7490 und alles war wieder in Butter.

    Ich hoffe ich habe das verständlich erklärt.

    Jetzt läuft alles wieder aber wo ist der Fehler?

    Das ich alles Beta habe weis ich aber bei der Release wird das sicher genau so sein (Meine Vermutung).

    Hallo

    Nach dem ich die FritzBox7590 zurückgeben musste, habe ich eine 7490 mit Firmware 7.29 eingebaut Selbe Konstellation und das hat bis Vorestern einwandfrei funktioniert.

    Dann habe ich Vorgestern auf die Firmware 07.51-104919 geupdatet und da fing das nach dem ich neu gestartet hatte wieder an.

    Die 7490 wahr auf festen Kanal und die I4 und Dimmer2 auf feste IP eingestellt auch hatte die 7490 einen anderen SSID als alle Anderen Boxen und Repeater die ja im Mash laufen.

    Nach dem ich zurück auf die Firmware 7.29 gegangen bin war alles wieder OK, keine Abstürze und auch keine gelöschten Scripte mehr.

    Für mich sieht es so aus als haben die Shellys Probleme mit einer Box Firmware höher als 7.29.

    Hardwarefehler sowie Mash kann man sicherlich ausschließen da ich sonst nichts verändert habe.

    Hat eine eine Idee was das letztendlich sein könnte und ob es eine Hilfe gibt?

    Dann hast du etwas endscheidendes übersehen was ich geschrieben habe.

    Wenn bei der Kalibrierung etwas schief gegangen ist !!!!

    Wenn bei der Kalibrierung alles OK war wird er das über die geschlossen % Anzeige auch melden.

    Warum überprüfst du das Ventil nicht einmal ?

    Wer schreibt der bleibt ist keine Lösung.

    TRV runter, Handventil drauf und probieren.

    Ventilstößel mal von Hand betätigen (reindrücken) geht der im vergleich zu einem Anderen schwer ?

    Ich glaube das der TRV OK ist und alles geschreibsel deutet darauf hin.

    Ich habe hier auch 2 solche Kandidaten da streiken die TRV, Danvon,Devolo und auch Eurothronics die Dinger gehen nicht zu 100% zu.

    Ursache Ventil schwergängig oder undicht.

    Die Smart-Home Geräte sind OK.

    PS Bei einigen Ventilen bei mir im Altbau hat Silikonfett geholfen und bei der Nächsten Gelegenheit fliegen die raus.

    Danke für den Tipp mit den UP Dosen!

    Ich muss Mal gucken, was da vor Ort verbaut ist. Ich meine aber da sind schon diese tiefen Unterputz-Dosen verbaut. Die sind ja so 6cm tief, so dass ich die Hoffnung habe da alles reinzubekommen - auch wenn es bestimmt eng wird.

    Hier ist so etwas da bekommst du sehr viel rein.

    Der Sack kann oben unten rechts oder links sein.

    Voxura Hohlwand-Elektronikdose Tunneldose Gerätedose Schalterdose 75mm tief HW Ø 68mm Orange 2 Stück : Amazon.de: Baumarkt

    Natürlich seh ich die % Werte, genau das macht es ja so seltsam. Die Ventile sind laut MQTT und Cloud zu 0% geöffnet aber warm. Wenn die TRVs nicht mehr richtig schließen könnten wegen zu wenig Kraft, dann würde ich da keine 0% sondern 5% oder 1% erwarten. ;)

    Dann hast du eigentlich dein Problem selbst analysiert.

    Der TRV geht davon aus das Das Ventil geschlossen ist.

    Somit ist er erst mal aus der Fehlerquelle raus.

    Betrachten wir das mal weiter, warum meint er das Das Ventil zu ist ?

    Er geht davon aus das bei der Kalibrierung das Ventil bei Erreichen der Endstellung (Motorstrom über Max-Stromparameter) erreicht wurde.

    Das er damit möglicherweise den Zustand geschlossen noch nicht erreicht hat kann er nicht wissen (Woher auch).

    Somit ist die Größte Wahrscheinlichkeit die das das Ventil defekt oder zu schwergängig ist.

    Somit ist der TRV OK und macht das was er soll.

    Oben wurde schon geschrieben das du das Ventil betrachten und Prüfen sollst.

    Tausche es aus wenn du der Meinung bist oder die Analyse es hergibt das es defekt ist.

    z.B TA Heimeier Thermostat-Oberteil Standard mit Nockenkennzeichnung DN 10, 15, 2001-02.300 : Amazon.de: Baumarkt

    Ob genau das nun passt kann ich nicht sagen aber so etwas vergleichbares würde dein Problem lösen.

    Wenn deine Anlage so alt ist tausche besser alle aus.

    Aber auch dann würde ich eine entsprechende Meldung erwarten. Die TRVs "wissen" ja wie weit der Weg ist, den sie das Ventil maximal bewegen können. Wenn das plötzlich nicht mehr geht, dann muss ich sowas melden können.

    Guten Morgen

    Schau mal hier !

    Shelly TRV: /status – API Reference

    Shelly TRV: /thermostats/0

    AttributeTypeDescription
    posnumberPosition of the valve, 0..100 and -1 if not calibrated. Setting position to arbitrary value disables automatic temperature control

    Per MQTT könnte man den Zustand des Ventiles kontrollieren wenn man es den möchte.

    Möglicherweise hilft dir das weiter.

    Ich mache alles per MQTT und da geht das. Ob das beim Shelly-Adapter auch geht kann ich nicht sagen.

    Ostergrüße aus dem Sauerland