Plugins programmieren

[callidomus]

Hi,

man eine Logik mit knx_reply bei read request triggern.
Wenn man eine Logik mit knx_listen bindet, dann wir die Logik bei write requests getriggerd.

Bis bald

Marcus

[JuMi2006]

Kurz nochmal zurück ... ich kann den ganzen knx-plugin Änderungen im Moment noch nicht ganz folgen (ich denke halt noch in KNX ).

Kann man jetzt (irgendwie) mit einem Lesetelegramm vom Bus bestimmte Aktionen in anderen Plugins durchführen?

Grüße

[callidomus]

Und was wäre eleganter als die 2-Item Lösung?

Da fällt mir vor dem 0.9 Release nichts ein. :-)

Bis bald

Marcus

[greentux]

Und was wäre eleganter als die 2-Item Lösung?

[JuMi2006]

Ich auch nicht, aber eine Rückmeldung die nur durch Daten aus dem Plugin gefüttert wird finde ich elegant.
So nun beschäftige ich mich mal github um das einzuchecken .... ob das heute noch was wird ...

[callidomus]

Hallo,

bei den ersten Absätzen gibt es keinen wesentlichen Unterschied zwischen den Plugin-Frameworks.

Weiterhin ist da folgendes verankert. Wenn ich einen Parameter setze wird dieser gleich darauf ausgelesen und auf die Rückmeldeadresse der ausgelesene Wert gesendet. So kann ich mir ziemlich sicher sein dass der Parameter der via Visu/KNX/whatever gesetzt wurde auch vom Gerät angenommen wurde. Das sehe quasi in Echtzeit in der Visu.

das könntest Du in Deinem Plugin realisieren, wenn Du zwei separate Items verwendest (eines mit knx_listen für die Schaltaktion, und eines mit knx_send für den Status) und die mit der gleiche ebus_id kombinierst. Bei einer Änderung des Schaltitems liest Du einfach auch den Wert gleich wieder aus und aktualisierst damit das Statusitem.

Ich empfinde das aber als nicht besonders elegant.

Bis bald

Marcus

[callidomus]

Ne, ein Item eine CAN ID. Kein Problem. Aber zwei GAs, wie das immer so ist mit Status GA und Schalt GA.

das ist kein Problem.
(Ich hatte noch einen kleine Bug im KNX-Plugin, der ist jetzt in github gefixed.)

Es kommt eine Änderung eines Item per Schalt GA (knx_listen) rein.
Das Item wird aktualisiert.
Alle Plugins die Änderungen an dem Item verfolgen werden benachrichtigt.
u.A. das KNX-Plugin das an die Status GA (knx_send) den Staus schickt und auch die Visu (visu = yes).

Bis bald

Marcus

[JuMi2006]

Naja ich kann ja mal kurz skizzieren wie dieses Plugin auf dem WireGate(knxd) in Verbindung mit der Visu aussieht.
Bleiben wir bei der Betriebsart (ob I/O oder Auto,Eco,Manu ist egal).

"Fremde" Eingriffe sehe ich wirklich erst nach dem letzten polling, damit meine ich z.B. Befehle an der Wärmepumpe direkt.
Jetzt hab ich aber Busteilnehmer die darauf zugreifen und entsprechende Logiken ausführen, ebenso die Visu. Also die Betriebsart wird durchaus in Abhängigkeit mehrerer Faktoren von unterschiedlichen Geräten beeinflusst.

Die Kommunikation mit der Heizung ist in gewisser Weise schon bidirektional. Dort hat der eibd im Zweifel die Werte in seinem Cache - also der KNX ist das Backend. Ich kann aber gezielt den aktuellsten Wert abfragen in dem ich den Cache des eibd umgehe. Damit bin ich ganz nahe dran an einem "echten" KNX-Gerät.

Weiterhin ist da folgendes verankert. Wenn ich einen Parameter setze wird dieser gleich darauf ausgelesen und auf die Rückmeldeadresse der ausgelesene Wert gesendet. So kann ich mir ziemlich sicher sein dass der Parameter der via Visu/KNX/whatever gesetzt wurde auch vom Gerät angenommen wurde. Das sehe quasi in Echtzeit in der Visu.

[greentux]

Ne, ein Item eine CAN ID. Kein Problem. Aber zwei GAs, wie das immer so ist mit Status GA und Schalt GA.

[callidomus]

Gehts besser?

logisch. Dein Plugin muss halt bei Änderungen einer CAN ID alle Items aktualisieren, die die gleiche CAN ID verwenden. Dann wird die Visu auf jeden Fall unmittelbar aktualisiert.

Wobei wir uns evtl. in einem separaten Thread oder per E-Mail unterhalten sollten wieso man mehrere Item mit der gleichen CAN ID verwenden will/sollte.

Bis bald

Marcus

[greentux]

Ja klarer.

Ich habe im Plugin für meinen Pelletkessel verschiedene GAs für die gleiche CAN ID (Beispiel Ein/Aus) schreiben und lesen.
Ich schreibe also eine 0 auf Ein/Aus und kann das Icon in der Visu erst aktualisieren, wenn das Plugin im nächsten Lauf die 0 wieder geholt hat. Das war defacto beim WG Plugin auch so.
Gehts besser?

[callidomus]

d.h. also das plugin muss oft genug laufen, wenn was von geräten kommt, die man auch noch bedienen kann.
wie ist das, wenn ich per knx das item update, der das auf den 1wire schreibt? wird dann gleichzeitig ein 1wire read gemacht, so das ein update erfolgen könnte?

Prinzipiell hängt das erst einmal vom Plugin ab. Wenn das Plugin bzw. das Backend an das die Anbindung realisiert wird gut ist, dann wird das Item sofort geändert. z.B. bei Asterisk, KNX,CLI, Network, Russound und Visu Plugin.

Die anderen Plugins müssen den Zustand (regelmäßig) pollen, da das Backend keine Notifications bei Änderung unterstützt.

In Deinem Beispiel:
Wenn KNX das Item updated, dann wird der z.B. I/O Output Port direkt geschalten.
Wenn sich ein I/O Input Port ändert, wird das erst beim nächsten Pollen erfasst und das Item aktualisiert.

Deswegen sollte man als Plugin-Entwickler sich bewusst sein wie die Kommunikation mit anzubindenden System aussieht, wer alles Änderungen an dem System machen kann. Wie oft Änderungen passieren usw.
Bei meiner DMX-Installation kann nur SH.py Änderungen vornehmen. Dort muss ich nicht, selbst wenn es meine DMX-Kompententen unterstützen würden, den Status regelmäßig auslesen. Die korrekte Information ist immer in den Items gespeichert.

Ich hoffe es ist jetzt klarer.

Bis bald

Marcus

[greentux]

jetzt haette ich gern ein "reminder for docu" flag.
wieder was gelernt, auch wenn ich es mir schonmal beim code anschauen gedacht hatte.
d.h. also das plugin muss oft genug laufen, wenn was von geräten kommt, die man auch noch bedienen kann.
wie ist das, wenn ich per knx das item update, der das auf den 1wire schreibt? wird dann gleichzeitig ein 1wire read gemacht, so das ein update erfolgen könnte?

(ich bleibe mal bei 1wire, auch wenns mein pelletkessel oder eine WP sein könnte)

[callidomus]

Geht das nicht?

Nein. Das 1-Wire Plugin aktualisiert das Item. Das KNX-Plugin schickt die Änderungen des Items auf den Bus und ermöglicht das lesen des Item Wertes.

Die Plugins untereinander 'kennen' sich nicht.

Bis bald

Marcus

[greentux]

Mirko möchte nur auf ein KNX-Read (aus dem KNX Plugin) mit einer Methode aus seinem Plugin (ebus) antworten. Diese direkte Verknüpfung ist nicht vorgesehen.
Und ich sehe bis jetzt keinen sinnvollen Use Case für diese Feature. Ich lasse mich aber gerne eines besseren belehren.

Vielleicht steh ich auch neben mir. Aber ist das bei 1wire nicht die gleiche Anforderung?
Ein knx read soll den Wert vom 1wire holen und raussenden.
Geht das nicht?