es sind ja 2 DTU´s eine hat ja solar und die andere solar2.
dann müsste ich auf zb. Topic balkon ändern oder?
danke Alex
Oder 1 und 2 
Balkon geht auch, wenn dann aber noch irgendwas anderes über MQTT läuft wo irgendwo balkon vorkommt, dann wird das auch wieder an diese Instanzen gesendet.
Dann sollte zumindest die Instanz 49404 weniger oft auftauchen.
Warum aber 42122 auch so oft in den Threads auftaucht, erschließt sich mir noch nicht.
Das ändert aber alles nichts daran, dass du viele WR da drin hast, die jeweils alle ihre einzelnen Datenpunkte per mqtt senden. Die PHP Module haben es nunmal so ansich, dass dann immer ein Thread (hier bei jedem Datenpunkt) gestartet wird.
Das „Problem“ das Nall-chan beschreibt würde die Anzahl der Threads in deinem Fall nur halbieren.
Ich sehe aber auch nicht das Problem, die threads werden ja schnell und ggf. nacheinander abgearbeitet - da bleibt nichts hängen.
Nur wenn es nicht noch andere MQTT Pakete gibt wo irgendwo die Strings auftauchen. Der Filter ohne Zuordnung zum Index im Datenfluss ist sehr unvorteilhaft. Es können also auch locker mehr als die Hälfte sein.
Da so etwas wie /irgendwas/solartechnik auch durch den Filter kommt, egal ob nun im Payload oder im topic.
ja wenn er alle abarbeitet ist es ja für mich mal OK,
hab heute nochmal kontrolliert und gesehen das jedoch einige rot sind und hängen, ob dies zusammenhängt kann ich nicht sagen.
Wie kann man rausfinden was das ForwardData bedeutet? hab es 20x bei 200 Kanäle.
Doppelklick bringt nichts.
Danke
Alex
Tach zusammen,
hab mal versucht, den Thread querzulesen, aber zu meinem Problem nichts gefunden.
Kurz: die Daten der einzelnen Wechselrichter werden nicht aktualisiert.
Lang:
Meine Konfiguration:
Beim Klicken von alle erstellen gab es diese Fehlermeldung:
Nun habe ich in den Splitter-Instanzen 2 OpenDTU-Einträge, von denen eine Updates erhält, eine nicht.
Die einzelnen Instanzen der Wechselrichter scheinen an der ersten Splitterinstanz zu hänger, bekommen nämlich auch keine Updates.
Dazu der Dump:
dumpDTU.txt (233,4 KB)
Hat jemand eine Idee, was da falsch laufen könnte?
Schönen Gruß
Robinson
PS: Unknown bedeutet in meinem Fall 7x HMT2000-4T und 3x HMT1600-4T
Hast du mal die Hoymiles Instanzen versucht? Bei mir sieht das nämlich anders aus.
Und haben die Server Sockets vielleicht den gleichen Port verwendet?
Ok, ich hab nochmal in die nicht aktualisierte Splitter-Instanz geschaut - keine Fehlermeldung. Dann die Schnittstelle (Server) explizit nochmal neu ausgewählt und siehe da, jetzt funktioniert alles.
Wenn du sagst, bei dir sieht es anders aus, d.h. du hast nur eine Splitter-Instanz?
Schönen Gruß
Robinson
Ich habe nur eine OpenDTU und entsprechend auch nur jeweils eine Splitter- und eine Konfiguratorinstanz. In der Konfiguratorinstanz erscheinen dann die einzelnen Wechselrichter und aus der Konfiguratorinstanz habe ich die Geräteinstanzen erstellt. Letztere sehen bei mir aber in der Variablendarstellung anders aus.
Gruß
Marc
Genauso ist es bei mir, nur eine DTU und gleiches Vorgehen. Daher wundere ich mich ja über die zwei Splitter-Instanzen.
Die Variablen könnten von unterschiedlichen Wechselrichtern kommen.
Schönen Gruß
Robinson
Bei einer DTU müsstest du auch nur eine Splitter-Instanz haben. Schau doch mal, auf welche Schnittstelle die jeweils verweisen.
Den exakt gleichen Fehler bekomme ich auch jedesmal wenn ich den gefundenen WR anlegen möchte. Er legt den auch an, wie bei Dir, aber erstellt auch einen neuen DTU Splitter (dem fehlt dann die Nummer die der erste dran hat).
Das hab ich aber gar nicht bemerkt, hatte aber auch den Effekt dass beim WR keine Daten kamen.
Danke, genau das hat mich dann weiter gebracht. Hab die zuviel erzeugte OpenDTU im Splitter gelöscht und den WR an die bestehende OpenDTU Splitter gehangen. Nun kommen die Daten auch.
Das geniale Modul scheint aber eben trotzdem einen Fehler zu haben, auch wenn man sich helfen kann.
Kann man da noch was liefern um das zu finden @hirschbrat ?
Cheers Seppm
ICh nehme an, dass das durch die neue Art von Symcon, wie IO/Splitter angelegt werden, entsteht. Das wurde wohl von Symcon nicht richtig abwärtskompatibel implementiert - ich weiß da auch nicht, wie man das umgehen soll ohne das Modul für ältere Symcon versionen inkompatibel zu machen
Wenn du die ganze Kette angibst, ist der Fehler weg und es ist weiterhin kompatibel.