Grundverständiss GA <-> FHEM-define-Mapping

[crushvx]

Hallo zusammen,

bin stolzer Eigenheimbesitzer, und habe hier eine KNX-Installation mit Raffstore, Rolladen & Licht-Steuerung.

"Intelligenz" (wenn man das so nennen kann; eher Zeitschaltur) habe ich über FHEM umgesetzt.
Die flexibilität im Vergleich zu z.B. openhab ist manchmal schon überwältigend.
Ich frage mich wie Ihr das "mapping" von Gruppenadressen und KO zu fhem-devices vorgenommen habt.

Konkret am Beispiel von Raffstores. (Habe das selbe gedankliche "Problem" jedoch auch mit Lampen die sich z.B. dimmen und schalten lassen; kurz: mit jedem physikalischen Gerät, welches mehr als eine Gruppenadressen die man irgendwie beeinflussen/schalten/dimmen kann)
Ich hab derzeit Raffstores mit den Funktionen:

• Auf/Ab
• Absolute Positionierung
• Absolute Positionierung Lamelle

wie folgt implementiert:

define wz_verschattung_fenster_aufab KNX 1/1/0:DPT1.008
attr wz_verschattung_fenster_aufab room _KNX,Wohnzimmer

define wz_verschattung_fenster_abspos KNX 1/3/0:DPT5.001 1/5/0:DPT5.001
attr wz_verschattung_fenster_abspos room _KNX,Wohnzimmer

define wz_verschattung_fenster_lamelleabspos KNX 1/4/0:DPT5.001 1/6/0:DPT5.001
attr wz_verschattung_fenster_lamelleabspos room _KNX,Wohnzimmer


Wenn ich mir Threads wie diesen oder den hier anschaue, habe ich das Gefühl, dass "alle anderen" eher Versuchen ein fhem-define für ein physikalisches Gerät zu machen.

• Was ist der "FHEM-Weg" es zu tun?
• Womit verbaut man sich auch im Hinblick auf andere Module am wenigsten?
• Welcher Ansatz funktioniert gut mit TABLETUI?
• Übersehe ich etwas?

Beim All-In-One-Ansatz fällt mir auf (ist ja auch in den beiden Threads Thema) dass "State-Management" relativ komplex werden kann. (Bei Raffstores: State 60%) 60% Lammellenposition?! 60% Absolute Position?! Klar alles irgendwie lösbar über user-Readings was weiß ich.
Die Gedanken muss ich mir bei "meinem" Ansatz nicht machen. Dafür sieht z.B. auch das FHEMWEB out of the Box nicht so gut aus. Und fühlt sich irgendwie falsch an.

Danke, wer es bis hier Geschafft hat.
Versteht einer mein Problem?
Habe gesucht, probiert und nix gefunden!

VG,
Christian

[Andi291]

Servus!

Bei mir hat sich folgende Logik am besten im Hirn eingebrannt: jede Sensorgröße hat eine eigene GA. Aktoren lauschen immer nur, und können mehreren GA gehören.
Ich persönlich setzte meine KNX-Installationen so um und logischerweise auch die FHEM-Config.

[EDIT]:
Diese Zustände bündele ich dann wo sinnvoll in einem gemeinsamen Device. Beispiele in der commandref.

[crushvx]

Danke für dein Feedback.

Ich habe jetzt den Abend damit verbracht mal etwas greifbareres auf die Problemstellung zu münzen.

Eine Lampe, die man auch Dimmen kann.
Die hat ein meinem Fall 3 Gruppenadressen.

Welche Lösung würdest du bevorzugen?
Die erste, hier entspricht ein "define" halt einem Physikalischen "Gerät" (Lampe an der Decke).
Die ist nunmal Dimmbar.

Code Auswählen Erweitern


define wz_beleuchtung_esstisch_kombi KNX 3/1/14:DPT5.001:dimmlevel 3/1/46:DPT1:schalter 3/1/78:DPT3:schrittdimmer
attr wz_beleuchtung_esstisch_kombi room _KNX,Wohnzimmer
attr wz_beleuchtung_esstisch_kombi eventMap {\
usr=>{\
'^on'=>'value on g2',\
'^off'=>'value off g2',\
'^value on'=>'value on g2',\
'^value off'=>'value off g2',\
'^value (\d+)'=>'value $1 g1'\
},\
fw=>{\
'^on'=>'value on g2',\
'^off'=>'value off g2',\
'^value on'=>'value on g2',\
'^value off'=>'value off g2',\
'^value (\d+)'=>'value $1 g1'\
}\
}
attr wz_beleuchtung_esstisch_kombi slider 0,1,100
attr wz_beleuchtung_esstisch_kombi webCmd on:off:value
#hack damit der state immer nur den dimmlevel enthaelt.
#on und off von der schalter-GA bringt den Slider durcheinander
attr wz_beleuchtung_esstisch_kombi stateCmd {$state = sprintf("%s", ReadingsVal($name,"dimmlevel-get","undef"))}
attr wz_beleuchtung_esstisch_kombi event-on-change-reading schalter.*,schrittdimmer.*,dimmlevel.*,state


Oder das hier:
Hier entspricht ein "define" eher einer Gruppenadresse. Das eigentliche Gerät ist auf 3 "defines" aufgeteilt.

Code Auswählen Erweitern

define wz_beleuchtung_esstisch_schalter KNX 3/1/46:DPT1
attr wz_beleuchtung_esstisch_schalter userattr room_map structexclude
attr wz_beleuchtung_esstisch_schalter event-on-change-reading state
attr wz_beleuchtung_esstisch_schalter room _KNX,Wohnzimmer


define wz_beleuchtung_esstisch_schrittdimmer KNX 3/1/78:DPT3
attr wz_beleuchtung_esstisch_schrittdimmer room _KNX,Wohnzimmer

define wz_beleuchtung_esstisch_dimmlevel KNX 3/1/14:DPT5.001
attr wz_beleuchtung_esstisch_dimmlevel event-on-change-reading state
attr wz_beleuchtung_esstisch_dimmlevel room _KNX,Wohnzimmer
attr wz_beleuchtung_esstisch_dimmlevel slider 0,1,100
attr wz_beleuchtung_esstisch_dimmlevel webCmd value

Ich habe das Bauchgefühl, dass HomeMatic und andere eher den "physikalisches Gerät" Ansatz fahren. Vielleicht täusche ich mich auch. Welcher style ist für FHEM zu bevorzugen? Vielleicht ist's ja auch total wurscht und ich mach mur umsonst kopp

Gruß!

[crushvx]

[EDIT]:
Diese Zustände bündele ich dann wo sinnvoll in einem gemeinsamen Device. Beispiele in der commandref.

Dem Edit nach zu Urteilen, am Beispiel der Lampe in FHEM, dann eher Hardware-Zentrisch.
Also 1 define, für 1 Lampe an der Decke die man z.B. auch dimmen, schalten, was weiß ich kann!?
Auch wenn das define 3 GA's oder so nutzt.

Gruß!

[crushvx]

Coole Sache das.... 

Hab mir jetzt das Hirn zermatert, viele verschiedene Ansätze ausprobiert und werde jetzt den, ich nenne Ihn mal Hardware-Zentrischen, fahren.
Meint: Wenn ich da draußen ein Raffstore habe, dann strebe ich dazu auch genau ein define im FHEM an. Ob der Raffstore jetzt Lamellen kippen kann, Hoch und Runter fahren kann, egal. -> 1 define.

Das hat IMHO unschlagbare Vorteile wenn man in Notify's auf Events des Geräts reagieren und eine Andere eigenschaft gleichzeitig abprüfen will.
Sowas wie Notify -> Raffstore wurde gekippt. Im Notify dann prüfen "wenn Raffstore im oberen drittel, dann fahre ganz hoch" lässt sich halt nur schwer prüfen, wenn man die Absolute position des Raffstores in nem ganz anderen Define hat.

Den Ausschlaggebenden Punkt hat aber eine Erkenntniss gegeben: Es lassen sich ein oder auch mehrere, von einander, und vom STATE unabhängige Slider erstellen.
Die Slide-Position ist nur von die zusätzlichen Readings (GA's) abhängig.

Kein Springen des Sliders mehr, weil irgendwas ganz kurz STATE überschrieben hat. 
Konkret: Endlich Lamellen Kippen und Absolute Positionierung per Slider. Das sieht dann so aus!

Vielleicht ist das für euch alter Hut... Aber ich hab das soooo in dem Wiki und den Dokus noch nicht gesehen.

Code Auswählen Erweitern


define wz_verschattung_tuer_kombi KNX 1/1/1:DPT1.008:aufab 1/3/1:DPT5.001:abspos 1/5/1:DPT5.001:abspos-state 1/4/1:DPT5.001:lamelleabspos 1/6/1:DPT5.001:lamelleabspos-state
attr wz_verschattung_tuer_kombi room _KNX,Wohnzimmer
attr wz_verschattung_tuer_kombi widgetOverride abspos-state-get:slider,0,5,100 lamelleabspos-state-get:slider,0,5,100
attr wz_verschattung_tuer_kombi webCmd on:off::AbsPos:abspos-state-get::Lamelle-AbsPos:lamelleabspos-state-get
attr wz_verschattung_tuer_kombi eventMap {\
usr=>{\
'^on'=>'value on g2',\
'^off'=>'value off g2',\
'^abspos-state-get (\d+)'=>'value $1 g2',\
'^lamelleabspos-state-get (\d+)'=>'value $1 g4',\
},\
fw=>{\
'^on'=>'on',\
'^off'=>'off',\
'^abspos-state-get (\d+)'=>'abspos-state-get',\
'^lamelleabspos-state-get (\d+)'=>'lamelleabspos-state-get',\
}\
}


Bild habe ich angehängt.

[Andi291]

Dem kann ich nichts mehr hinzufügen