CUL_FHTTk FHT80TF-2 virtual für FHT80B mit fhem

Begonnen von Newti64, 04 Oktober 2020, 12:46:56

Vorheriges Thema - Nächstes Thema

Newti64

Hallo,
ich betreibe seit vielen Jahren FHEM mit 9x FHT80B, 2x FHT80TF-2 und ein paar MAX-Fensterkontakten (extra CUL-MAX)
Jetzt wollte ich weitere Fenster mit MAX-Sensoren ausstatten und in FHEM das Modul CUL_FHTTk mit model virtual verwenden, um den Fenster-Zustand in den FHTs zu ändern.
Was ich in der Wiki-Seite des CUL_FHTTk nicht ganz verstanden habe, ist die Beschränkung auf 4 Stück.
Ist damit gemeint, ich kann z.B.:
1. CUL_FHTTk virtual mit  1. FHT verbinden,
2. CUL_FHTTk virtual mit  2. FHT verbinden,
3. CUL_FHTTk virtual mit  3. FHT verbinden,
4. CUL_FHTTk virtual mit  4. FHT verbinden,
also 4x CUL_FHTTk virtual mit jeweils 1x FHT ?

oder
1. CUL_FHTTk virtual mit 4x FHT verbinden ?
und
2. CUL_FHTTk virtual mit 4x FHT verbinden ?
3. CUL_FHTTk virtual mit 4x FHT verbinden ?
4. CUL_FHTTk virtual mit 4x FHT verbinden ?

So viel ich gelesen habe gilt die Beschränkung auch/oder wegen der CUL Firmware (1.66 und 1.67 ist bei mir im Einsatz).
Da ich 2 CUL mit unterschiedlichen FHT-IDs habe, am CUL1 sind 4 FHTs angemeldet, am CUL2 sind 5 FHTs angemeldet, habe ich gehofft, dass es dadurch möglich ist insgesamt 8 FHTs (4x FHT virtual pro CUL) mit virtuellen Fensterkontakten zu verbinden.
Leider bekomme ich nur 4 FHTs verbunden, ohne dass bei den zuerst verbundenen FHTs die Fenster-Symbole zu blinken anfangen.

Mein Wunsch-Zenario wäre:
FHTTK-EG virtual mit 3 FHT über CUL1
FHTTK-WiGa virtual mit 1 FHT über CUL1
FHTTK-OG virtual mit 4 FHT über CUL2
FHTTK-DG virtual mit 1 FHT über CUL2 (oder über einen FHTTK-2, falls nicht möglich)

Die FHTs will ich nicht ersetzten, da sie ja noch einwandfrei funktionieren.
Im schlimmsten Fall verwende ich die externen Eingänge der beiden FHTTK-2 um sie am Raps-GPIO zu steuern, dann kann ich mehrer MAX-Sensoren mit DOIF auf GPIO-FHTTK-2 mit 2 virtuellen FHTTK ersetzen, dabei bleibt nur 1 FHT auf der Stecke.

Hoffentlich hat hier da schon mehr Erfahrung.

Grüße
Claus

Matscher

Hi Claus,
also aktuell können von der CUL Firmware nur 4 Fensterkontakte (FHT80-TF) simuliert werden. An welchem FHT80b jeweils ein virtueller FHT80-TF angelernt wird, ist für den CUL irrelevant. Warum nur 4? Das war damals die Entscheidung um die 1% Regel (LOVF) nicht zu überschreiten. Denkbar sind sicherlich mehr, solang der CUL nicht noch übermäßig mehr Kommunikation leisten muss.

Mit der Einschränkung auf 4 virtuelle Kontakte ist es im Wiki leider nicht ganz so eindeutig beschrieben.
Wenn ich Dein Szenario richtig verstanden habe, willst Du auch nur 4 FHT80-TK's simulieren (auch noch aufgeteilt auf zwei CUls), die an mehreren FHT80b's angelernt werden/sind. Dem sollte nichts eingegen stehen.

Gruß,Steve
Rasp 3
CUL V3 868Mhz + nanoCUL 868Mhz als RFR + nanoCUL 868Mhz für Homematic + SIGNALduino
Zigbee CC2531 - Aquara TempSensor
MySensors Ethernet Gateway, Water meter, Gas meter
Modul: 09_CUL_FHTTK.pm (assumed), culfw part HAS_FHT_TF

Newti64

Hallo Steve,
schon mal danke für die Info.
Zitat von: Matscher am 04 Oktober 2020, 22:26:00
Mit der Einschränkung auf 4 virtuelle Kontakte ist es im Wiki leider nicht ganz so eindeutig beschrieben.
Da bin ich ja beruhigt, dass ich das nicht ganz versanden habe :-)
Zitat von: Matscher am 04 Oktober 2020, 22:26:00
Wenn ich Dein Szenario richtig verstanden habe, willst Du auch nur 4 FHT80-TK's simulieren (auch noch aufgeteilt auf zwei CUls), die an mehreren FHT80b's angelernt werden/sind. Dem sollte nichts eingegen stehen.
Ja, es sollen nur 4 virtuelle FHT80-TK's simuliert werden und somit nur 2 pro CUL.
So wie ich dich jetzt verstanden habe, könnte ich pro CUL 4 virtuelle FHT80-TK's anlegen, also in meinem Fall wären 8 virtuelle FHT80-TK's möglich?
Dazu darf ich auch noch meine beiden FHT80-TK-2 (richtige Hardware) weiter benutzen?

Das Szenario 4 virtuelle FHT80-TK's auf 2 CULs verteilt habe ich heute nochmal probiert, indem ich alle FHTTKs in den FHT80b gelöscht habe und anschließend jeweils nur einen virtuellen FHTTK pro FHT80b verbunden habe. (Im FHT80b könnten ja auch bis zu 4 verschiedene FHTTKs angemeldet werden.)
Jetzt sind
FHTTK-EG virtual    mit 1x FHT80b über CUL1
FHTTK-WiGa virtual mit 3x FHT80b über CUL1
FHTTK-OG virtual    mit 4x FHT80b über CUL2
FHTTK-DG virtual    mit 1x FHT80b über CUL2
miteinander verbunden.
Die Bestätigung der Verbindung am FHT80b kam jeweils sofort.
Das Reading in FHEM bei den FHT80b 'warnings   Fault on window sensor' ist nicht bei allen FHT80b gleich verschwunden, aber nach ein paar Stunden wieder gekommen. Im Moment ist nur ein FHT80b ohne Warnung. Die Fenster-Symbole blinken natürlich auch.
Ich lass das jetzt mal noch einen Tag in Ruhe laufen, mal sehen ob sich das wieder automatisch verbindet.

Grüße
Claus




Matscher

Hallo Claus,

Zitat von: Newti64 am 05 Oktober 2020, 20:11:57
So wie ich dich jetzt verstanden habe, könnte ich pro CUL 4 virtuelle FHT80-TK's anlegen, also in meinem Fall wären 8 virtuelle FHT80-TK's möglich?
Dazu darf ich auch noch meine beiden FHT80-TK-2 (richtige Hardware) weiter benutzen?

ja ganz genau.

Zitat von: Newti64 am 05 Oktober 2020, 20:11:57FHTTK-EG virtual    mit 1x FHT80b über CUL1
FHTTK-WiGa virtual mit 3x FHT80b über CUL1FHTTK-OG virtual    mit 4x FHT80b über CUL2
FHTTK-DG virtual    mit 1x FHT80b über CUL2
Beim Anlernen musst Du darauf achten, das Du innerhalb von 60 Sekunden alle FHT80b die zum Bespiel den FHTTK-OG virtual haben sollen in den Anlernmodus steckst und nicht den virtuellen FHTTK jedes Mal neu auf Pair setzt. Dann kommen die anderen nicht mehr mit. Das kann sich zwar dann in Laufe der Zeit ändern, weil die FHT80B dann immer wieder auf Empfang gehen und versuchen den Fensterkontakt zu "hören".
Hat es bei Dir soweit funktioniert?
Grüße,Steve
Rasp 3
CUL V3 868Mhz + nanoCUL 868Mhz als RFR + nanoCUL 868Mhz für Homematic + SIGNALduino
Zigbee CC2531 - Aquara TempSensor
MySensors Ethernet Gateway, Water meter, Gas meter
Modul: 09_CUL_FHTTK.pm (assumed), culfw part HAS_FHT_TF

Newti64

#4
Hallo Steve,
leider hat es so nicht funktioniert. Es war auch nicht nachvollziehbar wie und wann das Pairing aus dem Tritt kam, bzw. wieder mal funktionierte.
Ich hatte aber beim Anlernen für jede Verbindung Pair gedrückt und nicht wie du es beschreibst die 4x FHT80b in den Anlernmodus geschaltet und dann erst Pair am zugehörigen virtuellen Device gestartet.
Nachdem ich noch einen FHT80TF (ohne -2), mit korrodiertem Batterie-Kontakt, im Keller liegen hatte, habe ich den jetzt repariert.
Jetzt sind 3x FHT80TF(-2) als echte Hardware vorhanden. Diese habe ich für 3 virtuelle Devices ersetzt und mit BS170 Transistoren die externen Kontakte mit dem Raspberry Pi GPIO verbunden um zu sehen, ob mein Vorhaben überhaupt funktioniert mit echter Hardware.
Angelernt habe ich jetzt die 3 echten FHT80TF(-2) an die FHT80b.
Aber hier auch jeden extra mit der Pair-Taste angelernt.
Also am 1. FHT80b ins Menu Fenster und den oberen Knopf länger drücken bis Code erscheint, dann am FHTTK_OG Taste drücken, es erscheint sofort EA im Display vom FHT80b.
Das gleiche habe ich für die anderen 3 FHT80b und mit dem FHTTK_OG durchgeführt. ... und mit FHTTK_WiGa den zugehörigen FHT80b .... und mit FHTTK_EG die letzten 4 FHT80b... gemacht.

Blieb nur noch FHTTKv_DG als virtueller Kontakt übrig mit 1 FHT80b. Bei dem habe ich es so gemacht, wie du es beschreibst, da es ja nur einer ist :-) macht es keinen Unterschied :-)

Bei den FHT80b, die mit den Hardware-FHTTK verbunden sind funktioniert alles, so wie es soll.
Leider nicht bei dem einen virtuellen FHTTKv_DG, egal welche CUL ich als IODevice angebe. Ich habe auch neu gepair, nachdem ich das IODevice geändert hatte.
Es kommt immer wieder die Fehlermeldung bei windowsensor fault und bei warnings Fault on window sensor, das Fenstersymbol am FHT80b blinkt.
Kann es noch an meiner Konfiguration des virtuellen FHTTKv_DG liegen?
Hier mal ein list FHTTKv_DG

Internals:
   COCStZi_MSGCNT 248
   COCStZi_RAWMSG T86310A01
   COCStZi_RSSI -80.5
   COCStZi_TIME 2020-10-12 20:41:47
   COC_MSGCNT 58
   COC_RAWMSG T86310A02
   COC_RSSI   -82
   COC_TIME   2020-10-11 16:41:50
   CODE       86310a
   DEF        86310A
   FUUID      5c4cd132-f33f-3e6f-3a7b-e999d9106b346dbd
   IODev      COC
   LASTInputDev COCStZi
   MSGCNT     306
   NAME       FHTTKv_DG
   NR         852
   OPEN       1
   PREVSTATE  Open
   PREVTIMESTAMP 1602527854
   STATE      Open
   TYPE       CUL_FHTTK
   PREV:
     STATE      01
     TIMESTAMP  1602528107
   READINGS:
     2020-10-11 16:42:46   Previous        Closed
     2020-10-12 20:41:47   Reliability     ok
     2020-10-11 11:19:30   Sync            Syncing
     2020-10-11 12:54:03   Test            Success
     2020-10-11 21:15:45   Unknown         ff
     2020-10-12 20:41:47   Window          Open
     2020-10-12 20:41:47   batteryState    ok
     2020-10-12 20:41:47   state           Open
Attributes:
   IODev      COC
   devStateIcon Closed:fts_window_2w Open:fts_window_2w_open
   event-min-interval 3600
   event-on-change-reading .*
   genericDeviceType contact
   group      FHTTK
   icon       fts_window_2w_open
   model      virtual


Ich werde den einen virtuellen FHTTKv_DG nochmal am FHT_DaZi löschen und etwas später neu verbinden, und dann das Logfile mal posten, vielleicht kann man ja da was finden.

Grüße
Claus

Hier noch das Log vom virtuellen FHTTKv_DG.
Was mich wundert, ist dass es immer open und closed schickt, obwohl kein Fenster geöffnet wurde. Ich disable mal das DOIF der Fenster-Auswertung.

2020-10-12_22:00:30 FHTTKv_DG Closed
2020-10-12_22:00:30 FHTTKv_DG Window: Closed
2020-10-12_22:00:31 FHTTKv_DG Success
2020-10-12_22:00:31 FHTTKv_DG Closed
2020-10-12_22:04:28 FHTTKv_DG Open
2020-10-12_22:04:28 FHTTKv_DG Window: Open
2020-10-12_22:06:27 FHTTKv_DG Closed
2020-10-12_22:06:27 FHTTKv_DG Window: Closed
2020-10-12_22:06:44 FHTTKv_DG Open
2020-10-12_22:06:44 FHTTKv_DG Window: Open
2020-10-12_22:08:38 FHTTKv_DG Closed
2020-10-12_22:08:38 FHTTKv_DG Window: Closed
2020-10-12_22:10:14 FHTTKv_DG Window: Open
2020-10-12_22:10:14 FHTTKv_DG Open
2020-10-12_22:10:40 FHTTKv_DG Window: Closed
2020-10-12_22:10:40 FHTTKv_DG Closed
2020-10-12_22:12:13 FHTTKv_DG Open
2020-10-12_22:12:13 FHTTKv_DG Window: Open
2020-10-12_23:40:34 FHTTKv_DG Closed
2020-10-12_23:40:34 FHTTKv_DG Window: Closed
2020-10-12_23:42:59 FHTTKv_DG Window: Open
2020-10-12_23:42:59 FHTTKv_DG Open
2020-10-12_23:46:31 FHTTKv_DG Window: Closed
2020-10-12_23:46:31 FHTTKv_DG Closed
2020-10-12_23:51:25 FHTTKv_DG Window: Open
2020-10-12_23:51:25 FHTTKv_DG Open
2020-10-12_23:59:10 FHTTKv_DG Window: Closed
2020-10-12_23:59:10 FHTTKv_DG Closed
2020-10-12_23:59:51 FHTTKv_DG Window: Open
2020-10-12_23:59:51 FHTTKv_DG Open
2020-10-13_00:07:35 FHTTKv_DG Window: Closed
2020-10-13_00:07:35 FHTTKv_DG Closed
2020-10-13_00:08:17 FHTTKv_DG Window: Open
2020-10-13_00:08:17 FHTTKv_DG Open
2020-10-13_00:16:01 FHTTKv_DG Window: Closed
2020-10-13_00:16:01 FHTTKv_DG Closed
2020-10-13_00:16:43 FHTTKv_DG Window: Open
2020-10-13_00:16:43 FHTTKv_DG Open
2020-10-13_00:20:14 FHTTKv_DG Window: Closed
2020-10-13_00:20:14 FHTTKv_DG Closed
2020-10-13_00:25:09 FHTTKv_DG Window: Open
2020-10-13_00:25:09 FHTTKv_DG Open
2020-10-13_00:32:52 FHTTKv_DG Window: Closed
2020-10-13_00:32:52 FHTTKv_DG Closed
2020-10-13_00:33:34 FHTTKv_DG Window: Open
2020-10-13_00:33:34 FHTTKv_DG Open
2020-10-13_00:37:05 FHTTKv_DG Window: Closed
2020-10-13_00:37:05 FHTTKv_DG Closed
2020-10-13_00:37:47 FHTTKv_DG Window: Open
2020-10-13_00:37:47 FHTTKv_DG Open
2020-10-13_00:53:56 FHTTKv_DG Window: Closed
2020-10-13_00:53:56 FHTTKv_DG Closed
2020-10-13_00:54:39 FHTTKv_DG Window: Open
2020-10-13_00:54:39 FHTTKv_DG Open
2020-10-13_00:58:09 FHTTKv_DG Window: Closed
2020-10-13_00:58:09 FHTTKv_DG Closed
2020-10-13_00:58:52 FHTTKv_DG Window: Open
2020-10-13_00:58:52 FHTTKv_DG Open
2020-10-13_01:02:22 FHTTKv_DG Window: Closed
2020-10-13_01:02:22 FHTTKv_DG Closed
2020-10-13_01:07:18 FHTTKv_DG Window: Open
2020-10-13_01:07:18 FHTTKv_DG Open
2020-10-13_01:10:47 FHTTKv_DG Window: Closed
2020-10-13_01:10:47 FHTTKv_DG Closed
2020-10-13_01:11:31 FHTTKv_DG Window: Open
2020-10-13_01:11:31 FHTTKv_DG Open
2020-10-13_01:15:00 FHTTKv_DG Window: Closed
2020-10-13_01:15:00 FHTTKv_DG Closed
2020-10-13_01:15:44 FHTTKv_DG Window: Open
2020-10-13_01:15:44 FHTTKv_DG Open
2020-10-13_01:19:13 FHTTKv_DG Window: Closed
2020-10-13_01:19:13 FHTTKv_DG Closed
2020-10-13_01:19:57 FHTTKv_DG Window: Open
2020-10-13_01:19:57 FHTTKv_DG Open
2020-10-13_01:23:26 FHTTKv_DG Window: Closed
2020-10-13_01:23:26 FHTTKv_DG Closed
2020-10-13_01:36:49 FHTTKv_DG Window: Open
2020-10-13_01:36:49 FHTTKv_DG Open
2020-10-13_01:40:17 FHTTKv_DG Window: Closed
2020-10-13_01:40:17 FHTTKv_DG Closed
2020-10-13_01:41:02 FHTTKv_DG Window: Open
2020-10-13_01:41:02 FHTTKv_DG Open
2020-10-13_01:44:30 FHTTKv_DG Window: Closed
2020-10-13_01:44:30 FHTTKv_DG Closed
2020-10-13_01:49:28 FHTTKv_DG Window: Open
2020-10-13_01:49:28 FHTTKv_DG Open
2020-10-13_01:52:55 FHTTKv_DG Window: Closed
2020-10-13_01:52:55 FHTTKv_DG Closed
2020-10-13_01:53:41 FHTTKv_DG Window: Open
2020-10-13_01:53:41 FHTTKv_DG Open
2020-10-13_01:57:08 FHTTKv_DG Window: Closed
2020-10-13_01:57:08 FHTTKv_DG Closed


2020-10-12_22:01:52 FHT_DaZi desired-temp: 8.0
2020-10-12_22:01:53 FHT_DaZi window: open
2020-10-12_22:01:53 FHT_DaZi warnings: Window open
2020-10-12_22:07:31 FHT_DaZi desired-temp: 22.0
2020-10-12_22:07:32 FHT_DaZi measured-temp: 24.3
2020-10-12_22:07:32 FHT_DaZi temperature: 24.3
2020-10-12_22:09:40 FHT_DaZi window: closed
2020-10-12_22:09:40 FHT_DaZi warnings: none
2020-10-12_22:13:08 FHT_DaZi desired-temp: 8.0
2020-10-12_22:13:09 FHT_DaZi window: open
2020-10-12_22:13:09 FHT_DaZi warnings: Window open
2020-10-12_22:22:56 FHT_DaZi measured-temp: 23.5
2020-10-12_22:22:56 FHT_DaZi temperature: 23.5
2020-10-12_22:38:36 FHT_DaZi measured-temp: 22.9
2020-10-12_22:38:36 FHT_DaZi temperature: 22.9
2020-10-12_22:54:16 FHT_DaZi measured-temp: 22.4
2020-10-12_22:54:16 FHT_DaZi temperature: 22.4
2020-10-12_23:07:58 FHT_DaZi measured-temp: 22.3
2020-10-12_23:07:58 FHT_DaZi temperature: 22.3
2020-10-12_23:21:41 FHT_DaZi desired-temp: 22.0
2020-10-12_23:21:41 FHT_DaZi window: closed
2020-10-12_23:21:41 FHT_DaZi windowsensor: fault
2020-10-12_23:21:41 FHT_DaZi warnings: Fault on window sensor
2020-10-12_23:23:39 FHT_DaZi measured-temp: 22.6
2020-10-12_23:23:39 FHT_DaZi temperature: 22.6
2020-10-12_23:39:24 FHT_DaZi desired-temp: 21.5
2020-10-12_23:47:07 FHT_DaZi actuator: 9%
2020-10-12_23:49:05 FHT_DaZi actuator: 16%
2020-10-12_23:51:03 FHT_DaZi actuator: 24%
2020-10-12_23:54:57 FHT_DaZi actuator: 35%
2020-10-12_23:54:58 FHT_DaZi measured-temp: 20.4
2020-10-12_23:54:58 FHT_DaZi temperature: 20.4
2020-10-12_23:56:56 FHT_DaZi desired-temp: on
2020-10-13_00:00:50 FHT_DaZi actuator: 0%
2020-10-13_00:02:49 FHT_DaZi desired-temp: 22.0
2020-10-13_00:04:46 FHT_DaZi desired-temp: 8.0
2020-10-13_00:06:43 FHT_DaZi desired-temp: on
2020-10-13_00:10:38 FHT_DaZi desired-temp: 22.0
2020-10-13_00:12:36 FHT_DaZi desired-temp: on
2020-10-13_00:18:28 FHT_DaZi desired-temp: 8.0
2020-10-13_00:18:29 FHT_DaZi measured-temp: 19.8
2020-10-13_00:18:29 FHT_DaZi temperature: 19.8
2020-10-13_00:18:29 FHT_DaZi window: open
2020-10-13_00:18:29 FHT_DaZi windowsensor: ok
2020-10-13_00:18:29 FHT_DaZi warnings: Window open
2020-10-13_00:20:27 FHT_DaZi desired-temp: 22.0
2020-10-13_00:54:06 FHT_DaZi measured-temp: 19.7
2020-10-13_00:54:06 FHT_DaZi temperature: 19.7
2020-10-13_00:55:41 FHT_DaZi desired-temp: on
2020-10-13_01:09:22 FHT_DaZi actuator: 99%
2020-10-13_01:09:24 FHT_DaZi window: closed
2020-10-13_01:09:24 FHT_DaZi windowsensor: fault
2020-10-13_01:09:24 FHT_DaZi warnings: Fault on window sensor

Newti64

#5
Hallo,
das andauernde Open / Closed des virtuellen FHTTK lag an meiner Auswertung der MAX-Fenstersensoren. Hatte da ein do always drin.
Jetzt läuft es besser, ich trau der Sache aber noch nicht :-), werde weiter beobachten und wieder berichten wenn es 1-2 Wochen ohne Fehler läuft.
Danke für die Hilfe und die vielen neuen Infos.
Grüße
Claus

Newti64

#6
Hallo,
irgendwas passt aber immer noch nicht.
Hier die Readings im DOIF:
mode enabled 2020-10-14 23:24:19
state  cmd_1   2020-10-16 10:53:56
Das bedeutet für mich, letzte Aktion cmd_1 um 10:53 Uhr, seitdem kein anderer Befehl. cmd_1 ist ein set FHTTKv_DG Open
die Readings im FHTTKv_DG:
Previous      Closed    2020-10-16 10:50:30
Reliability     ok         2020-10-16 21:31:20
Sync            Syncing 2020-10-12 21:42:49
Test             Success 2020-10-12 22:00:31
Unknown      ff          2020-10-11 21:15:45
Window        Open    2020-10-16 21:31:20
batteryState ok        2020-10-16 21:31:20
state            Open    2020-10-16 21:31:20
Also letztes Closed um 10:50 Uhr passt in etwa zum DOIF cmd_1 um 10:53:56 Uhr als das Fenster geöffnet wurde.
Aber das Logfile irritiert mich. Am 15.10. um 07:47 Uhr wurde das Fenster oder die Tür geöffnet und um 23:35 Uhr Fenster und Tür wieder geschlossen. Solange Fenster/Türe offen ist, alles ok, nur wenn beide Kontakte Closed sind, was ist da falsch? List kommt unten.

...
2020-10-15_07:22:03 FHTTKv_DG Window: Open
2020-10-15_07:22:03 FHTTKv_DG Open
2020-10-15_07:32:53 FHTTKv_DG Window: Closed
2020-10-15_07:32:53 FHTTKv_DG Closed
2020-10-15_07:34:42 FHTTKv_DG Window: Open
2020-10-15_07:34:42 FHTTKv_DG Open
2020-10-15_07:41:18 FHTTKv_DG Window: Closed
2020-10-15_07:41:18 FHTTKv_DG Closed
2020-10-15_07:47:21 FHTTKv_DG Window: Open
2020-10-15_07:47:21 FHTTKv_DG Open
----------------------------------------------
2020-10-15_23:35:52 FHTTKv_DG Closed
2020-10-15_23:35:52 FHTTKv_DG Window: Closed
2020-10-15_23:35:57 FHTTKv_DG Window: Open
2020-10-15_23:35:57 FHTTKv_DG Open
2020-10-15_23:36:39 FHTTKv_DG Window: Closed
2020-10-15_23:36:39 FHTTKv_DG Closed
2020-10-15_23:44:23 FHTTKv_DG Window: Open
2020-10-15_23:44:23 FHTTKv_DG Open
2020-10-15_23:54:34 FHTTKv_DG Window: Closed
2020-10-15_23:54:34 FHTTKv_DG Closed
2020-10-15_23:57:02 FHTTKv_DG Window: Open
2020-10-15_23:57:02 FHTTKv_DG Open
2020-10-16_00:02:59 FHTTKv_DG Window: Closed
2020-10-16_00:02:59 FHTTKv_DG Closed
2020-10-16_00:05:28 FHTTKv_DG Window: Open
2020-10-16_00:05:28 FHTTKv_DG Open
... hier etwas gekürzt, geht die ganze Nacht so.
2020-10-16_10:29:26 FHTTKv_DG Open
2020-10-16_10:32:52 FHTTKv_DG Window: Closed
2020-10-16_10:32:52 FHTTKv_DG Closed
2020-10-16_10:33:39 FHTTKv_DG Window: Open
2020-10-16_10:33:39 FHTTKv_DG Open
2020-10-16_10:37:05 FHTTKv_DG Window: Closed
2020-10-16_10:37:05 FHTTKv_DG Closed
2020-10-16_10:42:05 FHTTKv_DG Window: Open
2020-10-16_10:42:05 FHTTKv_DG Open
2020-10-16_10:45:31 FHTTKv_DG Window: Closed
2020-10-16_10:45:31 FHTTKv_DG Closed
2020-10-16_10:50:30 FHTTKv_DG Window: Open
2020-10-16_10:50:30 FHTTKv_DG Open

Hier um 10:50 Uhr wurde die Tür wieder geöffnet und das log hört auf.
Die eine hälfte vom DOIF funktioniert anscheinend, nur wenn Fenster und Tür zu sind, da passt noch was nicht? Aber ich komm nicht drauf.
Hier das List vom DOIF:
Internals:
   DEF        ([MAX_1bc31e_TkDaZi] eq "opened"
              or [MAX_1bc287_FkDaZi] eq "opened")
                  (set FHTTKv_DG Open)
                 DOELSEIF ([MAX_1bc31e_TkDaZi] eq "closed"
                           and [MAX_1bc287_FkDaZi] eq "closed")
                        (set FHTTKv_DG Closed)
   MODEL      FHEM
   NAME       di_FHTTKv_DG
   NOTIFYDEV  MAX_1bc287_FkDaZi,MAX_1bc31e_TkDaZi,global
   NR         851
   NTFY_ORDER 50-di_FHTTKv_DG
   STATE      cmd_1
   TYPE       DOIF
   VERSION    22913 2020-10-04 21:46:02
   READINGS:
     2020-10-16 10:57:45   Device          MAX_1bc287_FkDaZi
     2020-10-16 10:53:56   cmd             1
     2020-10-16 10:53:56   cmd_event       MAX_1bc31e_TkDaZi
     2020-10-16 10:53:56   cmd_nr          1
     2020-10-16 10:57:45   e_MAX_1bc287_FkDaZi_STATE opened
     2020-10-16 10:52:56   e_MAX_1bc31e_TkDaZi_STATE opened
     2020-10-14 23:24:19   mode            enabled
     2020-10-16 10:53:56   state           cmd_1
     2020-10-16 10:53:56   wait_timer      no timer
   Regex:
     accu:
     cond:
       MAX_1bc287_FkDaZi:
         0:
           &STATE     ^MAX_1bc287_FkDaZi$
         1:
           &STATE     ^MAX_1bc287_FkDaZi$
       MAX_1bc31e_TkDaZi:
         0:
           &STATE     ^MAX_1bc31e_TkDaZi$
         1:
           &STATE     ^MAX_1bc31e_TkDaZi$
   attr:
     cmdState:
     wait:
       0:
         60
       1:
         60
     waitdel:
   condition:
     0          ::InternalDoIf($hash,'MAX_1bc31e_TkDaZi','STATE') eq "opened"  or ::InternalDoIf($hash,'MAX_1bc287_FkDaZi','STATE') eq "opened"
     1          ::InternalDoIf($hash,'MAX_1bc31e_TkDaZi','STATE') eq "closed"  and ::InternalDoIf($hash,'MAX_1bc287_FkDaZi','STATE') eq "closed"
   devices:
   do:
     0:
       0          set FHTTKv_DG Open
     1:
       0          set FHTTKv_DG Closed
     2:
   helper:
     DEVFILTER  ^global$|^MAX_1bc31e_TkDaZi$|^MAX_1bc287_FkDaZi$
     NOTIFYDEV  global|MAX_1bc31e_TkDaZi|MAX_1bc287_FkDaZi
     event      opened,RSSI: -77.5,onoff: 1
     globalinit 1
     last_timer 0
     sleepdevice MAX_1bc31e_TkDaZi
     sleepsubtimer -1
     sleeptimer -1
     timerdev   MAX_1bc287_FkDaZi
     timerevent opened,RSSI: -77.5,onoff: 1
     triggerDev MAX_1bc287_FkDaZi
     timerevents:
       opened
       RSSI: -77.5
       onoff: 1
     timereventsState:
       state: opened
       RSSI: -77.5
       onoff: 1
     triggerEvents:
       opened
       RSSI: -77.5
       onoff: 1
     triggerEventsState:
       state: opened
       RSSI: -77.5
       onoff: 1
   internals:
     all         MAX_1bc31e_TkDaZi:STATE MAX_1bc287_FkDaZi:STATE
   readings:
   trigger:
   uiState:
   uiTable:
Attributes:
   room       FHTTK
   wait       60:60

Warum wird bei dem 2. Teil im DOIF mit dem AND alle paar Minuten der Befehl gestartet, bzw. kommt beim FHTTKv_DG open und closed?
Grüße
Claus

Newti64

#7
Hallo,
bin einen Schritt weiter, ich habe beim DOIF jeweils ein :state hinzugefügt, seitdem schickt es nur bei Änderung noch was raus.
([MAX_1bc31e_TkDaZi:state] eq "opened"
or [MAX_1bc287_FkDaZi:state] eq "opened")
(set FHTTKv_DG Open)
DOELSEIF ([MAX_1bc31e_TkDaZi:state] eq "closed"
  and [MAX_1bc287_FkDaZi:state] eq "closed")
(set FHTTKv_DG Closed)

Das DOIF wurde ohne :state bei 2x Closed immer getriggert, sodas die Timestamp von cmd_2 oft aktualisiert wurde, und somit wohl auch ein Closed gesendet, aber kein Open.
In den Logs der MAX-Sensoren sind nur die Einträge, wenn Tür bzw. Fenster wirklich geöffnet/geschlossen wurde.
Bei den MAX-Sensoren habe ich das Attribut gesetzt.
attr event-on-change-reading .*

Trotzdem sind im Log vom FHTTKv_DG noch immer die Open/Closed Meldungen, wenn Fenster und Tür geschlossen ist.  :-\
Kann es sein, dass das noch alte Befehle sind, die in einer Warteschlange langsam abgearbeitet werden?

Grüße
Claus

Matscher

Hallo Claus


leider komme ich aus Zeitgründen nicht immer zum Antworten.


Mit DOIF kenne ich mich nicht aus. Was die alten Befehle angeht, merkt sich zumindest das culfhttk Modul und der CUL keine davon. Es wird der aktuelle Zustand benutzt. Da die FHT Fensterkontakte im Interval von ca. 2 min senden, kann es zwischendurch auch passieren das wieder jemand das Fenster schließt. Damit wird der Status auch intern geändert und der neue Befehl nur abgearbeitet.


Du schreibst, das das nur im geschlossenen Zustand passiert, das die Meldungen von closed au open und open auf closed toggeln?


Kannst Du mal beim CUL per "get <culname> raw T12" den FHT80TF buffer auslesen?


Gruß,
Steve
Rasp 3
CUL V3 868Mhz + nanoCUL 868Mhz als RFR + nanoCUL 868Mhz für Homematic + SIGNALduino
Zigbee CC2531 - Aquara TempSensor
MySensors Ethernet Gateway, Water meter, Gas meter
Modul: 09_CUL_FHTTK.pm (assumed), culfw part HAS_FHT_TF

Wzut

@Newti64 , Tipp : Vermeide Abfragen des state bei MAX , der kann mehr als nur die zwei Zustände haben.
Nutze immer das Reading onoff (0|1) um auf der sicheren Seite zu sein.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Newti64

#10
Hallo Wzut, hallo Steve,
@Wzut:
Danke für den Tipp zu den Max-Sensoren, ich habe das DoIF jetzt von state auf onoff Reading umgestellt und schon geht das DoIf so wie gewollt :-)
Auch im Logfile vom FHTTKv_DG sind jetzt auch nur noch die open/closed Meldungen so wie es sein soll :-)+

@Steve:
Mach dir keinen Stress, ich hab auch nicht immer Zeit :-) der Winter bzw. die Heizsaison fängt ja erst an.
Trotzdem zeigt das Wand-Thermostat immer wieder das blinkende Fenster-Symbol und beim FHTTKv_DG die Warnung, bzw. windowsensor: fault.
Ein get CULxxx raw T12 bringt folgendes Ergebnis, wenn windowsensor: fault ist.
Ich habe kurz nach 21:25 Uhr abgefragt:
raw => 00:86310A01


2020-10-22_19:08:40 FHT_DaZi desired-temp: 16.0
2020-10-22_19:08:41 FHT_DaZi window: closed
2020-10-22_19:08:41 FHT_DaZi windowsensor: fault
2020-10-22_19:08:41 FHT_DaZi warnings: Fault on window sensor
2020-10-22_19:38:06 FHT_DaZi measured-temp: 19.3
2020-10-22_20:01:34 FHT_DaZi desired-temp: 8.0
2020-10-22_20:01:34 FHT_DaZi battery: ok
2020-10-22_20:01:34 FHT_DaZi batteryState: ok
2020-10-22_20:01:34 FHT_DaZi lowtemp: ok
2020-10-22_20:01:34 FHT_DaZi window: open
2020-10-22_20:01:34 FHT_DaZi windowsensor: ok
2020-10-22_20:01:34 FHT_DaZi warnings: Window open
2020-10-22_21:08:08 FHT_DaZi desired-temp: 16.0
2020-10-22_21:08:09 FHT_DaZi window: closed
2020-10-22_21:08:09 FHT_DaZi windowsensor: fault
2020-10-22_21:08:09 FHT_DaZi warnings: Fault on window sensor
2020-10-22_21:21:50 FHT_DaZi actuator: 0%
2020-10-22_21:22:06 FHT_DaZi measured-temp: 19.3
2020-10-22_21:22:07 FHT_DaZi battery: ok
2020-10-22_21:22:07 FHT_DaZi batteryState: ok
2020-10-22_21:22:07 FHT_DaZi lowtemp: ok
2020-10-22_21:22:07 FHT_DaZi window: closed
2020-10-22_21:22:07 FHT_DaZi windowsensor: fault
2020-10-22_21:22:07 FHT_DaZi warnings: Fault on window sensor
2020-10-22_21:23:47 FHT_DaZi actuator: 0%

Dann den FHTTKv_DG auf closed gestellt und nochmal das raw T12 abgefragt:
raw => 00:86310A02

und das steht nach dem Fernster schließen und der 2 raw Abfrage im log:

2020-10-22_21:38:07 FHT_DaZi measured-temp: 19.3
2020-10-22_21:39:30 FHT_DaZi battery: ok
2020-10-22_21:39:30 FHT_DaZi batteryState: ok
2020-10-22_21:39:30 FHT_DaZi lowtemp: ok
2020-10-22_21:39:30 FHT_DaZi window: closed
2020-10-22_21:39:30 FHT_DaZi windowsensor: fault
2020-10-22_21:39:30 FHT_DaZi warnings: Fault on window sensor

Gleich nach einem Resync im FHTTKv_DG bring die raw Abfrage:
raw => 00:86310AFF

Etwas später, nach dem korrekten Anlernen:
raw => 00:86310A01

Aber es wechseln sich wieder windowsensor: failed/ok in etwa jeder Stunde ab.

Grüße
Claus

Matscher

Hallo Claus,

wie ist jetzt der aktuelle Stand? Wechselt sich noch der windowsensor status von ok auf failed für den FHTTKv_DG ? Eigentlich sollte sich mit der Zeit der FHT80b an den Intervall des FHTTKv_DG anpassen.
[/size]Kann gut möglich sein, das der Empfang schlecht ist!?
[/size]
[/size]Gruß,
[/size]Steve
Rasp 3
CUL V3 868Mhz + nanoCUL 868Mhz als RFR + nanoCUL 868Mhz für Homematic + SIGNALduino
Zigbee CC2531 - Aquara TempSensor
MySensors Ethernet Gateway, Water meter, Gas meter
Modul: 09_CUL_FHTTK.pm (assumed), culfw part HAS_FHT_TF

Newti64

Hallo Matscher,
der Stand ist leider unverändert. Der Wechsel von ok und failed verschwindet nicht. Obwohl ich jetzt ja auf nur einen virtuellen FHTTK reduziert hatte.

Ich hab jetzt FHTTKv_DG deaktivert, und das DOIF so geändert, dass es ein (set FHT_DaZi desired-temp [FHT_DaZi:windowopen-temp]) bzw. (set FHT_DaZi desired-temp [FHT_DaZi:day-temp]) setzt.
Das geht ohne Fehlermeldungen und für die anderen FHT's hab ich die drei ferngesteuerten echten FHTTK's.

Aber wenn noch jemand eine Idee hat, bin ich gerne bereit weiter zu testen. Über die Feiertage finde ich bestimmt etwas Zeit dafür.

Grüße
Claus

Matscher

Hallo Claus,
das ist natürlich nicht so erfeulich. Hast Du einen Logauszug vom virtuellen FHTTKv_DG oder könntest einen erstellen? Der eine CUL sollte ja hoffentlcih den anderen hören können. Vllt. kann man so erkennen, ob der Interval überhaupt stimmt. Was noch interessanrt ist, was das für CULs sind? In der einen Definition kann man COC lesen, ist das zufällig einer?
Grüße,Steve
Rasp 3
CUL V3 868Mhz + nanoCUL 868Mhz als RFR + nanoCUL 868Mhz für Homematic + SIGNALduino
Zigbee CC2531 - Aquara TempSensor
MySensors Ethernet Gateway, Water meter, Gas meter
Modul: 09_CUL_FHTTK.pm (assumed), culfw part HAS_FHT_TF

Newti64

#14
Hallo Steve,
da der FHEM-Raspi im Keller ist und die Kellerdecke das Signal sehr abschwächt habe ich im EG und im OG jeweils einen weiteren Raspberry Pi, diese sind per ser2net mit dem FHEM-Raspi im Keller verbunden. Am Raps-EG steckt ein SCC und am Raps-OG steckt ein COC V10.
Hier ein Auszug des Logs FHTTKv_DG

2020-10-22_04:43:05 FHTTKv_DG Open
2020-10-22_04:43:05 FHTTKv_DG Window: Open
2020-10-22_04:46:37 FHTTKv_DG Closed
2020-10-22_04:46:37 FHTTKv_DG Window: Closed
2020-10-22_07:16:35 FHTTKv_DG Open
2020-10-22_07:16:35 FHTTKv_DG Window: Open
2020-10-22_21:31:39 FHTTKv_DG Closed
2020-10-22_21:31:39 FHTTKv_DG Window: Closed
2020-10-22_21:50:35 FHTTKv_DG Open
2020-10-22_21:50:35 FHTTKv_DG Window: Open
2020-10-22_23:18:47 FHTTKv_DG Closed
2020-10-22_23:18:47 FHTTKv_DG Window: Closed
....
2020-10-29_07:34:59 FHTTKv_DG Open
2020-10-29_07:34:59 FHTTKv_DG Window: Open
2020-10-29_21:51:14 FHTTKv_DG Closed
2020-10-29_21:51:14 FHTTKv_DG Window: Closed
2020-10-30_02:42:12 FHTTKv_DG Open
2020-10-30_02:42:12 FHTTKv_DG Window: Open
2020-10-30_02:46:10 FHTTKv_DG Closed
2020-10-30_02:46:10 FHTTKv_DG Window: Closed
2020-10-30_06:50:04 FHTTKv_DG Open
2020-10-30_06:50:04 FHTTKv_DG Window: Open
2020-10-31_00:09:25 FHTTKv_DG Closed
2020-10-31_00:09:25 FHTTKv_DG Window: Closed
2020-10-31_07:13:40 FHTTKv_DG Open
2020-10-31_07:13:40 FHTTKv_DG Window: Open
2020-10-31_22:23:33 FHTTKv_DG Closed
2020-10-31_22:23:33 FHTTKv_DG Window: Closed
2020-11-01_05:33:17 FHTTKv_DG Open
2020-11-01_05:33:17 FHTTKv_DG Window: Open
2020-11-01_05:36:27 FHTTKv_DG Closed
2020-11-01_05:36:27 FHTTKv_DG Window: Closed
2020-11-01_08:58:14 FHTTKv_DG Open
2020-11-01_08:58:14 FHTTKv_DG Window: Open
2020-11-04_23:00:27 FHTTKv_DG Closed
2020-11-04_23:00:27 FHTTKv_DG Window: Closed


Da sind nur die Einträge, wie der virtuelle Kontakt geöffnet bzw. geschlossen wurde, aber keine Sende-Daten.
Da muss ich wohl noch was im SCC einstellen, damit der die gesendeten Daten vom COCStZi mitschreibt.
Reicht da das verbose 5 beim SCC?
Das kommt alles mit verbose 5.

2020.12.06 20:14:53 4: CUL_Parse: COCWoZi TE642640204 -72
2020.12.06 20:14:53 5: COCWoZi: dispatch TE6426402
2020.12.06 20:14:53 4: CUL_FHTTK e64264 RAW message: TE6426402
2020.12.06 20:14:53 5: CUL/RAW: /TE642648205

2020.12.06 20:14:53 4: CUL_Parse: COCWoZi TE642648205 -71.5
2020.12.06 20:14:53 5: COCWoZi: dispatch TE6426482
2020.12.06 20:14:53 4: CUL_FHTTK e64264 RAW message: TE6426482
2020.12.06 20:14:54 5: CUL/RAW: /T110C00A
2020.12.06 20:14:54 5: CUL/RAW: T110C00A/6000F

2020.12.06 20:14:54 4: CUL_Parse: COCWoZi T110C00A6000F -66.5
2020.12.06 20:14:54 5: COCWoZi: dispatch 810c04xx0909a001110c0000a600
2020.12.06 20:15:04 3: CUL_FHTTK (FHTTKv_DG) changed window state to closed.
2020.12.06 20:16:49 5: CUL/RAW: /T110400A
2020.12.06 20:16:49 5: CUL/RAW: T110400A/60040


Ich werde morgen den virtuellen FHTTKv_DG wieder am Thermostat anlernen und dann das log nochmal posten.

Grüße
Claus