Plugin Pelletkessel

[greentux]

Hallo,

mal angenommen, ich möchte mein Perl Plugin fürs WG
https://knx-user-forum.de/forum/supp...wiregate/17199
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?

[callidomus]

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

[callidomus]

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...

[callidomus]

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?

[callidomus]

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.

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

[callidomus]

- kann ich im Item dafür sorgen, das die Werte regelmässig gesendet werden?

Nein, dafür müsste man ein separate Lokig oder Plugin schreiben oder das KNX Plugin erweitern.

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.

Nein, Dein Plugin aktualisiert in einem Rutsch 40 Items. Wenn diese Items auch ein 'knx_send' haben, wird der Wert (wenn er sich geändert hat) auf den Bus gesendet.
Alternativ könnte man 'enforce_updates' bei einem Item setzen, dann wird der Vergleich ignoriert und der Wert an jedes Plugin - das sich beim Item für Updates registriert hat - gesendet.
Das Item ist der 'Cache'! Aus meiner Sicht muss die Werte nicht zyklisch senden, wenn nicht ein RTR oder ähnliches den Wert zyklisch erwartet.
Wozu brauchst Du das? Für die Visu? Dann würde es auch langen die Werte bei Änderung auf den Bus zu schicken, da der eibd ja die alten Werte zusätzlich cached. Das KNX Plugin kann ja bei Bedarf auch auf KNX READs antworten.

- 1 Item = 1 Wert ?

Prinzipiell Ja, 1 Item = 1 Wert. Man könnte aber auch mehrere Werte in ein Item schreiben, das führt hier jetzt wahrscheinlich zu weit.

Also Schlafzimmer mit drei Sensoren sind 2 Items?

Ich sehe da 4 Items. Wobei das Schlafzimmer-Item nur zu Struktur dient und keinen Wert hat.

[Schlafzimmer]
  [[Sensor1]]
    type = num
  [[Sensor2]]
    type = num
  [[Sensor3]]
    type = num

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

In den Items. (siehe meine Fantasie-Config für Dein Plugin)

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

Im Plugin.

Bis bald

Marcus

[greentux]

Hallo,

ich weiß nicht, ob das jetzt hier in dieses Thema rein passt, da es jedoch so ziemlich der einzige Thread ist, welcher sich explizit mit der ETA PU beschäftigt will ich mein Anliegen mal hier äußern.

Seit kurzem besitzen wir eine PU15 der Firma ETA. Ansonsten ist nichts an Hausautomatisierung vorhanden oder geplant (Haus der Eltern). Jedoch möchte ich mir gerne etwas günstiges aufbauen, was aktuell zum Loggen der Heizungsdaten genutzt werden kann. Meine erste Idee ist die, eine Raspberry Pi anzuschaffen und diese zum zyklischen Auslesen und zum Visualisieren zu nutzen. Jedoch bin ich bisher bei meiner Recherche nicht so richtig schlau geworden, was ich dazu alles benötige, ob ein EIBD/KNX notwendig ist, ob Smarthome (auf Pi) bzw. Wiregate / Communitygate overkill ist etc.
Genau hier setzt jetzt meine eigentliche Frage an:
Was benötige ich, um die Heizungsdaten auszulesen und eine per html zugängliche Visualisierung (z.B. CometVISU) zu realisieren, wobei das ganze nicht zu komplex werden soll. Eventuell ist auch später mal etwas Logik geplant (z.B. Wetterdaten aquierieren und bei schönem Wetter den Kessel ausschalten um nur Solar zu nutzen).
Da ich noch keine Raspberry pi besitze, konnte ich noch nicht rumprobieren. Ansonsten ist als Technik ein TP-LINK MR3420 v2 vorhanden, welcher aktuell auf originaler Firmware läuft (und wohl auch darauf bleiben soll, da die Zuverlässigkeit mit openWRT wahrscheinlich nicht so toll ist?!?).

Über Informationen würde ich mich freuen.

Mir sei der Fullquote gestattet. Wir kommen gerade aus dem WG Bereich herüber. Fürs WG hatte ich damals mit Sascha ein Plugin geschrieben, was auch ausgezeichnet tut. Sowohl lesend, als auch schreibend. Ich habe also sowohl die Diagramme (lesend), kann aber auch den Kessel ein- und ausschalten (schreibend).

Da es auch für mich einige Gründe gibt, vom WG wegzuwechseln, bin ich hier bei SH.py gelandet. Ein neues Plugin ist in Arbeit, aber das dauert noch etwas.
Generell willst Du ja nur lesend darauf zugreifen und dann Diagramme befüllen. Das sollten wir recht schnell hinbekommen. KNX etc. brauchste alles nicht. SH.py ist auch nicht darauf fokussiert. KNX ist ein Konnektor, wie jeder andere auch (1wire, CAN, DMX).
Ich empfehle Dir also, Dir einen Rasperry zu kaufen, das Image hier draufzutun und damit ein wenig rumzuspielen. In der Zwischenzeit mach ich mich mal an das Plugin...

PS: Ein paar 1Wire Sensoren wären trotzdem nicht schlecht, das Du dann noch an den Vorlauf-/Rücklauf/Zirkulation/Warmwasser jeweils einen ranbauen kannst. Auch den Speicher oben/unten habe ich bestückt. Einiges gibt es auch in der ETA, aber nicht alles.

[2ndsky]

PS: Ein paar 1Wire Sensoren wären trotzdem nicht schlecht, das Du dann noch an den Vorlauf-/Rücklauf/Zirkulation/Warmwasser jeweils einen ranbauen kannst. Auch den Speicher oben/unten habe ich bestückt. Einiges gibt es auch in der ETA, aber nicht alles.

Nur als Info an den Fragesteller: diese können ebenfalls an den PI mittels ROT Extension angeschlossen werden... ein Wiregate ist dafür also nicht notwendig.

[JuMi2006]

Und noch was ... fürs erste ... bis das Plugin fertig ist tut es auch der knxd mit dem WireGate-Plugin: Knxd - Open Automation

Der läuft auch auf "jeder" Plattform und hier auf dem Pi parallel zu smarthome. Einzig ein "virtueller KNX-Bus" in Form vom eibd ist nötig.

[superdolle]

Hui, danke schonmal für die vielen guten Antworten.

Die zusätzliche Ausstattung mit 1-Wire Sensoren liegt erstmal noch in weiterer Zukunft, ist jedoch gut, wenn man das ganze doch noch erweitern möchte. Soweit ich das bisher beim PU Kessel gesehen habe, hat dieser bereits viele Sensoren (für den Puffer 4: WW, oben, unten, unten Solar). Vorlauf / Rücklauf sollte meines Erachtens auch vorhanden sein.

Jedenfalls werde ich mir da mal den Raspberry Pi besorgen und ein wenig rumspielen. Die Information mit dem knxd ist denke ich auch ganz hilfreich, jedoch versuche ich es erstmal mit dem SH-Image was hier im Board angeboten wird, um später nicht das System wechseln zu müssen.

Falls ich mit den URI - Zuordnungen vom PU weiterhelfen kann, werde ich dies gerne tun. Verbaut ist bei uns folgendes:
PU15 Kessel
HK1
HK2 - FBH
Puffer mit Warmwasser
Solar

Leider bin ich nicht zu oft bei meinen Eltern, so dass eine Auskunft auch mal etwas länger dauern kann.

Vielen Dank schonmal für eure Infos und ich hoffe auf ein tolles Plugin :-)

MfG
Dirk