Plugin Pelletkessel

[greentux]

Hallo,

mal angenommen, ich möchte mein Perl Plugin fürs WG
Plugin: Pelletskessel ETA PU
aufs SmartHome.py migrieren. Was wäre da das geeignete Vorgehen?
Die Werte auf den Bus senden ist relativ einfach, das könnte man auch per crontab erschlagen also unabhäng jeglicher 1wire-Infrastruktur.
Wie siehts aber damit aus, bei reinkommenden KNX Befehlen, diese an den Pelletter weiterzuleiten?
Wo passt das in die SmartHome.py Infrastruktur?

[mknx]

Hallo,


uiii, die Hälfte des Plugins sind ja die Mappingtabellen.

Man könnte das mit einer normaler Logik machen und die auf die KNX Adressen horchen lassen. Für mich sieht es aber so aus, als ob der sinnvolle Umgang mit dem Mapping das schwierigste ist.

Daher würde ich das ganze in ein Plugin packen und das Mapping in eine separate Items-Konfigdatei packen z.B. eta.conf:

[eta]
    [[kessel]]
        [[[status]]]
            type = str
            knx_send = 1/1/3
            knx_listen = 1/1/4
            knx_dpt = 24
            eta_can = 112/10021/0/0/12000
...

Das Plugin würde (beim Start) alle Items durchforsten und sich die mit eta_can rauspicken. Du kannst Dir ja einfach mal ein paar Plugins ansehen:


Als Basis: https://github.com/mknx/smarthome/bl...mx/__init__.py
http Anfragen: https://github.com/mknx/smarthome/bl...wl/__init__.py
xml parsen: https://github.com/mknx/smarthome/bl...wd/__init__.py

Wenn Du Fragen hast oder eine Starthilfe benötigst melde Dich einfach.

Bis bald

Marcus

[greentux]

Das Mapping mal aussen vor muss ich erstmal lernen, wie die Plugins funktionieren. Mal sehen, was trübe Novembertage noch bieten an Zeit.

[greentux]

So, ich habe mal etwas nachgedacht und mir die Plugins im sh.py angeschaut.
Das ganze WG-Pelletplugin ist vermutlich ein Mischung aus Logik und Plugin.

Was brauchts generell:

- eine Möglichkeit, um den Webservice des Kessels abzufragen. Dazu legt man eine Gruppe von CAN-Knoten an. Diese können dann mit einem Aufruf abgefragt werden. Jede CAN ID liefert dann Ergebnisse, die interpretiert werden müssen. Generell kann man Values und Texte unterscheiden.

- Value Werte können auch geschrieben werden. Dies kann einzeln pro CAN-Knoten passieren.

Aus meiner Sicht wäre das eine Mischung aus Plugin (Webservice/XML lesen/schreiben) und Logik (Umrechnung Ergebnis XML in "Werte" mit DPTs)

Im Perl Plugin haben wir am Anfang eine Menge definiert. u.a.
CAN-ID, GA, DPT
Das Ganze jeweils für Value-read, Value-write und String-read CAN-IDs.

Marcus, vl. kannst Du mir eine Idee geben, wie das einzubauen wäre. Das eigentliche Einbauen würde ich dann selber mal probieren.

Grüße

[mknx]

Hi,

eine separate Logik sehe ich momentan nicht.
Was musst Du den umrechnen?
Das ganze KNX Zeug hat nichts mit dem ETA Plugin zu tun. Du musst dem entsprechenden Item nur die 'echten' Werte mitteilen und ein paar Angaben für das KNX Plugin machen.

[eta]
    [[kessel]]
        [[[temp]]]
            type = num
            knx_send = 1/1/3
            knx_listen = 1/1/4
            knx_dpt = 9
            eta_can = 112/10021/0/0/12001
            eta_send = yes
            eta_eval = value * Pi  # evtl. falls eine Bereinigung der ETA Eingangswerte notwendig ist.

Aber so richtig verstehe ich das Problem bzw. den Datenfluss nicht.

1. Du baust ein paar Funktionen um mit der ETA per http zu kommunizieren zu können (GET, POST, ...)
2. Du parst das XML (zyklisch) und setzt die items.
3. Bei Änderungen der items, die eta_send gesetzt haben, sendest Du das ein POST Update an die ETA.

Die Kommunikation und XML parsen kannst Du auch erst mal so in ein Python Script hacken. Die Integration als Plugin wird dann sehr einfach.
Achtung bei urllib2 gibt es ein memleak. In lib/tools.py habe eine Funktion definiert die das umgeht. Es sollte Dir als Vorlage für Deine Kommunikationsfunktionen dienen.

Bis bald

Marcus

[greentux]

zu 1.
Das wäre ja das, was bisher bei Dir unter /plugins liegt. Also beispielweise würde ich den udp Sender/Empfäger nehmen, um dann einen http/xml Sender/Empfänger zu haben.

GET /user/var/112/10021/0/0/12112 HTTP/1.1

HTTP Response
HTTP/1.1 200 OK
Content-Encoding: utf-8
Content-Type: application/xml
<?xml version="1.0" encoding="utf-8"?>
<eta version="1.0" xmlns="http://www.eta.co.at/rest/v1">
<value uri="/user/var/112/10021/0/0/12112" strValue="Off" unit=""
decPlaces="0" scaleFactor="1" advTextOffset="1802">1802</value>
</eta>

Das Ergebnis (1802) ist nun mit scaleFactor (1) zu multiplizieren. Anschliessend ist advTextOffset (1802) zu subtrahieren (=0). Ggf. hat man die unit übergeben. Parallel gibs hier auch einen Text ("off"), das sind also im Grunde zwei GAs.

Der Teil oben ist vermutlich dann "plugin", das auswerten und knx anbinden ist normale Logik. So war auch mein Vorschlag...

[mknx]

Hi,

ich würde alles im Plugin machen. Das Plugin holt sich zyklisch die XML Files, parst diese, berechnet den Wert und setzt die Items.

Kopier Dir mal plugins/sample/__init__.py (das kannst Du auch direkt ohne SmartHome.py ausführen, geht zum entwickeln schneller) und fange an das Plugin zu entwickeln.
1. Schritt Kommunikation = Hol Dir ein XML File als String. Für den Anfang kannst Du ja nur eine CAN_ID auslesen und das ganze in der run methode aufrufen.

Dann poste den Code und ich gebe Dir Feedback

Wollen wir es so machen?

Bis bald

Marcus

[greentux]

Ich habe jetzt mal den Python Code soweit, das er sich mit der ETA verbindet und Daten holt bzw Daten abliefern kann.

Daraus könnte man nun ein Plugin machen, was alle 300s läuft und Daten holt. Um diese dann auf den KNX zu senden sollte man aus dem ETA Plugin direkt mittels sh.knx.groupwrite auf den Bus schreiben?

Die gleiche Frage stellte sich mir, wie man 1Wire Werte auf den KNX bekommt. In einer Logik oder direkt in einem 1wire Plugin?

Ich verstehe glaube ich vl. die Architektur noch nicht so ganz. Kümmern sich die Plugins nur jeder um ihren "Bus" / "Gerät" etc. und der Austausch dazwischen passiert immer via Logik oder wie soll es sein?

Fangen wir mal mit dem einfachsten Fall an.
10 Werte vom Kessel auf den KNX bekommen.
Ich habe GA, CAN-ID und DPT in einer Liste im Plugin (später mal in der plugin.conf) und kann diese nun lesen. Wo sollen die Daten dann hin?

[mknx]

Zitat von greentux Ich habe jetzt mal den Python Code soweit, das er sich mit der ETA verbindet und Daten holt bzw Daten abliefern kann. Daraus könnte man nun ein Plugin machen, was alle 300s läuft und Daten holt.

Klasse. Kannst Du mir den Code mal per Mail schicken? Dann kann ich Ihn mir am Sonntag Abend mal ansehen.

Zitat von greentux Um diese dann auf den KNX zu senden sollte man aus dem ETA Plugin direkt mittels sh.knx.groupwrite auf den Bus schreiben? Die gleiche Frage stellte sich mir, wie man 1Wire Werte auf den KNX bekommt. In einer Logik oder direkt in einem 1wire Plugin? Ich verstehe glaube ich vl. die Architektur noch nicht so ganz. Kümmern sich die Plugins nur jeder um ihren "Bus" / "Gerät" etc. und der Austausch dazwischen passiert immer via Logik oder wie soll es sein?

Ja, die Plugins kümmern sich immer nur um ihren Bus/Gerät.
Verknüpft werden sie primär über Items. Über Logiken geht auch, fällt mir aber momentan kein Use Case ein.

Für 1-Wire => KNX:

[temperature]
  type = num
  ow_id = 28.FE4D7207777
  ow_sensor = temperature
  knx_dpt = 9
  knx_send = 1/1/8

Ode für Dein Plugin:

[eta]
    [[kessel]]
        [[[temp]]]
            type = num
            knx_send = 1/1/3
            knx_listen = 1/1/4
            knx_dpt = 9
            eta_can = 112/10021/0/0/12001
            eta_send = yes
            eta_eval = value * Pi  # evtl. falls eine Bereinigung der ETA Eingangswerte notwendig ist.

Dein eta Plugin setzt auf eta.kessel.temp auf 21. Das KNX Plugin reagiert auf die Wertveränderung und sendet den Wert 21 als dpa 9 kodiert an die 1/1/3.
Dazu müssen sich die Plugins bei dem Items registrieren wenn sie über Änderungen informiert werden wollen. (Das geschieht in der parse_item Methode).

Andersrum könnte man für Werte die man setzen möchte, z.B. die gewünschte Vorlauftemperatur, einen Wert über das KNX-Plugin ändern und dein eta Plugin würde auf die Änderung reagieren.
Als z.B. den Wert 23 als dpt 9 kodiert an die 1/1/4 schicken und dein Plugin schickt den Wert dann an die 112/10021/0/0/12001 richtig kodiert.

Verständlich?

Bis bald

Marcus

[greentux]

Ja, soweit verständlich. Das 1Wire ist ja ein guter Vergleich.
Dann zwei Fragen (ich denke immer a la WG

- kann ich im Item dafür sorgen, das die Werte regelmässig gesendet werden? (Für die Uhrzeit ist das ja schon vorgesehen). Da die Lesewerte auch immer als ein Set (etwa 40 Werte) gelesen werden, wäre es gut, wenn die dann auch in einem Rutsch rauskämen. Wenn es jetzt 40 Items gäbe und jedes wieder beim Plugin nachfragt, muss ich das im Plugin anders gestalten. Dann muss da eine Art Cache rein. Beim WG lese ich halt alle 5 Minuten alle Werte und schreibe die auf den Bus.

- 1 Item = 1 Wert ? Also Schlafzimmer mit drei Sensoren sind 2 Items?

Zwei strukturelle Fragen:
- Wo lege ich am besten eine Config ab (primär GA, CAN, DPT Einträge)? Im Plugin selbst wärs unschön.

- Wo sollten administrative Aufgaben passieren (also anlegen des CAN-ID Sets falls noch nicht angelegt weil Heizung Rebootet