HTTPMOD - JUDO isoft Plus

[fsch]

Hallo zusammen,

das httpmod-Modul für die JUDO-Anlage habe ich schon länger im Betrieb und alles läuft gut soweit.
Kürzlich habe ich mich aber mal wieder gewundert, dass wir in der Standard-Konfiguration des Moduls die (Fehler-)Meldungen nicht sehen. Der Status gibt ja keine Auskunft über aufgetretene Fehler (zumindest nicht bei mir).
Dafür habe ich einen Request ergänzt, der die "event list" holt. Wenn man line=0 setzt holt er offenbar immer die letzte Meldung (max_lines):
https://%JUDO_ipaddress%:8124/?group=state&command=event%20list&line=0&offset=0&token=%token%

Die gelieferten Events liefern bis zu vier Komma-getrennte Werte, wobei das erste der Unix-Zeitstempel ist, gefolgt von vom Message-Typ, einem mir unbekannten Wert und ggf. einem Konfigurationsparameter.
Beispiel:
1701958287, 40, 1968722, 30
1701958287=07.12.23 15:11:27
40= Wasserstopp geschlossen, maximal zulässige Entnahmezeit xx Minuten
1968722=Der vierte Wert gibt wohl den aktuellen Stand des totalen Wasserverbrauchs beim Event wieder
30= 30 Minuten

Kennt jemand das gesamte Mapping der Meldungen bzw. eine einfachere Lösung dafür?
Ich habe schon einige Meldungsmappings gefunden im Internet, die aber irgendwie nicht zu meinen Erfahrungen passen.
Ich konnte bisher 40,42,71 und 2 empirisch nachvollziehen. Deshalb könnten auch die anderen 1 bis 14 passen.


1:Regenerationsantrieb defekt
2:Solestand im Salzbehälter hoch
3:Fehlfunktion beim Nachfüllen
4:Wasserstoppantrieb defekt
5:VSV defekt
6:Leitwertmessung defekt
7:Temperaturmessung defekt
8:Weichwasserzähler defekt
9:Rohwasserzähler defekt
10:RH < 2x MH
11:Lsu oder Lgnd wird nicht erkannt
12:Lso immer nass
13:Doppelfehler: Lsu wird nicht erkannt und Lso dauernd nass
14:RS 485 Verbindungsproblem

40:Wasserstop geschlossen, maximal Entnahmezeit <<Parameter 4 in Minuten>>
42:Mengenüberschreitung <<Parameter 4 in Liter>>
71:Salzmangel

Weiß jemand, woran ich sehe, ob die Meldung noch akut ist (Meldung wird noch auf dem Geräte-Display) angezeigt und welche bereits bestätigt wurden?

[ch.eick]

Weiß jemand, woran ich sehe, ob die Meldung noch akut ist (Meldung wird noch auf dem Geräte-Display) angezeigt und welche bereits bestätigt wurden?

Hallo,
ich habe diese Frage mal per Mail an meine Judo Service Kontakte geschickt, bisher habe ich da immer eine Rückmeldung bekommen.

VG   Christian

[fsch]

Hi Christian,

vielen Dank, bin gespannt.

Die Messages in der Eventlist werden offenbar automatisch gelöscht, wenn ihr Alter 6 Monate erreicht.
Damit ändern sich dann auch die Messagenummern der noch jüngeren Einträge (rücken alle hoch).
Ich merke mir daher separat den UNIX-Timestamp der letzten (jüngsten) Message.
Damit kann ich dann erkennen, ob eine neue Message gekommen ist.

Gruß
Frank

[fsch]

Hallo zusammen,

nochmal zur Einordnung, weil es vielleicht auch andere betrifft:
Bei mir ist kürzlich meine Hebeanlage ausgefallen, die eigentlich die verbrauchte Sole in einen höher liegenden Abfluss pumpen soll.
Dadurch ist dann der Flüssigkeitspegel im Salzbehälter immer weiter angestiegen, bis die JUDO-Anlage dann einen Fehler (EVENT) geworfen hat:
2:Solestand im Salzbehälter hoch

Der Status in der Geräte-API wurde aber weiterhin als "OK" geliefert, obwohl die Anlage erfreulicherweise diesen unerfreulichen Zustand bemerkt hat.
Der Status gibt dann wohl keinen Hinweis auf den Status der Anlage (wie ich gedacht habe), sondern bezieht sich nur auf die API-Abfrage.
Auch an anderen Remote-Parametern konnte ich diese Schieflage nicht erkennen und habe es erst gesehen als ich mehr zufällig die (schwer zugängliche) Anlage geprüft habe.
Aus diesem Grund ist diese "event list" spannend, mit der tatsächlich wohl alle Display-Meldungen über die API auslesen werden können.
Und Fehlerzustände kann es wohl einige geben, wenn man sich die Meldungsliste so ansieht.

Das Ganze wieder flott zu machen, hat mich übrigens einige Arbeit gekostet, da es mit einem bloßen Absaugen der überschüssigen Flüssigkeit nicht getan war. Die Anlage hat dann immer wieder "71:Salzmangel" gemeldet (trotz vollem Salzbehälter), bis ich den Salzbehälter komplett geleert und gereinigt und einige Resets durchgeführt hatte.
Jetzt läuft wieder alles reibungslos so wie ich es seit Jahren gewohnt bin.

Gruß
Frank

[ch.eick]

Hallo Frank,
offiziel muss wohl einmal im Jahr eine Wartung gemacht werden, bei der auch der Salzbehälter gereinigt wird
VG   Christian

[Dirk070]

Hallo Frank,
offiziel muss wohl einmal im Jahr eine Wartung gemacht werden, bei der auch der Salzbehälter gereinigt wird
VG  Christian

Richtig und das Sieb am Ansaugschlauch im Salzbehälter wird i.d.R. ersetzt (ca. 10€).
Wartung wurde gerade durchgeführt 

[fsch]

Hi Ihr alle,

ja, das weiß ich doch und mache das auch ... und den Leitwert-Sensor tausche ich alle zwei Jahre, weil er nach einem Jahr idR. noch gar nicht so schlecht aussieht.
Wie beschrieben gab es jetzt aber außer der Reihe den Vorfall, dass die verbrauchte Sole nicht abgesaugt wurde und sich aufstaute.
Somit musste ich dann nochmal ran und das ausgerechnet als auch noch der Salzbestand recht hoch war.
Mit der Wartung wartet man ja normalerweise ab, bis der Salzbehälter ohnehin leer ist.

Gruß
Frank

[ch.eick]

Dafür habe ich einen Request ergänzt, der die "event list" holt. Wenn man line=0 setzt holt er offenbar immer die letzte Meldung (max_lines):
https://%JUDO_ipaddress%:8124/?group=state&command=event%20list&line=0&offset=0&token=%token%

Hallo Frank,
hast Du da noch andere Kombinationen von line und offset identifizeirt?
Bei mir sind wohl nur zwei Events vorhanden, die ich mit line [0|1] abfragen kann, bei offset fehlt mir das empirische Verständnis

Interessant wäre die letzte Melding, oder die letzten 5 in einer Abfrage, wenn das geht.

VG   Christian

[fsch]

Hi Christian,

... bin jetzt nach den tollen Tagen wieder online

Ich habe derzeit 106 Events in der Liste und kann mit line=x&offset=0 genau den x-ten Event holen. Das offset wird offenbar auf line hinzuaddiert, sodass man mit line=x&offset=y das (x+y)-te Event holt. Das offset kann insbesondere auch negativ sein. Also liefert line=100&offset=-1 das 99-te Event.
Wir hatten ja schon gesehen, dass line=0&offset=0 genau das jüngste Event (höchste Messagenummer) liefert.
Tatsächlich kann man darauf negative offsets anwenden.
Die letzten fünf Events müsste man somit also durch fünf einfache Anfragen holen können ohne separate Arithmetik, weil die Liste ja ständig wachsen (neues Event) oder schrumpfen (Housekeeping Event-Alter 6 Monate) kann:
line=0&offset=0
line=0&offset=-1
line=0&offset=-2
line=0&offset=-3
line=0&offset=-4

Wenn der offset den Anfang der Liste überspringt, liefert die API übrigens immer das erste Event.
Bei Deinen zwei Events würde bei line=0&offset=-4 also das erste Event geliefert werden.
Hier müsste man ggf. schauen, wie viele überhaupt vorhanden sind (max lines), um es schön zu machen.

Gruß
Frank





Gruß
Frank

[ch.eick]

< snip >
Wenn der offset den Anfang der Liste überspringt, liefert die API übrigens immer das erste Event.
Bei Deinen zwei Events würde bei line=0&offset=-4 also das erste Event geliefert werden.
Hier müsste man ggf. schauen, wie viele überhaupt vorhanden sind (max lines), um es schön zu machen.

Hallo Frank,
hast Du bereits readings erstellt, die die Eventliste aufnehmen?

VG  Christian

[fsch]

Hi Christian,

bisher lese ich immer nur das aktuelle Event aus und das alle 5 Minuten:

Code Auswählen Erweitern

attr JUDO_iSoft get19Name event
attr JUDO_iSoft get19Poll 1
attr JUDO_iSoft get19PollDelay 300
attr JUDO_iSoft get19URL https://%JUDO_ipaddress%:8124/?group=state&command=event%20list&line=0&offset=0&token=%token%
Dabei wird dann automatisch das Reading "event-list" aus dem Response angelegt, was die in einem früheren Post beschriebene Struktur hat.
z.B: event-list 1704097964, 42, 2007928, 600
Das verteile ich dann mit userReadings auf folgende Readings. Diese fangen alle mit "event" an, sodass alles zum Event untereinander steht.

event-message Mengenüberschreitung 600l
event-time 2024-01-01 09:32:44
event-watergauge 2007928

Meine Definition der userReadings sieht folgendermaßen aus:

Code Auswählen Erweitern

saltRangeInWeeks:salt-range.* {int((ReadingsVal("JUDO_iSoft","salt-range",0)/7))}
,event-time:event-list.* {ReadingsVal("JUDO_iSoft","event-list",0)=~/(\d+),.*/i?strftime "%F %X", localtime($1):"Zeitstempel nicht vorhanden"}
,event-message:event-list.* {
ReadingsVal("JUDO_iSoft","event-list",0)=~/\d+,\s*(\d+).*/i?
$1 eq "1"?"Störung! Regenerationsantrieb defekt":
$1 eq "2"?"Störung! Solestand im Salzbehälter hoch":
$1 eq "3"?"Fehlfunktion beim Nachfüllen":
$1 eq "4"?"Wasserstoppantrieb defekt":
$1 eq "5"?"VSV defekt":
$1 eq "6"?"Leitwertmessung defekt":
$1 eq "7"?"Temperaturmessung defekt":
$1 eq "8"?"Weichwasserzähler defekt":
$1 eq "9"?"Rohwasserzähler defekt":
$1 eq "10"?"RH < 2x MH":
$1 eq "11"?"Lsu oder Lgnd wird nicht erkannt":
$1 eq "12"?"Lso immer nass":
$1 eq "13"?"Doppelfehler: Lsu wird nicht erkannt und Lso dauernd nass":
$1 eq "14"?"RS 485 Verbindungsproblem":
$1 eq "40"?"Wasserstopp geschlossen, maximal zulässige Entnahmezeit ".(ReadingsVal("JUDO_iSoft","event-list",0)=~/\d+,\s*\d+,\s*\d+,\s(\d+).*.*/i?$1." Minuten überschritten":""):
$1 eq "41"?"Wasserstopp geschlossen, maximal zulässiger Wasserdurchfluss von ".(ReadingsVal("JUDO_iSoft","event-list",0)=~/\d+,\s*\d+,\s*\d+,\s(\d+).*.*/i?$1." l/h überschritten":""):
$1 eq "42"?"Wasserstopp geschlossen, maximal zulässige Wassermenge ".(ReadingsVal("JUDO_iSoft","event-list",0)=~/\d+,\s*\d+,\s*\d+,\s(\d+).*.*/i?$1." l überschritten":""):
$1 eq "45"?"Wasserstopp manuell geschlossen":
$1 eq "70"?"Reichweite der Salzmenge ist gering":
$1 eq "71"?"Achtung Salzmangel!":
"Eventtyp unbekannt":"Struktur unbekannt"}
,event-watergauge:event-list.* {ReadingsVal("JUDO_iSoft","event-list",0)=~/\d+,\s*\d+,\s*(\d+).*/i?$1:""}
Die Events kommen m.E. nicht so häufig, dass man sich mehrere Meldungen ansehen müsste.
Ich habe noch ein separates Notify, das mir eine Push-Nachricht sendet, wenn ein neues Event kommt. Dieses Notify speichert dann den Zeitstempel (event-time) des gemeldeten Events in einem Dummy, um nicht dasselbe Event mehrfach zu pushen.
Wenn man die letzten fünf Events zeigen wollte, müsste man die obigen Definitionen duplizieren mit offset=-1 (usw.) in der URL und entsprechend weiteren userReadings.
Das finde ich aber etwas aufwändig für den Zweck, weil die alten Events eigentlich gar nicht spannend sind.

Gruß
Frank

[fsch]

Hallo zusammen,

heute hatte ich noch ein anderes Thema mit dem JUDO-Modul.
Irgendwie hat sich das Modul verschluckt und keine Werte mehr angezeigt. Die meisten Readings standen dann auf "not connected", weil wohl irgendwann mal der Login funktioniert hat, aber der connect nicht. Alle requests sind dann mit einem Token ausgeführt worden, das (noch) nicht connected war.
Lösen konnte ich das, indem ich "not connected" im Attribut reAuthRegex ergänzt habe:

Code Auswählen Erweitern

attrib JUDO_iSoft reAuthRegex (no token)|(not logged in)|(not connected)
Dieses Attribut gibt wohl an, wann ein neues Login/Connect durchgeführt werden muss.
Hier sollte man auch den Status "not connected" berücksichtigen, um nicht auf "not logged in" oder "no token" warten zu müssen.

Gruß
Frank

[ch.eick]

< snip >
Lösen konnte ich das, indem ich "not connected" im Attribut reAuthRegex ergänzt habe:

Code Auswählen Erweitern

attrib JUDO_iSoft reAuthRegex (no token)|(not logged in)|(not connected)

Hallo Frank,
ich habe da sogar zusätzlich noch einen String identifiziert.

Code Auswählen Erweitern

attrib JUDO_iSoft reAuthRegex (no token)|(not logged in)|(not connected)|(Connection refused)


[Dirk070]

ich habe mit Deinen RAW ein neues Device angelegt.
Nun bekomme ich immer einen Fehler: status error / data not logged in

Mit meinem alten Device (dieses hat schon ein Token) gibt es weiterhin kein Problem.
Zum Testen habe ich das alte Device kopiert (copy) und auch damit bekomme ich den Fehler und damit kein Token.

Es liegt also am initialen Anmelden und der Vergabe des Token.

Hast Du eine Idee, woran das liegen kann und wie ich das Ganze eingrenzen kann?

Hallo Dirk,
Hast Du beim Device das Passwort und den User Namen auch gesetzt?
Evenbtuell aus dem RAW des alten Devices die setstate ind RAW des neuen Devices übernehmen und dann ausführen.
Ansonsten erstmal verbose 5 und ins Log schauen.

VG   Chrstian

Hallo Christian,

ja, PW und User sind gesetzt.
Hättest Du einen Tipp, zunächst minimalistisch nur den Connect mit dem Token zu testen?

Danke und schöne Grüße
Dirk

[ch.eick]

ja, PW und User sind gesetzt.
Hättest Du einen Tipp, zunächst minimalistisch nur den Connect mit dem Token zu testen?

Hallo Dirk,
da die Verbindung sich bei einem get automatisch selber aufbaut könntest Du einfach mal ein "get JUDO_iSoft Waterstop_Valve" durchführen.
Beim httpbody sollte dann so etwas kommen und natürlich das reading waterstop_State gesetzt werden.

Code Auswählen Erweitern

{"command":"valve","data":"opened","group":"waterstop","msgnumber":"1","status":"ok","token":"275a1baa800e7969da4e1f70e615105215a05b016aa23d01d621faedd39d03ea","wtuType":"i-soft plus","serial number":"96586","tftStarted":1665641837385}