Schnittstellenänderung

Begonnen von Andi291, 12 Dezember 2017, 15:58:41

Vorheriges Thema - Nächstes Thema

JoeALLb

Die Funktion könnte schlicht alle KNX devices aus FHEM und alle neuen Devices aus dem ETS Export anzeigen, dann wäre dein ABER schon kein Problem mehr.
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Andi291

Oder die pflicht, alle GA in der ETS anzulegen. Auch die "leeren" vom raspi.
So mach ich das zumindest. Versteht ja sonst keiner mehr 😉

JoeALLb

Jemand ohne ETS sollte das Modul halt auch nutzen können ;-)
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Andi291

Da sind wir uns denke ich einig. Ein Assistent kann nur ein addon sein.
Definition zu Fuß (wie heute) muß immer möglich bleiben...

Andi291

#19
Aktueller Stand - Ich habe begonnen, die Datenstrukturen im DeviceHash umzubauen.
Den Get-Pfad hab ich schon so umgebaut, wie ich ihn mir im Ziel vorstellen könnte - also Fokus mit Bedienung per GAD-Name. Für den Rüko-Pfad wäre eine Bedienung mit "g<n>" noch möglich.

Feedback?

docm

Hallo Andi,

kurzes Feedback:

Ich finde es super, wenn ein Zugriff bei get und set über Readingnames möglich wird anstelle g1, g2, g3.

Ich finde es nicht so toll, wenn die hash-Struktur verändert wird. Das hat weitreichende Auswirkungen und würde z.B. bei mir im System einigen Änderungsaufwand an Perl-Skripten mit sich bringen.

Viele Grüße
Andreas

docm

Noch ein Wunsch, was man verbessern kann:
Die dpt1 Untertypen haben ja oftmals Werte, die nicht "on" oder "off" heißen, sondern z.B. für dpt1.008 "down" und "up".
Beim Set Kommando würde ich doch in diesem Fall auch lieber "down" angeben wollen anstelle von "on".
Kann man sich natürlich in jedem Einzelfall per eventMap bauen, aber das KNX-Modul kennt ja die zulässigen Werte für den dpt und könnte es daher auch automatisch ohne eventMap machen. Für die Rü-Ko müssten natürlich "on" und "off" weiter akzeptiert werden.
Viele Grüße
Andreas

docm

Hallo Andi291,
sollen wir das ganze mal gemeinsam angehen?
Hier mein Vorschlag, was wir implementieren
set <device> <groupname> <value>
get <device> <groupname> <value>
Möglichkeit, bei "set" die Werte im gleichen Format anzugeben, wie sie im Reading angezeigt werden, also z.B. "up" "down"
Einführung von -put Readings. Wenn vom knx eine GA des Devices gelesen wird und ein -put Reading existiert, wird dieser Wert auf den Bus ausgegeben und nicht state.
set and put  <device> <groupname> <value> -> schreibt den Wert zusätzlich ins -put Reading
attr putCmd -> Perl Code, der aufgerufen wird, wenn von knx aus eine GA ausgelesen wird, bevor das Device antwortet.
ein FHEM-Event, der ausgelöst wird, nachdem vom knx eine GA gelesen wurde und das Device geantwortet hat. 
attr setList -> zur besseren Integration mit Widgets
<groupname> soll case-sensitive werden. Dann brauchen wir aber einen Schalter, um das wieder abzustellen für RüKo. Es könnte nämlich sein, dass Nutzer heute bei den groupnames Groß- und Kleinbuchstaben mischen, die ja dann für die Readings auf Kleinbuchstaben gemappt werden.

Die interne Datenstruktur muss aus Kompatibilitätsgründen gleich bleiben. Wir können sie aber um weitere Elemente ergänzen, die einen effizienteren Zugriff über <groupname> ermöglichen. Ich weiß, dir gefällt dieser Punkt nicht. Aber ich sehe für viele User potenzielle Probleme, wenn wir die alte Datenstruktur nicht mehr unterstützen.

TUL fassen wir jetzt nicht an. Hat zu große Auswirkungen auf bestehende Installationen ohne echten Mehrwert. Man könnte unabhängig von der knx Erweiterung mal überlegen, was es an TUL zu verbessern gibt. Es gibt bei der Konfiguration immer mal wieder Probleme für den Anfänger. Außerdem ist TUL nicht 100% robust, wenn das Netzwerk zum knx-IP-Gateway, oder das Gateway selbst nicht verfügbar ist. Ein Kommando, um die Verbindung zu testen, wäre manchmal ganz hilfreich. Aber lass uns das alles erstmal ausklammern.

Gibt es weitere Themen, die noch mit aufgenommen werden sollen?

Wie machen wir jetzt konkret weiter?

Viele Grüße
Andreas

EIB-Fan

Hallo Andi291,

viele beschriebene Änderungen sehe ich ebenfalls an sinnvoll an.

Einige Änderungen scheinen nicht so innovativ durchgeführt werden zu können, da Kompatibilitätsgründe dagegen sprechen.

Mein Gedanke dazu ist, das bisherige KNX-Modul in der aktuellen Version "einzufrieren" und ein völlig neues Modul z.B. KNXv2 zu programmieren.

Was hälst du davon?

Gruß Jens

docm

Hallo EIB Fan
ich frage mich ernsthaft, welche innovativen Dinge denn im KNX Modul nicht möglich sein sollen.
Eine Neuordnung der internen Datenstruktur hat m.E. hauptsächlich für den Programmierer ästethische Gesichtspunkte. Für den Anwender bringt das nichts.
Ich würde es echt für einen Fehler halten, jetzt ein KNXv2 Modul zu machen und damit die User-Gemeinde abzuhängen, bzw. zu spalten.
Es gibt heute noch genügend Anwender, die das EIB-Modul nutzen. Auch sie haben noch Supportbedarf.

Natürlich ist es aus Sicht des Modulentwicklers immer einfacher, auf der grünen Wiese neu anzufangen, weil man sich dann nicht um die Vergangenheit kümmern muss. Ich glaube aber in diesem Fall hier - ich habe den Code des KNX-Moduls mittlerweile ganz gut verstanden - besteht gar keine Notwendigkeit alles umzuschmeißen und die Aufrechterhaltung der Kompatibilität ist nicht sonderlich schwierig.

Also mein Vorschlag ist, das vorhandene Modul weiterzuentwickeln und kein neues aufzusetzen.
Da würde ich auch sofort mitarbeiten.

Viele Grüße
Andreas

Löwenzahn

Ja, ich kann mich noch gut erinnern, wie ich meine Definitions usw. auf das knx Modul heben musste. :o
Somit wäre es psychologisch wohl nicht so gut wieder ein ganz neues Modul einzuführen?!

Gleichzeitig muss ich gestehen daß mir der Vorschlag mit dem put Reading noch nicht einleucht. Ich habe es zwar verstanden, sehe aber das Szenario ich nicht, wo man das benötigt.
Gruß Löwenzahn

Andi291

Servus!

Die genannten Vorschläge hab ich größtenteils auf dem Schirm.
Einen Teil hab ich schon umgesetzt, hab aber im Moment wenig Zeit. Ostern kann ich mich mal wieder länger konzentrieren.

@docm:
Die Datenstrukturen wird ich dennoch anpacken - da finden wir leider keinen Konsens :-(
Beim zweiten Punkt bin ich bei Dir. Die TUL bleibt, wie sie ist. In einem weiteren Schritt werd ich ein knxd-modul bauen - muss mich dazu mal mit smurfix abstimmen, ob man einige Konfigurationsoptionen nach FHEM hoch holen kann. Das macht es - denke ich - einigen Usern einfacher. Den Schritt heb ich mir aber für kommenden Winter auf :-)

docm

Hallo Andi291 und andere Interessierte,
ich stelle hier mal eine Variante von KNX ins Forum, die folgende Zusatzfunktionalität liefert:
Man kann Readings vom Typ groupname-put bzw putGn erstellen, analog zu den automatisch erstellten -get und -set Readings.
Wenn man das getan hat, kriegt das Modul ein neues Verhalten bezüglich Leseanfragen vom knx Bus.

Das Standardverhalten ist ja, dass das Modul den Wert von state sendet, wenn das Attribut answerReading gesetzt ist. Und zwar egal, welche GA des Moduls gelesen wird.

Das neue Verhalten ist: Wenn die zu dem -put Reading passende GA vom KNX ausgelesen wird, liefert das Modul den Wert des -put Readings an den Bus. Unabhängig vom Attribut answerReading.

Neues und altes Verhalten können auch parallel genutzt werden. Dann liefert das Modul den Wert von state nur dann, wenn zu der angefragten GA kein -put Reading existiert, ansonsten das -put Reading.

Ein weiteres neues Feature in diesem Zusammenhang ist das Attribut putCmd. Diesem kann - analog zu stateCmd - ein Perl Code zugewiesen werden. putCmd wird angesprungen, wenn vom Bus aus ein -put Reading angefordert wird und bevor das -put Reading ausgegeben wird.
Im Perlcode stehen folgende Variablen zur Verfügung
$name - Name des Moduls
$reading - Name des abgerufenen -put Readings
$value - Wert dieses Readings
Wenn innerhalb von putCmd $value ein neuer Wert zugewiesen wird, so wird automatisch das -put Reading aktualisiert und dieser aktualisierte Wert auf den Bus gesendet.

Nach dem Senden eines -put Readings auf den Bus wird ein "KNX response" Event erzeugt, der z.B. über ein notify aufgegriffen werden kann.

Schaut euch das gerne mal an. Über Rückmeldungen würde ich mich freuen.

Viele Grüße
Andreas



JoeALLb

Das ist eine toller Ergänzung, damit kann ich endlich auf die Abfragen meiner Heizungsthermostate nach einem KNX Ausfall ordentlich reagieren... Ein erster schneller Test scheint vielversprechend.

DANKE!
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Andi291

Zitat von: JoeALLb am 10 Februar 2018, 13:23:51
Das ist eine toller Ergänzung, damit kann ich endlich auf die Abfragen meiner Heizungsthermostate nach einem KNX Ausfall ordentlich reagieren... Ein erster schneller Test scheint vielversprechend.

DANKE!
Puh, Mammutergänzung. Danke, kommt auf den Stapel...

Gesendet von meinem XT1580 mit Tapatalk