[Gelöst] Problem mit readings bei Fibaro FGMS001

Begonnen von Muellermann, 16 September 2017, 17:21:05

Vorheriges Thema - Nächstes Thema

Muellermann

Hallo zusammen,

ich verzweifele leider daran, dass mein FGMS001 nur eine wenige readings ausspuckt. Das u.a. für mich wichtige reading Battery wurde zuletzt am 24.12.2016 übertragen. Die Bewegungserkennung funktioniert hingegen, wie auch die Temperaturübermittlung.

Hier ist der entsprechende list

Internals:
   DEF        ce38762c 4
   IODev
   LASTInputDev ZWAVE1
   MSGCNT     4856
   NAME       Flur_Bewegung
   NR         85
   STATE      wakeupInterval 86400 1
   TYPE       ZWave
   ZWAVE1_MSGCNT 4856
   ZWAVE1_RAWMSG 00040004097105000000ff070800
   ZWAVE1_TIME 2017-09-16 17:16:38
   ZWaveSubDevice no
   homeId     ce38762c
   isWakeUp   1
   lastMsgSent 1505574974.85837
   nodeIdHex  04
   READINGS:
     2017-09-16 17:12:42   CMD             ZW_APPLICATION_UPDATE
     2017-09-16 17:16:38   alarm           HomeSecurity: Motion Detection - Unknown Location
     2016-12-24 18:53:13   battery         100 %
     2017-01-02 09:44:37   configAmbientIlluminationLevelAbove83 1000
     2017-01-02 09:44:37   configAmbientIlluminationLevelBelow82 100
     2017-01-02 09:44:37   configAssociationsInSecurityMode 15
     2017-01-02 09:44:37   configBASICOFFCommandFrameValue 0
     2017-01-02 09:44:37   configBASICONCommandFrameValue 255
     2017-01-02 09:44:37   configBasicCommandClassFrames12 BASICONAndBASICOFFCommandFrames0
     2017-01-02 09:44:37   configIlluminationReportThreshold 200
     2017-01-02 09:44:37   configIlluminationReportsInterval 3600
     2017-01-02 09:44:37   configIntervalOfTemperatureMeasuring 900
     2017-01-02 09:44:37   configLEDBrightness 50
     2017-01-02 09:44:38   configLEDIndicatingTamperAlarm LEDIndicatesTamperAlarm
     2017-01-02 09:44:38   configLEDSignalingMode LongBlinkThenShortBlinkLEDColour10
     2017-01-02 09:44:38   configMaximumTemperatureResultingInRed87 28
     2017-01-02 09:44:38   configMinimumTemperatureResultingIn86 18
     2017-01-02 09:44:38   configMotionAlarmCancellationDelay 30
     2017-01-02 09:44:38   configMotionSensorSBlindTime2 15
     2017-01-02 09:44:38   configMotionSensorSSensitivity 8
     2017-01-02 09:44:38   configNightDay  200
     2017-01-02 09:44:38   configPIRSensorOperatingMode PIRSensorAlwaysActive
     2017-01-02 09:44:38   configPIRSensorSPulseCounter 2Pulses
     2017-01-02 09:44:38   configPIRSensorSWindowTime 12Seconds
     2017-01-02 09:44:38   configTamperAlarmBroadcastMode TamperAlarmSentTo3rdAssociation0
     2017-01-02 09:44:38   configTamperAlarmCancellationDelay 30
     2017-01-02 09:44:38   configTamperBackwardCompatible29 backwardCompatibleTamperAlarm0
     2017-01-02 09:44:38   configTamperOperatingModes Tamper
     2017-01-02 09:44:38   configTamperReportCancellation SendTamperCancellationReport
     2017-01-02 09:44:38   configTamperSensitivity 20
     2017-01-02 09:44:38   configTemperatureOffset 0
     2017-01-02 09:44:38   configTemperatureReportThreshold 10
     2017-01-02 09:44:38   configTemperatureReportsInterval 0
     2017-09-16 17:16:25   luminance       1219 Lux
     2016-12-24 18:50:20   model           FIBARO System FGMS001-ZW5 Motion Sensor
     2016-12-24 18:50:20   modelConfig     fibaro/fgms-zw5.xml
     2016-12-24 18:50:20   modelId         010f-0801-1001
     2016-12-24 18:50:19   state           wakeupInterval 86400 1
     2017-09-16 17:16:25   temperature     22.2 C
     2017-03-12 09:24:23   timeToAck       0.024
     2017-03-12 09:24:23   transmit        OK
     2017-09-16 17:16:14   wakeup          notification
   SendStack:
     sentset:13040485040401255d
Attributes:
   classes    ZWAVEPLUS_INFO BASIC VERSION MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO ASSOCIATION POWERLEVEL WAKE_UP BATTERY ALARM CRC_16_ENCAP CONFIGURATION SENSOR_MULTILEVEL MULTI_CHANNEL_ASSOCIATION APPLICATION_STATUS SENSOR_BINARY SENSOR_ALARM SECURITY FIRMWARE_UPDATE_MD
   room       Flur,ZWave
   vclasses   ALARM:5 APPLICATION_STATUS:1 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BASIC:1 BATTERY:1 CONFIGURATION:1 CRC_16_ENCAP:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MANUFACTURER_SPECIFIC:2 MULTI_CHANNEL_ASSOCIATION:2 POWERLEVEL:1 SECURITY:1 SENSOR_ALARM:1 SENSOR_BINARY:1 SENSOR_MULTILEVEL:8 VERSION:2 WAKE_UP:2 ZWAVEPLUS_INFO:2
   verbose    5


Kann mir da evtl. jemand von euch auf die Sprünge helfen?

Herzliche Grüße

  Andreas

MadMax-FHEM

Es ist ein wakeup Gerät bei dem musst du den Batteriestand abfragen.
Das Gerät schickt den Wert dann beim nächsten Aufwachen...

Oder du machst ein Notify auf das wakeup und setzt dann den Befehl ab:

Flur_Bewegung.wakeup.* get $NAME battery

Wenn du mehrere Geräte hast, kannst du auch ein passendes Notify für alle bauen...

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)

Muellermann

Ich mache immer einen manuellen Wakeup, ansonsten kommt der ja eh einmal am Tag. Trotzdem wird nichts übertragen und das verstehe ich halt nicht.


MadMax-FHEM

#3
Der Batteriewert wird ja auch nur auf Anfrage übertragen...

get Gerätename battery

Die Übertragung findet dann beim nächsten wakeup statt...
...daher die Abfrage im Notify bei wakeup weil dann ist der Sensor wach und führt den get sofort aus...

So aktualisiere ich bei mir die Batteriewerte...

EDIT: trotzdem erfolgt die Aktualisierung mit dem wakeup Intervall. Wenn du den Wert öfter willst, dann musst du das wakeup Intervall kürzer machen. ABER: damit geht auch die Batterie schneller leer! Ebenso, wenn du andere Thresholds etc. verkürzt...

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)

Muellermann

Zitat von: MadMax-FHEM am 16 September 2017, 19:49:21


Die Übertragung findet dann beim nächsten wakeup statt...


Nee, eben leider nicht. Egal ob automatischer oder manueller Wakeup. Es wird, wie man dem list vom device entnehmen kann, eben nichts ausser der Bewegung, der Temperatur und einem Tamper Alarm übertragen. Das verstehe ich halt leider nicht.

MadMax-FHEM

#5
Setzt du auch den get-Befehl ab!?

Also:

get Flur_Bewegung battery

Und dann wakeup (selbständig oder manuell ist egal) dann sollte der Batteriewert übertragen werden...

Oder halt das mit dem Notify.

Bei mir klappt das prima...

Gruß, Joachim

P.S.: auch andere Werte/Readings kommen nur auf Anfrage...
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)

Muellermann

Wie gesagt,

welches readig auch immer ich abfrage, es kommt nichts zurürck. Egal. wie ich den Wakeup mache.

Was mir auch noch aufgefallen ist, ist dass wenn ich ein

set Flur_Bewegung configMotionAlarmCancellationDelay 60

kommt folgendes zurück

unknown argument configMotionAlarmCancellationDelay, choose one of alarmnotification associationAdd associationDel basicSet basicValue configByte configDefault configLong configWord mcaAdd mcaDel neighborUpdate powerlevel powerlevelTest returnRouteAdd returnRouteDel secSupportedReport wakeupInterval wakeupNoMoreInformation

:-[

MadMax-FHEM

Das ist eigenartig...

Bin leider nicht der ZWave-Spezialist habe hauptsächlich Homematic.

Habe aber auch 2 von den Bewegungsmeldern (meine sind NICHT Gen5 soweit mir mal mitgeteilt wurde / was deiner ist weiß ich leider nicht / auch nicht ob das was macht).

Was ich gesehen habe ist, dass du bei IODev nichts hast, ob das was ausmacht (bei ZWave) weiß ich nicht, bei Homematic ist das schlecht und bei mir steht dort eben mein ZWave-Stick...

Ansonsten ist es bei den Readings abhängig was per get abgefragt wurde, von daher macht Unterschiede vergleichen kaum Sinn...

Du hast ja verbose 5, was steht im Log, wenn du den get battery absetzt?
Bei mir kommt dann ein Popup: Scheduled for sending after WAKEUP

Und dann eben beim nächsten Wakeup (manuell oder warten) der Batteriewert.

Genauso mit anderen Abfragen per get.

Hast du wie beschrieben auch alle get (Association, config, model, ...) wie glaube ich im Wiki beschrieben abgesetzt?
Es wird auch geraten bei Configänderungen ein get auf den geänderten Wert zu machen um sicher zu gehen (und dann manuell zu wecken).

Ansonsten habe ich leider auch keine Idee mehr...
(außer vielleicht mal Batterien raus warten und wieder rein...)

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

Zitat von: Muellermann am 17 September 2017, 09:02:44
set Flur_Bewegung configMotionAlarmCancellationDelay 60

kommt folgendes zurück

unknown argument configMotionAlarmCancellationDelay, choose one of alarmnotification associationAdd associationDel basicSet basicValue configByte configDefault configLong configWord mcaAdd mcaDel neighborUpdate powerlevel powerlevelTest returnRouteAdd returnRouteDel secSupportedReport wakeupInterval wakeupNoMoreInformation
Indiz, dass die model.* - Readings nicht mehr vorhanden sind.

Für den Rest:
Verstehe leider das Problem noch nicht. Hilfreich wäre eventuell ein Log-Auszug des get-battery-Abrufs und ein aktuelles list des Devices. Zum Vorgehen siehe bitte: Welche Infos sollten Anfragen im ZWave-Forum enthalten

Gruß, Christian

Muellermann

Keine Ahnung warum, aber ein Löschen des devices und eine anschliessende Neuerkennung durch Autocreate haben dazu geführt, dass ich den Sensor wieder vernünftig programmieren und auslesen kann.

Vielen Dank für eure Unterstützung :)