windowOpenCheck funktioniert nicht [gelöst]

Begonnen von TRallala, 27 November 2020, 11:43:56

Vorheriges Thema - Nächstes Thema

TRallala

Hallo,

scheitere gerade an dem Projekt meine Fensteroffenmeldung mithilfe des windowOpenCheck umzubauen.
Problem ist, dass das reading windowOpen immer 0 ist/bleibt.

Internals:
   DEF        ShutterContact 1a00f6
   FUUID      5def3628-f33f-5c1d-500f-b1263497b7e40e21
   IODev      culmax
   NAME       FK_Schlafzimmer
   NR         208
   NTFY_ORDER 50-FK_Schlafzimmer
   STATE      opened
   SVN        22368
   TYPE       MAX
   addr       1a00f6
   devtype    4
   type       ShutterContact
   READINGS:
     2020-11-27 10:52:29   RSSI            -66
     2020-11-27 10:52:29   battery         ok
     2020-11-27 10:52:29   batteryState    ok
     2019-12-20 07:37:05   firmware        1.0
     2019-12-20 07:37:05   groupid         0
     2020-10-04 14:22:00   lastcmd         set_associate HzSchlafzimmer
     2020-10-04 14:22:00   msgcnt          3
     2020-11-27 10:52:29   onoff           1
     2020-08-24 06:19:34   peerIDs         0e3c02
     2020-08-24 06:19:34   peerList        MAX_0e3c02
     2020-11-27 10:52:29   rferror         0
     2020-11-27 10:52:29   state           opened
     2019-12-20 07:37:05   testresult      0
     2020-11-26 21:46:58   windowOpen      0
Attributes:
   IODev      culmax
   devStateIcon closed:fts_window_1w opened:fts_window_1w_open
   icon       fts_window_1w
   model      ShutterContact
   room       MAX,Schlafzimmer
   timestamp-on-change-reading .*
   userattr   sensoren sensoren_map structexclude
   windowOpenCheck 1


Bei diesem ist zumindest der Timestamp bei windowOpen korrekt.
Bei einem zweiten Testkandidaten ist selbst dies nicht aktuell:

Internals:
   DEF        ShutterContact 047022
   FUUID      5c559e2e-f33f-5c1d-ba21-a2c59ef42de6130e
   IODev      culmax
   NAME       FK_Bad
   NR         121
   NTFY_ORDER 50-FK_Bad
   STATE      closed
   SVN        22368
   TYPE       MAX
   addr       047022
   devtype    4
   type       ShutterContact
   READINGS:
     2020-11-27 09:58:44   CUL_868_RSSI    -58
     2020-10-04 20:11:06   PairedTo        123456
     2020-11-27 09:58:44   RSSI            -58
     2020-10-04 20:11:06   SerialNr        JMD4012944
     2020-11-20 11:10:11   battery         ok
     2020-11-20 11:10:11   batteryState    ok
     2020-10-04 20:00:52   error           Invalid command/argument  8112
     2020-10-04 20:11:06   firmware        1.3
     2020-10-04 20:11:06   msgcnt          40
     2020-11-27 09:58:44   onoff           0
     2020-11-20 06:19:08   peerIDs         1741a0
     2020-11-20 06:19:08   peerList        HzBad
     2020-11-20 11:10:11   rferror         0
     2020-11-27 09:58:44   sendTo_HzBad    18
     2020-11-27 09:58:44   state           closed
     2020-10-04 20:11:06   testresult      15
     2020-11-20 06:10:11   windowOpen      0
Attributes:
   IODev      culmax
   comment    Configured using template MAX_ShutterContact_dark
   debug      1
   devStateIcon closed:fts_window_1w opened:fts_window_1w_open
   event-on-change-reading .*
   icon       fts_window_1w
   model      ShutterContact
   room       Bad,MAX
   timestamp-on-change-reading .*
   userattr   sensoren sensoren_map structexclude
   windowOpenCheck 1



Latest Revision: 23239
14_CUL_MAX.pm                   22175 2020-06-13 17:32:49Z Wzut
10_MAX.pm                       22368 2020-07-07 17:18:53Z Wzut


Irgendjemand einen guten Tip?

Gruß
Markus

Wzut

sieht aus als ob bei dir der interne Timer nicht anläuft, direkt nach dem open sollte windowOpen den Wert 00:00 haben statt nur 0
Teste das doch biite mal mit meinen aktuellen Beta Versionen von 10_MAX und 14_CUL_MAX -> https://forum.fhem.de/index.php/topic,115018.0.html
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

TRallala

der Timer läuft nach einem neustart für das offene Fenster sofort los:


     2020-11-27 13:57:25   windowOpen      00:03


und auch ein neu geöffnetes funktioniert
     2020-11-27 14:02:55   windowOpen      00:00

Die Beta kam mir auch in den Sinn, aber da mein System nach einigen Umbauten gerade (noch) einen sehr reduzierten WAF Wert aufweist, wollte ich bisher davon absehen.
Wenn die Frau also morgen früh 6Grad im Bad hat, bekomm ich ein Problem.  ;)

Erwartest du noch (größere) Probleme mit den Versionen?

Danke und Gruß
Markus

Wzut

Ich habe die Betas seit Wochen bei mir aktiv laufen und auch die Feedbacks waren extrem sparsam.
Kann man daher nur deuten wie beim Chef : Schweigen bedeutet Zustimmung :)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

TRallala


okay - wochenende rum:
Frau ist weder erfroren, noch gabs Sauna.
Ich schweige dann also mit der Masse.  :-X