Plugins programmieren

[callidomus]

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.

Nein, das ist komplett anders.
Die Zustände werden in den Items gespeichert. Welche Plugins angebunden sind spielt keine Rolle und man braucht dazu auch keine Logik die das macht.

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.

Bis gleich

Marcus

[JuMi2006]

Ja, soweit korrekt.

Ich hatte gestern zwar einen disconnect/connect eingebaut, aber nicht geprüft ob er auch stattfindet...fand er nicht....jetzt schon und es läuft sauber durch, daher erstmal kein Handlungsbedarf.

Ja im Prinzip möchte ich eine Verknüpfung zwischen zwei Plugins. Falls das doch mal eingebaut wird dann ist das ja schnell geändert. Das Plugin hier war meine "Übungsaufgabe" ... der Pi in der Wärmepumpe mit knxd und ebusd wird sicherlich bleiben. Auf ein anderes Gerät werde ich in Zukunft wohl verzichten können.

[callidomus]

Nach einem Neustart sind erstmal grundsätzlich keine Daten für die items vorhanden, woher auch.

wenn man das Item-Attribute `cache = yes` setzt, wird es mit dem letzten bekannten Wert initialisiert.

Jetzt kann aber jeder der in diesem Moment einen Datensatz braucht diesen auch bekommen, da das Plugin die Daten in "Echtzeit" abruft.

Zeitlicher Ablauf:
1) Man beendet SH.py
2) Man startet SH.py
3) Das Plugin liest die aktuellen Werte ein.

Das Problem existiert also wenn sich Daten zwischen 1 und 2 ändern und der Benutzer vor 3 die Daten abfragt?
Wie oft startet ein Benutzer SH.py neu und ist dann unmittelbar (innerhalb weniger Sekunden) auf die aktuellen Daten angewiesen?

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.

Full Ack.

Ich möchte nur lieber über das eigentlich Problem diskutieren und nicht über das Feature. Bei SH.py dreht sich, bewusst, nicht alles um KNX.
Ich möchte z.B. meine Visu-Kommunikation nicht über den KNX-Bus abwickeln.

Bis bald

Marcus

[callidomus]

Hallo Robert,

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

das ist unfair. Wenn sich das Wiregate so deterministisch verhalten würde, wäre es schon gefixt.

Bis bald

Marcus

[greentux]

Mit Verlaub Robert. Das stimmt nicht ganz.

root@wiregate497:~# uptime
 20:20:11 up 2 days,  6:49,  1 user,  load average: 2.58, 1.92, 1.57

[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?

[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]

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]

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]

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]

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]

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

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

[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

[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