Plugins programmieren

[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

[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

[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

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

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

[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

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

[Robert]

Angenommen man würde [...]

crontab -e

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

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

[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

[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

[2ndsky]

Plugins programmieren

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

[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

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

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

Grüße