Ankündigung

Einklappen

PLUGINS

Bitte im Titel immer zuerst den Namen des Plugin hinschreiben
Mehr anzeigen
Weniger anzeigen

Loxberry Wolf ISM8 Server Plugin

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #46
    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?
    Angehängte Dateien

    Kommentar


    • #47
      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


      • TobiW
        TobiW kommentierte
        Kommentar bearbeiten
        Hi, nach dem Speichern der Adresse und zwei mal Neustart läuft es wieder, danke!

    • #48
      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!
      Angehängte Dateien

      Kommentar


      • Gagi
        Gagi kommentierte
        Kommentar bearbeiten
        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.

      • docpayce
        docpayce kommentierte
        Kommentar bearbeiten
        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!

    • #49
      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.
      Angehängte Dateien
      Zuletzt geändert von docpayce; In den letzten 3 Wochen.

      Kommentar


      • Gagi
        Gagi kommentierte
        Kommentar bearbeiten
        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

    • #50
      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).log

      Kommentar


      • Gagi
        Gagi kommentierte
        Kommentar bearbeiten
        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.

    • #51
      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


      • Gagi
        Gagi kommentierte
        Kommentar bearbeiten
        Dachte wir hätten Glück und ein "fire&forget" würde funktionieren...

        Also was, bzw. warum das passiert kann ich immer noch nicht sagen. Ich bin mir nicht sicher ob es wirklich mit dem Neustart von Loxone zu tun hat, aber zumindest hast du ja damit einen weg um es zu reproduzieren. An der Menge der Kommandos kann es eigentlich nicht liegen, sind ja eigentlich nur ne Handvoll und sie ändern sich jetzt auch nicht so oft. 6 Kommandos in 5 Sekunden.
        Was ich einfach nicht verstehe ist warum das senden einer UDP Nachricht auf einmal nicht mehr funktioniert (der "permission denied" Fehler) und das von jetzt auf gleich, gerade weil bei UDP ja keine Verbindung ausgehandelt werden muss und es damit eigentlich immer funktioniert.
        Ab dem Punkt sind komischerweise auch alle anderen Verbindungen tot. Weder von Loxone noch vom ISM.

        Bei mir ist es so dass das ISM von selbst seine aktuellen Daten schickt ohne vorher ein Kommando zu brauchen (die erste Version konnte ja noch gar nichts schreiben). Kommt denn nach so einem Verbindungsabbruch wirklich auch nichts mehr vom ISM ? Also auch wenn du sagen wir mal 30min. wartest ? Laut Anleitung sollte nach 30min. definitiv alle Werte einmal kommen. Wenn das auch nicht in der log auftaucht (unabhängig ob es im Loxone ankommt), dann ist wirklich alles tot.

        Mir ist auch noch gerade aufgefallen dass du für 66 immer eine "1" schickst anstatt "1.0", wobei ja beides ein Temperatur-wert ist. Es sollte zwar nichts machen, aber evtl. verschluckt er sich daran ?

        Ich hab das Plugin bei mir in ner VM laufen, nicht auf einem Pi, aber das werde ich heute mal ändern, evtl. gibt es da irgendein Problem.

        Gruss und danke für die vielen Logs!

      • docpayce
        docpayce kommentierte
        Kommentar bearbeiten
        Gerne, ich habe zu danken.

        Ich probiere jetzt dann mal das iobroker Plugin aus und berichte, wie es damit läuft. Vielleicht kann man sich da ja was abgucken. Ist allerdings halt Javascript und kein perl...

        Noch zu Deinen Fragen/Anmerkungen:
        Nope, auch nach 30 Minuten kommt nix mehr. Auch nach einer Woche nicht (hatte ich schon mal).
        Das mit der Nachkommastelle ist ein guter Hinweis, das probiere ich mal noch... *test* ... nope, liegt auch nicht daran. Hätte aber sein können. Aber dann hätte das Plugin vermutlich auch immer abstürzen müssen. Schade auch.

        Grüße!

      • Gagi
        Gagi kommentierte
        Kommentar bearbeiten
        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; In den letzten 2 Wochen.
    Lädt...
    X