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.
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)
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.
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.
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.
:) 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.
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
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
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 5oder 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.
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.
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...
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 ?
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...
...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
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
so alles umgesetzt , die neuen Version habe ich in Antwort 6 ausgetauscht und dort auch die Beschreibung angepasst (neue Attribute , neues Sendeverhalten, regEx)
Bitte beide Dateien austauschen , für den Broadcast musste ich Änderungen in 14_CUL_MAX vornehmen und zur Sicherheit FHEM neu starten statt nur einem einfachen reload.
ZitatMode Broadcast : der VFK sendet nur ein Telegramm mit Ziel alle ohne auf Rückmeldungen zu warten.
erster Test begeistert, schnelle Info über Broadcast von allen assoziierten WTs und HTs abgegriffen, bisher keine Verluste bemerkt -- super
In den Readings wird "state" aktualisiert, das große "STATE" aus den Internals und im FhemWeb ändert sich nicht.
ich bekomme den externalSensor weder mit <wz_FK:state:open:closed> noch mit <wz_FK:state:(open.*|til.*):(close.*|zu)> zu der gewünschten Reaktion.
Hier das verbose 5 LOG für das öffnen des wz_FK
2020.03.04 20:34:57 4: CUL_Parse: MaxCun **A0C0B84411CC443000000010AC80E
2020.03.04 20:34:57 5: MaxCun: dispatch **A0C0B84411CC443000000010AC80E
2020.03.04 20:34:57 5: Starting notify loop for wz_FK, 4 event(s), first is battery: ok
2020.03.04 20:34:57 5: wz_vFK,EVENT | battery: ok
2020.03.04 20:34:57 5: wz_vFK,EVENT | contact: open (to broadcast)
2020.03.04 20:34:57 5: wz_vFK,EVENT | open
2020.03.04 20:34:57 5: wz_vFK,EVENT | trigger_cnt: 10
2020.03.04 20:34:57 5: wz_vFK, state - trigger_cnt
2020.03.04 20:34:57 5: wz_vFK, regex 0
2020.03.04 20:34:57 5: End notify loop for wz_FK
2020.03.04 20:35:16 5: CUL/RAW: /Z0C9A044208859A06E1BC0024BBFF
Z0E9A020206E1BC08859A0001182824F8
**A2110008E22BDA3BA950708FA2D1DAC983A7CAF1EE5595B702C89DE638960DA35D160D7
2020.03.04 20:35:16 4: CUL_Parse: MaxCun Z0C9A044208859A06E1BC0024BBFF -74.5
2020.03.04 20:35:16 5: MaxCun: dispatch Z0C9A044208859A06E1BC0024BB
2020.03.04 20:35:16 5: MaxCul, IODev MaxCun, len 12, msgcnt 9A, msgflag 04, msgType WallThermostatControl, src 08859a, dst 06e1bc, group 0, payload 24BB, rssi -74.5
2020.03.04 20:35:16 5: MaxCul: dispatch MAX,0,WallThermostatControl,08859a,24BB
2020.03.04 20:35:16 5: MAX_Parse, MAX,0,WallThermostatControl,08859a,24BB
2020.03.04 20:35:16 5: d_Wand, desiredTemperature : 18, temperature : 18.
und jetzt für das schließen des wz_FK
2020.03.04 20:37:47 4: CUL_Parse: MaxCun **A0C0C84411CC443000000010B000A
2020.03.04 20:37:47 5: MaxCun: dispatch **A0C0C84411CC443000000010B000A
2020.03.04 20:37:47 5: Starting notify loop for wz_FK, 4 event(s), first is battery: ok
2020.03.04 20:37:47 5: wz_vFK,EVENT | battery: ok
2020.03.04 20:37:47 5: wz_vFK,EVENT | contact: closed (to broadcast)
2020.03.04 20:37:47 5: wz_vFK,EVENT | closed
2020.03.04 20:37:47 5: wz_vFK,EVENT | trigger_cnt: 11
2020.03.04 20:37:47 5: wz_vFK, state - trigger_cnt
2020.03.04 20:37:47 5: wz_vFK, regex 0
2020.03.04 20:37:47 5: End notify loop for wz_FK
2020.03.04 20:37:54 5: CUL/RAW: /**A2110008E22BDA3BA950708FA2D1E7C690500F9B8654C9EB8777AA032618F85D7CC26D5
2020.03.04 20:37:54 4: CUL_Parse: MaxCun **A2110008E22BDA3BA950708FA2D1E7C690500F9B8654C9EB8777AA032618F85D7CC26D5
2020.03.04 20:37:54 5: MaxCun: dispatch **A2110008E22BDA3BA950708FA2D1E7C690500F9B8654C9EB8777AA032618F85D7CC26D5
2020.03.04 20:37:59 5: CUL/RAW: /Z0C9B044208859A06E1BC0024BB00
Z0E9B020206E1BC08859A0001182824F8
2020.03.04 20:37:59 4: CUL_Parse: MaxCun Z0C9B044208859A06E1BC0024BB00 -74
2020.03.04 20:37:59 5: MaxCun: dispatch Z0C9B044208859A06E1BC0024BB
2020.03.04 20:37:59 5: MaxCul, IODev MaxCun, len 12, msgcnt 9B, msgflag 04, msgType WallThermostatControl, src 08859a, dst 06e1bc, group 0, payload 24BB, rssi -74
2020.03.04 20:37:59 5: MaxCul: dispatch MAX,0,WallThermostatControl,08859a,24BB
2020.03.04 20:37:59 5: MAX_Parse, MAX,0,WallThermostatControl,08859a,24BB
2020.03.04 20:37:59 5: d_Wand, desiredTemperature : 18, temperature : 18.7
2020.03.04 20:37:59 5: Starting notify loop for d_Wand, 7 event(s), first is temperature: 18.7
2020.03.04 20:37:59 5: End notify loop for d_Wand
Sehr schön in dem Fall habe ich zwei gute Nachrichten für dich :
1. das Thema STATE : der User hat hier alle Freiheiten sich das selbst zu formatieren und gestalten (Text , Icons , usw.) das Zauberwort nennt sich stateFormat
Was man da so treiben kann hänge dich dir mal als Screenshot an. In deinem Fall wäre das dann halt einfach nur
attr wz_vFK stateFormat stateaber das ziehe ich in der nächsten Version nach
2. dein open close kommt schon mal beim wz_vFK an :
Zitat2020.03.04 20:34:57 5: wz_vFK,EVENT | open
2020.03.04 20:37:47 5: wz_vFK,EVENT | closed
jetzt gilt es nur noch herauszufinden was bei deinen Events anders ist als bei meinen und wir z.Z. ganz kurz vor dem Ziel scheitern.
Ich baue da dann noch mehr Logging ein, bis dahin must du dir halt mit einem externen notify und gelöschtem externalSensor Attribut behelfen.
Edit : ich bin dem Problem auf der Spur. Das besondere an dem HM Sensor ist das hier nicht ein Event alleine kommt sondern ein ganzes Bündel. Wäre der state Event mit seinem open/close der letzte in dieser Kette dann ginge es. Ich muß mal schauen wie andere Modulautoren ihre Notify Funktionen gebaut haben und ggf. dort ein bissel was abschreiben.
Furchtbar offtopic, aber ich bin sehr neidisch auf dein stateFormat, Wzut. Magst du vielleicht den Code verraten?
*lach*, das ist eigentlich nichts Besonderes, alles mit FHEM Bordmittel. Hier ein Beispiel für ein HT und ein WT jeweils für den raw Editor :
Edit -> https://forum.fhem.de/index.php/topic,109034.0.html
...nach der Schöngeisterei wieder zurück in den schnöden Topic ;)
ich habe testweise den externalSensor mit dem <wz_FK:state:trigger_cnt:closed> gesetzt - damit wurde mit dem öffnen des Fensters auch brav der WT und die HTs in Windows open gefahren. -- funktioniert also Grundsätzlich
Zitatattr wz_vFK stateFormat state
dann kommt auch der kleine state beim großen STATE an -- gut
-- aber der große STATE will nicht mit dem kleinen state zusammen auf close wechseln.
Zitat von: fhemHolli am 05 März 2020, 22:07:47
funktioniert also Grundsätzlich
und würdest du auf das Reading contact triggern statt auf state würde es sogar komplett funktionieren ....
aber anyway, die nächste Version wird alles schlucken und dann müssen wir auch nicht mehr über den Unterschied des
Readings state und des
Internals STATE diskutieren, u.a. da den Readings eh noch das onoff Reading fehlt.
So ist das wenn Benutzer mit gefährlichem Halbwissen hinter Entwicklern herlaufen. 8)
Eigentlich ist alles schon da, man muss es nur richtig nutzen...
Freue mich schon auf die nächste Version
Gruß Uwe
macht nichts zum dazulernen ist man nie zu alt :)
Ich habe die 10_MAX in Antwort #6 ausgetauscht, teste mal
Hallo Wzut,
es gibt positives zu berichten.
wz_FK:state:(open.*|til.*):closed erzeugt das gewünschte Verhalten -- sehr gut
Damit wird das nutzen von Fremdfensterkontakten deutlich vereinfacht.
Die Auswahl beim SendMode finde ich gut, jetzt kann ich gezielt bei den räumlich vom MaxCun weiter entfernten WTs & HTs den Modus group oder peers angeben, was bei mir im Schlafzimmer und auf dem Dachboden für mehr Übertragungssicherheit sorgt.
Bei den virtuellenShutter Kontakten habe ich kein attr stateFormat gesetzt und bekomme in der FhemWeb Ansicht für den status close ein Bildchen angezeigt.
Habe ich da wieder etwas nicht beachtet? ;)
Gruß Uwe
diesmal bin ich unschuldig :) das ist eine Eigenart von FHEMWEB state durch ein Icon zu ersetzen, Bsp ist die kleine Glühbirne bei on & off oder ich habe manchmal Wolken mit Regentropfen wenn state nur eine Zahl ist ...
Abhilfe : das Attribut devStateIcon : entweder da eine Kombination eintragen für die Wunsch Icons oder schlicht den Text none wenn nie der Text in ein Icon gewandelt werden soll.
Edit : ok so ganz unschuldig bin ich doch nicht, da ich open oder close z.Z. als state ausgebe, richtig(er) wäre aber opened / closed
mit der aktuellen Version aus dem Beta Fred wir der closed Zustand in state nicht angezeigt, die Funktion ist aber gegeben.
Die MaxCommon.pm aus dem normalen update kennt heute Morgen die virtuellenShutter Kontakte noch nicht.
...jetzt muss ich aber fix zur Arbeit
viel zu früh für update ! ab 8:00 Uhr ....
Zitat von: fhemHolli am 09 März 2020, 07:37:22
mit der aktuellen Version aus dem Beta Fred wir der closed Zustand in state nicht angezeigt, die Funktion ist aber gegeben.
ja da fehlten u.a. zwei Hochkommas, ich habe sie ausgetauscht
:) nachdem der virtualShutterContact in den halb offiziellen Beta Zweig eingezogen ist und alle grundlegenden Funktionen gegeben sind ist es Zeit diesen Topic zu schließen.
Link zu den Beta Dateien: neue Beta Versionen von 10_MAX und 14_CUL_MAX --> https://forum.fhem.de/index.php/topic,106258.0.html (https://forum.fhem.de/index.php/topic,106258.0.html)
Link zur Beta Diskussion: Die MAX Module heute und die Aussichten für 2020 --> https://forum.fhem.de/index.php/topic,106577.0.html (https://forum.fhem.de/index.php/topic,106577.0.html)
@Wzut Allerbesten Dank für die Weiterentwicklung der MAX Module!