alle HM-PB-6-WM55 Tasten in einem notify unterbringen

[Navigator]

Mahlziet. Als frisch gebackender HM Komponenten Nutzer, frage ich mich gerade ob ich alle 6 Tasten und deren Bedingungen in einem Notify unterbringen kann. Also nach dem Schema:

Code Auswählen Erweitern

HM_Device.* {if (Value ("HM_Device_Btn_1") eq"Short.*"){....}elsif .........}. Aber die Channels sind ja kein Value/STATE, also gehts so nicht. Gibts da noch eine Möglichkeit. Für die 6 Tasten mit Long/Short hätte ich sonst 12 Notifys.

[Puschel74]

Hallo,

hab auch grad einen vor mir liegen.

Du kannst doch auf die Channel wie auf eigene Device triggern.
Somit kannst du auch den state auswerten.
Btn1:Short etc

Zumindest lassen sich die Channel bequem ohne das Device einzeln in Räume verschieben.
Daher meine Vermutung - ich werd mich morgen mal an meine notify machen.

Grüße

[justme1968]

du musst doch nur die regex so gestalten das sie auf alle channels matched. die information welcher channel und welches event es war steckt in $EVENT und den $EVNTPART variablen. das mit Value oder ReadingsVal von hand abzufragen ist nicht sinnvoll und effizient.

statt den ganzen code direkt ins notify zu schreiben steck es besser in eine sub in ein 99_myUtils file und ruf diese aus dem notify nur auf.

aber warum hast du etwas gegen mehre notifys? falls es dir um die effizienz geht: notifys die nur genau auf ein device matchen sind effizienter als ein notify das auf viele matched. da wird FHEM intern optimiert.

wenn es dir um die übersichtlichkeit geht: auch hier hilft der 99_myUtils ansatz. die eine sub kannst du aus mehr als einem notify aufrufen.

sind die aktionen für die einzelnen buttons wirklich so ähnlich das das zusammenfassen sinnvoll ist? 6 kleine einfache übersichtliche und unabhängige notifys viel übersichtlicher als ein ein if/elsif wust und auf dauer sehr viel wartbarer.

das zusammenfassen ist eigentlich nur sinnvoll wenn das gleiche device gesteuert werden soll. und auch dann nicht immer.

gruß
  andre

[Navigator]

Hallo zusammen, ja eigentlich hatte ich Perfomancegründe. Als ich mit FHEM begonnen hatte, war ich von meiner alten Anlage gewohnt die Scripte, vergleichbar mit den Notifys, die damals nicht endlos verfügbar waren mit möglichst viel Code "vollzustopfen" . Natürlich hab ich mir damit auch eine Art der Übersichtlichkeit geschaffen, die ich gewohnt war. Irgendwie schwirrt bei mir der Gedanke im Kopf herum, warum auch immer, daß mit mehr Notify´s das System mit der Zeit langsamer in der Abarbeitung wird, egal ob da jetzt viel oder wenig Code drin steht.

Das ich die Channel hin und herschieben kann, kommt mir aber gelegen. Danke.

@Puschel

...sind das auch deine ersten Gehversuche mit HM? Das ohne ein extra virtuelles Device nicht so einfach eine Rückmeldung seitens FHEM an den Aktor erfolgt hatte ich mir bis heute so nicht träumen lassen...

[justme1968]

weniger notifys sind besser. aber notifys genau auf ein device sind besser als notifys die auf mehr als ein device reagieren.

du brauchst kein extra virtuelles device. du kannst eine vccu dafür verwesten. das ist der 'neuere' ansatz. 

gruß
  andre

[Navigator]

Danke... ich belese mich mal dazu. 

[Puschel74]

Hallo,

ich hab schon einige HM-Aktoren im Einsatz.
Das ist jetzt mein erster Sender.

Ich verwende zum anlernen immer gerne die Wiki-Seite dazu:
http://www.fhemwiki.de/wiki/Kategorie:HomeMatic_Components
Einfach den bp-6-wm anklicken - dort wird das auch mit der Rückmeldung erklärt (aber noch ohne vccu sondern mit virtuellen Kanälen).
Es gibt dort aber auch bereits einen Eintrag für die VCCU.
Aber ich denke das kennst du alles schon.

Grüße

[Navigator]

Ich bin jetzt den Weg von Betateilchen gegangen und hab statt des virtuellen Aktors, direkt mit HMUSB gepeert und mache auf Anraten den Vergleich noch vor der Einleitung des Notifys.
Der Taster meldete folgende Events im Monitor.

2014-11-01 16:01:11 CUL_HM Taster_Kueche battery: ok
2014-11-01 16:01:11 CUL_HM Taster_Kueche Taster_Kueche_Btn_06 Short (to HMusb)
2014-11-01 16:01:11 CUL_HM Taster_Kueche CMDs_done
2014-11-01 16:01:11 CUL_HM Taster_Kueche_Btn_06 Short (to HMusb)
2014-11-01 16:01:11 CUL_HM Taster_Kueche_Btn_06 trigger: Short_7

Da der HM 55 den kurzen Tastendruck Short in gleich zwei Events meldet, reicht hier ein einfaches :Short:* nicht um doppelte Ausführung zu verhindern.
Mein Notify wird jetzt foldendermaßen eingeleitet.

Code Auswählen Erweitern



Taster_Kueche_Btn_06:Short.\(.* set blabla ON .... eigentlich sollte hier nur der Trigger auf das Event "Short (to HMusb) anspringen, sehe ich das richtig?

Ist diese Lösung sinnvoll oder gibt es hier noch effizentere Möglichkeiten?
Ich bin mir noch unsicher wegen dem Eintrag des Device unabhängig vom Channel im Eventmonitor.

Grüße

[martinp876]

Ist diese Lösung sinnvoll oder gibt es hier noch effizentere Möglichkeiten?

denke schon - leicht getunt

Weg von Betateilchen gegangen und hab statt des virtuellen Aktors, direkt mit HMUSB gepeert

baue eine vccu ein und richte Kanäle ein. Das peeren mit dem IO ist von Ablauf identisch, von der Darstellung allerdigns unsauber. Faktisch peerst du  mit einem Kanal der Zentrale. Ohne vccu kann man das nicht darstellen.
Ein IO hat eigentlich keine ID (akademische Frage). Die ID hat immer die Zentrale. Genauso hat ein IO keine Kanäle, die Zentrale schon.

mit vccu kannst du mehrere IOs verwalten
du kannst auch mehrere vccus einrichten, wenn du willst.

Das peering kannst du stehen lassen. wenn du es noch einmal ausliest und die vccu existiert sollte alles automatisch eingerichtet werden.

Das notify kannst du dann fest machen wo du willst, am vccu kanal oder am Sensor

[Navigator]

Die VCCU hatte ich schon mal testweise. Nur habe ich dann den Glaubenskrieg von Dir und Betateilchen in einem Betrag verfolgt und war mir dann unsicher welchen Weg ich einschlage.  In welche Richtung geht die Entwicklung von HM und FHEM diesbezüglich wirklich? Es ist immer schwer sich von alten Lasten zu befreien, wenn man einmal sich in einer Sache festgefahren hat.

[martinp876]

man kann auf eine vccu verzichten. Ich würde das nicht. Eigentlich würde ich diese vorschreiben (oder automatisch installieren).
Ich glaube, betateilchen hat eh schon eine.

Eine VCCU schadet erst einmal nicht - evtl mag man sie nicht. Sie hat mehrere Funktionen
- bündeln der Info einer Zentrale. IOs können das nicht, da sie nicht Teil von CUL_HM sind.
- sichtbar machen der peerings zwischen Zentrale (channels) und devices. Ein IO kann das, aber nur mies. Es werden keine Kanäle unterstützt, bei mehreren Kanälen ist es nicht darstellbar, bei mehreren IOs sowieso nicht
- Ersatzschalten von IOs bei Ausfall.

=> eine VCCU ersetzt kein IO sie steuert es teilweise. Wovor hast du also angst?

Im Grunde habe ich das jetzt gefühlt schon 178mal erklärt und die Funktion in Wiki beschrieben. Wer jetzt nicht will oder irgend einen Angst hat soll darauf verzichten.
CUL_HM funktionen gibt es ausschließlich auf VCCU - auf IO geht das garnicht.