Tweet
Hallo Gagi, ich nutze aktuell die V2.3 und nach dem Loxberry Neustart, bekomme ich eine Exception, magst du mal ein Blick auf das Logfile werfen?
-
-
Das sieht komisch aus. Irgendwie passt bei dir die multicast_ip nicht mehr, das sollte die IP Adresse des Miniservers sein. Kannst du mal einfach nochmal speichern und schauen ob es dann weg ist ?Kommentar
-
Hi Gagi,
wie abgesprochen: Gestern war es wieder soweit, das Plugin hat um 10:43 Uhr (16.09.) den letzten Datensatz geschickt, danach keine Updates mehr gesendet (die kommen sonst so um halbstündlichen Takt circa). Ab 10:57 gab es dann im Plugin Log den letzten Pull Request ohne Antwort. Kann sein, dass dies nach einem Reset des Miniservers passiert ist, da ich wieder ein wenig rumprogrammiere und Sachen verändere (allerdings nicht an der Wärmepumpe bzw. in der Umgebung des Wolf ISM8 Plugins). Logfile findest Du anbei:
wolf_ism8i (3).log
Auffällig finde ich, dass es aufgrund von mehreren Kommandos, die ich schicke, auch immer zu mehreren Verbindungen eines Clients kommt (klar) mit unterschiedlichen Portnummern, weil Loxone die Verbindung immer schließen möchte (Haken bei "Verbindung nach Senden schließen" ist gesetzt). Weiß nicht, ob die unterschiedlichen Portnummern hier etwas durcheinander schmeißen? Bspw. 10:57:24 erst 192.168.1.90:42400, dann 192.168.1.90:42402. Soll ich die Verbindung seitens Loxone mal offen lassen?
Grüße!Kommentar
-
Hi,
also was offensichtliches kann ich nicht erkennen. Kannst du noch ein log aber mit VERBOSE log level erstellen ?
Die Port-Nummern für die Client-Verbindung haben nichts zu sagen. Ich schliese die Verbindung zu Loxone unahängig auch nach jedem Kommando. Das kann man denke ich schon optimieren, aber ich glaube nicht das es daran liegt.
Mit dem VERBOSE log Level sollte man auch die normale Kommmunikation vom ISM8 zum Plugin sehen. Aus der log ist mir nicht ganz klar, von wo keine Daten mehr kommen. Ist die Verbindung zum ISM8 tot, oder kommen einfach keine Kommandos mehr von Loxone zum Plugin ?
Das letzte Kommando kam um: 2021.09.16 10:57:24. Gab es danach keine Anfragen von Loxone mehr (sprich, über welche Logik schickst du die Kommandos ? Periodisch ?). Wenn danach trotzdem noch Daten deiner Geräte an Loxone ankommen, also zB Temp-Änderungen, kann man das ganze ja schonmal eingrenzen. -
Klar, mache ich mal. Das ist Log-Level "Debug", richtig?
Von Loxone kommen weiterhin Kommandos, die sehe ich Loxone im UDP Monitor auch erfolgreich verlassen. Ich schicke Kommandos teilweise manuell (bspw. Änderungen der Temperaturanpassung). Die kommen dann nicht mehr im Plugin an, das Log hängt und es findet keine Kommunikation mehr statt. Nach einem Neustart des Plugins läuft alles wieder normal.
Ich starte das Plugin jetzt direkt mal neu und versuche, einen Hänger zu provozieren. Grüße!
-
-
Ok, das ging schnell, ich kann den Fehler jetzt wohl provozieren:
Direkt nach einem Neustart von Loxone schickt Loxone ziemlich zeitgleich zwei UDP-Befehle mit unterschiedlichen Ports raus (Protokoll anbei, Zeitpunkt des Neustarts lag bei 13:53:47, also deutlich *nach* dem letzten Zeitstempel im Log). Diese Befehle (65 und 66) werden nur gesendet, wenn die zu sendenden Werte sich jeweils von 0 unterscheiden. Das war auch der Grund, warum ich das in der Vergangenheit nicht sauber reproduzieren konnte - die Temperaturanpassung (65) ist öfters mal auf 0 gestellt.
Log anbei, das sollte jetzt helfen, hoffe ich. Workaround in Loxone könnte sein: Alle Werte auf 0 initialisieren und zeitlich gestaffelt auf die tatsächlichen Werte setzen. Zusätzlich müssen auch während der Laufzeit Änderungen aller Befehle zeitlich gestaffelt abgefeuert werden. Kann mit Analogspeichern und zeitichen Triggern sicher realisiert werden.
Grüße!
wolf_ism8i (4).log
PS: Du könntest versuchen, den Fehler selbst zu provozieren, indem Du bspw. Befehle 149 (Programm) und 158 (zeitweiser Feuchteschutz) zeitgleich absetzt für den CWL. Könnte funktionieren. Aber die CWL hat halt nicht viele Befehle, die sinnvoll verwendet werden können.Zuletzt geändert von docpayce; 27.09.2021, 13:09.Kommentar
-
Ok, das ist jetzt definitiv hilfreich, allerdings versteh ich nicht so ganz warum das passiert.
Aus irgend einem Grund kann er keinen UDP-Daten an Loxone schicken und durch den Fehler stürzt das script ab. Das lässt sich durchaus beheben, dauert aber ein bisschen. Das ist denke ich auch nur eins der Probleme, da bei dem log davor kein Fehler zu sehen war.
Das mit der debug log hat leider nicht geklappt, ist allerdings mein Fehler. Könntest du die Datei /opt/loxberry/bin/plugins/wolfism8/wolf_ism8i.pl bei dir anpassen. In Zeile 77 auf folgendes ändern:
my $verbose = 3;
Dann sollte man deutlich mehr sehen. Also für jede Nachricht die vom ISM8 kommt und auch die Antwort die ich zurückschicke.
Interessant ist, ob die Nachrichten ausbleiben (Verbindung zum ISM8 abgebrochen).
Bzw. wenn kein "Verbindung eines Clients von" mehr zu sehen ist, kommen keine Verbindung mehr von Loxone zu stande.
Es kann auch beides gleichzeitig passieren, das wäre auch interessant.
Gruss
-
-
Jo, habs hinbekommen. Kleine Korrektur noch: Der Fehler kann nur provoziert werden, wenn gerade eine Menge UDP Daten vom Plugin an Loxone weitergeleitet werden (nach einem pull request) und dann Loxone versucht, einen Batzen Daten zusätzlich zurück zu schicken. Ich denke mal, das erklärt auch die sporadischen Abstürze mitten drin. Es kann immer mal vorkommen, das Weiterleitung vom Plugin in Richtung Loxone und zurückschreiben von Loxone zum Plugin kollidieren.
Auffällig: Die beiden Befehle nach einem Neustart von Loxone (65 und 66), die den Absturz provozieren, kommen gar nicht mehr an im Plugin.
wolf_ism8i (5).logKommentar
-
Puhh, es wäre echt praktisch wenn ich das hier auch irgendwie reproduzieren könnte...
Probieren wir mal die Holzhammer-Methode. Ersetz mal die Zeile 151 mit folgendem:
my $ok = $igmp_sock->send($message)
Also ohne dem "or die..." Teil.
Damit sollte er einen Fehler einfach ignorieren und weiter machen.
-
-
Moin moin,
also wirklich etwas verbessert hat sich dadurch nicht. Man merkt jetzt nur nicht mehr, an welcher Stelle das ganze gestoppt hat.
Log anbei.
- Ab 09:34:28 wurde mit der o.g. Änderung neu gestartet (ich war mal so frei und habe alles von davor aus dem Log gelöscht, damit das Log 200 kB und nicht 2 MB groß ist). Dann erstmal lange nix auffällig.
- Um 09:35:59 Loxone neu gestartet, Werte für 65 & 66 kommen um 09:36:03 an.
- Bei 09:36:29 gibt es zwei Leerzeilen, das habe ich so bisher noch nie im Log gesehen...
- Danach noch zwei weitere Mal Loxone Neustart, um den Fehler zu provozieren
- Ab circa 09:37:14 Abbruch der Verbindung. Loxone empfängt auch keine UDP Daten mehr.
- Ab 09:37:55 kommen auch von Loxone gesendete Werte nicht mehr im Plugin an, das Log bleibt hängen
- Danach nochmal Neustart des Plugins, danach aber nichts interessantes mehr.
Grüße!
wolf_ism8i (6).log
Kommentar
-
Ich hab das jetzt mal auf meinem Test Rpi laufen und bin mal hergegangen und schicke wild Änderungen über ein shell script. Bisher kann ich weiterhin keinen Absturz reproduzieren. Auch wenn ich zum Beispiel 100 Änderung Kommandos in kurzer Zeit verschicke. Was hast du denn sonst noch alles auf dem Loxberry am laufen ? Könntest du evtl. auch mit nem 2ten Rpi testen (falls vorhanden) auf dem nur Loxberry + Plugin läuft ?
Irgendwie hab ich die Vermutung dass das Plugin eigentlich alles richtig läuft aber irgendwas am System amok läuft, deswegen der Test auf nem frischen Loxberry ohne andere Plugins.
Was wir auch noch testen könnten ist ob evtl. der automatische Pull-Request bei dir die Probleme verursacht. Im Prinzip braucht man den nicht wirklich, da das ISM8 neue Werte automatisch schickt, auch ohne Pull-Request. Allerdings muss man dann darauf Warten bis das ISM diese Daten schickt, was mir zu langsam war, weshalb der Pull-Request die neuen Daten beschleunigen kann.
Du könntest also Zeile 317 bis 323 und Zeile 325 und 326 entfernen und schauen ob es stabiler ist.
Lass mich auch wissen ob es mit iobroker besser läuft, lässt du dass dann direkt auf dem Loxberry laufen ?Zuletzt geändert von Gagi; 29.09.2021, 16:05. -
Hey!
Sorry für die späte AW, da waren wieder 15 andere Sachen wichtiger (immer noch Baustelle, PV Anlage installiert, zwei Kinder...).
Den Umstieg auf iobroker bin ich auch noch nicht angegangen, außerdem ist mir jetzt iobroker auch noch abgeschmiert... manmanman...
- Ich weiß nicht, ob ich zeitlich dazu komme einen 2ten RPi aufzusetzen, muss ich mal schauen. Ich kann höchstens mal eine Handvoll Plugins rausschmeißen, die ich nicht mehr brauche.
- Pull-Request rausschmeißen probiere ich mal.
- iobroker läuft bei mir auf einem eigenen Rpi4
Auffällig ist inzwischen, dass die Plugin-Abstürze häufig passieren, wenn ich Loxone neu starte. Dort werden dann zwei Parameter fast zeitgleich abgesetzt.
Noch zwei Ideen, wie das zu umgehen wäre:
- Wenn ein Absturz festgestellt wird, warum nicht einfach das Plugin neu starten? So wird es beim KLF200 Plugin in iobroker gemacht (die Velux API ist notorisch instabil). Statt einem "or die"?
- Beim iobroker Plugin wird die Kommunikation zwischen ISM8i und Rest entkoppelt, will heißen, alle Parameter landen erst einmal in einem Pufferspeicher auf dem iobokrer, aus dem kontrolliert Werte abgeholt und abgesetzt werden (mit entsprechend langen Pausen).
Ich kann nicht versprechen, dass ich zeitnah weitermachen kann. Zuviel um die Ohren, sorry.
Grüße! -
Kein Problem, kann ich voll nachvollziehen und geht mir teilweise nicht anders.
Das mit dem neustarten, hab ich mir auch schon gedacht und werde ich mal versuch einzubauen. Allerdings muss ich das ausserhalb des perl-scripts machen, ich bin mir da einfach nicht sicher ob nicht in perl selbst da was kaputt geht und deswegen gar nichts mehr geht.
Damit der Zwischen-Speicher das Problem loest, muesste man wirklich auf 2 Prozesse umstellen, ich denke das ist mir zu viel Aufwand. Aber evtl. ist es besser gleich den MQTT support einzubauen, dann ist quasi der MQTT-Gateway der Zwischen-Speicher und die Werte sind auch noch Verfuegbar wenn das Plugin abgeschmiert ist.
Ich geb nochmal Bescheid wenn ich was neues zum Probieren habe.
Gruss
-
-
Gagi
Mit Deinem Plugin hab ich erfolgreich die Kommunikation mit der CHA herstellen können. Bis jetzt sieht das sehr gut aus!
Die Firmwareversion von dem ISM8i entspricht der Version 1.70
Die WP selbst betreibe ich ohne Kaskadenmodule, sprich Loxone übernimmt ab dem Speicher und regelt die Mischerkreise.
Die Sammlertemperatur ist mit 45 angegeben und wird auch dementsprechend von der WP bis zu dem Wert geladen.
Das Auslesen klappt:
Weißt Du wie, ich diesen Wert über die Schnittstelle anpassen kann?
Gruß
Zuletzt geändert von Rik; 20.12.2021, 11:18.Kommentar
-
Hallo,
die Sammlertemperatur kannst Du im Gegensatz zur Warmwassetemperatur leider nicht direkt einstellen - aber über die Sollwertkorrektur (+/- 4) #65 und den Sparfaktor (0-10) #66 zumindest rauf- und runterschieben. Berechnungsmethode, wie die Sollwertkorrektur / der Sparfaktor auf die Sammlertemperatur zurückschlagen siehe Fachmann-Anleitung vom BM-2 (Kap. 31).
Achtung: Bei mir kommt es regelmäßig zu Plugin-Abstürzen, wenn mehr als ein Parameter parallel verändert wird (Sammlertemp. / Warmwasser / Sparfaktor). Muss man ggf. zeitlich auseinander ziehen, bspw. über eine Ablaufsteuerung o.ä. - kann bei Dir auch passieren, muss aber nicht. Gagi hätte auf jeden Fall Interesse, wie es läuft. Ich auch.
Grüße! -
Vielen Dank für die schnelle Antwort! Das teste ich heute Abend gleich mal.
Ich hatte gestern versucht einen Wert Richtung WP zu senden und seitdem liefert sie keine Werte mehr, was dem entspricht was Ihr schon beobachtet habt.
Für den Reset, muss ich hierzu die ganze IDU ausschalten oder reicht es den kleinen Taster auf der ISM8i Platine zu drücken?
Nachtrag: Hab gerade den ISM8 Server AUS und wieder EIN geschalte, die Werte kommen nun wieder....Zuletzt geändert von Rik; 21.12.2021, 07:17.
-
-
Guten Morgen,
erstmal vielen Dank für das tolle Plugin. Leider bekomme ich es nicht installiert. Es kommt immer folgende Fehlermeldung:
07.01.2022 09:59: : Error while extracting from plugin archive.
Mach ich irgendetwas falsch? Bisher konnte ich Plugins immer installieren.
Viele Grüße
FreddiKommentar
-
docpayce und @Rik
Ich hab im Github mal ne neue Version angefangen und einen Watchdog implementiert. Mit der neuen Version sollte der Server sich bei Fehlern automatisch neustarten. Ich würde mich um Feedback dazu freuen.
Gruss
Gagi
Kommentar
-
Ich kann das Problem jetzt bei mir auch sehen. Das neustarten an sich, funktioniert schon mal, allerdings ist es wohl zu kurz hintereinander und er läuft deshalb immer in den gleichen Fehler. Ich versuch da mal noch was zu optimieren... Aber am liebsten wäre mir immer noch den Hauptgrund des Fehlers zu finden... -
Ich hab nochmal ne Version hochgeschoben und ich glaube ich habe auch verstanden was das Problem ist.
In der neuen Version versucht der watchdog es öfter, wartet aber bei jedem neustart etwas länger, bis zu 30min bei der letzten Stufe. Sollte es dann auch nicht gehen, besteht wohl ein grösseres Problem.
Ich denke das Problem an sich, sind evtl. Neustarts des Miniservers entweder wegen einer Config Änderung, oder wegen der Installation eines Updates. Es werden zwar UDP Pakete geschickt das eigentlich Fire&Forget sein sollte, allerdings gibt der Kernel Fehler weiterhin zum Programm durch. Wenn der Miniserver also beim Booten keine UDP Pakete akzeptiert(Port nicht offen, oder Firewall Rule), könnte so ein Fehler auftreten. Zumindest ist es hier recht ähnlich beschrieben (http://www.linuxmisc.com/16-linux-de...b9eac27f86.htm).
Die Fehlerbehandlung will ich eigentlich nicht abschalten und nachdem der Boot beim Miniserver immer etwas dauern kann, denke ich ist es wohl besser einfach abzustürzen, nochmal zu probieren und einfach etwas länger zu warten. Nach 20 Versuchen sollte es jeder Miniserver hinbekommen wieder zu starten...
Ist nur ne Theorie, aber im Moment das beste das ich anbieten kann. Ich hoffe das es damit besser ist...
Mit der Umstellung auf MQTT sollte das Problem so auch hoffentlich nicht mehr bestehen, aber das dauert noch etwas...
-
Wo finde ich die angepasste Version? Habe seit einigen Tagen das gleiche Problem.Kommentar
-
Die aktuelle version ist noch im Entwicklungszustand, aber du kannst sie von hier installieren: https://github.com/Gagi2k/LoxBerry-P...ads/master.zip
Rik wie laeuft der aktuelle Stand bei dir ?Kommentar
-
Gagi Bin jetzt auch endlich mal dazu gekommen, mir die neue Version zu ziehen und teste das jetzt intensiv. DANKE!!!!!!! Und sorry fürs späte melden, bei mir gehts drunter und drüber seit einem halben Jahr.
PS: Ich hoffe, ich ziehe mir mit obigen Link eine laufende Version? XDZuletzt geändert von docpayce; 26.07.2022, 15:40.
-
Habe nun die 2.3.0 Version drauf und leider läuft immer noch nichts. Habe schon das Gerät komplett neu gestartet, Interface neu gestartet und auch das Plugin neu gestartet. Nichts hilft.Kommentar
-
Ohne Details kann ich dir leider nicht weiter helfen. Am besten mal ins Log schauen ob der Server gestartet wurde und im Server Log schauen ob da Fehler auftauchen, bzw. ob es eine Verbindung des ISM8 gibt. Wenn das nichts bringt, gerne mir per PN schicken. -
Ich habe mir gestern nochmal die Logs angeschaut und gesehen, dass Daten im Plugin ankommen. Habe daraufhin noch einmal den UDP Port umgestellt und siehe da: Die Daten kommen wieder im Miniserver an.
Bislang läuft das ganze auch stabil!Zuletzt geändert von ManuelB; 08.04.2022, 07:50.
-
-
Hallöle,
Gagi, mal eine kurze Frage zu der neuen Version (die aus https://github....master.zip): Kann es sein, dass Du den pull Request vollständig entfernt hast? Ich war ganz verwundert, weil ich auf einem Rückkanal immer nachgeschaut habe, ob der Befehl ankam (bspw. 57 schaltet den Betriebszustand um: 0 = Auto, 2 = StandBy... den habe ich erst geschickt, dann nachgeschaut, ob er angekommen ist).
Danke & Grüße!Kommentar
-
Hi,
ja ich hab ihn entfernt weil ich nach vielem testen festgestellt habe, dass es eigentlich nichts bringt. Wenn der Pull-Request nach dem schreiben geschickt wird, werden erstmal weiterhin die alten Werte ausgelesen, bis die Heizung/Lüftung oder welches Gerät auch immer darauf reagiert hat und dann entsprechend neue Werte geschickt hat. Die neuen Werte kriegst du dann so oder so.
Aber du hast recht, dass du jetzt keinen Rückkanal mehr hast dass die Werte wirklich im Plugin angekommen sind. Ich kann das gerne auch wieder einbauen und dann als Option anbieten ob es verwendet werden soll oder nicht.Kommentar
-
Hey,
och, Du, das wäre lediglich ein nettes Feature für so Freaks wie mich. Sprich völlig unnötig in 99% der Fälle. XD Ich hatte eigentlich geplant, das Absetzen der Kommandos nach einem Delay zu kontrollieren, aber mit der neuen Version des Plugins läuft bisher alles so stabil und die Befehle - wie Du schon gesagt hast - kommen alle an und werden umgesetzt. Von daher, denke ich, ist mein ursprünglicher Plan eh recht obsolet und unnötig.
Wenn es KEINE Umstände macht, hau es rein als Option, aber nur dann. Ich bin sehr happy mit der jetzigen Version!!! Ich teste weiter und berichte. Ich meine auch schon einmal den Watchdog beim reingrätschen beobachtet zu haben (Miniserver Neustart), kann mich aber irren.
Danke & Grüße!Kommentar
Kommentar