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
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
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.
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.
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
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 .