Beiträge von Frank Berges

    Generell wäre es sehr Cool wenn man über ein Shelly Gerät das Hausnetzwerk in einen Schaltschrank bekommt ohne alle Wände für Kabel aufreissen zu müssen. Das ist glaube ich ein Anwendungsfall den viele Leute nutzen würden ...

    Hallo

    Das gibt es schon von vielen Herstellern.

    Da Schaltschänke zu Meist aus Stahl sind, hat man einen Faradayschen Käfig in den keine Funkwellen eindringen können.

    Ich vermute aber das du den Zählersachrank meinst.

    Auch bei mir ist das Teil in der Wand aus Kunststoff und die Türen aus Stahlblech.

    Da kommt Wlan rein aber nur sehr schlecht je nach Mauerwerk.

    Ich habe es so gelöst das im Selben Raum ein AVM 1200AX sich befindet und dann geht dass.

    Aber es gibt noch eine Lösung, ein Powerlan Modul einzubauen und am Router ein Gegenstück davon.

    Wenn die Ausdehnung des Stromnetzes nicht wie bei mir zu Groß ist funktioniert auch das Prima.

    Achte nur darauf das du möglichst bei einem Hersteller bleibst damit da keine Unstimmigkeiten bei der Übertragung passiert.

    Das Gegenstück im Zählerschrank kann dann so sein, das du ein LAN-Kabel einstecken kannst oder da ist ein Wlan-Modul integriert.

    Dabei wird das Lan über 230V übertragen vom Teil am Router über die Stromleitung zum Teil in dem Zählerschrank.

    Powerline-Module, Router, Wlan-Verstärker (Repeater), Acess-Point usw. gibt es in verschiedenen Ausführungen und für Alles gibt es eine Lösung, wenn auch ab und an nur befriedigend und nicht Super.

    Da muss meines Erachtens nichts mehr neu erfunden werden.

    Grundlegend ist zu sagen, das nichts über eine Kabellösung geht, das ist immer die aller Beste Lösung.

    Grüße aus dem Sauerland


    Hallo

    Nac dem ich nun einige Probleme mit meinen TRV habe, wollte ich auf COIOT mal einen Versuch starten ob die Teile besser laufen.

    Probleme habe ich mit dem MQTT vom ioBroker wie auch mit dem von der Shelly-Instanz.

    Mein TRV (Grade frisch ausgetütet und Neue Firmwahre aufgespielt) hat jetzt die 20231122-131839/v2.2.2@a458c94d installiert.

    Den habe ich auf eine Feste IP eingestellt und RESTRICT LOGIN

    Username 1234

    Passwort ABCD

    Enable CoIoT

    192.168.2.50:5683 (192.168.2.50 IP vom ioBroker)

    Auf dem ioBroker läuft eine 2 Instanz Version v6.6.1

    Die habe ich auf CoAP eingestellt.

    HTTP-Benutzername auf 1234

    HTTP-Passwort ABCD

    TRV Neu gebootet und Instanz neu gestartet, Ergebnis TRV meldet sich nicht.

    Dann einen Dimmer2 genommen und das auch so eingestellt.

    Der meldet sich sofort bei der 2 Instanz an.

    Wo sitze ich da wieder auf dem Schlauch ?

    Irgend wo ein Denkfehler ?

    Funktioniert der TRV nicht mit dem COIOT im Zusammenhang mit dem ioBroker?


    Das sieht man im Protoikoll


    Es handelt sich tatsächlich um den Laderegler.

    Das habe ich mir auch so gedacht, anhand der Lage und der zugehörigen Bauteile lag das nahe, nur konnte ich nichts mehr drauf erkennen.

    Was mir noch eingefallen ist, ich habe zur gleichen Zeit beim Laden auch kalibriert, ob der Oberhalb der Leistungsdaten war, je nach dem wie der aufgebaut ist, könnte das sein.

    Die Vorgeschlagene Schaltung spricht gegen eine Überlast.

    Seih es drum, ohne Schaltplan ist das fischen im Trüben.

    Das Packet ist gepackt und geht Morgen auf die Reise.

    Das muss nicht so schnell fertig sein, mache es wenn du Zeit hast.

    Grüße vom Sauerland nach Rheinland-Pfalz

    thgoebel

    Hallo

    Ich habe hier einen TRV der von Jetzt auf gleich beim Laden den Geist aufgegeben hat.

    Nach dem Ich Ihn Dank deiner Doku offen bekommen habe, sah ich auch den Grund.

    Der U2 ist hoch gegangen.

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

    Da ich aber keinen Schaltplan habe, kann ich nicht sagen wofür der ist und warum der hochgegangen sein könnte.

    Vermutung von mir ist, das er für die Akkuladung zuständig ist.

    Da ich das Ladegerät (USB Netzteil) auch für Andere benutze, macht mich das etwas raschelig.

    Weist du wofür der U2 ist ?

    Weiterhin, hast du eine Vermutung warum der hochgegangen sein könnte?

    Eure Gemeinsamkeit ist wohl der ioBroker 🧐

    Ich habe meine Shellys im ioBroker mal über den MQTT vom ioBroker und mal über den vom Shelly-Adapter MQTT angebunden und bei beiden gab es das Problem.

    Ich tippe auf die MQTT-Anbindung mit der Der TRV Probleme hat.

    Das ist aber eine Vermutung und ich kann das nicht beweisen.

    nur durch reboot zu beheben.

    irgendwas mit Json

    Das Problem kenne ich, habe ich hier auch so bei meinen 8 TRV.

    Ich bekomme das meist mit http://P-Nummer des-Shelly/reboot wieder hin.

    Das könnte man im ioBroker automatisieren wenn ich nur wüste wie ich den Fehler selektieren kann.

    Eine Automatiklösung per Shelly-Programm hat hier schon mal einer gepostet.

    Grüße aus dem verschneiten Sauerland

    Gibts schon neuigkeiten von Dir Frank.

    Bzw. Hat jemand mehr input zu dem Problem. grad nervt es wieder ziemlich bei mir.

    Hallo

    Tja ich habe das umgestellt, und es hat zwar eine "Bessere" Übersichtlichkeit gegeben aber das Problem mit dem ab und an nicht zu erreichen und das nicht reagieren auf Temperaturanforderung ist gleich geblieben.

    Ab und an hängen sich die TRV auf dann muss ein ip/reboot her oder einmal kurz der Reset gedrückt werden.

    Das nicht reagieren betrifft natürlich die Temeraturvorgabe wie auch die Istwert (Externer Fühler) vorgabe.

    Ich könnte wieder zurück zu meinen Eurothronic Spirit Plus z-wave aber da weis ich nicht wie das mit einem Externen Fühler geht.

    Uns bleibt nur das Warten auf eine funktionierende Firmware oder ein Wechsel.

    Ich benutze von allen Funktionen des TRV eigentlich nur die Temperaturvorgabe und die Funktion Externer Fühler-

    Alles Andere (offenes Fenster, Zeitpläne, Boost usw.) mache ich mit ioBroker.

    Ich habe schon über den Wechsel zu Fritz 302 nachgedacht, aber ob das besser ist ?

    Der Verlust ist schon beträchtlich und kann einen schon echt Nerven Geld ausgegeben für ein vermutlich Tolles Produkt und so ein Dessaster.

    Die sollten besser erst mal die Probleme lösen anstelle von Neueren Produkten raus zu bringen.

    Das ist wie bei allen Software-Sachen, der Apfel reift beim Kunden.

    Also mein Fazit: Das Problem muss mit MQTT zusammen hängen ... weil ohne laufen die ja ... nur ob die Firmware oder der Broker schuld sind kann ich nicht sagen :/
    Jetzt bleibt MQTT auf jeden Fall aus bis es neue Firmware oder neuen Adapter gibt und dann teste ich wieder ....

    Dann werde ich mal den Shellyadapter auf MQTT umstellen und die TRV auf den Shelly/MQTT Port umstellen.

    Den ioBroker MQTT brauche ich eh also nur umstellen, der Shelly/MQTT hat auch mehr Objeke als der normale MQTT auch die ext_1 und target_1 brauche ich nicht anzulegen die sind da schon vorhanden.

    Batterie muss nicht geparst werden usw. das Ding ist bequemer.

    Wenn das nicht geht, setze ich mal einen Mosquito auf bei meinem NAS auch kein Problem.

    Das muss doch funktionieren, ich kann nicht einfach 7 TRV in die Tonne hauen !

    Da bin ich mal gespannt ob das besser wird.

    Deshalb hab ich ostfriese sein Script am laufen, was die TRVs überwacht und dann wenn sie anfangen nur noch Schrott in den JSONs zu produzieren nen reboot triggern.

    Diesen Müll sieht man auch per MQTT im ioBroker.

    Bei mir haben sich von meinen 9 TRV Heute 2 aufgehängt (Softwareversion V2.2.1).

    Per IP kam man nicht mehr auf die WebUi.

    Auch ein reboot oder reset war über HTTP nicht möglich.

    Erst ein Reset mit dem Resettaster weckte den TRV wieder auf.

    Die Batterien waren bei 85 und 93% der RSSI bei -63 und -60.

    Nach dem Reset waren alle Funktionen wieder da.

    So weit wie gehabt.

    Du hast geschrieben das im MQTT die Daten Defekt sind, das war bei mir nicht der Fall, somit ist es auch nicht per Blockly der Java feststellbar das er sich aufgehängt hat.

    Alle JSON waren OK und deren Integrität war OK.

    Ob nun der ioBroker MQTT Fehler abgefangen hat kann ich nicht sagen, zumindest gab es keinen Protokolleintrag der mir aufgefallen währe.

    Der Adapter Ping wahre eine Möglichkeit aber der kostet Batterie im TRV.


    Das ist schon sehr Ärgerlich.

    was hat denn ein mesh mit ap verkabelung zu tun ? erleuchte mich kurz ?

    Alle meine AP´s (Access Point´s) sind per Kabel mit dem Router verbunden.

    Das hat nur indirekt etwas mit mash zu tun.

    Mash ist eine Softwaregeschichte und der Router kommuniziert mit den AP (Access Point´s) und handelt Kanäle, Zugriff usw. aus.

    Ob das nun bei einigen mit der Ankopplung der AP an den Router mittels Wlan Probleme gibt, ist auch möglich (aber komisch, könnte mir das nur mit Latenz erklären).

    Ich stehe da eher bei der Kabelkfraktion nur Kupfer oder Glasfaser ist Senkrecht (Geht aber nicht immer).

    mesh abschalten und ohne mesh ein repeater netzwerk aufbauen

    TRvs rebooten, einfach im browser die ip des trvs eingeben mit also 192.168.xxx.xxx/reboot

    Bei mir laufen die Dinger einwandfrei im mash und mit MQTT zu mindestens mit der V2.1.8.

    Jetzt ist bei allen die V2.2.1 drauf und da habe ich noch keine Ergebnisse (noch laufen die ca. 1 Tag).

    Ich hatte nur gefragt wie du merkst, das er nicht mehr unter den Seinen ist.

    Wen der GUI abstürzt erkenne ich das schon nur ein /reboot geht dann auch nicht mehr da er jegliche Befehle missachtet hat.

    Nach dem Anschluss eines Ladegerätes und einem Taster-Reset sah ich auch warum das so war (im GUI), die Batterie war auf <10% und da macht der nichts mehr.

    Die Batterieanzeige war dabei im MQTT bei 99 und auch der Status war auf online.

    Ich vermute das wir hier mehrere Fehler haben, MQTT Batterie und Statusfehler, GUT Abstürze und Netzzwerkprobleme.

    Darum stelle ich noch mal die Frage, wie merke ich das Das Teil sich verabschiedet hat im MQTT?

    Wie ich darauf reagiere muss ich mir dann noch ausdenken /rebott noch mal versuchen oder zu mindestens eine Meldung auf dem Handy.

    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, die geräte leider gar nicht, weil irgendein billiger wlan chip an den TRV´s verbaut wurde, welcher diese Technologie nicht unterstützt).

    Mein Netz besteht aus 1x7590AX und 6x1200AX verteilt über 3 Etagten und insgesamt 270m², aufgebaut als Mash.

    Alle TRV haben feste IP und werden nur über MQTT angesprochen.

    Bis Dato hatte ich noch keine Probleme oder habe es nicht gemerkt.

    Wie machst du das mit der Kontrolle der Funktion über den ioBroker und wie gibst du einen Neustart (wenn die sich aufgehängt haben)?

    Grüße aus dem Sauerland

    Frank

    Hallo

    Ich betreibe 7 TRV an einem ioBroker teilweise mit Externen Thermostat, alles über MQTT und hatte bis Dato noch keine Probleme (V2.1.8).

    Da der TRV nur als "einfacher" Heizungsthermostat läuft (ohne Heizplan usw.) dachte ich alles OK.

    Gestern kam meine Frau an und beschwerte sich über ein zu kaltes Badezimmer und ich habe da mal nachgesehen was da los ist.

    Alle Batterieanzeigen standen im ioBroker auf > 80% also eigentlich alles OK.

    Dann wollte ich über die IP auf die TRV Weboberfläche und siehe da keiner der TRV war zu erreichen.

    Dann an den ersten ein Netzteil angeschlossen, etwas gewartet und noch mal versucht, aber auch das hat nach ca. 10min nicht funktioniert.

    Danach einmal den Reset betätigt und dann wurde der TRV wach.

    In der Weboberfläche zeigte sich eine Batteriekapazität von < 10%.

    Das ist jetzt sehr ÄRGERLICH, da ich im ioBroker eine Batterieüberprüfung integriert habe die genau so etwas verhindern soll.

    Auch sind einige so verbaut das man schwierig an den Reset kommt.

    Ist ja auch bauseits etwas ungünstig, Anzeige oben und Lade sowie Reset unten.

    So wird das aber nichts mit der Automatischen Überwachung wenn die Geräte nicht sauber funktionieren.

    Jetzt habe ich die Version 2.2.1 auf die TRV aufgespielt und hoffe auf Besserung dieses Problemes.

    Grüße aus dem Sauerland

    Hallo miteinander

    So nach fast 1 Monat störungsfreien Betrieb wollte ich meine Aussage das war der Fehler bekräftigen.

    Damit ist es erledigt und hat mir einiges an Nerven gekostet.

    @De kat Danke noch mal für die Hilfe.

    Schönen Tag gewünscht.

    Die ganzen Allterco Skripts kannst du in die Tonne kloppen, das hat garantiert ein Praktikant von denen erstellt.

    So ich wollte mich noch bedanken, das Problem scheint erledigt zu sein.

    Die Lösung wahr scheinbar "Clear Timer" und "unsubscribe() topics".

    Da hat zu mehreren antizyklischen Abstürzen geführt die man scheinbar nirgendwo dran festmachen konnte.

    Wenn ich mir Hier einige scripte so ansehe so könnten die auf vergleichbare Probleme stoßen den auch da ist das nicht berücksichtigt.

    Darauf muss man aber auch erst mal kommen, ist zwar logisch aber mir bis Data noch nicht bekannt gewesen.

    Sch.. Falle !

    Danke nochmal und einen Schönnen Sonnigen Tag gewünscht !

    PS Wo kann man das eigentlich nachlesen ?

    Ok, ja du hast recht, aber du prüfst nicht direkt auf Nullwerte, sondern nur auf leere Strings, deswegen solltest du auch zusätzlich auf Nullwerte prüfen und solange deine Timer Schleifen wiederholen bis es funktioniert, deine Timer Schleife solltest du übrigens auch anpassen, da man deinen Timer gerade über 5 mal gleichzeigt aufrufen kann.

    Das mit dem Timer ist nicht auf meinem Mist gewachsen, das ist eine Vorlage schau hier :

    shelly-script-examples/mqtt-announce-control.js at main · ALLTERCO/shelly-script-examples · GitHub

    Da ich Probleme mit dem Script abbruch beim Starten hatte, habe ich nach Lösungen gesucht und nachgesehen was ALLTERCO da so bastelt und bin genau darauf gestoßen.

    Ich habe es mal eingebaut wie du geschrieben hast.

    Das klingt logisch, wenn das mehrfach hintereinander aufgerufen wird läuft irgendwann der Stack voll.

    Nur sollte ALLTERCO das in seinen Beispielen dann auch so machen damit nicht Andere das genau so falsch machen.