[HMCCU] HmIPW-FIO6 / HmIPW-DRI32 - Probleme mit Taster/Kontakt/Schalter Option

Begonnen von Depechem, 09 Juni 2022, 13:46:44

Vorheriges Thema - Nächstes Thema

Depechem

Hallo zusammen,
seit einer ganzen Weile nutze ich FHEM mit HMCCU und meinen Wired Modulen.

Ich habe seit Anfang an irgendwie Probleme beim richtigen Einrichten von Taster/Kontakt/Schalter Modulen.
Ich hoffe ihr könnt mir irgendwie helfen.

Das habe ich vor (Aber noch keine saubere Lösung gefunden)

- am Eingangsmodul habe ich einen Taster angeschlossen (in der CCU als "Taster" vorbelegt)
- über HMCCU in FHEM als HMCCUCHN eingebunden
   attr event-on-change-reading.*
   attr ccureadingfilter (STATE|1.PRESS_LONG|PRESS_LONG|1.PRESS_SHORT|PRESS_SHORT)

- wenn der Taster gedrückt wird, wird in FHEM "PRESS-SHORT" kurz akualisiert (Reading ist immer eine "1")

Aber um einen Schalter/Taster ordentlich und sauber in FHEM auszuwerten (z.b.: in DOIF`s oder notify`s) benötige ich eine richtige Auswertung des Readings > also Beispielsweise wenn Taster nicht gedrückt ein "false" und wenn er gedrückt wird ein kurzes "true"

Wenn das Reding immer nur getriggert wird kommt es heirbei zu Fehlauswertungen un DOIFs und co.

Das gleiche habe ich mit "Schalter" statt "Taster" versucht > in FHEM wird es aber gleich ausgewertet.
Wenn ich die Funktion "Kontakt" einstelle, bekomme ich wie gewünscht das reading entweder als "closed" oder "open" nur habe ich hierbei das Problem das man den Taster beim "HmIPW-FIO6" mindestens 4 Sec. gedrückt halten muss um von "closed" zu "open" zu  closed" > wenn man den Taster nur kurz drückt wechselt das Reading von "closed" zu "open" und erst wieder zu "closed" wenn wieder kurz gedrückt wird (Das Problem besteht auch direkt in der CCU mit dem Statuswechsel.


Habt ihr eine Idee wie ich einen ganz normalen Tastendruck der CCU ordnungsgemäß in fhem auswerten könnte?

Hier ein Beispiel warum die einfache Aktualisierung des Readings zu Fehlern in FHEM kommen.
Türklingel ist mit einem Tastereingang verbunden. > in fhem wird über notify der Tastereingang getriggert
Klingelsensor_Thomas_Hoftor:PRESS_SHORT:.*
set WandTabletBadThomas ttsMsg Klingel Hoftor;


Beispiel: wenn hier der Schalter "Klingel_Thomas_bekommt_alles_Schalter" aktiviert wird, wird das notify getriggert da ich nur "state" auswerte und nicht state:on.
(([Klingelsensor_1_Eltern_Haustuer:state] or [Klingelsensor_Eltern_Hoftor:state]) and [Klingel_Thomas_bekommt_alles_Schalter] eq "on")((set Klingelmodul_Thomas datapoint 1.SUBMIT 1,1,8,6); set Pushover_Pushnachrichten msg 'Klingel' 'von Eltern' 'iPhoneThomas' 0 'pushover')


Nun wird aber durch Neustart von FHEM oder der HMCCU das Reading automatisch getriggert. Somit werden die notifys fehlerhaft ausgelöst


Die einzige Lösung die mit bisher eingefallen ist, ist in der CCU den Taster mit einem Virtuellen Taster in einem Programm zu verknüpfen. Dieses Programm schaltet den virtuellen Taster für 5 Sekunden ein und dann wieder aus, Diesen virtuellen Taster binde ich in FHEM ein. Nur kann dies doch keine Lösung sein bei 2x 32 Eingangsmodulen und 10x HmIPW-FIO6 mit je 6 Tastern!

Viele Grüße Thomas
RaspberryPi2 / FHEM / 3 Wand-Tablets mit Tablet UI / HM USB / verschiedene HM-Aktoren / JeeLink USB für WS1600 und mehrere LaCrosse Sensoren / HEOS ...

zap

Die CCU kennt (u.a.) die Rollen KEY und SWITCH. Ein Lichtschalter hat mindestens eine SWITCH Rolle. In einer SWITCH-Rolle gibt es den Datenpunkt STATE vom Typ BOOL, d.h. dieser kann true oder false werden.

Ein Taster hingegen hat eine Rolle KEY in der es z.B. einen Datenpunkt PRESS_SHORT gibt. Dieser hat den Typ ACTION, der wiederum nur 1 bzw. true sein kann. Daher siehst Du in FHEM immer eine 1, wenn der Taster gedrückt wird. Es gibt den Zustand "unpressed" in der CCU nicht.

Du musst also FHEM seitig eine Lösung finden.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

Depechem

Zitat von: zap am 09 Juni 2022, 14:17:55
Die CCU kennt (u.a.) die Rollen KEY und SWITCH. Ein Lichtschalter hat mindestens eine SWITCH Rolle. In einer SWITCH-Rolle gibt es den Datenpunkt STATE vom Typ BOOL, d.h. dieser kann true oder false werden.

Ein Taster hingegen hat eine Rolle KEY in der es z.B. einen Datenpunkt PRESS_SHORT gibt. Dieser hat den Typ ACTION, der wiederum nur 1 bzw. true sein kann. Daher siehst Du in FHEM immer eine 1, wenn der Taster gedrückt wird. Es gibt den Zustand "unpressed" in der CCU nicht.

Du musst also FHEM seitig eine Lösung finden.

Ok Danke zap, hast du einen Lösungsansatz für mich, oder ein Beispiel wie ich mein Problem sinnvoll lösen könnte
RaspberryPi2 / FHEM / 3 Wand-Tablets mit Tablet UI / HM USB / verschiedene HM-Aktoren / JeeLink USB für WS1600 und mehrere LaCrosse Sensoren / HEOS ...

zap

Ich glaube, ich habe Dein Problem noch nicht richtig verstanden.

Du musst für PRESS_SHORT ein event-on-update-reading einstellen. Sonst bekommst Du nur eine Event beim 1. Tastendruck, da die CCU für PRESS_SHORT immer eine 1 schickt.

Wenn dann jemand die Klingel drückt, sollte genau 1 Event generiert werden, das Du in FHEM auswerten kannst. Beim nächsten Klingeln wieder ein neues Event.




2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

Depechem

Zitat von: zap am 09 Juni 2022, 14:57:58
Ich glaube, ich habe Dein Problem noch nicht richtig verstanden.

Du musst für PRESS_SHORT ein event-on-update-reading einstellen. Sonst bekommst Du nur eine Event beim 1. Tastendruck, da die CCU für PRESS_SHORT immer eine 1 schickt.

Wenn dann jemand die Klingel drückt, sollte genau 1 Event generiert werden, das Du in FHEM auswerten kannst. Beim nächsten Klingeln wieder ein neues Event.






Ja da hast du recht und das habe ich auch so gemacht nur nochmal ein Beispiel bei dem es Probleme gibt.

Ich habe ein umfangreiches DOIF (hier nur ein Auszug daraus)

##cmd_1 - Badezimmer_Licht_komplett_an - per großen Taster
([Bad_Taster_Eingangstuer_1:PRESS_SHORT] eq "1") and [Bad_Licht_Spiegelschrank:state] eq "off")) (set Bad_Licht_Spiegelschrank on)
##cmd_2 - Badezimmer_Licht_komplett_aus - per großen Taster
([Bad_Taster_Eingangstuer_1:PRESS_SHORT] eq "1") and [Bad_Licht_Spiegelschrank:state] eq "on")) (set Bad_Licht_Spiegelschrank off)

weitere cmd`s folgen.

Nun triggert das DOIF wenn ich "Bad_Taster_Eingangstuer" drücke, nur erkennt das DOIF in fhem selbst nie ob der Taster wirklich gedrückt wurde. Also kann man das nie unterscheiden.
Da das DOIF ([Bad_Taster_Eingangstuer_1:PRESS_SHORT] eq "1") in jedem cmd "wahr" ist


RaspberryPi2 / FHEM / 3 Wand-Tablets mit Tablet UI / HM USB / verschiedene HM-Aktoren / JeeLink USB für WS1600 und mehrere LaCrosse Sensoren / HEOS ...

Depechem

oder das andere Beispiel bei der Klingel.

Ein Klingeltaster betätigt ein Klingelmodul. Nun habe ich einen Dummyschalter erstellt, wenn ich diesen aktiviere, wird so lang dieser aktiv ist eine weitere Klingel mit angesteuert.
Das DOIF für die Aktivierung sieht so aus:
(([Klingelsensor_1_Eltern_Haustuer:state] or [Klingelsensor_Eltern_Hoftor:state]) and [Klingel_Thomas_bekommt_alles_Schalter] eq "on")((set Klingelmodul_Thomas datapoint 1.SUBMIT 1,1,8,6); set Pushover_Pushnachrichten msg 'Klingel' 'von Eltern' 'iPhoneThomas' 0 'pushover')

wenn ich nun den Dummy aktiviere wird ja automatisch dieser Befehl im DOIF getriggert Klingel_Thomas_bekommt_alles_Schalter] eq "on" und es wird das gesamte oben stehende DOIF aktiviert und die Klingel geht an, soll sie ja aber nur wenn geklingelt wird und nicht schon wenn nur der Dummy für die Aktivierung der zweiten Klingel angeschalten wird.
Hier ist das gleiche Problem durch [Klingelsensor_1_Eltern_Haustuer:state] kann das DOIF nicht unterscheiden ob der Taster betätigt wurde oder nicht.


Dies ist ein großes Problem. Oder hast du eine Idee wie man sein DOIF nur aktivieren kann wenn zu der zeit wirklich das Redaing des Tasters aktualisiert wird.


Ich hoffe du versteht was ich damit meine
RaspberryPi2 / FHEM / 3 Wand-Tablets mit Tablet UI / HM USB / verschiedene HM-Aktoren / JeeLink USB für WS1600 und mehrere LaCrosse Sensoren / HEOS ...

zap

ok, von DOIF habe ich leider keine Ahnung. Ein "Notify" würde vermutlich nur greifen, wenn eine Taste gedrückt wird. Vermutlich gibt es diese Möglichkeit auch bei DOIF.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

SamNitro

Da muss man mit einem kleinen Trick arbeiten... Bin mir jetzt aber nicht 100% sicher wie das damals war, bin aktuell auf der Arbeit und kann nicht testen.

1. Man erstellt eine Systemvariable gibt dem einen Logikwert wahr=pressed falsch=released
2. Verknüpft den Taster nur einmal, kann auch nur vorübergehend sein (und hierbei bin ich mir nicht mehr sicher ob direkt oder als Programm)

Danach sollte er korrekt angezeigt werden.
(Intel-Nuc Proxmox) (Homematic) (EnOcean) (CUL868) (CUL433) (Zigbee2MQTT) (ESP8266) (Echo) (DUOFERN)

fuppking

Hallo,

ich hab GANZ GENAU das gleiche PROBLEM! ich habe an einem HMIPW_DRI16 mehrer Taster angeschlossen sowie 1x in der CCU als Contannt hinterlegen schalter.

Ich würde auch gern einen Klingelschalter realisieren nur ich bekomme keinerlei
brauchbare readings bei Tastendruck. Die PRESS_SHORT bleibt reaktionslos und wird nur unregelmäsig aktualisiert. Bei Tastendruck bekomme ich folgende readings:
   
     ..aktivity `=   alive
     ..devstate  =  ok
      ..hmstate  =  false

diese Werte ändern sich auch nie. Ich bin glaub alle attr´s durch.

Aber bei meinem Contaktschalter ändert sicher das Reading von PRESS_SHORT auch nicht aber das reading "STATUS" von frue auf false

ich glaub das muss ein bug im modul sein.

ich hba nun schon seit Frühjar keine wirkliche Klingel. es wäre
schön wenn es irgendwie eine Löschung gib die uns mal mitzuteilen.

vieln Dank

Miami

Ich habe einen Wandtaster HMIP-WRC2. Über eine HmIP Direktverknüpfung schaltet der das "normale" Licht ein und aus.
Mit langen Druck auf "Ein" soll auch eine LED Leiste mit angehen, die über FHEM angesprochen wird, und mit einem Druck auf "aus" soll immer (also egal ob SHORT oder LONG) auch die LED Leiste mit ausgeschaltet werden.

Um diesen Wandtaster nun auch in FHEM auszuwerten, habe ich in der CCU (bei mir eine Raspimatic) ein Programm angelegt, siehe Bild. Das ist notwendig, damit der Wandtaster seinen Zustand an die CCU meldet, denn nur dann sieht FHEM den Wandtaster. (Vermutlich kann man es nach der ersten Nutzung auch wieder löschen, weiter Info dazu im Homematic-Forum Homematic-Forum).

In der fhem.cfg steht dann bei mir:
#Lichttaster im Wohnzimmer
define Wohnzimmer_Lichttaster_aus HMCCUCHN 00001234567890:1
attr Wohnzimmer_Lichttaster_aus event-on-update-reading PRESS.*
attr Wohnzimmer_Lichttaster_aus stateFormat devstate

define Wohnzimmer_Lichttaster_an HMCCUCHN 00001234567890:2
attr Wohnzimmer_Lichttaster_an event-on-update-reading PRESS.*
attr Wohnzimmer_Lichttaster_an stateFormat devstate

#LED_Fenster im Wohnzimmer schalten
define Wohnzimmer_Lichttaster_an_long_nf notify Wohnzimmer_Lichttaster_an:PRESS_LONG_START:.* set LED_Fenster on
define Wohnzimmer_Lichttaster_aus_short_nf notify Wohnzimmer_Lichttaster_aus:PRESS.* set LED_Fenster off

Funktioniert bei mir prima.

Ruft doch mal den Event monitor auf und filtet nach dem Wandtaster (bzw. das Device, dass ihr nutz).
Da sieht man dann gut, was so gemeldet wird. So sieht das bei mir aus (Ein, Aus, Ein-lang-gedrückt, Aus-lang gedrückt):
ZitatEvents (Filter: .*Wohnzimmer_Lichttaster.*)   FHEM log   ResetCreate/Modify Device

2022-11-25 15:24:00 HMCCUCHN Wohnzimmer_Lichttaster_an PRESS_SHORT: pressed
2022-11-25 15:24:02 HMCCUCHN Wohnzimmer_Lichttaster_aus PRESS_SHORT: pressed
2022-11-25 15:24:08 HMCCUCHN Wohnzimmer_Lichttaster_an PRESS_LONG: pressed
2022-11-25 15:24:08 HMCCUCHN Wohnzimmer_Lichttaster_an PRESS_LONG_START: 1
2022-11-25 15:24:08 HMCCUCHN Wohnzimmer_Lichttaster_an PRESS_LONG: pressed
2022-11-25 15:24:08 HMCCUCHN Wohnzimmer_Lichttaster_an PRESS_LONG: pressed
2022-11-25 15:24:09 HMCCUCHN Wohnzimmer_Lichttaster_an PRESS_LONG: pressed
2022-11-25 15:24:09 HMCCUCHN Wohnzimmer_Lichttaster_an PRESS_LONG: pressed
2022-11-25 15:24:09 HMCCUCHN Wohnzimmer_Lichttaster_an PRESS_LONG: pressed
2022-11-25 15:24:09 HMCCUCHN Wohnzimmer_Lichttaster_an PRESS_LONG: pressed
2022-11-25 15:24:10 HMCCUCHN Wohnzimmer_Lichttaster_an PRESS_LONG_RELEASE: 1
2022-11-25 15:24:12 HMCCUCHN Wohnzimmer_Lichttaster_aus PRESS_LONG: pressed
2022-11-25 15:24:12 HMCCUCHN Wohnzimmer_Lichttaster_aus PRESS_LONG_START: 1
2022-11-25 15:24:12 HMCCUCHN Wohnzimmer_Lichttaster_aus PRESS_LONG: pressed
2022-11-25 15:24:12 HMCCUCHN Wohnzimmer_Lichttaster_aus PRESS_LONG: pressed
2022-11-25 15:24:12 HMCCUCHN Wohnzimmer_Lichttaster_aus PRESS_LONG: pressed
2022-11-25 15:24:13 HMCCUCHN Wohnzimmer_Lichttaster_aus PRESS_LONG: pressed
2022-11-25 15:24:13 HMCCUCHN Wohnzimmer_Lichttaster_aus PRESS_LONG: pressed
2022-11-25 15:24:13 HMCCUCHN Wohnzimmer_Lichttaster_aus PRESS_LONG_RELEASE: 1

fuppking

Hallo,

danke für die ausführliche Beschreibung. ich habe in meinen Readings von dem DRI16 Modul keinelei PRESS... stehen. In den Readings vom Bewegungsmelder HMIPW ha stehen die Press... Readings drinn und es funktioniert auch wie du es mit dem Wandtaster gemacht hast.f
Leider aber nicht bei dem  DRI16  modul. Wenn ich auf die Tast drücke hab ich im Eventmonitor nur  state activity devstatus ohne zusandsänderung drinne stehen.
Ich kann diese Events aber nicht als Trigger nehmen da Sie sich zyklich immer mal neu Laden.

Wenn mir noch jemand Helfen könnte wäre super...

Liebe Grüße