[ERLEDIGT]MAX! HT+Xiaomi Aqara Fensterkontakt, alle reagieren auf einen Kontakt.

[D3ltorohd]

Hallo Com,

ich würde gern meine Aqara Fensterkonakte mit den Max! HT's verbinden, damit diese auf off gehen, wenn das Fenster geöffnet wird und man lüftet.

Ich steig da aber irgendwie nicht so recht durch. Ich muss erst mal den fakeshutterContact mit den HT's verknüpfen, aber was passiert danach ? Irgendwoher muss dann wohl der Befehl

Code Auswählen Erweitern

Nun können wir per

set cm fakeSC Heizung 1
die Nachricht "Fenster offen" an die Heizung senden und per

set cm fakeSC Heizung 0
die Nachricht "Fenster zu".

kommen richtig ? Kann mir da einer erklären, wie das funktioniert ? im Wiki und im commandref stehen leider keine Beispiele. Mache ich das einfach mit einem DOIF, DOELSEIF ? Wobei Heizung hier wohl durch den Namen meines HT's ersetzt werden muss, oder cm ?

Grüße,

[D3ltorohd]

Ok ich hab das jetzt mal so gelöst. Weiß gar nicht ob das anders auch geht mit dem fakeShutterContact. Aber so scheint es ganz gut zu klappen...

Code Auswählen Erweitern

defmod HT_Fensteroffen_Buero DOIF ([Buero_links_Sensor:"open"]) (set Buero_HT desiredTemperature off) DOELSE (set Buero_HT desiredTemperature 18)
attr HT_Fensteroffen_Buero do always
attr HT_Fensteroffen_Buero icon time_eco_mode
attr HT_Fensteroffen_Buero room Doif
attr HT_Fensteroffen_Buero wait 15

[Wzut]

Nun deine Lösung hat aber den Nachteil das es nur zwei Zustände gibt, aus und manuell 18 Grad.
Das Beispiel im Wiki ist doch recht eindeutig, bei dir wäre es eben nicht Heizung sondern Buero_HT
d.h.

Code Auswählen Erweitern

defmod HT_Fensteroffen_Buero DOIF ([Buero_links_Sensor:"open"]) (set cm fakeSC Buero_HT 1) DOELSE (set cm fakeSC Buero_HT 0)
natürlich unter der Bedingung das dein CUL_MAX Device auch den Namen cm hat.

[D3ltorohd]

Nun deine Lösung hat aber den Nachteil das es nur zwei Zustände gibt, aus und manuell 18 Grad.
Das Beispiel im Wiki ist doch recht eindeutig, bei dir wäre es eben nicht Heizung sondern Buero_HT
d.h.

Code Auswählen Erweitern

defmod HT_Fensteroffen_Buero DOIF ([Buero_links_Sensor:"open"]) (set cm fakeSC Buero_HT 1) DOELSE (set cm fakeSC Buero_HT 0)
natürlich unter der Bedingung das dein CUL_MAX Device auch den Namen cm hat.

Grad wollte ich schreiben ob du mir mit den fsc helfen könntest.

Indem Fall bin ich schon auf dem richtigen Weg. Das doif wird für die Dankeshütter contacrs gebraucht, damit ich den Befehl dann senden kann ?

Mein cm heißt anders aber ich teste das später. Super danke schon mal für deine Hilfe.

Mit der Originalvariante wird auf die gesetzte temp im HR gestellt und nach dem Schließbefehl wieder in den Ursprung vor dem lüften versetzt ?

[D3ltorohd]

Hab gleich beide Kontakte mit rein, sollte ja so passen : Funktioniert wunderbar und das Problem mit dem Status vor lüften fällt weg, weil er wieder auf das stellt, was als letztes eingestellt ist. Wunderbar danke dir noch mal für den Tipp. Mit dem doif könnte man vllt mit in die Wiki aufnehmen, hab schon die set Befehle gesehen, aber hätte jetzt als Anfänger nicht gewusst wie ich die an das fakesc schicke. Hätte jetzt versucht im Xiaomi Device den Befehl irgendwie zu senden.

Code Auswählen Erweitern

define ([Buero_links_Sensor:"open"] or [Buero_rechts_Sensor:"open"]) (set MaxCube fakeSC Buero_HT 1) DOELSE (set MaxCube fakeSC Buero_HT 0)

Das ist aber heftig. Hatte einmal das Linke Fenster probiert da ging's beim rechten gings schon nicht mehr. Credits alle.

2019.11.25 19:49:28 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 3, but we need 110. Waiting 107 seconds. Currently 8 messages are waiting to be sent.

[D3ltorohd]

So und noch mal ich. Das klappt nicht mehr. Seit ich das mit dem fsc mache, habe ich immer keine Credits mehr.

Code Auswählen Erweitern

2019.11.25 19:49:28 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 3, but we need 110. Waiting 107 seconds. Currently 8 messages are waiting to be sent.
2019.11.25 19:51:17 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 3, but we need 110. Waiting 107 seconds. Currently 7 messages are waiting to be sent.
2019.11.25 19:53:07 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 3, but we need 110. Waiting 107 seconds. Currently 6 messages are waiting to be sent.
2019.11.25 19:55:01 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 8, but we need 110. Waiting 102 seconds. Currently 6 messages are waiting to be sent.
2019.11.25 19:56:46 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 3, but we need 110. Waiting 107 seconds. Currently 5 messages are waiting to be sent.
2019.11.25 19:58:36 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 3, but we need 110. Waiting 107 seconds. Currently 4 messages are waiting to be sent.
2019.11.25 19:59:02 3: ABFALL MeinAbfall - CALENDAR:Abfallkalender triggered, updating ABFALL MeinAbfall ...
2019.11.25 20:00:25 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 3, but we need 110. Waiting 107 seconds. Currently 3 messages are waiting to be sent.
2019.11.25 20:02:15 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 3, but we need 110. Waiting 107 seconds. Currently 3 messages are waiting to be sent.
2019.11.25 20:04:04 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 3, but we need 110. Waiting 107 seconds. Currently 2 messages are waiting to be sent.
2019.11.25 20:05:54 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 3, but we need 113. Waiting 110 seconds. Currently 1 messages are waiting to be sent.
2019.11.25 20:18:06 2: CUL_MAX_SendQueueHandler: Missing ack from 0d8435 for 0b3606302222220d84350010
2019.11.25 20:18:13 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 82, but we need 110. Waiting 28 seconds. Currently 3 messages are waiting to be sent.
2019.11.25 20:18:48 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 8, but we need 110. Waiting 102 seconds. Currently 3 messages are waiting to be sent.
2019.11.25 20:20:38 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 8, but we need 110. Waiting 102 seconds. Currently 3 messages are waiting to be sent.
2019.11.25 20:22:24 2: CUL_MAX_SendQueueHandler: Missing ack from 0d8435 for 0b3706302222220d84350010
2019.11.25 20:22:24 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 5, but we need 110. Waiting 105 seconds. Currently 2 messages are waiting to be sent.
2019.11.25 20:24:17 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 8, but we need 110. Waiting 102 seconds. Currently 2 messages are waiting to be sent.
2019.11.25 20:26:06 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 8, but we need 110. Waiting 102 seconds. Currently 2 messages are waiting to be sent.
2019.11.25 20:27:56 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 8, but we need 110. Waiting 102 seconds. Currently 2 messages are waiting to be sent.
2019.11.25 20:29:42 2: CUL_MAX_SendQueueHandler: Missing ack from 0e85cf for 0b2b06302222220e85cf0010
2019.11.25 20:29:42 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 5, but we need 110. Waiting 105 seconds. Currently 1 messages are waiting to be sent.
2019.11.25 20:31:35 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 8, but we need 110. Waiting 102 seconds. Currently 1 messages are waiting to be sent.
2019.11.25 20:33:24 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 8, but we need 110. Waiting 102 seconds. Currently 1 messages are waiting to be sent.
2019.11.25 20:35:14 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 8, but we need 110. Waiting 102 seconds. Currently 1 messages are waiting to be sent.
2019.11.25 20:37:00 2: CUL_MAX_SendQueueHandler: Missing ack from 0e85cf for 0b2c06302222220e85cf0010
2019.11.25 20:38:30 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 94, but we need 110. Waiting 16 seconds. Currently 1 messages are waiting to be sent.
2019.11.25 20:38:53 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 8, but we need 110. Waiting 102 seconds. Currently 2 messages are waiting to be sent.
2019.11.25 20:40:38 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 3, but we need 110. Waiting 107 seconds. Currently 3 messages are waiting to be sent.
2019.11.25 20:42:27 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 3, but we need 110. Waiting 107 seconds. Currently 2 messages are waiting to be sent.
2019.11.25 20:44:17 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 3, but we need 110. Waiting 107 seconds. Currently 1 messages are waiting to be sent.

ASC_DEBUG!!! 2019.11.25 20:45:09 - EventProcessingWindowRec: Buero_li - RECEIVED EVENT: device-manufid: 4151 device-type: EndDevice device-modelid: lumi.sensor_magnet.aq2 device-powersource: Battery device-manufname: LUMI device-ieeeaddr: 0x00158d000322ae64 device-swbuildid: 3000-0001 device-status: online device-hwversion: 2 device-friendlyname: Buero_rechts_Sensor device-datecode: 20161128 device-nwkaddr: 50684 linkquality: 47 state: open contact: false voltage: 3005 battery: ok battery_level: 100 - IDENTIFIED EVENT: open - STORED EVENT: open

ASC_DEBUG!!! 2019.11.25 20:45:09 - EventProcessingWindowRec: Buero_li - HOMEMODE: none QueryShuttersPosWinRecTilted:1 QueryShuttersPosWinRecComfort: 1

ASC_DEBUG!!! 2019.11.25 20:45:09 - EventProcessingWindowRec: Buero_re - RECEIVED EVENT: device-manufid: 4151 device-type: EndDevice device-modelid: lumi.sensor_magnet.aq2 device-powersource: Battery device-manufname: LUMI device-ieeeaddr: 0x00158d000322ae64 device-swbuildid: 3000-0001 device-status: online device-hwversion: 2 device-friendlyname: Buero_rechts_Sensor device-datecode: 20161128 device-nwkaddr: 50684 linkquality: 47 state: open contact: false voltage: 3005 battery: ok battery_level: 100 - IDENTIFIED EVENT: open - STORED EVENT: open

ASC_DEBUG!!! 2019.11.25 20:45:09 - EventProcessingWindowRec: Buero_re - HOMEMODE: none QueryShuttersPosWinRecTilted:1 QueryShuttersPosWinRecComfort: 1
2019.11.25 20:46:06 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 3, but we need 110. Waiting 107 seconds. Currently 2 messages are waiting to be sent.


Hatte gestern ja ein wenig mit dem normalen doif herum probiert, da hat es nicht einmal nicht reagiert. Kann das sein ? Gibt es da einen Bug oder Fehler ? War grad min 20-30 min oben bei den Kids, in der Zeit gab es keine Befehle für Max Komponenten. Jetzt komm ich runter mach das Fenster auf und schau, ob es funktioniert, keine Reaktion, da wieder Credits alle.

EDIT::

Jetzt grad noch mal geschaut, war um 20:47 noch 1 message are waiting. Danach stand off am Thermostat, weil das Fenster noch offen war, jetzt hab ich das Fenster zu gemacht, jetzt steht schon wieder...

2019.11.25 20:51:40 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 8, but we need 110. Waiting 102 seconds. Currently 2 messages are waiting to be sent.

[Wzut]

Bitte Log Ausgaben in Code Tags setzen , nicht als Zitat ( der # Knopf )
Das schaut aus als ob du deinen cm unter Dauerfeuer setzt , d.h entweder mit deinem DOIF ( do always ? ) oder deine FKs erzeugen ständig Events.
Beides sollte man aber im Eventmonitor sehen, wenn nicht den verbose Level am cm Device mal auf 5 hochsetzen. 

Edit : habe ich gerade gefunden -> https://forum.fhem.de/index.php/topic,105668.0/topicseen.html
Da würde ich dann aber bei den DOIF Gurus nochmal nachfassen, sehe dort in deinem ersten Post so Dinge wie do always und wait ... 

[D3ltorohd]

Also die FK's senden nur genau einmal bei Status Änderung, also Fenster auf oder zu.

Mit dem do Always muss ich noch mal schauen, das habe ich so verstanden, das der Befehl sonst genau nur einmal abgesetzt wird und danach wird nicht mehr gesendet, egal was der FK meldet. Wait ist ja nur damit er nicht direkt bei Fenster auf aus schaltet sondern 10 Sekunden wartet falls man mal nur kurz das Fenster öffnet und wieder schließt.

Aber ich Frage da noch mal im doif nach.

Komisch nur das es mit meinem ursprünglichen Didi keine Probleme gab und da hatte ich öfters getestet ob es geht.

Mit den fsc kann das nichts zu tun haben ?

[Wzut]

Mit den fsc kann das nichts zu tun haben ?

egal was da jetzt antworte, es wäre Kaffeesatz Leserei.
Nur dein Log (mit entsprechendem verbose Level) oder Event Monitor kann verraten was da im Detail passiert.

[D3ltorohd]

Melde mich heute Abend hoffentlich mit dem richtigen Log.

[D3ltorohd]

Also ich glaube das lag wie du schon sagtest an dem "do always" da wird wohl mehrmals gesendet, hab es nicht angeschaut, aber direkt umgestellt ohne "do always" und nun scheint es auch mit den Credits hin zu hauen... Werde das mal weiter beobachten.

[D3ltorohd]

So bis jetzt läuft es wie gewollt. Die Credits sind auch nicht gleich verbraucht, wunderbar.

Eine Frage hätte ich noch, habe 2 Heizkörper die mit einem WT verbunden sind, indem Fall muss ich Fenster offen an das WT senden, oder auch an die HT's ? Das WT kann ich ja auch mit dem fsc verbinden.

[Wzut]

von der reinen Logik reicht nur zum WT, dieses gibt die Info dann an die beiden HTs weiter.
Ganz auf der sicheren Seite bist natürlich wenn die Info an alle drei geht, wobei ich bei dem Thema WT an mehr als ein HT keine eigene Erfahrung habe.

[D3ltorohd]

Wenn das WT an die HT's sendet, kostet das auch Credits ? Dann würde das senden an das WT Credits kosten, dann das senden vom WT an die HT's gleich noch mal. Ich teste mal ob es auch geht, wenn ich direkt die HT's off schalte, ohne über das WT zu gehen.

[Wzut]

Wenn das WT an die HT's sendet, kostet das auch Credits ?

ja das WT aber nicht deinen CUL wer sendet zahlt, Empfang ist kostenlos