Idee: Integration von Wiregate Plugins

[henfri]

Hallo,

was wäre eigentlich nötig, um WG-Plugins auch in der SH.py Umgebung laufen zu lassen? Das wäre ja interessant, da man so das Rad hier und dort nicht neu erfinden muss.

Ich weiß: perl vs. python. Aber es gibt ja in einigen Programmiersprachen auch die Möglichkeit, andere einzubinden. Ich weiß nicht, wie das bei Python und Perl aussieht.

Ansonsten wäre die Frage allgemeiner: WG-Plugins Standalone laufen zu lassen.

Wie ich es überblicke, sind es nur drei Funktionen:
knx_write
knx_read
subscribe_ga

Aber bevor ich weiter denke:
Was denkt ihr?

Gruß,
Hendrik

[callidomus]

Hallo Hendrik,

Was denkt ihr?

ich denke es ist einfacher das Rad neu zu erfinden. Der eigentliche Wert der Plugins ist nicht das (Perl-) Plugin an sich sondern die darin umgesetzte Logik.
Die Logik in einer anderen Sprache zu schreiben ist relativ einfach. IMHO sind viele "Hilfskonstrukte" in den WG-Plugins bei SH.py-Logiken nicht notwendig und dadurch sind diese einfacher aufgebaut und geschrieben.

Eine Alternative ist vllt. die Kopplung über KNX.

Bis bald

Marcus

[henfri]

Hallo,

ich kann das nicht beurteilen.
Aber es gibt schon recht große Plugins, wie z.B. das ETA Plugin. Das neu zu schreiben wäre schon großer Aufwand, denke ich.

Die Kopplung über KNX wäre ja der Plan-B, den ich genannt habe.
Dafür wäre eine "Stanalone"-Implementierung von knx_write, knx_read und subscribe_ga nötig. Dies könnte man komplett Standalone machen, oder eben SH.py die Arbeit machen lassen (decode der GAs, lauschen auf den GAs, etc).

Wie auch immer. Nur ein Gedanke. Können kann ich es eh nicht und momentan brauche ich es auch nicht. Später vielleicht.

Gruß,
Hendrik

[callidomus]

Hallo Hendrik,

Aber es gibt schon recht große Plugins, wie z.B. das ETA Plugin. Das neu zu schreiben wäre schon großer Aufwand, denke ich.

das ist ein gutes Beispiel. Dazu kann greentux evtl. was sagen was den Aufwand betrifft, er ist gerade daran es zu migrieren.

Gefühlt sind 70% des Plugins Mapping-Tabellen das CAN-Adressen. Die eigentliche Kommunikation mit dem Anlage sind nur wenige Zeilen. Aber das ist nur mein Eindruck von außen.

Bis bald

Marcus

[greentux]

Ja, in der Tat war das auch mein erster Gedanke. Das ETA Plugin standalone laufen zu lassen. Allerdings geht dann erstmal nur die Leserichtung, da ja der Trigger zum Schreiben fehlt (also wenns nur via crontab läuft, was ja zum lesen, anzeigen und rrd schreiben reicht).

Ich machs neu, stehe momentan allerdings etwas auf der Stelle. Ich kann vom ETA lesen, schreiben. Aber für smarthome.py Integration habe ich mir grad nen Kollegen geangelt

Andere Sachen, wie das Mörder-Logicplugin brauchts hier gar nicht.
Und nachdem ich nun das Python Buch für Anfänger duchhabe muss ich sagen: coole Sprache, interessiert mich.

[JuMi2006]

Also ich baue gerade den wiregated um nachdem mir bei smathome.py einfach ein HowTo von Usern für User fehlt und ich natürlich von Python auch keinen Plan habe.

Ich bin jetzt soweit dass er Standalone arbeitet und von allen Zusatzfunktionen befreit ist. Die WireGate Plugins kann man damit also auf jeder x-beliebigen Kiste laufen lassen.

Ich verfolge die Entwicklung von smarthome.py trotzdem ein wenig, aber schrecke momentan vor der "neuen" Sprache noch zurück.


Grüße

[greentux]

Was haste denn dem wiregated alles entzogen?
ein wg-light?

[JuMi2006]

... quasi.

Was weg ist:
- VPN-Geschichten
- alles was mit Busmastern oder 1-Wire zu tun hatte
- sämtliche hardcoded Pfade
- natürlich die gesamte Webmin Geschichte

Was noch da ist:
- EIB-Log (incl. optionaler eibga.conf)
- Plugin System (incl. subscribe)

Was neu ist:
- erweiterte config incl. der Pfade zu den RRDs, Logs, Plugins, configs (eibga/daemon)
- der RRD-Patch
- Speicherüberwachung (memleaks) erfolgt intern ... löst aber das Problem nicht .. ab 6.5 MB Speicherbedarf gehts los, Neustartgrenze ist konfigurierbar


Fertig bin ich damit aber noch nicht. Ich hoffe zum Ende der Woche soweit zu sein. Entstanden ist es aus dem eBus-Plugin-Thread. Vielleicht bekommt der ebus-Daemon dort noch ne KNX-Schnittstelle aber das ist noch nicht sicher. Da mir zu smarthome wie gesagt der Einstieg nicht geglückt ist war das der nächst bessere Weg um meine Heizung später mittels Raspberry auf den Bus zu bekommen.
Smarthome.py ist da aber immer noch im Visier wobei der "wiregated-light" sicherlich weniger Abhängigkeiten erzeugt für eine so simple Nutzung. Zeitkritisch ist da nichts.
Bei mir heißt der übrigens knx1.pl


Eigentlich nur ein bisschen abgespeckt und etwas konfigurierbarer (fürchterliches Wort) gemacht.

Grüße