Probleme mit fakeShutterContact

Begonnen von patlabor, 15 Dezember 2019, 13:10:35

Vorheriges Thema - Nächstes Thema

patlabor

Hallo zusammen,

ich versuche gerade durch die Idee mit dem fakeShutterContact durchzusteigen.
Wo genau kann ich das denn einstellen.

Habe mir für Testzwecke einen Raum mit einem Wandthermostat und 2 Heizkörperthermostaten rausgesucht.
An den beiden Heizkörperthermostaten gibt es kein setter für windowOpenTemperature, den gibt es nur am Wandthermostat, umgekert gibt es am Wandthermostat kein windowOpenDuration, das gibt es nur an den Heizkörpern.

Vermutlich muss ich daher das Wandthermostat mit dem fakeShutterContact assoziieren, aber wo setzte ich den dann auf open bzw closed?
Laut Wiki soll das ja über das CULMAX gehen, dort habe ich allerdings nur broadcasttime und pairmode als setter.

Irgendwie blicke ich hier jetzt nicht mehr durch, was mit wem assoziiert werden muss und wo was "gesettet" werden soll.


Wzut

Zitat von: patlabor am 15 Dezember 2019, 13:10:35
Vermutlich muss ich daher das Wandthermostat mit dem fakeShutterContact assoziieren, aber wo setzte ich den dann auf open bzw closed?
Laut Wiki soll das ja über das CULMAX gehen, dort habe ich allerdings nur broadcasttime und pairmode als setter.
a. richtig , das WT muss in Zukunft auf den Fake hören

b. fakeSC ist z.Z. nicht als Vorlage in FHEM Web , gib es einfach zum Testen in der Kommandozeile ein, später kommt es ja dann dann eh in ein notify oder DOIF
(du kannst aber auch meine angepinnte Testversion nehmen da ist fakeSC als FHEM Web Kommando drin)

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

patlabor

Super,

danke für den Hinweis.
Jetzt klappt das Ganze auch.
Ich wollte das Ganze erst mal "trocken" per FHEM Web durchspielen, bevor ich mich hinsetzt und mir ein passendes DOIF bastele.
Bin natürlich nicht auf die Idee gekommen das es einen Befehl geben könnte, der sich nicht auch direkt über die Webschnittstelle ausführen lässt.
Naja, man lernt eben nie aus.

fhemHolli

Helau, ich versuche derzeit meine vorhandenen Homematic Fensterdrehgriff Schalter (sind einfach schöner und unauffälliger als die Max Shutter Klötze) mit meinen Max WTs zu verheiraten.

Das mit dem Fake Shutter Kontakt funktioniert richtig gut solange ich das nur für einen Raum mache, kommt in weiterer Raum dazu schaltet der Fake Shutter Kontakt immer auch den WT aus dem anderen Raum. Dabei werden die unterschiedlichen groupid's missachtet.

Ich habe das mit den Fhem Standard Modulen und den neuen Beta Modulen von Wzut ausprobiert, das Verhalten ist bei Beiden gleich.
Da ich ja alle WTs mit den fakeShutterContact assozieren muss und dieser immer die peerID 222222 hat, wäre das schon eine Erklärung warum immer alle assozierten WTs reagieren.
Einfach gedacht könnten mehrere Fake Shutter Kontakte (mit unterschiedlicher peerID) das Problem lösen.
Evtl. mache ich ja auch in meiner Konfiguration was falsch.
Eigentlich würde ich gerne den fakeShutterContact für 6 Räume nutzen, wäre eine tolle und durchgängige Konfiguration.

Falls Interesse besteht, liefere ich gerne Logs und führe Tests aus.
TS-453mini, QTS 4.3.6, fhem-5.9
MaxCun, HMLAN (das Original), Broadlink RM2
Homematic & Max Heizungs Gedöns
Intertechno Licht / Steckdosen

Wzut

Das Grundproblem ist mir bekannt -> zwei alte MAX WTs bekommen bei mir auch via HM Fensterkontakt ihr open/close und ja beide reagieren, egal welches Fenster ich aufmache. Ich hatte das Problem etwas nach hinten auf der ToDo geschoben, da ich dachte andere Dinge seien ersteinmal wichtiger ( Multi CUL ) Ich habe bei mir inzwischen einiges geändert und habe ein neues MAX Device eingeführt : virtuellerShutterContact
Der macht fast das gleiche wie der fakeSC aber mit der Ausnahme der jeder ein echtes MAX Device ist und auch seine eigene sechstellge HEX Adresse hat (MAXID).
Ich will die Version jetzt noch nicht als Beta hochladen, da ich noch ein paar Kleinigkeiten gerade ziehen muß, also bitte noch etwas Gedult.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

fhemHolli

 :) Wunderbar, das sind doch gute Nachrichten, zum einen habe ich mich nicht zu blöd angestellt und viel wichtiger, da ist schon eine Lösung in der Pipeline.
Das wird alle freuen, die Fremdkontakte mit ihrem Max System kreuzen wollen.
Da wartet man doch gerne.
TS-453mini, QTS 4.3.6, fhem-5.9
MaxCun, HMLAN (das Original), Broadlink RM2
Homematic & Max Heizungs Gedöns
Intertechno Licht / Steckdosen

Wzut

#6
Wer mal Lust & Laune auf einen Test mit der neuen Funktion des virtuellen Fensterkontakts statt des fakeSC hat :
Ich hänge die drei Dateien hier an und nicht im Beta Thread da es mir jetzt um einen Test dieser neuen Funktion geht.
Zum Ablauf , die drei Dateien nach opt/FHEM kopieren und FHEM danach unbedingt neu starten ( Wichtig wegen der neuen MaxCommon.pm )

1. zuerst legt man sich ein neues MAX Device an , Bsp :
define VFK_1 MAX virtualShutterContact 987654
wobei der Name und die sechstellige MaxID natürlich frei gewählt werden dürfen , sie müssen halt nur eindeutig sein. Wichtig ist nur der neue Typ "virtualShutterContact" da nur dieser die entsprechenden Funktionen mitbringt.
2. mit dem set Kommando "set VFK_1 groupid X" dem Device eine GroupID geben die zu den Geräten (HT / WT) passt die er später steuern soll.
3. ggf bei den HTs/WTs die GroupID ebenfalls anpassen. Die GroupID ist in der Original ELV Firmware auf dem Cube der Raum und daher extrem wichtig das Geräte die zusammen gehören auch die gleiche GroupID haben !
4. Nun jedem betroffenem HT / WT der Gruppe mit set associate den viruellen Kontakt bekannt machen ( er sollte in der DropDown nun zur Verfügung stehen )
Das Ganze ist einseitig , d.h. am viruellen Kontakt wird nichts assoziiert, denn er "kennt" seine Partner über die groupid.

5. Jetzt kann direkt am viruellen Kontakt mit set open / close der neue Status verschickt werden.

WICHTIG :
Diese Version bringt zwei neue Attribute mit :
sendMode : peers,group,Broadcast (default Broadcast) -> bestimmt wie der virtuelle Fensterkontakt mit den HTs/WTs "spricht"
Mode Broadcast : der VFK sendet nur ein Telegramm mit Ziel alle ohne auf Rückmeldungen zu warten.
Vorteil : verbraucht wenig Credits wenn mehr als ein HT/WT im gleichen Raum ist
Nachteill : wenn eines der Geräte das Telegramm nicht empfängt erfolgt keine Reaktion / Meldung

Mode group : sendet an jedes Mitglied seiner Gruppe ein eigenes Telegramm
Vorteil : erfolgt vom Ziel Gerät kein ACK wird das Telegramm bis zu zweimal wiederholt.
Nachteil : verbraucht mehr Credits als Broadcast, ggf. unnötige Wiederholungen falls nicht alle Mitglieder der Gruppe assoziert sind.

Mode peers : sendet nur an "bekannte" Geräte, d.h. Komma getrennte Liste der Zieladressen am neuen Attribut peers
Vorteil : Flexibler als Mode group z.B. senden nur an WT in der Gruppe
Nachteil :  verbraucht mehr Credits als Broadcast

Wenn nur ein Partner HT oder WT vorhanden ist sind die beiden Modes peers & group vom Verhalten eigentlich identisch und der Verbrauch an Creadits ist auch nicht größer als beim Mode Broadcast.

Das Device benötigt kein extra notify/DOIF sondern unterstützt wie die Thermostate das Attribut externalSensor.
attr <name>  externalSensor <name des echten Fenster Kontakts>:<Reading das open/close signalisiert>:<RegEx für Fenster offen>:<RegEx für Fenster geschlossen>
Bsp :
attr myVFK1 externalSensor HM_FensterBad:state:open:closed
attr myVFK1 externalSensor HM_FensterBad:state:(open.*|til.*):(close.*|zu)
attr myVFK1 externalSensor China_FK:isopen:1:0

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

fhemHolli

#7
Hallo Wzut erst mal besten Dank für die neue Möglichkeit mit virtuellen Fensterkontakt.

Hier kommt die erste Testauswertung:

  • direkt 3 virtuelle Fensterkontakte mit jeweils unterschiedlicher MAX id angelegt -- funktioniert
  • jedem virtuellen Fensterkontakt eine andere GroupID via set Befehl zugewiesen -- funktioniert
  • mit dem set Befehl open und close abgesetzt -- funktioniert
  • der jeweilige set Befehl wirkt nur auf das assoziierte Gerät, keine Nebenwirkung auf Geräte mit anderer GroupID -- sehr gut
  • egal ob open oder close ausgeführt wurde, der Status des jeweiligen virtuellen Fensterkontaktes wird nicht geändert, aktualisiert, STATE bleibt auf den drei Fragezeichen stehen -- schlecht
  • keine Reaktion auf externalSensor z.B. (wz_FK:state:open:closed) -- schlecht
  • enormer Verbrauch von Credits, wenn man open oder close über den set Befehl absetzt -- bitte überprüfen warum 

Ich habe bewusst nur den jeweiligen Raum WT assoziiert, da ich davon ausgehe das er nach dem Empfang der Fenster offen Information nach kurzer Zeit ca. 3 Minuten seine assoziierten HTs aktualisiert.
Evtl. könnte es bei den Credits helfen auch nur Das oder Die wirklich assoziierten Geräten anzusprechen. Die GroupID sollte nicht dazu führen das alle Geräte mit dieser ID automatisch mit Informationen beglückt werden.
Während des Tests, habe ich zweimal meinen MAXcun stromlos gemacht, damit ich wieder credits bekomme.

Gerne liefere ich weitere Informationen, ansonsten warte ich schon mal auf die nächsten Beta Dateien.

Besten Dank
Gruß Uwe
TS-453mini, QTS 4.3.6, fhem-5.9
MaxCun, HMLAN (das Original), Broadlink RM2
Homematic & Max Heizungs Gedöns
Intertechno Licht / Steckdosen

Wzut

#8
Zitat von: fhemHolli am 03 März 2020, 20:43:20
egal ob open oder close ausgeführt wurde, der Status des jeweiligen virtuellen Fensterkontaktes wird nicht geändert, aktualisiert, STATE bleibt auf den drei Fragezeichen stehen -- schlecht
hmmmm

Zitatkeine Reaktion auf externalSensor z.B. (wz_FK:state:open:closed) -- schlecht
komisch, das ging bei mir problemlos. Ganz sicher das der wz_FK auch einen Event erzeugt der im Eventmonitor sichtbar ist ?
Ansonst mal den virtuellen Kontakt auf verbose 5 stellen und ins Log schauen.
Beim virtuellen mus auch unter Internals NOTIFYDEV gelistet sein. Hier mal ein List meines :
Internals:
   .FhemMetaInternals 1
   .actCycle  300
   .count     0
   .sendToAddr -1
   .sendToName
   CHANGED   
   DEF        virtualShutterContact 987654
   FUUID      5e4e4f5f-f33f-5b1a-512e-a6101a0f507c1520
   FVERSION   10_MAX.pm:?/2020-03-03 UNSTABLE
   IODev      cm
   NAME       vFK_1
   NOTIFYDEV  Eddy_FK
   NR         126
   NTFY_ORDER 50-vFK_1
   STATE      closed
   TYPE       MAX
   addr       987654
   devtype    6
   type       virtualShutterContact
   .attreocr:
     .*
   .attrminint:
   READINGS:
     2020-03-02 09:28:33   .lastact        1583137713
     2020-03-03 20:55:53   Activity        dead
     2020-03-02 09:28:33   CUL2_RSSI       -78
     2020-03-02 09:28:33   RSSI            -78
     2020-03-02 09:15:19   groupid         1
     2020-03-02 09:28:33   onoff           0
     2020-03-02 09:28:33   peerIDs         014dc8,0c8688,0e0fe4
     2020-03-02 09:28:33   peerList        Thermo1,Thermo3,WandThermo
     2020-03-02 09:28:30   sendTo_Thermo1  1
     2020-03-02 09:28:31   sendTo_Thermo3  1
     2020-03-02 09:28:33   sendTo_WandThermo 1
     2020-03-02 09:28:33   state           closed
   internals:
     interfaces
Attributes:
   CULdev     CUL
   IODev      cm
   actCycle   0:05
   event-on-change-reading .*
   externalSensor Eddy_FK:state:on:off
   model      virtualShutterContact
   room       MAX
   verbose    5

oder sollte ich aus versehen die falsche Version hochgeladen haben ? dann hättest du kein NOTIFYDEV
Zitatenormer Verbrauch von Credits, wenn man open oder close über den set Befehl absetzt -- bitte überprüfen warum 
Das hatte ich oben geschrieben und auch erklärt warum
siehe nächster Post
ZitatIch habe bewusst nur den jeweiligen Raum WT assoziiert, da ich davon ausgehe das er nach dem Empfang der Fenster offen Information nach kurzer Zeit ca. 3 Minuten seine assoziierten HTs aktualisiert.
OK, dann darf dich aber jeder Schaltvorgang eigentlich nur 112 Credist kosten. Hier würde ich mal das CULMAX Device ebenfalls auf verbose 5 stellen und das Log beobachten ob da Wiederholungen dabei sind.
da sind ganz ganz viele Wiederholungen ... siehe nächster Post

ZitatEvtl. könnte es bei den Credits helfen auch nur Das oder Die wirklich assoziierten Geräten anzusprechen. Die GroupID sollte nicht dazu führen das alle Geräte mit dieser ID automatisch mit Informationen beglückt werden.
Das würd den Credit Verbrauch je nach Raum drücken, allerdings wie oben beschrieben ist das abarbeiten des Raums bzw. der groupid genau das was ein FK unter de Original ELV Firmware macht. Bzw. das macht er auch am CUL nach seinem Umzug vom Cube. Nur bei vielen Usern wird das nicht so sein da deren FKs (inkl meine eigenen) nicht richtig bzw gar nicht mit den HTS/WTs assoziert sind und die so immer ihren Status als Broadcast Nachricht verschicken. Da möchte ich auch noch hin nur hat es bei den bisherigen Tests nicht so sauber geklappt wie bei einem echten FK.

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wzut

Nachtrag : mit etwas Überlegen hätte ich vorhin schon drauf kommen können .....
Klar gehen bei dir die Credits weg wie geschnittenes Brot : Du hast nur das WT assoziert, der virtuelle FK will aber mit jedem Gruppenmitglied reden,
also werden die Nachrichten an die HTs dreimal wiederholt und dann verworfen.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

fhemHolli

ZitatKlar gehen bei dir die Credits weg wie geschnittenes Brot : Du hast nur das WT assoziert, der virtuelle FK will aber mit jedem Gruppenmitglied reden,
stimmt, habe jetzt auf die schnelle die beiden Wohnzimmer HTs auch mit dem virtuellen Fensterkontakt assoziiert, danach sieht das mit den Credits deutlich besser aus.
Vielleicht sollte ich mich von der Idee verabschieden alles Zentral über den jeweiligen Zimmer WT zu machen, sondern alle im Raum beteiligten HTs mitzubenutzen, dann kommt die Reaktion auf ein open auch deutlich schneller bei der Heizung an...
TS-453mini, QTS 4.3.6, fhem-5.9
MaxCun, HMLAN (das Original), Broadlink RM2
Homematic & Max Heizungs Gedöns
Intertechno Licht / Steckdosen

Wzut

ok, zum Thema senden habe ich mir noch etwas überlegt, vllt kann ich schon heute Abend eine neue Version posten.
Hat sich denn nun dein externalSensor Problem geklärt ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

fhemHolli

weiter geht's
Einträge im LOG wenn ich den HM Fenster Drehgriff Sensor wz_FK betätige:
2020.03.04 07:41:05 5: wz_vFK,EVENT | battery: ok
2020.03.04 07:41:05 5: wz_vFK,EVENT | contact: open (to broadcast)
2020.03.04 07:41:05 5: wz_vFK,EVENT | open
2020.03.04 07:41:05 5: wz_vFK,EVENT | trigger_cnt: 2
2020.03.04 07:41:54 5: wz_vFK,EVENT | battery: ok
2020.03.04 07:41:54 5: wz_vFK,EVENT | contact: closed (to broadcast)
2020.03.04 07:41:54 5: wz_vFK,EVENT | closed
2020.03.04 07:41:54 5: wz_vFK,EVENT | trigger_cnt: 3

Der virtuelle Fensterkontakt wz_vFK bekommt die Status Änderungen vom wz_FK scheinbar mit, so interpretiere ich die EVENT Einträge

Hier die zugehörige Ausgabe vom Event Monitor:

2020-03-04 07:39:54 Global global ATTR wz_vFK verbose 5
2020-03-04 07:40:19 Global global SAVE
2020-03-04 07:40:26 CUL_HM Terrasse humidity: 87
2020-03-04 07:40:26 CUL_HM Terrasse measured-temp: 4.8
2020-03-04 07:40:26 CUL_HM Terrasse T: 4.8 H: 87
2020-03-04 07:40:26 CUL_HM Terrasse_Weather humidity: 87
2020-03-04 07:40:26 CUL_HM Terrasse_Weather measured-temp: 4.8
2020-03-04 07:40:26 CUL_HM Terrasse_Weather T: 4.8 H: 87
2020-03-04 07:40:40 MAX k_Wand temperature: 18.9
2020-03-04 07:40:40 MAX k_Wand deviation: 1.9
2020-03-04 07:40:40 MAX k_Wand 17.0°C
2020-03-04 07:40:40 MAX k_Wand desiredTemperature: 17.0
2020-03-04 07:40:40 MAX k_Wand RSSI: -62
2020-03-04 07:40:40 MAX k_Wand peerList: Broadcast,MAX_222222,k_Temp,k_vFK
2020-03-04 07:40:40 MAX k_Wand peerIDs: 000000,0f5a49,222222,508902
2020-03-04 07:40:40 MAX k_Temp valveposition: 0
2020-03-04 07:40:40 MAX k_Temp 17.0°C
2020-03-04 07:40:40 MAX k_Temp desiredTemperature: 17.0
2020-03-04 07:40:40 MAX k_Temp RSSI: -53.5
2020-03-04 07:40:40 MAX k_Temp battery: ok
2020-03-04 07:40:40 MAX k_Temp batteryState: ok
2020-03-04 07:40:40 MAX k_Temp rferror: 0
2020-03-04 07:40:40 MAX k_Temp gateway: 1
2020-03-04 07:40:40 MAX k_Temp mode: auto
2020-03-04 07:40:40 MAX k_Temp panel: unlocked
2020-03-04 07:40:40 MAX k_Temp peerList: Broadcast,k_Wand
2020-03-04 07:40:40 MAX k_Temp peerIDs: 000000,113c8b
2020-03-04 07:40:53 MAX b_Wand temperature: 19.3
2020-03-04 07:40:53 MAX b_Wand deviation: 0.3
2020-03-04 07:40:53 MAX b_Wand 19.0°C
2020-03-04 07:40:53 MAX b_Wand desiredTemperature: 19.0
2020-03-04 07:40:53 MAX b_Wand RSSI: -84.5
2020-03-04 07:40:53 MAX b_Wand peerList: Broadcast,b_Temp
2020-03-04 07:40:53 MAX b_Wand peerIDs: 000000,04c4b0
2020-03-04 07:40:53 MAX b_Temp valveposition: 7
2020-03-04 07:40:53 MAX b_Temp 19.0°C
2020-03-04 07:40:53 MAX b_Temp desiredTemperature: 19.0
2020-03-04 07:40:53 MAX b_Temp RSSI: -58.5
2020-03-04 07:40:53 MAX b_Temp battery: ok
2020-03-04 07:40:53 MAX b_Temp batteryState: ok
2020-03-04 07:40:53 MAX b_Temp rferror: 0
2020-03-04 07:40:53 MAX b_Temp gateway: 1
2020-03-04 07:40:53 MAX b_Temp mode: auto
2020-03-04 07:40:53 MAX b_Temp panel: unlocked
2020-03-04 07:40:53 MAX b_Temp peerList: Broadcast,b_Wand
2020-03-04 07:40:53 MAX b_Temp peerIDs: 000000,10c990
2020-03-04 07:41:05 CUL_HM wz_FK battery: ok
2020-03-04 07:41:05 CUL_HM wz_FK contact: open (to broadcast)
2020-03-04 07:41:05 CUL_HM wz_FK open
2020-03-04 07:41:05 CUL_HM wz_FK trigger_cnt: 2
2020-03-04 07:41:09 MAX an_Wand temperature: 16.8
2020-03-04 07:41:09 MAX an_Wand deviation: 0.8
2020-03-04 07:41:09 MAX an_Wand 16.0°C
2020-03-04 07:41:09 MAX an_Wand desiredTemperature: 16.0
2020-03-04 07:41:09 MAX an_Wand RSSI: -52
2020-03-04 07:41:09 MAX an_Wand peerList: Broadcast,an_Temp
2020-03-04 07:41:09 MAX an_Wand peerIDs: 000000,046614
2020-03-04 07:41:09 MAX an_Temp valveposition: 0
2020-03-04 07:41:09 MAX an_Temp 16.0°C
2020-03-04 07:41:09 MAX an_Temp desiredTemperature: 16.0
2020-03-04 07:41:09 MAX an_Temp RSSI: -76
2020-03-04 07:41:09 MAX an_Temp battery: ok
2020-03-04 07:41:09 MAX an_Temp batteryState: ok
2020-03-04 07:41:09 MAX an_Temp rferror: 0
2020-03-04 07:41:09 MAX an_Temp gateway: 1
2020-03-04 07:41:09 MAX an_Temp mode: auto
2020-03-04 07:41:09 MAX an_Temp panel: unlocked
2020-03-04 07:41:09 MAX an_Temp peerList: Broadcast,an_Wand
2020-03-04 07:41:09 MAX an_Temp peerIDs: 000000,10c836
2020-03-04 07:41:18 CUL_HM Schuppen humidity: 82
2020-03-04 07:41:18 CUL_HM Schuppen measured-temp: 4.9
2020-03-04 07:41:18 CUL_HM Schuppen T: 4.9 H: 82
2020-03-04 07:41:18 CUL_HM Schuppen_Weather humidity: 82
2020-03-04 07:41:18 CUL_HM Schuppen_Weather measured-temp: 4.9
2020-03-04 07:41:18 CUL_HM Schuppen_Weather T: 4.9 H: 82
2020-03-04 07:41:45 STACKABLE_CC MaxCun_868 UNKNOWNCODE A066A1095BA9507
2020-03-04 07:41:49 CUL_HM Keller humidity: 60
2020-03-04 07:41:49 CUL_HM Keller measured-temp: 15.4
2020-03-04 07:41:49 CUL_HM Keller T: 15.4 H: 60
2020-03-04 07:41:49 CUL_HM Keller_Weather humidity: 60
2020-03-04 07:41:49 CUL_HM Keller_Weather measured-temp: 15.4
2020-03-04 07:41:49 CUL_HM Keller_Weather T: 15.4 H: 60
2020-03-04 07:41:51 CUL_HM Backup humidity: 57
2020-03-04 07:41:51 CUL_HM Backup measured-temp: 16.6
2020-03-04 07:41:51 CUL_HM Backup T: 16.6 H: 57
2020-03-04 07:41:51 CUL_HM Backup_Weather humidity: 57
2020-03-04 07:41:51 CUL_HM Backup_Weather measured-temp: 16.6
2020-03-04 07:41:51 CUL_HM Backup_Weather T: 16.6 H: 57
2020-03-04 07:41:54 CUL_HM wz_FK battery: ok
2020-03-04 07:41:54 CUL_HM wz_FK contact: closed (to broadcast)
2020-03-04 07:41:54 CUL_HM wz_FK closed
2020-03-04 07:41:54 CUL_HM wz_FK trigger_cnt: 3
2020-03-04 07:42:09 MAX sz_Wand temperature: 16.4
2020-03-04 07:42:09 MAX sz_Wand deviation: 3.4
2020-03-04 07:42:09 MAX sz_Wand 13.0°C
2020-03-04 07:42:09 MAX sz_Wand desiredTemperature: 13.0
2020-03-04 07:42:09 MAX sz_Wand RSSI: -62.5
2020-03-04 07:42:09 MAX sz_Wand peerList: Broadcast,sz_Temp
2020-03-04 07:42:09 MAX sz_Wand peerIDs: 000000,15fce1
2020-03-04 07:42:09 MAX sz_Temp valveposition: 0
2020-03-04 07:42:09 MAX sz_Temp 13.0°C
2020-03-04 07:42:09 MAX sz_Temp desiredTemperature: 13.0
2020-03-04 07:42:09 MAX sz_Temp RSSI: -84
2020-03-04 07:42:09 MAX sz_Temp battery: ok
2020-03-04 07:42:09 MAX sz_Temp batteryState: ok
2020-03-04 07:42:09 MAX sz_Temp rferror: 0
2020-03-04 07:42:09 MAX sz_Temp gateway: 1
2020-03-04 07:42:09 MAX sz_Temp mode: auto
2020-03-04 07:42:09 MAX sz_Temp panel: unlocked
2020-03-04 07:42:09 MAX sz_Temp peerList: Broadcast,sz_Wand
2020-03-04 07:42:09 MAX sz_Temp peerIDs: 000000,0e142d

Hier sieht man die Einträge vom HM Fenster Drehgriff wz_FK aber keine weitere Reaktion darauf

Das schicke ich erst mal ab, da ja gerade von dir eine Antwort hereingekommen ist...
TS-453mini, QTS 4.3.6, fhem-5.9
MaxCun, HMLAN (das Original), Broadlink RM2
Homematic & Max Heizungs Gedöns
Intertechno Licht / Steckdosen

fhemHolli

...und hier noch Internals aus der FHEM Web Ausgabe:
CFGFN
DEF        virtualShutterContact 508901
FUUID      5e5eeaf4-f33f-6c99-5eff-b6277489e55b83bd
FVERSION   10_MAX.pm:?/2020-03-03 UNSTABLE
IODev      MaxCul
NAME       wz_vFK
NOTIFYDEV  wz_FK
NR         1010
NTFY_ORDER 50-wz_vFK
STATE      ???
TYPE       MAX
addr       508901
devtype    6
type       virtualShutterContact


und direkt noch eine Frage, bei dem HM Fenster Drehgriff gibt es zusätzlich zu open, closed noch tilted für Fenster auf Kipp.
Kann man diese zweite Möglichkeit um ein offenes Fenster zu signalisieren auch in das Attribut für den externalSensor mit übergeben?
attr wz_vFK externalSensor wz_FK:state:open:closed   |tilted?

Ich hoffe das sind erst mal genug Infos zum weiter forschen.

Gruß Uwe
TS-453mini, QTS 4.3.6, fhem-5.9
MaxCun, HMLAN (das Original), Broadlink RM2
Homematic & Max Heizungs Gedöns
Intertechno Licht / Steckdosen

Wzut

OK, der wz_FK steht unter NOTIFYDEV aber ich schrieb auch du must den wz_vFK auf verbose 5 stellen um im Log zu sehen welche Events überhaupt und in welcher Forum zu ihm durchkommen.
Wegen deinem Tilt : eventuell könnte man den Part auch als regEx definieren , dann ergäbe sich so etwas
attr wz_vFK externalSensor wz_FK:state:(open|tilted):closed
muss ich mir aber genauer anschauen
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher