Plugin: Pelletskessel ETA PU

[haegar80]

Hallo Markus,

So ich komme erstmal dran an die Kiste. Das hat schonmal geklappt. Läuft bei dir die 1.20_1? Bei mir wird die nicht geupdatet. Daher die 1.20_0 am laufen.

Ist bei mir genauso, 1.20_0 geht aber.

Bisher hab ich erstmal den Webbrowser genommen und durch die xml gesurft. Geht ja auch.

Das mache ich auch, so bin ich an die XML Schnipsel in meinen vorangegangenen Postings gekommen.

Ich frage mich nun, ob Asche voll, dann wirklich mal als Fehler auftaucht. Ich bin gespannt.

Die XML für /user/errors sieht schon mal vielversprechend aus. Schade, daß es zu Zeit keinen Fehler gibt, an dem ich mich probieren kann.

Nun bleiben mir armseligen Programmierwürstchen zwei Möglichkeiten:
a) ich mach das auf der Shell mit wget, grep und co
b) ich suche mir am Montag einen Kollegen, der das elegant in Perl/Python macht, wobei Perl wg WG wohl prio hätte...

Das Modul LWP::UserAgent kann sowohl POST, als auch GET:

[COLOR=#006600]get[/COLOR][COLOR=#009900]($[/COLOR][COLOR=#ff0000]URL[/COLOR][COLOR=#009900])[/COLOR][COLOR=#339933];[/COLOR]
[COLOR=#006600]post[/COLOR][COLOR=#009900]([/COLOR][COLOR=#ff0000][COLOR=#009900]$[/COLOR][COLOR=#ff0000]URL[/COLOR][/COLOR][COLOR=#339933],[/COLOR][COLOR=#009900][[/COLOR]text1 [COLOR=#339933]=>[/COLOR] [COLOR=#ff0000]'blabla'[/COLOR][COLOR=#339933],[/COLOR]text2 [COLOR=#339933]=>[/COLOR] [COLOR=#ff0000]'blablubb'[/COLOR][COLOR=#339933],[/COLOR][COLOR=#009900]])[/COLOR][COLOR=#339933];[/COLOR]

Das Modul LWP::Simple kann anscheinend kein POST!
Warum willtst du das mit wget lösen? Die Plugins mit Perl haben ja alle Vorraussetzungen dafür. Es gibt eben nur das Problem des Umsetzens! ;-)
Ich halte ein Plugin im WG mit Perl Bordmitteln für die Beste Lösung.

Als Ideallösung am Ende stelle ich mir folgendes vor:

1. Definition der zu berücksichtigenden Variablen des Kessels in einm Array mit Hash Werten z. B. { Name=>'Vorrat', Gruppe=>'Silo', GA=>'4/7/11' },

2. Definition der DPT der zu berücksichtigenden Einheiten des Kessels in einm Array mit Hash Werten z. B. { Einheit=>'°C', DPT=>9.001},

3. XML-Datei für das Menü holen

4. Durchlaufen des Arrays mit den zu berücksichtigenden Variablen des Kessels.

4 a) Ermitteln der Variable für jedes Element aus der Definition im Array z. B. Name=>'Vorrat', Gruppe=>'Silo' entspricht /112/10201/0/0/12015

4. b) XML-Datei für die Variable holen und in Perl Variablen parsen

4. c1) Bei Schreibtransaktion auf GA des Array Elements z. B. GA=>'4/7/11' einen POST absetzen. Wobei die vorher geparste Einheit aus der XML-Datei für die Variable mit dem definierten Array zu einem DPT umgesetzt wird (für knx_read).

4. c2) Sonst auf GA des Array Elements schreiben. Wobei die vorher geparste Einheit aus der XML-Datei für die Variable mit dem definierten Array zu einem DPT umgesetzt wird (für knx_write).


Die Error Liste muss anschließend durchgegenen werden. Ich denke, daß hier das gleiche Array mit Hash Werten für die Variablen des Kessels genutzt werden kann. Die Aviablennamen sind bei den Errors identisch zu denen im Menü z. B. { Name=>'Vorrat', Gruppe=>'Silo', GA=>'4/7/11', GA_Error=>'4/7/12', GA_ErrorMessage=>'4/7/13'},
Die DPT sind dann immer fest: GA_Error: 1, GA_ErrorMessage: 16

Am Ende muss dann nur noch ein Arrays mit den zu berücksichtigenden Variablen gepflegt werden, weil das Plugin bei jedem mit einem ETA Kessel läuft.

Was hältst du davon?

@ALL: Wer kann mir beim Parsen der XML-Attribute helfen?

Gruß
Sascha

[greentux]

Ich habe jetzt mal nen Kollegen beauftragt, alle Werte in ein Array einzulesen, einzelne Werte zu lesen und einzelne Werte zu schreiben. In Perl, wg WG. Klar.

Deine Variante mit dem "ich will dies und jenes und das ist DPT xy" ist auch gut. Ich schicks ihm mal.

[makki]

Jungs, packt doch mal gelegentlich den aktuellen Stand des WG-Plugins (komplett!) mit rein, inkl dem zu parsenden XML, dann geht da vielleicht was mit Hilfe
Es ist ja nicht soo schwierig aber die Schnitzeljagd zwischen Plugin- und XML Fragmententen macht auch kein Spass Klar kann man sich das vielleicht über 5 Threads auch zusammenkramen, aber wenn man davon mal 50 hat..

Makki

[greentux]

Es gibt genau ein Dokument und da steht alles drin. Das haben die bei ETA schon vorbildlich gemacht. Wie schon gesagt. Ich denke, heute einen meiner XML und Perl affinen Mitarbeiter da mal für 2h beschäftigen zu können.

Wir wollen doch den WG-Schreibtisch nicht noch mehr belasten

[makki]

Nee, einverstanden, ich muss nicht War mehr so als allgemeiner Hinweis: mit ein bisschen "Fleisch" lassen sich die fehlenden 10% oft ohne grossen Aufwand ergänzen..

Makki

[greentux]

Eine Frage an den Meister wäre da schon noch...

Wenn ich nun den Value (1335) und die Masseinheit (kg) habe geb ich das ja an knx_write.

Wäre hier DPT 14.051 vermutlich der Richtige, aber ist das in WG und Visu supported?

Alternativ gibts noch 229.001, aber das wird erst recht niemand nutzen. Wie ist nun also der praktikabelste Weg?
Alles zusammen in einen ASCII String packen und DPT 16 nehmen?

Ich tippe mal auf Letzteres?

[makki]

DPT14 wäre da schon das "richtigere", ist auch beidseitig supported..

Makki

[greentux]

Das klingt gut. Also sollte die "kg" dann automatisch erscheinen, wenn man mit DPT 14.051 schreibt... werds dann mal probieren.


Andere Frage: der Kessel ist recht "lahm" beim Webservice. Ein Wert lesen dauert schonmal ne halbe Sekunde. Wenn man nun 20 Werte liest... Tja. Wie lange darf ein Plugin max laufen?

Es gibt dann noch eine Alternative, bei der man viele Werte mit einem Mal lesen kann. Sollte das also mit Einzelwerten Probleme machen, werd ich gleich 2. implementieren.

Gruß

[makki]

Hmm, die DPT's werden (leider!) quasi nirgends umgesetzt, so auch hier:
knx_write schreibt einen Wert auf den Bus, was der DPT_Subtype ist, welche Einheit, Bananen, kg oder m³, spielt dabei eh keine Rolle. Auf dem KNX sehen alle DPT14 gleich aus..

Ebensowenig beim lesen in der CV, das wäre zwar irgendwo schöner, wenn die Visu gleich aus dem DPT Einheiten&Werte "mitnehmen" würde, das kommt da vielleicht auch irgendwann, aber derzeit stellt man das (einheiten/Werte) ganz einfach separat ein.

Langsam ist ein Problem! Dokumentiert sind 10 sek. maximale Laufzeit eines Plugins, real sind es seit längerem 30sek, (aber schon 10s sind viel zu viel, da muss man andere Lösungen finden!) dann wird knallhart der Stecker gezogen und das kostet richtig Zeit, weil es eben alles andere blockiert.
Wenn das wirklich so langsam ist: entweder aufteilen oder einen Workaround: Die Daten erst per wget o.ä. in eine temporäre Datei pumpen oder so..
Wenn alles lesen auf einmal geht, ist das definitiv zu bevorzugen.

Makki

P.S.: Wer zwischen den Zeilen die sonst üblichen wenns&abers zur CV vermisst: ich glaube der Weihnachtsmann kommt heuer vor dem 24.12.

[greentux]

Ja, das habe ich eben auch festgestellt mit den Einheiten. Da hattest Du also meine Frage oder ich Deine Antwort falsch verstanden. Also Einheit händisch ranhängen. Oder eben, da die Einheit der Kessel vorgibt, dann halt doch alles in ein Textfeld packen.
Vom Kessel kommt Value und Unit...
Man kann natürlich auch zwei Felder übertragen (Zahl + Text), aber das bekommt die Visu nicht zusammen.

Das wget würde genauso lange dauern. Das ist ein Webservice, der beim GET dann erst auf dem CAN Bus den Werte einsammelt, aufbereitet und zurückschickt.

Also bau ich morgen mal um zum Parameterset.

[makki]

Aber die Einheiten werden sich ja nicht im laufenden Betrieb ändern (?)
Also sind diese bekannt und müssen nicht über den KNX als Text gepresst werden, irgendwo vermutlich auch das Grundlegende Prinzip der DPT's Sender und Empfänger wissens, das Medium dazwischen braucht diese Info nicht..

Ansonsten wäre es dann sinnvoller im Plugin auf den jew. DPT umzurechnen (also mal angenommen das gibt z.B. je nachdem g, kg oder Tonnen aus) -> Der DPT / Werte/Einheiten-Suffix in der Visu und allen verarbeitetenden consumern (RRD, ...) bleibt immer gleich.

Makki

[greentux]

Hier mal eine erste Version. Es handelt sich dabei um ein Perl-Programm für die Kommandozeile, welches alle notwendigen Funktionen enthält, um erstmal Daten zu lesen.
Dieses Programm nutzt die von ETA bereitgestellten Parametersets, so dass mehrere Daten mit einem Mal abgerufen werden kann. Somit sind in akzeptabler Laufzeit (<1 Sekunde) alle Daten verfügbar.
Dazu kann eine Datei geschrieben werden, die die ETA CAN-URIs enthält. Es sind mehrere Sets möglich (siehe ETA Doku).
Ab hier kann vermutlich jeder sein eigenes Plugin schreiben, da die Anforderungen doch recht unterschiedlich sind (lesen, rrd, schreiben, überwachen, etc, pp).

[makki]

1s ist dann kein Thema..

..da die Anforderungen doch recht unterschiedlich sind (lesen, rrd,

Nur am Rande: Ich hab mir angewöhnt, das immer hübsch zu trennen (auch aus Laufzeitgründen): Ein Plugin liest&sendet die Werte auf den Bus, eins macht die RRD's usw., so bleibt man auch schön flexibel, wenn man den Wert mal in der Visu haben will usw.. Welche Aufteilung Sinn macht kommt natürlich auf den konkreten Fall an..

Makki

[greentux]

Ja nun, das kann sich ja nun jeder bauen. Ich werds bei mir trennen, Sascha wollte das ggf eher zusammenfassen. Der Code ist aus meiner Sicht lesbar und weiterverwendbar.

[makki]

Auf jeden Fall, nur ein Hinweis (mangels ETA kann ich auch kaum mitreden)
Das ist ja u.a. Sinn&Zweck der Plugins, das eben bitte jeder alles so machen kann, darf und soll wie er es für richtig&passend hält.
Ich streue da am liebsten nur Hinweise ein aber nicht vergessen: vielleicht freut sich ein mitleser mal, wenn das Plugin dann auch veröffentlicht wird
Das hilft oft vielen mehr als man glaubt..

Makki