Grundsätzliche Fragen zum KNX-Modul

Begonnen von Löwenzahn, 11 Oktober 2017, 00:32:50

Vorheriges Thema - Nächstes Thema

Löwenzahn

Hallo,

ich möchte kurz vorweg geben, dass ich sehr froh dankbar über das KNX-Modul und deren Weiterentwicklung/Wartung bin.

Meine Fragen sind wirklich gedacht um mehr Verständnis dafür zu bekommen.
(... und dem Umstand geschuldet, das ich es gerade mit der FTUI ans Laufen bekommen möchte.  ???)

Nachdem ein Device angelegt wurde, werde die readings entsprechend erstellt, aber...

Warum ändern sich die Readings so unterschiedlich, je nach dem ob man die groups umbenannt hat oder nicht?
z.B.: setG1 vs. [neuer groupname]-g1
Was hat es mit der unterschiedlichen Großschreibung auf sich? (g vs. G)
Warum werden alle Großbuchstaben über Bord geworfen? In meinem Fall heißt ein dpt "StatusSchalten" und das reading später "statusschalten-get"

Wenn ich die groups in den Definitionen der dtp schon umbenenne, warum kann ich diese Namen dann nicht nutzen?
Eine Definition sieht bei mir zum Beispiel wie folgt aus.:

define EVG03_RGBW_weiss KNX 2/1/23:dpt5.001:Dimmwert 2/1/25:dpt5.001:StatusDimmwert 2/1/22:dpt3:Dimmen 2/1/21:dpt1:Schalten 2/1/24:dpt1:StatusSchalten 2/1/26:dpt1:Fehlerstatus
attr EVG03_RGBW_weiss IODev KNX
attr EVG03_RGBW_weiss eventMap /on g4:AN/off g4:AUS/
attr EVG03_RGBW_weiss slider 0,1,100 g2
attr EVG03_RGBW_weiss webCmd AN:AUS::value


Wenn ich nun schalten möchte geht es nur mit:

set EVG03_RGBW_weiss on g4

aber nicht mit:

set EVG03_RGBW_weiss on Schalten

Warum geht es nicht?

Warum wird ein set-befehl in der folgenden Reihenfolge definiert:
set <name> <on, off> [g<groupnr>]

Wohingegen es beim Homematic anders herum ist: (z.B. beim Dimmer gefunden, gibt es beim Jalousie-Aktor aber ähnlich)

set <name> <Helligkeit> [<Einschaltdauer>] [<Rampenzeit>] -> Schaltet den Aktor ein und dimmt dabei auf <Helligkeit>%,


Ich muss dazusagen, dass ich kein HM-Device habe und es somit auch nicht erschöpfend geprüft habe.
Die Frage ist nur warum diese Änderung, wenn doch das HM-Modul eher da war als das für KNX?
(Das ist eine reine Mutmaßung, die ich nicht belegen kann, weil ich nicht lange genug dabei bin)
... und ein SW Entwickler bin ich auch nicht, als dass ich dieses sofort erkenne.

Wäre es wegen der Kompatibilität zu den anderen Frontends nicht besser eine vergleichbare Syntax/Struktur zu haben?

Danke
Gruß Löwenzahn

Andi291

#1
Servus!

Das gibt ne Menge zu kommentieren :-)


ZitatNachdem ein Device angelegt wurde, werde die readings entsprechend erstellt, aber...
Nein, erst wenn ein entsprechendes Reading erzeugt wurde - also eine Nachricht gesendet oder empfangen wurde.

Zitat
Warum ändern sich die Readings so unterschiedlich, je nach dem ob man die groups umbenannt hat oder nicht?
z.B.: setG1 vs. [neuer groupname]-g1
Verstehe ich nicht. Beispiel, bitte...

ZitatWas hat es mit der unterschiedlichen Großschreibung auf sich? (g vs. G)
Meine willkürliche Festlegung: ich nutze beim Programmieren die ungarische Notation. Das zieht sich halt durch :-)

ZitatWarum werden alle Großbuchstaben über Bord geworfen? In meinem Fall heißt ein dpt "StatusSchalten" und das reading später "statusschalten-get"
Das Modul hat mittlerweile mehrere Dutzend Stringvergleiche. Damit ich hier nicht in den Wald komme, arbeite ich grundsätzlich mit lowercase.
Ja, man könnte drüber nachdenken, das bei der Readingsbenamsung anders zu machen. Hab ich aber nicht :-)

ZitatWenn ich die groups in den Definitionen der dtp schon umbenenne, warum kann ich diese Namen dann nicht nutzen?
Das ist der Architektur und den Plausichecks geschuldet. Zur Laufzeit wird auf Syntax "set <device> <on,off,value,string,raw,rgb> <g-nummer> geprüft. Wenn ich hier die Gruppennamen mit dazu nehme, mache ich den (onehin schon recht komplexen COdeteil) nochmal komplexer.
Denkbar wäre es. Ich hab da auch schon öfter drüber nachgedacht - aber der Aufwand ist immens und so ein richtig geiles Konzept ist mir bisher noch nicht eingefallen...
Hierfür nutze ich persönlich eventmap.

ZitatWarum wird ein set-befehl in der folgenden Reihenfolge definiert...
Weil es im Vorgängermodul ebenso war. Da ich selbst NUR KNX nutze, und die anderen module nicht kenne, habe ich das nie hinterfragt...

Grüße, Andi

P.S.: Für Feature-Requests, die einer Masse an Usern (also nicht nur 1-2 :-)) was bringen, bin ich immer zu haben...







JoeALLb

Hallo Andi,

nur mal als hinweis/Idee
Zitat von: Andi291 am 11 Oktober 2017, 07:40:25
...
Das Modul hat mittlerweile mehrere Dutzend Stringvergleiche. Damit ich hier nicht in den Wald komme, arbeite ich grundsätzlich mit lowercase.
Ja, man könnte drüber nachdenken, das bei der Readingsbenamsung anders zu machen.

Man könnte den mode modifier "ignore case"  für regexp nutzen, also
(?i)
als Beispiel
(?i)(off)|(on)
Dieser Matcht "on ON On"...
Diese Schreibweise würde ggf. auch in der Definition der DPTs im Modul die Lesbarkeit erhöhen -....

sG
Joe
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

Löwenzahn


Für die Änderung/Umbenennung der Readings, möchte ich mit einem Beispiel genauer aufzeigen, was ich meine.
Denn ich kann es nicht nachvollziehen.

Eines meiner Devices sieht so aus:

define EVG03_RGBW_weiss KNX 2/1/23:dpt5.001:Dimmwert 2/1/25:dpt5.001:StatusDimmwert 2/1/22:dpt3:Dimmen 2/1/21:dpt1:Schalten 2/1/24:dpt1:StatusSchalten 2/1/26:dpt1:Fehlerstatus


Die Readings sehen dann so aus:

dimmwert-get
dimmwert-set
last-sender
schalten-get
schalten-set
state
statusdimmwert-get
statusschalten-get


Dem gegenüber steht das Beispiel aus der Commandref:

define lamp1 KNX 0/10/01:dpt1 0/10/02:dpt1

Dabei sehen die Readings dann wie folgt aus :

getG1
setG1
getG2
setG2

etc.



Zitat von: Andi291 am 11 Oktober 2017, 07:40:25
Denkbar wäre es. Ich hab da auch schon öfter drüber nachgedacht - aber der Aufwand ist immens und so ein richtig geiles Konzept ist mir bisher noch nicht eingefallen...
Hierfür nutze ich persönlich eventmap.

Da stellt sich natürlich die Frage, wo der Aufwand höher ist beim einmaligen Umbau im Modul, beim Erstellen und Warten der eventmap.
(Soll nicht frech sein, ich kann es wirklich nicht beurteilen)

Könntest du bitte mal ein Dimmer/ Rollo, wo auch wirklich mehrere Gruppennamen verwendet werden, posten?
Meine komplette Definition hatte ich ganz oben schon gepostet.
Heiß das, ich könnte in meinem Fall auch anstatt von

set EVG03_RGBW_weiss on g4

auch

set EVG03_RGBW_weiss AN

senden?
Das muss ich direkt mal probieren. Aber selbst wenn das geht, wird es bei Gruppennummern mit ,,value" wieder schwierig.

Bei der set-Befehls Reihenfolge kann ich das Argument des Vorgängermoduls zwar verstehen, aber nicht richtig gelten lassen.
Denn selbst bei einem Dummy, (der warscheinlich noch älter ist) wird ein Wert in dem folgenden Format erwartet:

setreading <name> <reading> <value>


Das muss ich direkt mal probieren. Aber selbst wenn das geht, wird es bei Gruppennummern mit ,,value" wieder schwierig.

Zitat von: Andi291 am 11 Oktober 2017, 07:40:25
P.S.: Für Feature-Requests, die einer Masse an Usern (also nicht nur 1-2 :-)) was bringen, bin ich immer zu haben...
Ich bin mir nicht sicher, ob es ein Feature-Request ist. Ich sehe es eher als eine Investition in die Zukunft, in Kompatibilität (Frontends) und ein Schritt in Richtung Homogenität zum Ursprung (FHEM).
Dennoch, wie wäre der richtige Weg um einen solchen Feature-Request einzutüten?

Wie macht ihr das in der Visu? Welches Frontent ist den kompatibel zu dem Syntax des aktuellen KNX-Moduls?

Danke
Gruß Löwenzahn

Andi291

#4
@Joe:
Sehr geil...das hätte ich vor 1,5 Jahren gebraucht :-)
Schönes Teil. Wenn ich das jetzt aber umbaue, funktionieren Readingzugriffe nicht mehr sauber (weil dann ja nicht mehr "gelowercased")...Muss mal überlegen...

@Löwenzahn:

Zitat
Für die Änderung/Umbenennung der Readings, möchte ich mit einem Beispiel genauer aufzeigen, was ich meine.
Denn ich kann es nicht nachvollziehen.

Jetzt weiß ich, was Du meinst. Schau nochmal in die Commandref:
ZitatWenn Ihr einen readingNamen angebt, wird dieser als Basis für die Readings benutzt (z.B. hugo-set, hugo-get for name hugo).

Zitat
Da stellt sich natürlich die Frage, wo der Aufwand höher ist beim einmaligen Umbau im Modul, beim Erstellen und Warten der eventmap.
(Soll nicht frech sein, ich kann es wirklich nicht beurteilen)
Grundsätzlich geb ich Dir recht. Der Input kommt allerdings a bisserl spät :-) Ein einfacher Umbau hätte eine inkompatible Schnittstelle zur Folge - es ginge nur noch 08-15. Alle erweiterten Anwendungen würden streiken.
Ich sag ja, wenn mir ein geiles Konzept einfällt, wo ich
  - rückwärtskompatibel bin
  - die Lesbarkeit des Moduls nicht versaue
  - eine durchgängige Lösung finde
investier ich gerne nochmal Zeit...
Für 80% der Anwendungsfälle nutze ich übrigens Vererbung. Dazu nehme ich das Modul "Archetype" her.

ZitatDas muss ich direkt mal probieren. Aber selbst wenn das geht, wird es bei Gruppennummern mit ,,value" wieder schwierig.
Nö. Geht genauso.

ZitatDennoch, wie wäre der richtige Weg um einen solchen Feature-Request einzutüten?
Theoretisch ganz einfach:
Überzeuge mich, warum ich für ein schöner WOhnen-Thema eine inkompatible Änderung durchführen soll, und mir den Unmut einer unbekannten Menge User zuziehe...
In der Vergangenheit hat immer geholfen, wenn 2-3 Handvoll Leute bereit waren die Schelte mit mir gemeinsam einzustecken...


ZitatWie macht ihr das in der Visu? Welches Frontent ist den kompatibel zu dem Syntax des aktuellen KNX-Moduls?
Weiß nicht. Ich nutze NUR das Webfrontend. Die TabletUI geht wohl auch - aber mit Abstrichen - weißt ja :-)

Hier zwei komplexe Beispiele von mir. Mehr pack ich nicht rein, weil das dann kein Schwein mehr lesen kann:
1. Raumtemperaturregelung. Das Device selbst ist nur ein Dummy. Die Hauptsache passiert in der ReadingsGroup:
define rtr_eg_flur KNX 8/1/33:dpt9.001:sollwertv 8/1/32:dpt5:status 8/1/34:dpt1:heizbetrieb 8/1/35:dpt5.001:stellgrroh 8/1/36:dpt1:stellgr 8/1/37:dpt9.001:solltemp 8/1/38:dpt9.001:isttemp
attr rtr_eg_flur IODev knxd
attr rtr_eg_flur group Raumtemperaturregelung
attr rtr_eg_flur room Dummies
attr rtr_eg_flur stateCmd {$state = sprintf("%s", ReadingsVal($name,"sollwertv-get","undef"));;}
attr rtr_eg_flur webCmd :

define rtr_grp_eg_flur readingsGroup rtr_eg_flur:.*[status|sollwertv|solltemp|isttemp|stellgrroh|stellgr]-get
attr rtr_grp_eg_flur commands {'sollwertv-get' => 'value:slider,-2.4,0.2,2.4,1'}
attr rtr_grp_eg_flur group Raumtemperaturregelung
attr rtr_grp_eg_flur mapping {\
'status-get' => 'Status', 'sollwertv-get' => 'Sollwertverschiebung', 'solltemp-get' => 'Solltemperatur',\
'isttemp-get' => 'Isttemperatur', 'stellgrroh-get' => 'Stellgr&oumlsse', 'stellgr-get' => 'Status Aktor'\
}
attr rtr_grp_eg_flur noheading 1
attr rtr_grp_eg_flur nolinks 1
attr rtr_grp_eg_flur notime 1
attr rtr_grp_eg_flur room Flur_EG
attr rtr_grp_eg_flur valueFormat {\
  if ($READING =~ /status-get/) {\
      my $tempVal = $VALUE;;\
      if ($VALUE & 0x20) {$tempVal = 'heizen';;} else {$tempVal = 'kuehlen'};;\
      if ($VALUE & 0x1) {$tempVal = $tempVal . '-komfort';;}\
      elsif ($VALUE & 0x2) {$tempVal = $tempVal . '-standby';;}\
      elsif ($VALUE & 0x4) {$tempVal = $tempVal . '-nacht';;}\
      return $tempVal;;\
  } else {return $VALUE;;}\
}


2. Lichtsteuerung.Nach dem Einschalten geht der Aktor direkt auf Szene 1. Zum Einschalten brauchts allerdings eine separate GA. Deshalb erfolgt eine Synchronisierung über Notifies.
#----------------------------Wohnzimmer------------------------------
define licht_wohnzimmer_haupt KNX 3/5/4:dpt5:szene 3/5/0:dpt1.001:steuern 3/5/2:dpt1.001:status
attr licht_wohnzimmer_haupt IODev knxd
attr licht_wohnzimmer_haupt alias Decke
attr licht_wohnzimmer_haupt devStateIcon (on)|([Ee]in)|(^[1-9]\d*.*):general_an:Aus (off)|([Aa]us)|(^0.*):general_aus:Ein
attr licht_wohnzimmer_haupt eventMap /on g2:Ein/off g2:Aus/
attr licht_wohnzimmer_haupt group Beleuchtung
attr licht_wohnzimmer_haupt icon light_ceiling_light
attr licht_wohnzimmer_haupt room Wohnzimmer
attr licht_wohnzimmer_haupt slider 0,1,8
attr licht_wohnzimmer_haupt stateRegex /((status)|(steuern))-get:on/1/ /((status)|(steuern))-get:off/0/ /szene-get.*// /.*set://
attr licht_wohnzimmer_haupt webCmd value:Ein:Aus

define Notify_licht_wohnzimmer_off notify licht_wohnzimmer_haupt:szene-set:.0.* {fhem ("set licht_wohnzimmer_haupt off g2") if (not(ReadingsVal("licht_wohnzimmer_haupt", "status-get", "") =~ m/off/))}
attr Notify_licht_wohnzimmer_off group Events
attr Notify_licht_wohnzimmer_off room Wohnzimmer
define Notify_licht_wohnzimmer_on notify licht_wohnzimmer_haupt:szene-set:.[1-8].* {fhem ("set licht_wohnzimmer_haupt on g2") if (not(ReadingsVal("licht_wohnzimmer_haupt", "status-get", "") =~ m/on/))}
attr Notify_licht_wohnzimmer_on group Events
attr Notify_licht_wohnzimmer_on room Wohnzimmer

Löwenzahn

Danke für deine beiden Beispiele, die muss ich erstmal verdauen.

Zitat von: Andi291 am 11 Oktober 2017, 18:14:23
Jetzt weiß ich, was Du meinst. Schau nochmal in die Commandref:
Jetzt habe ich diese Stelle in der Commandref gefunden, aber ich hätte schwören können, die war gestern noch nicht da.  ???
Auch wenn das noch nicht so richtig das "warum" erklärt.

Ich habe es probiert und du hattest Recht zB: (hätte mich auch überrascht, wenn nicht  :) )

set EVG03_RGBW_weiss AN

funktioniert auch.

Zitat von: Andi291 am 11 Oktober 2017, 18:14:23
Für 80% der Anwendungsfälle nutze ich übrigens Vererbung. Dazu nehme ich das Modul "Archetype" her.
Das schaue ich mir mal genauer an.

Dennoch muss ich nochmal nachhaken. Mit dem major update von EIB auf KNX hast du schon einmal die Nutzer (mich incl. ) zum nacharbeiten überredet. Also werde ich gerne versuchen, dir bei den drei Voraussetzungen zu helfen ...
Wobei ich bei der Rückwärtskompatibilität eher etwas gleichgültiger bin, wenn es dafür viel kompatibler zum Rest des FHEM-Kosmos wird. ... und die Lesbarkeit wäre doch auf jeden Fall viel besser.

Vielleicht sollte "man" einen separaten Beitrag eröffnen und die Nutzer mal nach ihren Bedürfnissen oder Ideen und Lösungsvorschlägen (siehe Joe) fragen? So könnte Community auch funktionieren.  8)

Zitat von: Andi291 am 11 Oktober 2017, 18:14:23
Ein einfacher Umbau hätte eine inkompatible Schnittstelle zur Folge - es ginge nur noch 08-15. Alle erweiterten Anwendungen würden streiken.
Mit "inkompatibel" meist du hier auch Rückwärstkompatibel?
Was sind erweiterte Anwendungen?
Kannst du kurz erläutern, was eine durchgängige Lösung ist und was nicht?
Durchgängig im Sinne der Verwendung von "raw, value, rgb, etc. oder im Sinne "Verwendung wie andere H/W Module"

Weißt du eigentlich, wieviele Nutzer du mit deinem Modul hast? Kannst du das irgendeiner user-Statistik entnehmen? Ich kann mir kaum vorstellen, dass die alle im Webfrontend bleiben. :-X
Ich denke auch das es für viele Nutzer mehr als nur "Schöner-Wohnen" ist, wenn man sich nur anschaut wie oft die Heizungsanbindung oder Kameraintegration diskutiert werden.  ;D

Gruß Löwenzahn

Andi291

Abend!

ZitatWeißt du eigentlich, wieviele Nutzer du mit deinem Modul hast? Kannst du das irgendeiner user-Statistik entnehmen? Ich kann mir kaum vorstellen, dass die alle im Webfrontend bleiben. :-X
Ich denke auch das es für viele Nutzer mehr als nur "Schöner-Wohnen" ist, wenn man sich nur anschaut wie oft die Heizungsanbindung oder Kameraintegration diskutiert werden.  ;D
Nein, die Info geht mir komplett ab.

ZitatDennoch muss ich nochmal nachhaken. Mit dem major update von EIB auf KNX hast du schon einmal die Nutzer (mich incl. ) zum nacharbeiten überredet. Also werde ich gerne versuchen, dir bei den drei Voraussetzungen zu helfen ...
Wobei ich bei der Rückwärtskompatibilität eher etwas gleichgültiger bin, wenn es dafür viel kompatibler zum Rest des FHEM-Kosmos wird. ... und die Lesbarkeit wäre doch auf jeden Fall viel besser.
Da hab ich mir viel Zeit und Kommunikation genommen - trotzdem waren etliche verprellt. Das hab ich mir gemerkt.
Persönlich und inhaltlich bin ich voll Deiner Meinung...

ZitatMit "inkompatibel" meist du hier auch Rückwärstkompatibel?
Korrekt - Crash nach dem Update.

ZitatWas sind erweiterte Anwendungen?
Kannst du kurz erläutern, was eine durchgängige Lösung ist und was nicht?
Durchgängig im Sinne der Verwendung von "raw, value, rgb, etc. oder im Sinne "Verwendung wie andere H/W Module"
Erweitert ist zum Beispiel jede Installation, die ein "set xxx value 4711 g2" verwendet.
Ich würde die Schlüsselworte mittlerweile komplett weglassen und on-the-fly anhand der DPT plausibilisieren. Dann auch gleich mit "set [readingname] 4711".
Beim Design des KNX-Moduls war ich dazu aber (weder FHEM- noch Perl-) technisch dazu in der Lage.
Mittlerweile würd ich es mir auf den ersten Blick zutrauen...

ZitatVielleicht sollte "man" einen separaten Beitrag eröffnen und die Nutzer mal nach ihren Bedürfnissen oder Ideen und Lösungsvorschlägen (siehe Joe) fragen? So könnte Community auch funktionieren.  8)
Bin ich voll dafür!
Wenn mir jemand (Du? :-)) diese Sondierungsarbeit abnehmen würde, und verschiedene, ausreichend konkrete Wünsche samt Lösungsrichtungen aufzeigt, wäre sicher deutlich mehr möglich.


Im stillen Kämmerlein bin ich halt in meinem Mikrokosmos unterwegs und bau mir primär die Lösungen, die ich brauche (natürlich so abstrakt, dass nach Möglichkeit alle was davon haben).
Nim zum Beispiel die Geschichte mit der TabletUI. Da geht sicher noch wahnsinnig viel. Aber ich kenne das aktuell nicht (und will es aus Gründen der Freizeit auch aktuell nicht kennen lernen).
Hier würd mir ein "Vorfilter" / Übersetzer durchaus helfen...

Grüße, Andi