Schau dir mal den Adapter "Log Parser" an, damit kann man die Logs auslesen und selektieren. Teste ich auch gerade.
ich hab ihn mir mal runtergeladen und werde am We mal ein blockly dazu entwerfen. vll. kommt ja was brauchbares dabei raus.
Beiträge von Paradoxx87
-
-
aber dann ist der FAll ja klar, dass es an MQTT liegen muss. Vll. wäre das eine wichtige Info an Alterco, um das Problem zu beheben.
-
welche verbindung nutzt ihr den beim HA ist das kein MQTT ?
-
-
Also ich hab jetzt an allen Geräten ein Update gemacht.
Leider hatte ich heute morgen wieder einen, welcher ausgetiegen ist.
Natürlich mit dem standard Fehler.
Sehr deprimierend.
-
habe heute schon gesehen das es jetzt ofiziell eine 2.2.2 version gibt. wo finde ich denn da den changelog. ?
-
Naja kann ja dann nur im Zusammenhang mit Mqtt stehen, ich nutze Coiot und hatte noch nie Probleme mit den TRV in Homeassistant, außer mit 2.2.1 hier hat das Ventil teilweise nicht ordnungsgemäß geschlossen ist aber mit 2.2.2 behoben. Ein problem gibt es anscheinend noch ist aber aktuell in Prüfung es kann manchmal vorkommen das der TRV nicht schließt wenn der Boost abgebrochen wird. Aber wie gesagt ist ja noch eine Beta.
Wenn das ein MQTT Problem ist, weis jemand zufällig, ob ich dann beim Iobroker zwei instanzen vom Shelly adapter laufen lassen kann, eine mit COIOT und den TRV´s und eine MQTT mit allen anderen MQTT shellys ?
Das wäre ja dann eine super lösung
-
Gibts schon neuigkeiten von Dir Frank.
Bzw. Hat jemand mehr input zu dem Problem. grad nervt es wieder ziemlich bei mir.
-
Danke firebowl.
Besser hätte ichs ned beschreiben können.
-
-
ich z.B. habe kein Mesh, bei mir sind alle APs verkabelt
Bei einem "Ausfall" kann ich auch keinen Reboot-Befehl anstoßen, der TRV reagiert einfach nicht mehr... siehe WebUI
Ohne HA würde ich es wahrscheinlich nicht mal merken, wenn wieder mal einer nicht verbunden ist.
Und wie ich schon schrieb, rund 180 andere Shellys funktionieren und die TRVs nicht? Schon etwas komisch, ne?
was hat denn ein mesh mit ap verkabelung zu tun ? erleuchte mich kurz ?
-
Also nochmal für alle, ihr müsst leider euer mesh abschalten und ohne mesh ein repeater netzwerk aufbauen. das hab ich auch so gemacht. damit behebt ihr das problem das Siek einen empfang haben.
Wenn jemand genauere infos haben will wieso, dann googlet das einfach. habe ich hier im forum bereits einen thread offen.
Für das thema GUI abgestürrzt ist es so das ich über den iobroker lediglich einen reboot manuel antriggere. Dafür gibt es aber auch einen anderen thread hier , wie man das automatisch machen kann. Suchfunktion nutzen.
ansonsten, wer keinen iobroker oder etwas dergleichen hat kann auch mit folgendem befehl die TRvs rebooten, einfach im browser die ip des trvs eingeben mit also 192.168.xxx.xxx/reboot
-
Es liegt daran, dass sich das komplete GUI aufhängt und nur durch einen reset die dinger wieder Befehle annehmen.
Welche Version hast du drauf und wie ist dein WLan aufgebaut ?
-
Ich denke das liegt wie bei allen anderen auch, welche dieses Problem haben an deinem Wlan. Ich hatte dazu mal einen Thread aufgemacht. Jedoch hat sich bis heute nichts bei alterco zu diesem Problem getan.
Meine Trv´s hängen sich regelmäsig auf und müssen dann durch einen restart, welchen ich über den Iobroker Triggere neu gestartet werden, um wieder korrekt zu funktionieren. Selbst mit der neuen 2.2.1 version scheint das Problem weiterhin zu bestehen. Ich habe eine Fritzbox mit 3 repeatern ohne Mesh(Mesh können die geräte leider gar nicht, weil irgendein billiger wlan chip an den TRV´s verbaut wurde, welcher diese Technologie nicht unterstützt).
Es ist super ärgerlich, weil du ständig danach schauen musst, ob sich die TRV´s wieder aufgehangen haben. Sobald der Fehler wieder auftritt schicke ich ein bild der Meldung
-
würde mich auch interessieren.
Ich nutze den Iobroker und würde gern die Temperatur von einem Sensor an den Shelly weitergeben, welcher auf auf dem modbus adapter liegt.
Wie muss das blockly script aussehen ?
kann da mal einer ein BSP. machen
Grüße PD
-
Um ehrlich zu sein, habe ich nichts anderes erwartet. Das war bei mir genau das gleiche. ich habe denen sogar ein video und was weis ich alles geschickt und nix kam dabei rum.
Einfach ein Saftladen in bezug auf die trv´s
Alle die das lesen, kauf euch keinen shelly trv
-
Ist das Setup bei anderen hier mit dem selben Problem ähnlich? Oder passiert das auch in absolut "langweiligen" Installationen bei denen remote fast nichts aktualisiert wird? Vielleicht sind das wirklich die vielen Requests? Ich habe wie gesagt bisher nichts gefunden um den TRV in diesen Zustand zu zwingen. Das würde vermutlich auch für Shelly das debuggen vereinfachen, wenn die das mal bei sich gezielt auslösen können.
also ich nutze den iobroker und heatingcontrol zum regeln der Temperatur in 10 Räumen. der TRV bleibt absolut dumm und bekommt, falls eine andere Heizperiode anfällt lediglich den neuen Temperatur Wert zugesendet. das passiert jedoch nur alle 5 std. oder sogar noch länger. Ich habe aber bereits festegestellt - und das bestätigt vll. auch deine These, dass in den letzten Tagen (ich spiele gerade sehr viel mit den TRV und schicke, wenn ich zuhause bin alle 10 minuten eine neue temperatur oder einstellung) häufiger bzw. fast jeden tag ein shelly ausfällt. Witzigerweise tracke ich welcher ausfällt und es sind eig. bis auf ausnahmen immer die gleichen. Was mich wiederrum total irritiert. Leider fehlt es mir absolut an der zeit genau diesen fall nachzubilden.
Ich denke da an folgendes:
1. TRV mit Repeater verbinden. Verbindung sollte nicht optimal sein. Rssi sollte -60 oder weniger sein.
2. Der TRV sollte per mqtt mit iobroker oder HA verbunden sein. Wenn ich das richtig verstanden habe, gibt es keine Probleme bei cloud usern
3. Keine änderungen oder kein senden an den TRV in den nächsten zwei oder drei wochen. Einfach den TRV laufen lassen ohne befehle über mqtt
falls es keinen fehler gibt ist es eig. fast klar.
falls es doch einen fehler gibt, dann:
1. TRV mit Repeater verbinden. Verbindung sollte nicht optimal sein. Rssi sollte -60 oder weniger sein.
2. Der TRV sollte per mqtt mit iobroker oder HA verbunden sein. Wenn ich das richtig verstanden habe, gibt es keine Probleme bei cloud usern
3. zum Testen ob irgend ein speicher volläuft, sollte der TRV eine woche oder länger alle 10 minuten mit einem wechsel der Temperatur beaufschlagt werden.
Kurz noch zum thema rssi:
einer meiner TRV´s ist direkt gegenüber eines fritz repeaters am Heizkörper montiert, doch auch hier ist der rssi kleiner als -50
und der fehler tritt immer mal wieder an diesem Gerät auf.
@ alias was meinst du dazu ? macht das Sinn, so ein Test ?
-
Das Problem ist nur wie verklickern wir das dem Support, sodass das behoben wird ?
-
Ich werde jetzt versuchen, alle drei komplett zurückzugeben. Scheinbar sind die zu inkompetent das zu fixen.
Amen, ich bin auch total abgenervt von den dingern. Die frage ist nur warum der Json fehlerhaft ist und das nur sporadisch. Was erzeugt diesen ausfall ?
-
Muss aber dann nur das Fritz Mesh betreffen. Mein TP-Link sagt auch ich benötige 802.11k/v/r und das funktioniert bisher. (zum Glück)
Ja, kann gut sein. Obwohl manche ein Mesh haben, können Sie trotzdem keine Probleme mit den TRV´s bekommen.
Das liegt schlicht und ergreifend daran, das die Repeater egal welcher, noch eine gute Verbindung mit dem TRV haben ohne das diese zyklisch abbricht.
Denn nur das abbrechen der Verbindung in zusammenhang mit Mesh stellt ja das Problem dar. (Woher soll der TRV wissen mit wem er sich verbinden soll, wenn alle SSID gleich heißen.
Da nimmt er halt irgendeine und wenn das Signal wieder sehr schlecht ist, bricht es halt beim nächsten Windstoß wieder ab. So geht das Spiel immerwieder von vorne los und irgendwann macht der TRV dicht.
Ich vermute, dass Alterco das Softwaretechnisch beim TRV abdecken könnte. Dies ist aber offensichtlich bei der bisherigen version nicht der Fall.