smarthomeNG über ETS konfigurieren

[smai]

Ich würde es auch wegen der benötigten Drittkomponente als separates Plugin belassen.
knx_ets würde mir auch vernünftig erscheinen.

[henfri]

Hallo,

den Ansatz verstehe ich nicht:
Mit dem neuen Plugin brauche ich doch knx_* nicht mehr.

Gruß,
Hendrik

[Onkelandy]

Könnte man das Ganze nicht ins normale knx Plugin einfließen lassen, indem es das Zusatzattribut knx_ets gibt? Etwaige Konkurrenz zwischen dan Attributen könnte dann auch eher abgefangen werden..Also knx_listen und knx_ets mögen sich ja obiger Info zufolge nicht..?

[henfri]

Hallo,

Besseren Namen für das Plugin ausdenken. (Vorschläge?)

knx-ETS
knxprod

Parameter von ETS nutzbar machen. Vielleicht als Item oder so. Keine Ahnung ob man das sinnvoll nutzen kann. Es ist wahrscheinlich einfacher die Werte in die plugin.yaml zu schreiben statt in ETS und dann durch ETS zu setzen

Den Teil habe ich nicht verstanden.

Ich überlege noch, ob es nicht sogar sinnvoll wäre, statt alles auf die Item-Yaml basieren zu lassen, die Objekte in der ETS zu erstellen und zu konfigurieren. Aber ich vermute, das ist zu komplex.

Gruß,
Hendrik

[Onkelandy]

Direkt nach dem Klonen ist noch Folgendes nötig:

cd knxd
git submodule init
git submodule update --recursive

Ich bekomme allerdings mit dem neuesten dev branch von SmarthomeNG folgenden Fehler beim Start (im Programmiermodus):

2019-01-20  15:27:18 ERROR    lib.item          Item WP.Status.Modus: problem running <bound method KNX2.update_item of <plugins.knx2.KNX2 object at 0xaa426a90>>: bytesValue
Traceback (most recent call last):
  File "/usr/local/smarthome/lib/item.py", line 2103, in __update
    method(self, caller, source, dest)
  File "/usr/local/smarthome/plugins/knx2/__init__.py", line 204, in update_item
    groupObject.value = rawValue
ValueError: bytesValue

Das Item:

Modus:
            visu_acl: r
            type: num
            cache: 'true'
            knx_go: 5
            knx_dpt: 5

Der Go Wert ist zufällig bei 5. Beim anderen num Item ist er 6, knx_dpt auch auf 5.
Bei boolschen Items scheint es im Log keine Probleme zu geben.

[thesing]

Das soll keine extra Konfigurationsdatei werden, sondern eher ein Cache. So kann man sicherstellen, dass ein Item jedes mal die gleiche KO-Nummer erhält. Welche KO-Nummern ein Item erhält ist ja eigentlich egal, sie sollte sich nur nicht ändern. Beim fester Vergabe durch ein Attribut muss man dann wieder aufpassen welche Items zwei KO-Nummern brauchen und welche nicht.

Hast du Ideen für einen Namen? knx2 ist nicht so toll.

[smai]

Oder einfach im im items/*.yaml knx_go als Liste zulassen? Eine zusätzliche Konfigurationsdatei würde das ganze IMHO nur verkomplizieren.

[thesing]

Ich werde wohl die Zuordnung von Items zu Kommunikationsobjekten in einem yaml in var speichern. Dann kann ich auch für eine Item zwei Kommunikationsobjekte erzeugen.

[smai]

Für knx_status kann man auch einfach ein neues Item erstellen das dann getriggert wird. Dazu kann man dann auch die neuen Unteritem-Templates nutzen.

Das würde ich möglichst vermeiden, weil es nicht ganz der Strategie von SHNG entspricht.
Aber funktionieren würde es natürlich.

[thesing]

@smai: Die Flags von ETS werden voll unterstützt. Das I-Flag muss ich mal noch implementieren, der Rest geht aber. Für knx_status kann man auch einfach ein neues Item erstellen das dann getriggert wird. Dazu kann man dann auch die neuen Unteritem-Templates nutzen.

@msinn: Du kannst das Problemlos parallel nutzen. Wenn du die gleiche GA einmal direkt als Attribut und einmal per ETS konfigurierst, werden Änderungen von shNG vermutlich doppelt gesendet. Bei unterschiedlichen GAs gibt es lustige Effekte wie. Wenn ein Item in shNG z.B. die GA 1/0/1 hat und per ETS 2/0/1 kriegt, werden die beiden GAs synchron geschaltet: 2/0/1 kommt vom Bus -> mein Plugin setzt Item -> knx-Plugin schickt auf den Bus 1/0/1. Umgekehrt geht es auch.

[Msinn]

Das klingt interessant. Das wäre wohl nicht das knx Plugin für jedermann, aber sicherlich eine Option für SmartHomeNG Nutzer, deren Installation stark auf der KNX Seite liegt und die zur Konfiguration häufig in der ETS unterwegs sind.

Ich kann mir vorstellen, dass wir (nachdem Dein Plugin die Entwicklungsstadien hinter sich hat) das Plugin mit in das Repo aufnehmen.

Eine Frage zum testen: Kann ich das Plugin parallel zum bestehenden Plugin (für andere Items) einsetzen?

[smai]

Klingt sehr interessant.

Wäre es nicht möglich, knx_status als separates KO auf demselben Item zu implementieren? Bzw. allgemein ein separates KO für knx_listen und knx_send ermöglichen.
Das würde auch der Lösung in heutigen KNX-Aktoren entsprechen.

knx_reply müsste am besten über das L-Flag in der ETS gelöst werden, falls möglich.

[thesing]

Hallo allerseits,

eine neues knx-Plugin als Proof-of-Concept gehackt. Bei diesem Plugin wird shNG als KNX-Gerät behandelt. Es bekommt eine eigene PA und die entsprechend konfigurierten Items erhalten eine GA von ETS. Ich habe das bisher nur alpha-getestet. Aber vielleicht möchte jemand experimentieren
Die Kommunikation zum Bus erfolgt über einen KNX-Router. Dies kann auch knxd sein.

Installation python knx-Modul:

#git clone https://github.com/thelsing/knx.git
#cd knx/knxPython
#cmake .
#make
#cp knx.*.so  /usr/local/lib/python<pythonVersion>/dist-packages

Das Plugin ist im Anhang. Die Dateien kommen nach plugins/knx2.
In die plugins.yaml kommt:

knx2:
    class_name: KNX2
    class_path: plugins.knx2

Die Items müssen eine Attribut knx_go erhalten. Dies ist die Nummer des Kommunikationsobjekts in ETS. Die müssen mit 1 startend durchnummeriert werden. Zusätzlich ist noch das Attribut knx_dpt nötig.
Passend zu den Items muss man sich dann noch eine knxprod-Datei erstellen. Das muss man derzeit manuell mit https://github.com/thelsing/CreateKnxProd machen.
Später soll die xml-Datei mal aus den Items generiert werden. Dann muss man die nur noch in das Tool laden und als knxprod-Datei exportieren.

Aktuell muss man den Programmiermodus im Plugin einkommentieren. (__init__.py Zeile 112) Dann startet das Plugin shNG im Programmiermodus. Wenn man eine PA vergeben hat, kann man das wieder auskommentieren. Dass kann man sicher besser über das Backend lösen.

Die von ETS konfigurierten Daten werden in einer Datei "flash.bin" abgelegt. Die Datei wird noch im aktuellen Verzeichnis abgelegt. Daher funktioniert das ganze wahrscheinlich nur, wenn man shNG von der Kommandozeile startet.

Das Plugin kann natürlich viele Sachen nicht, die das normale knx-Plugin kann. Da bei meinem Plugin ein item zu einem Kommunikationsobjekt wird, sind knx_reply und knx_status so nicht möglich. Durch ETS kann ein item nur eine sendende GA und ggf. noch weitere "lauschende" GAs erhalten. Andere Features wie knx_poll könnte man nachbauen.

Ich werde langfristig durch dieses Plugin das knx-Plugin bei mir ersetzen. Besteht hier an dem Plugin Interesse?

Meine weiter Planung:
- flash bin nach var verschieben
- xml für CreateKnxProd generierbar machen lassen.
- knx_go-Attribut überdenken. Das ist eigentlich nur da, um bei der Generierung der xml-Datei dafür zu sorgen, dass Items die gleichen KO-Nummern behalten. Dann sollte es möglich sein einfach die geänderte knxprod-Datei in ETS zu importieren, ohne das smarthomeNG-"Gerät" komplett neu konfigurieren zu müssen. Evtl. kann man aber das gleiche erreichen indem man die xml-Datei unter var ablegt und dort beim Generieren die letze KO-Nummer rausparst.
- Programmiermodus einfacher schaltbar machen.
- Besseren Namen für das Plugin ausdenken. (Vorschläge?)
- Features vom knx-Plugin wieder einbauen (Webinterface und so)
- Parameter von ETS nutzbar machen. Vielleicht als Item oder so. Keine Ahnung ob man das sinnvoll nutzen kann. Es ist wahrscheinlich einfacher die Werte in die plugin.yaml zu schreiben statt in ETS und dann durch ETS zu setzen.

Das ganze wird eine Weile dauern, da ich Python während der Programmierung erst lerne.

Viele Grüße,
Thomas

P.S. Bitte keine Diskussion darüber ob CreateKnxProd legal ist oder nicht. Wer mag kann sich KNX-MT kaufen um ein ETS-Projekt zu erstellen und darüber das Gerät in ETS importieren.