WeekdayTimer - ZWave-Specials (erst mal: Fensterkontakt)

Begonnen von Beta-User, 19 Oktober 2020, 13:21:19

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo zusammen,

aus gegebenem Anlass, insbesondere auch in diesem Thread:
Zitat von: Beta-User am 19 Oktober 2020, 10:32:14
auch WeekdayTimer (bzw. Heating_Control) behandelt das anders (werde bei Gelegenheit auch noch setpointTemp dazunehmen).

Der WDT enthält an ein paar Stellen Code, der unterschiedlich reagiert, je nachdem, mit welchem Device-TYPE man es zu tun hat. Das betrifft zum einen typische setter-Namen wie eben setpointTemp), und zum anderen insbesondere auch die Behandlung von Fensterkontakten. Bei denen versucht der WDT derzeit, das Reading "state" zu verwenden, was aber nach meinen bisherigen oberflächlichen Recherchen eigentlich völlig sinnlos ist, weil eben ein ZWave-Fensterkontakt (ohne User-Eingriffe) entweder nur "basicSet 255" für "Fenster ist offen" anzeigt, oder eben eine etwas sprechendere Meldung in "alarm" (da steht dann z.B. "AccessControl: Window/Door is closed").

Da ich nach meinen ersten eigenen ZWave-Erfahrungen davon ausgehe, dass es nicht die eine Lösung für das Thema gibt, sondern ggf. eben beide (oder alle drei?) Varianten, gibt es ein paar Fragen, die ich mir so stelle:

- Übersehe ich was?
- Nutzt das derzeit überhaupt jemand, und wenn ja,
-- mit welchen Rahmenbedingungen (userReading für state oder wird das doch richtig gesetzt?)
-- Wäre der Umstieg auf was anderes (alarm oder basicSet) stressfrei möglich?
- Wenn was anderes: Was wäre aus eurer Sicht sinnvoll?

Grüße,
Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

tomspatz

Ich nutze es tatsächlich an allen Fenstern, "NOCH" mit dem "alten" Heating_Controll (bin aber in der Umstellung). Damit wird ja der nächste Schaltvorgang verzögert fall "das Fenster" offen ist.
Worauf dort allerdings Modulintern geschaut wird.... keine Ahnung.
Meine Z-Wave FIBARO System FGK101 Door Opening Sensor liefern allerdings open und closed.

Wenn ich etwas dazu beitragen kann gerne.

LG
Tom

Beta-User

Zitat von: tomspatz am 19 Oktober 2020, 14:41:05
Wenn ich etwas dazu beitragen kann gerne.
Ein list von einem der FIBARO System FGK101 Door Opening Sensor würde mich interessieren.

Zitat"NOCH" mit dem "alten" Heating_Controll (bin aber in der Umstellung). [...]
Worauf dort allerdings Modulintern geschaut wird.... keine Ahnung.
Na ja, wenn du nicht grade eine vorsintflutliche Fassung in Verwendung hast: HC ruft Code aus WDT auf um festzustellen, was den nun Sache ist ;) .

OT zur Geschichte von HC/WDT, soweit ich mir das zusammenreimen konnte:
Ursprünglich entwickelt wurde das mal als Heating_Control (unter Verwendung von Codeelementen, die ursprünglich mal aus Twilight kamen und auch sehr lange von dort "geborgt" worden waren). Irgendwann scheint jemand mal auf den Gedanken gekommen zu sein, dass das auch was sinnvolles ist, wenn man nicht nur Temperaturprofile darüber "abfahren", sondern das ganze als universelle Zeitschaltuhr verwenden könnte. Daher hat derjenige dann den Code kurzerhand in WeekdayTimer umbenannt und Heating_Control nur noch als "wrapper" gestaltet, für den eigentlichen Code, der seitdem eigentlich fast ausschließlich nur noch in WeekdayTimer steckt... Vielleicht wirfst du einfach mal spasseshalber einen Blick auf den Code: ab https://svn.fhem.de/trac/browser/trunk/fhem/contrib/deprecated/98_Heating_Control.pm#L48 sind fast nur noch "Umpackroutinen" zu finden, die die Subroutinen von WeekdayTimer aufrufen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

tomspatz

Internals:
   DEF        c9cc092a 69
   FUUID      5f8acd92-f33f-fa82-8663-2b9c15fb30c6642d
   IODev      ZWDongle_0
   LASTInputDev ZWDongle_0
   MSGCNT     153
   NAME       BalkontuerWohnzimmer_69
   NR         635
   STATE      closed
   TYPE       ZWave
   ZWDongle_0_MSGCNT 153
   ZWDongle_0_RAWMSG 0004004503800355
   ZWDongle_0_TIME 2020-10-19 17:29:11
   ZWaveSubDevice no
   cmdsPending 0
   endpointChildren TemperaturFuehlerWohnzimmer_69.02
   homeId     c9cc092a
   isWakeUp   1
   lastMsgSent 1603121353.15303
   nodeIdHex  45
   READINGS:
     2020-02-24 13:37:11   CMD             ZW_APPLICATION_UPDATE
     2020-10-07 14:39:35   SEND_DATA       failed:00
     2019-07-10 20:40:12   assocGroup_1    Max 5 Nodes
     2019-07-10 20:40:12   assocGroup_2    Max 5 Nodes
     2019-07-10 20:40:12   assocGroup_3    Max 1 Nodes ZWDongle_0
     2019-07-10 20:40:12   assocGroups     3
     2020-10-17 12:55:23   associatedWith  TemperaturFuehlerWohnzimmer_69.02
     2019-07-10 20:35:15   basicSet        0
     2020-10-19 17:29:11   battery         85 %
     2020-10-19 17:29:11   batteryPercent  85
     2020-10-19 17:29:11   batteryState    ok
     2019-07-10 20:34:20   configDeactivateTransmissionOfFrame9 Groups1And2Sent
     2019-07-10 20:34:21   configForcedLevelOfDimmingGroup1 255
     2019-07-10 20:34:21   configIN1AlarmCancellationDelay 0
     2019-07-10 20:52:46   configInsensitivenessToTemperature12 0
     2019-07-10 20:34:50   configIntervalBetweenSuccessive10 1
     2019-07-10 20:34:50   configSceneActivation ScenesDisabled
     2019-07-10 20:35:08   configStatusChangeSignalledByLED LEDTurnedOff
     2019-07-10 20:34:51   configTransmittingTheAlarmOrControl13 IN1AndIN2BroadcastInactive
     2019-07-10 20:34:51   configTypeOfInputNo1 NONormalOpen
     2019-07-10 20:34:51   configTypeOfTransmittedControlFrameFor5 BASICSET
     2019-12-27 13:16:55   config_15       0
     2019-07-10 20:29:01   mcCapability_01 SENSOR_BINARY
     2019-07-10 20:29:05   mcCapability_02 SENSOR_MULTILEVEL
     2019-07-10 20:59:39   mcEndpoints     total 2, different
     2019-07-10 20:28:57   model           FIBARO System FGK101 Door Opening Sensor
     2019-07-10 20:28:57   modelConfig     fibaro/fgk001.xml
     2019-07-10 20:28:57   modelId         010f-0700-1000
     2019-07-20 18:12:03   neighborList    ZWDongle_0 LichtWohnzimmerSchrank1A LichtWohnzimmerSchrank2A FunkDose2 LichtBuero1A LichtKueche LichtFlurSpiegel DimmerWohnzimmer LichtBad DimmerSchlafzimmer LichtWC Balkon_47 KuecheFensterLinks_49 LichtKammer KuecheArbeitsflaecheLinks_55 KuecheArbeitsflaecheRechts_56 Waschmaschine_58 LichtWohnzimmerFenster_68
     2020-10-19 15:59:50   reportedState   closed
     2020-10-19 15:59:50   state           closed
     2020-10-19 17:29:13   timeToAck       0.034
     2020-10-19 17:29:13   transmit        OK
     2020-10-19 17:29:11   wakeup          notification
     2019-07-10 20:43:03   wakeupReport    interval 4000 target 1
Attributes:
   IODev      ZWDongle_0
   alias      Balkontür WZ
   classes    SENSOR_BINARY SENSOR_ALARM MULTI_CHANNEL ASSOCIATION MANUFACTURER_SPECIFIC CONFIGURATION VERSION BATTERY CRC_16_ENCAP WAKE_UP FIRMWARE_UPDATE_MD MARK SCENE_ACTIVATION
   devStateIcon open:fts_door_open@red .*:fts_door
   group      Fenster und Türen
   icon       fts_door
   room       System,Wohnzimmer,ZWave
   vclasses   ASSOCIATION:2 BATTERY:1 CONFIGURATION:1 CRC_16_ENCAP:1 FIRMWARE_UPDATE_MD:1 MANUFACTURER_SPECIFIC:1 MULTI_CHANNEL:3 SCENE_ACTIVATION:1 SENSOR_ALARM:1 SENSOR_BINARY:1 VERSION:1 WAKE_UP:1

ZitatNa ja, wenn du nicht grade eine vorsintflutliche Fassung in Verwendung hast: HC ruft Code aus WDT auf um festzustellen, was den nun Sache ist ;) .

doch doch von 2018 etwa funktioniet aber nach einem Update neulich einwandfrei.

Deckoffizier

Hallo,

vielleicht nicht gerade Hilfreich,
bei mir habe ich das Reading    alarm_AccessControl  Event cleared: Window/Door is closed, arg 000, notificationIsOn

umgebogen mittels userReading  fenster:alarm_AccessControl.* {(split(/,|is /, ReadingsVal($name,"alarm_AccessControl","")))[1]}

ist aber nicht von mir erdacht.

Model ist Vision Security ZD2102 EU Door/Window Sensor und auch
FIBARO System FGDW002 Door Opening Sensor 2

Gruß
Hans-Jürgen
   
FHEM 5.8 auf "yakkaroo Emu A1FL.1" mit CUL 868MHz, SIGNALduino,2 1Wire USB Busmaster, diverse 1 Wire Sensoren,Landroid,Aeotec USB Dongle Z-Wave Plus

Beta-User

Hmm, Danke auf alle Fälle erst mal.
Es ist also so, wie ich das befürchtet hatte: Es gibt alle möglichen Varianten, und wenn es komfortabel (für den User) sein soll, braucht es etwas mehr an Code als heute im Modul steht. Muß mal hirnen und das fällt sicher auch nicht gleich vom Himmel, aber der Spur nach würde ich jetzt folgendes anpeilen:

- Schritt 1 wäre, das Reading "state" auf "open" oder "closed" zu durchforsten. Ist es _genau_ eines von beiden, sind wir durch (=sollte (!) kompatibel zum Ist-Zustand sein);
- Schritt 2 wäre, "alarm_AccessControl" auszuwerten. _Enthält_ das open oder closed => fertig;
- Schritt 3 könnte dann noch basicSet ansehen, ist das 0 oder ReadingsAge älter als einen Tag (?), ist das Fenster zu...?

Wird aber einen gewissen Umbau des Codes brauchen, bis das läuft.

Zitat von: tomspatz am 19 Oktober 2020, 17:45:28
doch doch von 2018 etwa funktioniet aber nach einem Update neulich einwandfrei.
;D
Das ist doch noch nicht vorsintflutlich... Würde vermuten, dass das noch zu Vor-Forums-Zeiten gewesen sein müßte ;D ;D ;D .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files