Fibaro Motion Sensor: (Reported) State bleibt auf open

Begonnen von pairo, 11 Januar 2017, 15:01:34

Vorheriges Thema - Nächstes Thema

MadMax-FHEM

Sorry, ok.
Wenn ich das mit den Gruppen gerade gezogen hab, dann ist basicSet weg...
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

pairo

Würde mich aber auch interessieren, weshalb man nicht auf basicset triggern sollte.

rudolfkoenig

Weil das primitiv ist. Man isst auch nicht mit den Fingern :)

MadMax-FHEM

Aber wenn's doch mit den Fingern besser/zuverlässiger funktioniert... ;)
...oder zu funktionieren scheint...
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

krikan

Zitat von: pairo am 13 Januar 2017, 08:58:40
Würde mich aber auch interessieren, weshalb man nicht auf basicset triggern sollte.
Ganz einfach: Weil vermutlich nach unnötiger weiterer Aufnahme des Controllers in Assogroup 2 (zusätzlich zu 1 und 3) des FGMS basicSet nicht mehr regelmäßig ankommt, sondern wieder nur open/closed und dann müsste man den trigger wieder anpassen. Deshalb bietet es sich auch an den Controller ausschließlich und alleine in die dafür vorgesehene Assogroup 3 des FGMS aufzunehmen.   ;)

Grundsätzlich haben Z-Wave-Geräte eine Assoziationsgruppe für den Controller ("lifeline"). Diese eine Assoziationsgruppe nimmt den Controller auf und liefert die notwendigen Infos. Weitere Gruppen melden regelmäßig die gleichen Informationsinhalte nur über andere Command Classes (Ja, es gibt Ausnahmen beim FGMS aber nicht). Damit können andere Z-Wave-Geräte direkt ohne Umweg über den Controller gesteuert werden. Assoziiert man den Controller mit zu vielen Gruppen können Funktionsstörungen auftreten.

Bei der Fehlersuche bindet man mMn die Hardware erst mit Inklusion, Assoziation und Konfiguration richtig und wie vom Hersteller/Standard vorgesehen ein, bevor man irgendwelche Lösungsversuche mit Software/FHEM startet.

Aber letztlich kann und darf jeder machen, was er möchte.   :)

Angenehmen Start ins Wochenende,
Christian

MadMax-FHEM

Hi Christian,

danke für die Erleuterungen.

Wie gesagt ich mache nicht so viel mit Z-Wave, hauptsächlich Homematic.

Dort schaue ich eigentlich auch immer, dass alles richtig gepaired und eingestellt ist, bevor ich weiter mache...

Bei Z-Wave fehlt noch die Erfahrung auf was dort zu achten ist...

Aber nachdem ich includiert hatte und das mit open/close gesehen habe habe ich ja darauf getriggert.
Auf irgendwelche AssocGroups (habe es zwar ein paar mal gelesen aber so richtig klar war es mir nicht) habe ich da dann nicht mehr geachtet...

Ich habe die "Augen" auch nur mit dem Controler "verbunden", keine zusätzlichen Geräte etc.
Da ich damit ein Homematic-Licht anmache muss ich ja über notify und set gehen...

Einiziges zusätzliches "Feature" war das mit den Batteriewerten, da ich das von Homematic halt gewohnt war, dass da immer wieder mal was kommt...
...und dann habe ich das halt so (notify wakeup und Abfrage) im Internet gefunden und umgesetzt...
Weil ansonsten kamen halt gar keine aktualisierten Batteriewerte, kommen die wenn sich der Wert ändert?
Welche Stufen?
Oder erst wenn er (fast) leer ist?


Am WE werde ich mal versuchen zu klären in welchen AssocGroups die sind...

Allerdings nachdem es jetzt seit Umstellung auf notify auf basicSet prima tut (laut meiner Freundin) soll ich ja nix mehr ändern! (auch orig-Ton ;)   )

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

krikan

Hallo Joachim!

Nimm meine Aussagen nicht zu absolut; das sind vereinfachende Grundsätze. Entscheidend ist immer der Einzelfall und handfeste Infos (list, log,...) zu Deinem und pairos Systemen habe ich nicht. Ich hatte nur Sorge, dass sich falsche Dinge einschleichen.  :)
Wenn es für Dich/Deine Freundin so ok ist, dann lass es so. Mich würde die Ursache trotzdem interessieren..

Die Batterieabfrage mit notify ist auch nicht zwingend schlecht, aber bei den alten "lahmen" 3er Geräten, die viel senden wie der FGMS eine mögliche Problemquelle. Ich habe das bei einem Philio-Gerät auch drin. Muss man im Einzelfall sehen. Ich schaue mir das Batterie-Thema bei meinen FGMSen am Wochenende auch mal an. Aus dem Kopf ist mir nur noch in Erinnerung, dass die battery-Meldungen bei einem Sensor ungenau waren; weiß aber nicht, ob ich die damals abgefragt hatte oder automatisch kamen/kommen.

Gruß, Christian

MadMax-FHEM

Hallo,

so einfach nochmal ein list des "Auges".

Wie gesagt ich habe nur included und den configMotionAlarmCancellationDelay 15sec gestellt ansonsten nur ein Notify auf state open/closed (bzw. jetzt auf basicSet 0/255) und eben das Notify auf "wakeup" mit anschließendem getBatteryState...

Hier mal das List:


Internals:
   DEF        d87dd285 5
   IODev      zwave_usb
   LASTInputDev zwave_usb
   MSGCNT     374
   NAME       Auge_Schrank2
   NR         577
   STATE      closed
   TYPE       ZWave
   ZWaveSubDevice no
   homeId     d87dd285
   isWakeUp   1
   lastMsgSent 1484474003.7009
   nodeIdHex  05
   zwave_usb_MSGCNT 374
   zwave_usb_RAWMSG 0004000503200100
   zwave_usb_TIME 2017-01-15 13:16:54
   Readings:
     2016-10-16 09:16:32   CMD             ZW_APPLICATION_UPDATE
     2017-01-11 08:59:02   alarm_type_00   level 255 node 5 seconds 0
     2016-10-16 09:04:02   assocGroup_1    Max 5 Nodes zwave_usb
     2016-10-16 09:04:04   assocGroup_2    Max 5 Nodes
     2016-10-16 09:04:06   assocGroup_3    Max 1 Nodes zwave_usb
     2016-10-16 09:04:02   assocGroups     3
     2016-10-16 09:04:02   basicReport     255
     2017-01-15 13:16:54   basicSet        0
     2017-01-15 10:53:21   battery         100 %
     2016-10-16 09:04:19   configAmbientIlluminationLevelAbove83 1000
     2016-10-16 09:04:19   configAmbientIlluminationLevelBelow82 100
     2016-10-16 09:04:20   configBASICOFFCommandFrameValue 0
     2016-10-16 09:04:21   configBASICONCommandFrameValue 255
     2016-10-16 09:04:21   configIlluminationReportsInterval 0
     2016-10-16 09:04:21   configIntervalOfTemperatureMeasuring 900
     2016-10-16 09:04:21   configLEDBrightness 50
     2016-10-16 09:04:21   configLEDIndicatingTamperAlarm LEDIndicatesTamperAlarm
     2016-10-16 09:04:21   configLEDSignalingMode LongBlinkThenShortBlinkLEDColour10
     2016-10-16 09:04:21   configMaximumTemperatureResultingInRed87 28
     2016-10-16 09:04:22   configMinimumTemperatureResultingIn86 18
     2016-10-16 09:16:32   configMotionAlarmCancellationDelay 15
     2016-10-16 09:04:22   configMotionSensorSBlindTime2 15
     2016-10-16 09:04:22   configMotionSensorSSensitivity 10
     2016-10-16 09:04:22   configNightDay  200
     2016-10-16 09:04:22   configPIRSensorOperatingMode PIRSensorAlwaysActive
     2016-10-16 09:04:22   configPIRSensorSPulseCounter 2Pulses
     2016-10-16 09:04:22   configPIRSensorSWindowTime 12Seconds
     2016-10-16 09:04:23   configTamperAlarmBroadcastMode TamperAlarmIsNotSentInBroadcast0
     2016-10-16 09:04:23   configTamperAlarmCancellationDelay 30
     2016-10-16 09:04:24   configTamperOperatingModes Tamper
     2016-10-16 09:04:25   configTamperSensitivity 15
     2016-10-16 09:04:26   configTemperatureOffset 0
     2016-10-16 09:04:27   configTemperatureReportThreshold 10
     2016-10-16 09:04:29   configTemperatureReportsInterval 0
     2016-12-10 14:03:48   luminance       57 Lux
     2016-10-15 18:38:02   model           FIBARO System FGMS001 Motion Sensor
     2016-10-15 18:38:02   modelConfig     fibaro/fgms.xml
     2016-10-15 18:38:02   modelId         010f-0800-1001
     2017-01-15 13:16:54   reportedState   closed
     2017-01-15 13:16:54   state           closed
     2017-01-03 04:17:23   temperature     18.8 C
     2017-01-15 10:53:23   timeToAck       0.034
     2017-01-15 10:53:23   transmit        OK
     2017-01-15 10:53:21   wakeup          notification
     2016-10-16 09:11:14   wakeupReport    interval 65535 target 1
Attributes:
   IODev      zwave_usb
   classes    SENSOR_BINARY WAKE_UP ASSOCIATION BATTERY MULTI_CMD CRC_16_ENCAP MANUFACTURER_SPECIFIC VERSION CONFIGURATION MULTI_CHANNEL_ASSOCIATION SENSOR_MULTILEVEL SENSOR_ALARM BASIC
   room       Flur
   vclasses   ASSOCIATION:2 BATTERY:1 CONFIGURATION:1 CRC_16_ENCAP:1 MANUFACTURER_SPECIFIC:1 MULTI_CHANNEL_ASSOCIATION:2 MULTI_CMD:1 SENSOR_ALARM:1 SENSOR_BINARY:1 SENSOR_MULTILEVEL:5 VERSION:2 WAKE_UP:1


Passt das so?
Oder ist da etwas "falsch"/komisch?

Wird wohl Zeit, dass ich mich mit Z-Wave mal ähnlich beschäftige und fit werde wie mit Homematic...

Allerdings darf (soll) ich nichts ändern! Vorgabe meiner Freundin weil aktuell funktioniert es wieder ;)

Interessanterweise kommen jetzt auch wieder die Batteriewerte (die waren ja seit kurz vor Weihnachten "weg", vielleicht Weihnachtsurlaub ;)  )...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)