[patch] 10_FBDECT: Unterstützung von LED HAN-FUN Lampen und FritZ!DECT 500

Begonnen von amenomade, 20 Juni 2020, 22:04:14

Vorheriges Thema - Nächstes Thema

kptkip

Voilà:
Internals:
   DEF        FritzDECT:09995_0049294 actuator,tempSensor
   FUUID      5c4f9cf5-f33f-57e4-3069-76fbffbdf3f06e47
   FritzDECT_MSGCNT 24
   FritzDECT_TIME 2020-07-01 18:59:36
   IODev      FritzDECT
   LASTInputDev FritzDECT
   MSGCNT     24
   NAME       Heizung_Schlafen
   NR         23
   STATE      desired-temp: 18.0 C
   STILLDONETIME 0
   TYPE       FBDECT
   id         09995_0049294
   props      actuator,tempSensor
   webCmd     desired-temp
   Helper:
     DBLOG:
       temperature:
         DBLogging:
           TIME       1593618576.49452
           VALUE      22.0
   READINGS:
     2020-07-01 18:59:36   AIN             09995 0049294
     2020-07-01 18:59:36   FBNAME          Schlafzimmer
     2020-07-01 18:59:36   FBPROP          actuator,tempSensor
     2020-07-01 18:59:36   FBTYPE          FRITZ!DECT 301
     2020-07-01 18:59:36   ID              21
     2020-07-01 18:59:36   battery         100 %
     2020-07-01 18:59:36   batteryPercent  100
     2020-07-01 18:59:36   batteryState    ok
     2020-07-01 18:59:36   batterylow      0
     2020-07-01 18:59:36   boostactive     no
     2020-07-01 18:59:36   boostactiveendtime N/A
     2020-07-01 18:59:36   day-temp        18.0 C
     2020-07-01 18:59:36   desired-temp    18.0 C
     2020-07-01 18:59:36   devicelock      no
     2020-07-01 18:59:36   errorcode       noError (0)
     2020-07-01 18:59:36   fwversion       04.94
     2020-07-01 18:59:36   holidayactive   no
     2020-07-01 18:59:36   locked          no
     2020-07-01 18:59:36   nextPeriodStart 2020-07-01 22:00:00
     2020-07-01 18:59:36   nextPeriodTemp  18.0 C
     2020-07-01 18:59:36   night-temp      18.0 C
     2020-07-01 18:59:36   present         yes
     2020-07-01 18:59:36   state           desired-temp: 18.0 C
     2020-07-01 18:59:36   summeractive    no
     2020-07-01 18:59:36   tempadjust      -4.0 C
     2020-07-01 18:59:36   temperature     22.0 C (measured)
     2020-07-01 18:59:36   windowopenactiv no
     2020-07-01 18:59:36   windowopenactiveendtime N/A
Attributes:
   DbLogExclude .*
   DbLogInclude desired-temp,temperature
   IODev      FritzDECT
   alias      Heizung Schlafzimmer
   event-min-interval power:120
   event-on-change-reading state,temperature,desired-temp
   group      Geräte für Heizung
   homebridgeMapping TargetTemperature=desired-temp::desired-temp,minValue=5,maxValue=35,minStep=0.5,nocache=1 CurrentTemperature=temperature,nocache=1
   icon       hm-cc-rt-dn
   room       Obergeschoss->Schlafzimmer
FHEM Revision: 22312 auf RasPI3B+,1xNeumannCUL,HMLAN,1xRasPi3B+,2xRasPI ZERO W
CUL_HM:HM-Sec-SCo, HM-CC-RT-DN
Fritz: Fritz!Box 6590C,DECT301,DECT200
Shelly:Shelly1,Shelly2, ShellyBulb Xiaomi: Schalter, Fensterkontakte HUE: ConbeeII
Tasmota:SonoffBridge, Stecker

amenomade

Ok, mein Schuld. Als ich die Änderungen in die inzwischen von Rudi wieder modifizierte Version übertragen habe, habe ich eine Zeile vergessen.

Ich bereite den Patch vor.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

amenomade

Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

rudolfkoenig


kptkip

Aloa,

Ich hab die neuen Funktionen getestet mit meinen Fritz!DECT 301 Heizungsthermostaten.

Kurze Rückmeldung: Es klappt!

Was hier allerdings das Problem ist - und dafür könnt Ihr als FHEM-Entwickler nunmal nix - ist die lange Latenz beim Synch zwischen Fritzbox und Thermostat.

Ich mach mal ein Beispiel:
- Es ist 10:00 Uhr und schicke den Befehl set DEVICENAME boost 300 (vulgo: Booste für 5 Minuten)
- Der ,,timestamp" im FHEM-Device steht also auf 10:05, um wieder abzuschalten.
- Der wird auch an die Fritzbox gesendet
- Dann dauert es - bei mir so rund 2-5 Minuten, bis das Thermostat auch reagiert. Kann offiziell bis zu 15 Minuten dauern.
- Die Konsequenz ist, dass das Thermostat u.U. Erst um 10:04 Uhr boostet und um 10:05 wieder abschaltet.

Ob das - gerade beim windowopen - so zielführende ist, darf bezweifelt werden. Selbst wenn er nicht den absoluten timestamp sondern die Dauer übermitteln würde, wäre das m.E. nicht optimal, weil der Zeitversatz immer noch drin wäre.

Aber wie gesagt, das ist ein Problem in der Kommunikationsstrategie von AVM.

Soweit mein Erfahrungsbericht.

Ob ich das ernsthaft einsetzen werde, bin ich mir noch nicht sicher. Trotzdem vielen Dank an @amenomade und @rudolfkönig.

Gruß
Alex
FHEM Revision: 22312 auf RasPI3B+,1xNeumannCUL,HMLAN,1xRasPi3B+,2xRasPI ZERO W
CUL_HM:HM-Sec-SCo, HM-CC-RT-DN
Fritz: Fritz!Box 6590C,DECT301,DECT200
Shelly:Shelly1,Shelly2, ShellyBulb Xiaomi: Schalter, Fensterkontakte HUE: ConbeeII
Tasmota:SonoffBridge, Stecker

amenomade

Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus