Plugins programmieren

[JuMi2006]

Also noch mal langsam sonst komm ich durcheinander

Ich versuche mal das Konzept zu beschreiben was am Ende rauskommen soll.

Das Plugin soll auf bestimmte GAs hören und dann deren Wert verarbeiten (über TCP senden).
Das Plugin läuft regelmäßig von allein und fragt bestimmte Werte per TCP ab. Diese Werte werden bei den bestimmten items hinterlegt und bei Änderung auf den Bus gesendet.
Kommt ein Lesetelegramm für ein bestimmtes item so soll der entsprechende Wert aktuell über TCP ausgelesen werden und auf den Bus gesendet werden (das ist noch nicht implementiert, habe ich aber in meinem WireGate-Plugin so gelöst.)

Im aktuellen Beispiel sind die 8/6/x-Adressen die Rückmeldeadressen. Wenn ich einen Wert ändern will (vom Taster oder per Visu) sende ich diesen auf 8/7/x.
Das Plugin muss also auf die 8/7/x Adressen hören und Rückmeldungen/Status an 8/6/x senden. Das Plugin ist also ein klassischer Aktor.

Nun komm ich mit der Bezeichnung der knx_xxxx hier nicht ganz klar.

Vergleiche ich das Plugin/smarthome.py/Visu mit einem Schalter und Aktor so wird doch beim Drücken eines Tasters folgendes ausgelöst:
- vom Schalter wird ein Telegramm an den Aktor gesendet (GA = knx_send)
- der Aktor sendet darauf hin eine Rückmeldung (GA = knx_listen)

Also sende ich via smarthome.py einen Wert auf das item, so sendet das KNX-Plugin diesen Wert an die Adresse knx_send.
Damit ich auch über den aktuellen Status immer auf dem laufenden bin trage ich bei item zusätzlich die Adresse knx_listen ein. Auf dieser höre ich auf Statusänderungen und aktualisiere ggf. das item.
Wenn ich nun Leseanfragen beantworten möchte muss mein item auch über knx_reply verfügen.

Für mich stellt sich die Frage ob sich smarthome.py jetzt eher als Taster oder Aktor versteht.

Edit: Das mit den DPTs ist mir klar. Das war einfach die Faulheit da ich über DPT 1.001 auch 1,2,3,4,5 übertragen bekomme, das muss ich mal ändern.

[callidomus]

Kommt ein Lesetelegramm für ein bestimmtes item so soll der entsprechende Wert aktuell über TCP ausgelesen werden und auf den Bus gesendet werden (das ist noch nicht implementiert, habe ich aber in meinem WireGate-Plugin so gelöst.)

Das kann das Plugin nicht so einfach, es gibt einen Weg dazu später mehr.

Damit ich auch über den aktuellen Status immer auf dem laufenden bin trage ich bei item zusätzlich die Adresse knx_listen ein. Auf dieser höre ich auf Statusänderungen und aktualisiere ggf. das item....

Für mich stellt sich die Frage ob sich smarthome.py jetzt eher als Taster oder Aktor versteht.

Wer ist den für den aktuellen Status verantwortlich? Ich denke in diesem Fall SH.py und ist daher Aktor. Das wiederspricht dann aber dem Satz mit knx_listen. Das listen dient zu Steuerung (durch Sensoren).

knx_reply ist im Endeffekt mit dem Read-Flag von KNX vergleichbar.

Edit: Das mit den DPTs ist mir klar. Das war einfach die Faulheit da ich über DPT 1.001 auch 1,2,3,4,5 übertragen bekomme, das muss ich mal ändern.

Das KNX-Plugin liefert für DPT 1 nur True/False zurück.

Bis bald

Marcus

[JuMi2006]

o.k. also gehe ich mal Funktion für Funktion durch.

Das Plugin soll auf bestimmte GAs hören und dann deren Wert verarbeiten (über TCP senden).

Welches Keyword muss jetzt die GA haben damit das Plugin aufgerufen wird?

knx_ listen, send oder reply ?

Danke für deine Geduld, aber python und smarthome.py ist erst der dritte Tag für mich.

EDIT: Erledigt, jetzt hab ich es

[ebusd]
    [[mode]]
        type = num
        knx_dpt = 5
        knx_send = 8/6/100
        knx_listen = 8/7/100
        knx_reply = 8/6/100
        comment = Heizkreis - Betriebsart
        ebusd_type = "set"
        ebusd_cmd = "cir2 mode"

[JuMi2006]

So nun haben wir ja die erste Hürde geschafft

knx_send = die Rückmeldeadresse auf die der Wert vom "Aktor" gesendet wird
knx_listen = die Adresse auf die der "Aktor" hört
knx_reply = die Rückmeldeadresse auf der "Aktor" mit einem read mit response antwortet


Also wie geht das jetzt mit der Reaktion im Plugin auf read-requests ?

[callidomus]

Du lernst schnell dazu, junger Padawan.

Also wie geht das jetzt mit der Reaktion im Plugin auf read-requests ?

Dazu musst Du eine kleine Logik schreiben, die auf knx_reply hört. Die kann dann mit groupwrite(ga, data, dpt) einen Wert senden.

Aber ich denke das ist eigentlich nicht nötig. Ich würde lieber die Polling-Frequenz des Plugins erhöhen.

Bis bald

Marcus

[JuMi2006]

Da muss ich noch mal ne Nacht drüber schlafen ... geht das wirklich nicht eleganter?

Grüße

[callidomus]

... geht das wirklich nicht eleganter?

noch eleganter?

Aber mal im Ernst, wie ist denn der Anwendungsfall?
Du möchtest mit der Cometvisu den akutellen Status auslesen? Der ist doch immer in SH.py, oder ändert jemand anderes auch noch den Status ohne KNX? Dann würde der Wert erst beim nächsten Pollen erfasst und an die Visu weitergegeben.

Bis bald

Marcus

[JuMi2006]

Ich brauch hier doch noch mal Hilfe.
Nach einer gewissen Zeit (20 Minuten) bringt das Plugin die Werte durcheinander

Bei start richtig:

Items:
======
ebusd
ebusd.mode = 3
ebusd.temp_out = 13.25
ebusd.boiler = 45.1875

später falsch:

Items:
======
ebusd
ebusd.mode = 13.25
ebusd.temp_out = 45.1875
ebusd.boiler = 3

Auf der Remote-Seite werden die Werte richtig gesendet. Ich habe auch schon probiert die Verbindung nach jedem Lesen wieder zu schließen und neu zu öffnen ... funktioniert, bringt aber keine Besserung. Hier fehlt mir jetzt total der Ansatz das zu debuggen.

Die Antwort stimmt einfach nicht mit dem überein was mir das andere System (glaubhaft) liefert. Da ich das gleiche Prozedere schon in Perl programmiert habe muss der Fehler irgendwo in meinem Plugin versteckt sein. Ich vermute mal im "answer = self._sock.recv(256)" liegt der Fehler ... wobei auch 1024 o.ä. nichts verbessern.

Grüße

[2ndsky]

Plugins programmieren

Ich bau für sowas einfach ein logger.debug(...) mit dem Empfangenen Wert ein.

[Robert]

Ich brauch hier doch noch mal Hilfe.
Nach einer gewissen Zeit (20 Minuten) bringt das Plugin die Werte durcheinander

Hi!

Hatte ich bei meinem Plugin auch: Beitrag: Plugin zum Lesen von SMA-Wechselrichtern (Sunnyboy 5000TL-21 getestet)

Da wird irgendwo eine Nachricht verschütt gehen oder (eher!) sendet deine Gegenstation eine (unaufgeforderte) Nachricht zwischendurch und bringt dein "Senden-Empfangen-Senden-..." durcheinander.

Hier solltest du, bevor du eine Anfrage machst, mit einem nicht-blockenden (socket.settimeout(0.0)) recv den gesamten Empfangspuffer leeren, um dann deine Anfrage abzuschicken.

Grüße
Robert

[JuMi2006]

Ich trenne derzeit jedes mal die Verbindung, mal sehen ob das auch hilft.

Debug-Messages hatte ich mir natürlich gesetzt, daher auch meine Vermutung dass es am Empfangspuffer liegt.

Deine Methode teste ich danach mal ... klingt eleganter

P.S.:
Du bist aber auch schnell

[greentux]

Da muss ich noch mal ne Nacht drüber schlafen ... geht das wirklich nicht eleganter?

Grüße

Ich glaube, ich verstehe was Du meinst.
Angenommen man würde ein wiregate nachbilden wollen, braucht man neben 1wire und knx in den items immer noch eine Logik, die das hin und herschickt.
Das ist hier wohl nicht anders.

[Robert]

Angenommen man würde [...]

crontab -e

 
0 0 * * * shutdown -r now > dev/null

[JuMi2006]

Der Vorteil ist eigentlich mal ganz einfach erklärt:

Nach einem Neustart sind erstmal grundsätzlich keine Daten für die items vorhanden, woher auch. Jetzt kann aber jeder der in diesem Moment einen Datensatz braucht diesen auch bekommen, da das Plugin die Daten in "Echtzeit" abruft. So hätte ich es eben gerne auch im Plugin gelöst...wenn es aus Desing-Gründen nicht geht dann ist das eben so. Auf dem Pi mit knxd klappt das jedenfalls genial, ich muss damit ja auch nicht unbedingt nach sh.py umziehen ...

Dennoch sollte man doch Plugins möglichst so abbilden dass sie keine weitere Logik mehr benötigen. Für den späteren Nutzer ist es jedenfalls bequemer.

[callidomus]

Ich brauch hier doch noch mal Hilfe.
Nach einer gewissen Zeit (20 Minuten) bringt das Plugin die Werte durcheinander

Wie lange ist denn die cycle time und wie lange braucht Deine Methode refresh_attributes für einen Durchlauf?

Ich vermute hier eine Überschneidung.

Du sagts Du baust die Verbindung immer neu auf. Wie machst Du das? Mit self._sock als Socket-Object?
Das teilst sich das Plugin und damit alle Methodenaufrufe.

SH.py ist Multithreaded. Du solltet in Deiner _request Methode ein locking einbauen. Schau Dir mal threading.Lock() an.

Hoffe das hilft.

Bis gleich

Marcus