Beiträge von Dieter Schmitz

    Genau soweit bin ich mit meinen Versuchen auch gekommen. (sieht vorherige Posts).

    Was bei mir hilft:

    Ich benutze einen shelly1 als externen Sensor wegen räumlicher Gegebenheiten.

    Der TRV steht auf Under floor heating, sonst wird die Temperatur des TRV und des externen Sensors

    irgendwie gemischt beim berechnen und es wird nicht war.

    Die Ist Temperatur des externen Sensors schicke ich alle 10 Sekunden vom IoBroker

    per http Befehl an den TRV.

    Der Fehler (Null Werte) tritt nur noch sehr sporadisch auf (ca. einmal die Woche wenn überhaupt).

    Wenn er auftritt wird der Null Wert spätestens nach 10 Sekunden vom IoBroker

    mit dem richtigen Wert überschrieben und der TRV läuft wieder normal weiter.

    Das und alle meine log files ect. habe ich an den Support geschickt.

    Antwort (Sinngemäß):

    Vielen Dank für die Angaben.

    Schön das jetzt alles bei ihnen funktioniert. X(

    ThomasKA

    Code [httpIoBrokerState] Error for state SHTRV-01#8CF681xxxxxx#1.name for 192.168.0.80 (shellytrv / shellytrv-8CF681xxxxxx / SHTRV-01#8CF681xxxxxx#1) "/settings": SyntaxError: Unexpected token < in JSON at position 0 - value: "<!--#settings-->"

    Das ist ein Log Eintrag im IoBroker. Der IoBroker hat den Befehl http://IP-Adresse-TRV/settings gesendet.

    Darauf bekommt der IoBroker seine Antwort im JSON Format.

    Entscheident ist die Aussage:

    SyntaxError: Unexpected token < in JSON at position 0 - value: "<!--#settings-->"

    Was soviel bedeutet wie:

    Die Antwort ist Schrott. An der Position value wird ein falsches Zeichen (wahrscheinlich ein Sonderzeichen) empfangen.

    Entspricht nicht dem JSON Format.

    Beispiel solch einer Antwort vom TRV:

    Code
    {"enabled":true,"value":��.�,"value_op":�.�,"units":"C"}


    Mehr dazu habe ich dir in einer Konversation geschickt.

    ;)

    Hallo,

    wieder mal ein Update von mir.

    Bei mir liegt es definitiv nicht am Mesh der FRITZ!Box oder generell an der FRITZ!Box (7490).

    Wie weiter oben beschrieben habe ich einen alten Speedport 721v an die FRITZ!Box gehängt, ein eigenes WLAN

    konfiguriert und da war der TRV drin. Der 721v ist so alt, der kennt gar kein Mesh.

    Der Fehler ist trotzdem aufgetreten.

    Was ich in der Zwischenzeit alles versucht habe kann man weiter oben in meinen Posts lesen.

    Stand heute:

    Ich lese die Temperatur mit dem IoBroker bei meinem externen Sensor (Shelly1) aus und schicke die

    mittels Http direkt an den TRV und das jede Minute und direkt 10 Sekunden danach noch mal.

    (Weil ich festgestellt habe das der TRV die IP Verbindung von Zeit zu Zeit hart beendet).

    Seit dem ist Ruhe und der TRV läuft wunderbar.

    Der TRV ist wieder ganz normal im WLAN der FRITZ!Box.

    Die Cloud habe ich am TRV abgeschaltet.

    Gestern habe ich im IoBroker mal mqtt für denTRV aktiviert. Das hat ihn meiner Meinung nach schon wieder

    an den Rand der Belastung gebracht. Also wieder abgeschaltet.

    Was ich an Daten von dem TRV haben will lese ich per http mit dem IoBroker aus. Das hat von Anfang an sauber

    funktioniert.

    der_timo

    Hallo,

    ich habe eine kurze Beschreibung und das Blockly in die angehängte PDF gepackt.

    Vorab noch kurz.

    Das ist natürlich eine "Krücke" bis es neue Firmware für den TRV gibt. Laut Support wird dran gearbeitet.

    Bitte auch Bedenken das ich noch einige andere Sachen bei mir verändert habe, die ich bisher noch nicht zurück genommen habe. (Dazu bitte meinen Ellenlangen Post weiter oben lesen).

    Ich benutze zur Temperaturermittlung einen Shelly1 mit externem Sensor. Der ist bereits per Adapter im IoBroker angemeldet.

    Diesen Eintrag benutze ich im Blockly.

    Über eine Rückmeldung würde ich mich freuen.

    der_timo (Vielleicht Postest du ja mal kurz wie es bei dir aufgebaut ist. Ist der TRV an der Fritzbox?)

    Falls noch Fragen sind einfach melden.

    Ich hoffe es hilft dir.

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    .

    Die url in den Browser eingeben und anstatt ner Temperatur (Float) irgendwas anderes eingeben. Nen String oder wie auch immer. Wie gesagt von fehlerhaften Werten wird er kaum Abstürzen vll. wenn ich selbst nen art DOS angriff starte. Aber das wäre was anderes.

    Ich tendiere hier weiterhin auf einen Fehlenden Timeout welcher die Verbindungen offen lässt und auch eine Erklärung für ein nicht Chronologisches Logfile spricht. Fehlerhafte werte werden nach eigenem Test weiterhin Chronologisch in das Logfile geschrieben!

    Genau das ist das Problem mit NULL.

    Ich kann das Leider nicht besser erklären deshalb habe ich mal nach einer Erklärung gesucht.

    Was ist NULL für ein Datentyp?

    Ein NULL-Wert wird in einer relationalen Datenbank verwendet, wenn der Wert in einer Spalte unbekannt ist oder fehlt. Ein NULL-Wert ist weder eine leere Zeichenfolge (für Zeichen- oder datetime-Datentypen) noch der Wert 0 (für numerische Datentypen).

    Und weil NULL eben eine Sonderstellung hat kann man damit nicht rechnen. Wird so ein Auftreten von NULL im Datenfeld nicht per Software abgefangen, führt das unweigerlich zu Komplikationen bei einer Berechnung.

    Und das versucht der TRV ja, aus dem Wert will er die benötigte Stellung des Ventils berechnen.

    Sorry, aber besser kann ich es nicht erklären. :/

    Würde nicht zum Absturz führen nur weil er was falsches speichert. Würde ja dann ständig passieren und wäre einfach zu reproduzieren

    Das Problem ist nicht das speichern des falschen Wertes.

    Die Berechnung läuft dann aus dem Ruder und bringt ihn zum Absturz.

    Wie soll ich dem TRV ein NULL senden?

    Per Browser habe ich keine Idee.

    Per IoBroker habe ich auch keine Idee. Da habe ich bisher nicht mal was gefunden auf NULL zu Prüfen.

    So, hier also wie bereits Angedroht meine Umfassende Beschreibung.

    Umfassend deshalb damit nicht wieder einer schreibt ich soll zum Beispiel an der Heizungsanlage was anders einstellen. Geht nicht, ich wohne zur Miete.

    Also,

    mein Wohnzimmer ist ca. 35 m² groß. Es gibt eine Heizung direkt unter einer massiven Fensterbank. Das Haus in dem ich zur Miete wohne ist über 70 Jahre alt.

    Durch diese Umstände ist es in der Mitte und vor allem am anderen Ende des Raumes gegenüber der Heizung um einige Grade kälter als direkt an der Heizung.

    Um es am Ende des Raumes auf 20-21 Grad zu bekommen muss ich die Heizung voll aufdrehen, so das man es vor der Heizung nicht aushalten kann und das

    natürlich die Heizkosten enorm in die Höhe treibt.

    Ich habe die Wandseite hinter der Heizung bereits mit Dämmplatten ausgeklebt. Des weiteren habe ich an der Heizung drei Lüfter die zeitgesteuert die Warme Luft

    von der Heizung in den Raum blasen.

    Durch die Größe des Raumes ergibt sich auch der unschöne Effekt, das wenn mein Nachbar unter mir aus Spargründen oder Abwesenheit die Heizung aus oder runter regelt,

    der Boden so Kalt wird das die Warme der Heizung sofort an die Decke steigt.

    Soviel also zu meinem Problem.

    Um dem entgegen zu wirken wollte ich einen Thermostat den ich mittels externem Sensor (Mitte des Raumes) steuern kann.

    Ich hatte bereits mehrere Thermostate von anderen Firmen im Einsatz ohne nennenswerten Erfolg.

    Dann habe ich mich als letztes für den Fritz Dect 301 (Thermostat) und den Fritz Dect 440 (Sensor) entschieden.

    Wie der Name schon sagt arbeiten die über Dect. Das hat den Nachteil, das Fritz wegen Akkulaufzeiten hier mit einem 15 Minuten Raster arbeitet.

    Das ist für meine Situation viel zu lang.

    Des weiteren, wie sich später heraus stellte, kann man den Fritz Thermostat nicht zwingen nur auf den externen Sensor zu hören.

    Das heißt in der Logik der Software des Thermostaten kommt der Punkt an dem die am Thermostat gemessene Temperatur zu hoch wird um im

    Bereich des Sensors (Mitte Raum) die 20-21 Grad zu erreichen. Die Software sagt "nein, das kann nicht sein". Die Temperatur Differenz zwischen

    Thermostat und Sensor ist der Software zu hoch.

    Das habe ich in längerem Schriftwechsel mit Fritz heraus bekommen. Diese Grenze liegt bei 9 Grad Differenz. Das scheint übrigends ein gängiger Wert zu sein auch bei anderen Produkten.

    An dieser Stelle vielen Dank an Fritz für ihren Support. Immer freundlich, schnell, kompetent und sehr bemüht.

    Leider kamen wir zu keinem positiven Ergebnis.

    Deshalb habe ich viel Hoffnung auf den TRV von Shelly gesetzt. Eine Einstellung "nur externen Sensor benutzen" lies mich hoffen.

    Ich habe also einen TRV zuerst mit einem H&T (dem kleinen Golfball, nicht dem Plus) als externen Sensor betrieben.

    Als der Fehler auftrat habe ich nach Lektüre hier im Forum die Schuld natürlich auf den H&T geschoben. (Gründe dafür kennt jeder der hier im Thema ist).

    Also habe ich einen Shelly1 mit externem Temperaturfühler benutzt. Leider trat der Fehler immer noch auf.

    An dieser Stelle sei auch schon gesagt, wenn der TRV läuft regelt er wunderbar und schnell. Mit diesem Ergebnis bin ich mehr als zufrieden.

    Die Temperatur im gesamten Raum regelt sich auf 20-21 Grad, d.h. das Temperaturgefälle von vorne (Heizung) zu hinten im Raum ist am Tag

    nicht größer als 1 Grad.

    Ich habe den TRV so eingestellt das er um 07:00 Uhr anfängt zu heizen. Ab da schallte ich auch die Lüfter ein im 15 Minuten Takt um die erwärmte Luft sofort zu verteilen.

    Um 07:30 Uhr habe ich Wohnzimmer schon eine angenehme Temperatur von 19-20 Grad die sich dann sehr rasch auf 20-21 Grad einregelt.

    Die Lüfter schalte ich ab 09:00 Uhr aus weil auf Dauer gehen die einem natürlich auf die Nerven.

    Soweit so schlecht, warum läuft der TRV also von Zeit zu Zeit gegen die Wand.

    (Ich hoffe der geneigte Leser ist noch Wach :) )


    Ich liste hier noch mal auf was bei mir nichts gebracht hat von allen Ratschlägen oder Vermutungen hier im Forum:

    TRV und externer Sensor in einem eigenen WLAN. Fehler! (Damit ist für mich auch das Thema "Mesh der Fritzbox ist Schuld" vom Tisch).

    Cloud am TRV abschalten. Fehler!

    IoBroker ist Schuld. IoBroker rausgenommen. Fehler!

    Ich hatte auch schon mal den Gedanken der Akku könnte Schuld sein und habe den TRV am Netzteil gehabt. Nutzt aber eh nichts, weil der TRV das Netzteil abschaltet wenn der Akku voll ist.

    Und der Fehler war immer noch da!

    Dann dachte iich den TRV am einschlafen zu hindern mit einem Dauer Ping. War natürlich völliger Unsinn, das läuft ja in einer unteren Ebene und hindert den TRV nicht am Einschalfen. Fehler!

    Dann hatte ich den Einfall den externen Sensor mit dem IoBroker per Script auszulesen und den Temperaturwert per Script an den TRV zu schicken,

    immer dann wenn sich der Wert ändert.

    Das funktioniert auch sehr gut, nur leider trat der Fehler immer noch auf!

    Dann habe ich die Taktung geändert auf "jede Minute senden" egal ob sich was geändert hat. Fehler!

    Da habe ich aber im Log des IoBroker als Meldung gesehen "Server (also der TRV) hat die IP-Verbindung beendet"

    Das brachte mich auf die Idee das der TRV entweder einfach einschläft oder einfach hart die IP-Verbindung kappt.

    Deshalb habe ich im IoBroker das Script geändert und Sende den Temperaturwert am Anfang der Minute und direkt 10 Sekunden später noch einmal.

    (Die Idee war einfach so oft zu schicken bis der TRV nicht mehr einschläft).

    Seit dem läuft bei mir alles Propper. Seit über einer Woche.

    Ich habe damit gerechnet das es einen Einfluss auf die Akku Laufzeit hat, konnte bisher aber nichts feststellen.

    Ich habe die bisher gemachten Änderungen noch nicht zurück genommen weil man nicht ausschließen kann das es mehr als eine

    Abhängigkeit gibt. Ich werde jetzt nach und nach wieder zurück Ändern um zu sehen was passiert.

    Zum guten Schluss noch meine Hardware und Konfiguration des TRV.

    Ich habe eine Fritzbox 7490 und dahinter einen alten Speedport 721v für das extra WLAN in dem der TRV und der Shelly1 laufen. (Der 721v kann kein Mesh, also kann es auch nicht an der Fritzbox liegen)

    Konfiguration des TRV:

    Sensor Settings

    Temperatur Offset => externer Sensor

    Open Window => Off

    Temperature Units => Celsius

    Weekly Schedule

    von 07:00 Uhr bis 23:00 Uhr 21 Grad

    von 23:00 Uhr bis 07:00 Uhr 17 Grad (die Temperatur in meinem Wohnzimmer ist bisher nicht unter 18 Grad Nachts gesunken)

    Internet & Security

    Wifi-Mode Client

    statische IP

    Wifi- Mode Access Point

    Off

    Restrict Login

    Off

    SNTP Server

    Macht meine Fritzbox

    MQTT Settings

    Off

    COIOT

    Off

    Cloud

    Off

    Actions

    Valve Open

    Off

    Valve Closed

    Off

    Settings

    Auto Temperatur Control

    Enable Automatic => On

    Accelerated Heating => Off

    Boost => Off

    Minimum Valve Position => 0

    Under Floor Heating Mode => On /wegen dem Satz "Оnly the data from the external sensor is valid, without taking into calculations changes from the built-in one." Hatte ich weiter Oben schon beschrieben. Damit wird der TRV gezwungen nur den externen Sensor zu benutzen.

    Display

    High

    no Rotation

    Child Lock => Off

    Glog Prevention => On

    Force Close => Off

    Firmwareupdate => 20220811-152343/v2.1.8@5afc928c

    Time Zone and GEO-Location

    Automitc

    Device Name

    Shelly-Thermostat

    Device Calibration => On

    Device Caliberable

    Das hacke ich zwar immer an, bleibt aber nicht gesetzt.


    Was habe ich bisher von meinen Veränderungen wieder zurück gestellt:

    Der Shelly1 ist wieder im WLAN der Fritzbox.

    Sobald sich etwas Neues ergibt werde ich wieder Posten.

    Stand 14.01.2023 15:45 Uhr => es Läuft


    Devil

    So ist es nicht.

    Der TRV lief korrekt auch während das Log "strubbelig" war.

    Plötzlich tritt der Fehler auf und sowohl bei der Abfrage von /status des TRV wie auch im Log des IoBrokers stehen falsche Einträge.

    Das ist immer zur gleichen Zeit, also kein Versatz.

    Interessant ist ja auch, das wenn ich es schnell genug schaffe (innerhalb mehrerer Minuten) im Browser den Befehl

    http://IP-TRV/ext_t?temp=XX.X abzusetzen, der TRV sich wieder fängt und weiter arbeitet.

    ThomasKA

    Vielen Dank für deinen Hinweis.

    Ich habe mal direkt nachgeschaut. Bei dir war auch der GPS Eintrag fehlerhaft, also nicht genau wie bei mir.

    Allerdings auch die gemessene Temperatur wie bei mir.

    Meine Hypothese lautet wie folgt (und das gilt nur für mein Netz/Problem mit dem TRV):

    Aus irgend einem Grund kappt der TRV die IP-Verbindung. Dadurch entstehen falsche Einträge in seinen Datenfeldern oder leere Datenfelder.

    Und hier sieht es für mich so aus als wäre da die gemessene Temperatur am wichtigsten bzw. der Auslöser.

    Laut Status Abfrage stehen dort im Fehlerfall ja "Sonderzeichen".

    Bei mir im IoBroker wird "NaN" angezeigt, das bedeutet "NULL". (Kurz zum Hintergrund. Der Wert "NULL" bedeutet es steht nichts in diesem Feld, also ein leeres Feld. Das ist ein Unterschied zu einer nummerischen 0. Das führt bei Datenverarbeitung sehr oft zu sehr komischen Fehlern. Das wird oft in der Software vergessen so einen Fall abzufangen, weil ja ein nummerischer Wert erwartet wird.)

    Mit diesem Wert NuLL kann die Software des TRV also nichts anfangen und rechnet und rechnet wie er denn das Ventil einstellen soll. Da steht dann irgendwann auch kein gültiger Wert mehr drin (so schon bei mir gesehen).

    Das führt dazu das der TRV aussteigt.

    Bei mir läuft bisher (ich klopfe auf Holz) alles rund. Der TRV arbeitet sehr gut. Da ich wie schon gesagt den IoBroker zur Datenerfassung nutze, habe ich eine

    schöne Statistik wie er Arbeitet bzw. Regelt. Werte für Heizung Zulauf, Heizung Temperatur, Heizung Ablauf, Temperatur in der Raummitte, Temperatur Raumende, Außentemperatur.

    Und ich muss sagen der TRV regelt hervorragend.

    Ich schreibe gleich noch einen Post in dem ich noch mal genau schreibe wie die Gegebenheiten bei mir sind und was ich genau im Moment verändert habe.

    Aber jetzt muss ich erst mal was Essen :)

    Ich kann mir das zwar dann bei anderen Leuten die eben kein übergeordnetes System nutzen nicht ganz vorstellen. Bei mir im HA hat der rest_command per default einen Timeout von 30 Sekunden.

    Status ändere die ich nur wenn sich der Sensor selbst ändert. Hier wird nach einer Wartezeit von 2 Sekunden geprüft ob sich der Wert geändert hat. Ansonsten wird er nochmals übermittelt.

    Was mich aber jetzt Stutzig macht ist dein durchwürfeltest Logfile. Das klingt mir fast so wie wenn hier der TRV die Verbindungen offen lässt und diese immer mal wieder sporadisch schließt (gelegentlicher Timeout) aber ansonsten irgendwann durch offene Verbindungen seinen Speicher zumüllt und abschmiert!

    Hallo Devil,

    vielen Dank für die Gedanken von Dir.

    Folgendes zur Info:

    Eigentlich benutze ich den IoBroker nur für die Übersicht und das eventuelle Bedienen der Shellys.

    Eine Steuerung der Heizung (des TRV) wollte ich eigentlich nicht damit machen.

    Das mache ich im Moment nur um weiter Eingrenzen zu können.

    Folgende Felder (und immer nur diese) sind im Fehlerfall immer fehlerhaft bei mir (Abfrage /status):

    Position des Ventils;

    Ziel Temperatur;

    value_op -> das ist die Temperatur die bei Fenster offen (wenn aktiviert) eingest4ellt werden soll. Bei Staus Abfrage steht hier 8.0 Grad. In der Beschreibung der API ist das Feld nicht angegeben.

    gemessene Temperatur;

    Batterie Spannung;

    Würde mich mal interessieren ob es bei den anderen auch diese Felder sind. Wer also mal Lust hat zu Posten, wäre Nett.

    Wie schon beschrieben habe ich zuerst auch nur bei Änderung der gemessenen Temperatur diese zum TRV geschickt.

    Da der Fehler aber weiterhin aufgetreten ist habe ich auf 1 x pro Minute gestellt.

    Und da ist mir dann der Fehler im IoBroker Log aufgefallen " Server hat die IP-Verbindung beendet"

    Dann habe ich es so eingestellt das ich 10 Sekunden später den Wert noch mal schicke.

    Und seit dem scheint es zu laufen.

    Daher denke ich auch das der Fehler (Abbruch der Ip-Verbindung) auch bei denen Auftritt die kein übergeordnetes System benutzen.

    Wenn der Fehler genau da Auftritt wenn die gemessene Temperatur übermittelt wird, läuft der TRV wohl vor die Wand weil er mit den Daten nichts Anfangen/Berechnen kann.

    Deine Überlegung mit dem Speicher hat mich auch ins Grübeln gebracht.

    Allerdings ist im Log wohl alles soweit vorhanden, nur halt manchmal durcheinander. Eventuell kann da aber auch mit der Cloud zusammen hängen. Die ist ja im Moment auch ausgeschaltet.

    Ich Poste dir hier mal einen Ausschnitt des Log von jetzt. Dann kannst du dir ein besseres Bild davon machen. Vom Fehlerfall habe ich leider nichts.

    (Im Fehlerfall sind die einzelnen Einträge ineinander geschrieben, so als hätte man die Daten zerschnitten und total verwürfelt wieder aneinander gefügt).

    ### Log Auszug #####

    Neue Update von meinen Versuchen.

    Den TRV und den Shelly1 (externer Temp Sensor) in ein seperates WLAN zu stecken hat nichts gebracht.

    Immer wieder Abstürze des TRV.

    Abschalten der Cloud (TRV) hat auch nichts gebracht.

    Zwischendurch ist mir immer wieder Aufgefallen das das Log de TRV mitunter durcheinander geht. D.h. Einträge sind Durcheinander geschrieben.

    Hat das schon mal jemand bei seinem festgestellt?

    Auch ist mir aufgefallen das im Fehlerfall immer die gleichen Einträge des TRV fehlerhaft sind. Unter anderem die Temperatur des externen Sensors.

    Im Fehlerfall steht da kein Eintrag außer einem Punkt (.) drin. (falsche Zeichen werden ja nicht angezeigt).

    Da ich wie weiter oben Beschrieben die Temperatur des Shelly1 (externer Sensor) mit dem IoBroker auslese und dann per IoBroker mit einem Blockly Script den

    Befehl http://TRV-IP/ext_t?temp=XX.X an den TRV schicke (weil ich dem Shelly1 auch nicht mehr getraut habe und so besser verfolgen kann wo was schief geht),

    ist mir was Aufgefallen. (Bisher habe ich den Befehl immer gesendet wenn sich die Temperatur am Shelly1 geändert hat, dann fest jede Minute).

    Im Log des IoBroker konnte ich feststellen das der TRV die IP Verbindung hart abbricht, während der Temp Befehl noch gesendet wird.

    Sinngemäß stand da im Log "Server hat die Verbindung abgebrochen".

    (Anmerkung: wenn ich den Fehlerfall früh bemerkt habe konnte ich öfter durch senden des Befehls mit dem Browser den TRV zum weiterarbeiten bringen).

    Daher habe ich das Script für das senden des Befehls geändert.

    Ich sende jede Minute die Temperatur zum TRV und direkt 10 Sekunden später direkt noch einmal. (das scheint den TRV wach zu halten)

    Ich habe seit über einer Woche keinen Fehlerfall gehabt.

    Im IoBroker ist im Log auch kein Fehler mehr zu finden.

    Einen Einfluss auf die Batterie konnte ich nicht feststellen.

    Momentanes Fazit:

    1. Es sind bei mir immer die gleichen Felder im Fehlerfall die Fehlerhaft sind.

    Für mich sieht es so das der Fehler auftritt wenn das Temperaturfeld falsch ist.

    2. Es sieht so aus als wäre das Mesh der Fritzbox (7490) nicht dran schuld.

    3. Was bei mir auffällig ist, ist das das Log des TRV nun immer sauber aussieht.

    Wie von einem Buchhalter geschrieben.

    4. Ich habe die Vermutung das der Sleepmode des TRV hart gecodet ist. Soll heißen nach X Sekunden/Minuten wird die IP-Verbindung dadurch gekappt,

    egal ob gerade Daten ankommen oder nicht.

    Ich habe bisher alle vorher gemachten Änderungen beibehalten weil man ja nicht ausschließen kann, das mehrere Dinge im Zusammenspiel den Fehler auslösen.

    Ich werde jetzt noch ein paar Tage abwarten ob es weiterhin so bleibt und dann nach und nach alles wieder zurück bauen, bis auf des Script.

    Sobald es was Neues gibt werde ich hier wieder Berichten.

    Vielleicht hilft es ja denen die ebenfalls den IoBroker benutzen. Wäre nett wenn der ein oder andere das bei sich auch mal probieren und hier Posten würde.

    Hallo,

    ich melde mich mal wieder nach einigen Fehlversuchen.

    Ich habe auch eine Fritzbox 7490 und einen IoBroker.

    Ich habe den TRV und einen Shelly 1 als Externen Sensor in Betrieb.

    Beide direkt an die Fritzbox ins WLAN. -> keine Änderung, TRV stürzt ab.

    Ich habe in der Fritzbox die beiden Geräte und den IoBroker priorisiert. -> keine Änderung, TRV stürzt ab.

    Ich habe die Externe Temperatur vom Shelly 1 per IoBroker ausgelesen und bei veränderung an den TRV geschickt. -> keine Änderung. (Weil laut Datenannalyse Coap Daten sendet wie verrückt)

    Jetzt habe ich an die Fritzbox einen alten Speedport W721V drangehängt als AP.

    In dem WLAN des Speedports sind nur der TRV und der Shelly1.

    Es scheint besser zu laufen als je zuvor.

    Die Weboberfläche ist immer sofort geladen, vorher hat das bis zu 10-15 Sekunden gedauert bis sich da was getan hat.

    Ich habe das erst seit heute in Betrieb.

    Ich werde hier weiter berichten ob es jetzt läuft.

    Meiner Meinung nach gibt es Schwierigkeiten mit der Fritzbox und deren Mesh. Das scheint erhebliche Verzögerungen zu erzeugen bis zu einem

    Timeout beim TRV, so das er keine Daten mehr annimmt.

    Im Fehlerfall ist mir aufgefallen das das Log des TRV ziemlich durcheinander aussieht, als wäre von den ankommenden Datenmengen überfordert.

    Hallo, relativ neu hier möchte ich doch auch meinen "Senf" dazu geben.

    Mein TRV ist nun auch zum dritten Mal gegen die Wand gelaufen.

    Abfrage mit IP/Status -> Sonderzeichen

    IP/reboot -> mal hat es funktioniert, mal nicht (vielleicht habe ich aber auch zu früh die Geduld verloren)

    Der TRV hängt direkt an der Fritzbox 7490.

    Für die Fritzbox ist der TRV noch im Wlan. (sonst wäre ja auch kein Ping, /status ect. möglich).

    Was mir aufgefallen ist: im IoBroker werden dann immer die Angaben über Temp und Pos mit NaN angezeigt.

    D.h. es gibt ein Problem mit dem Flieskomma. Eventuell ist das aber auch nur ein Folgeproblem.

    Zuerst hatte ich als externen Sensor einen H&T dran. Den hatte ich zuerst in Verdacht, da er nach dem Update bei eventuellen Fehlern

    "Null" als Wert an den TRV sendet für die Temperatur. Sowas führt öfter mal zu Problemen und Absturz einer Software.

    Den H&T habe ich durch einen Shelly1 mit externem Sensor ersetzt.

    Gefühlt lief das besser und ich glaube es hat auch länger gedauert bis zum Absturz des TRV. (Leider habe ich mir die Zeiten nicht aufgeschrieben).

    Ich benutze kein MQTT.

    Die MAC fängt auch mit 8CF6 an. (Das macht mich ziemlich stutzig).

    Firmware ist die 2.1.8

    Feste IP.