Hi,
ich habe gerade einen Fibaro MultiSensor in mein Fhem Server inkludiert, bekomme aber die Sensorwerte nicht angezeigt.
Folgende Ausgabe gibt mir List:
Internals:
CFGFN
DEF d344759d 27
IODev ZWAVE1
LASTInputDev ZWAVE1
MSGCNT 166
NAME ZWave_SENSOR_BINARY_27
NR 55
STATE wakeupInterval 86400 01
TYPE ZWave
ZWAVE1_MSGCNT 166
ZWAVE1_RAWMSG 0004001b03200100
ZWAVE1_TIME 2016-02-21 22:59:44
homeId d344759d
isWakeUp 1
lastMsgSent 1456081355.25663
nodeIdHex 1b
Readings:
2016-02-21 22:59:44 basicSet 00
2016-02-21 20:02:36 model FIBARO System FGMS001 Motion Sensor
2016-02-21 20:02:36 modelConfig fibaro/fgms.xml
2016-02-21 20:02:36 modelId 010f-0800-1001
2016-02-21 20:02:34 state wakeupInterval 86400 01
2016-02-21 20:02:37 transmit OK
SendStack:
get:131b03700553251b
get:131b03700552251b
get:131b03700510251b
get:131b0370050e251b
get:131b0370050c251b
get:131b03700528251b
get:131b0370052a251b
get:131b0370053e251b
get:131b03700551251b
get:131b03700559251b
get:131b03700550251b
get:131b03700557251b
get:131b03700556251b
get:131b03700506251b
get:131b03700502251b
get:131b03700501251b
get:131b03700509251b
get:131b03700508251b
get:131b03700503251b
get:131b03700504251b
get:131b0370051a251b
get:131b03700516251b
get:131b03700518251b
get:131b03700514251b
get:131b03700542251b
get:131b0370053c251b
get:131b03700540251b
get:131b03700553251b
get:131b03700552251b
get:131b03700510251b
get:131b0370050e251b
get:131b0370050c251b
get:131b03700528251b
get:131b0370052a251b
get:131b0370053e251b
get:131b03700551251b
get:131b03700559251b
get:131b03700550251b
get:131b03700557251b
get:131b03700556251b
get:131b03700506251b
get:131b03700502251b
get:131b03700501251b
get:131b03700509251b
get:131b03700508251b
get:131b03700503251b
get:131b03700504251b
get:131b0370051a251b
get:131b03700516251b
get:131b03700518251b
get:131b03700514251b
get:131b03700542251b
get:131b0370053c251b
get:131b03700540251b
set:131b0485010301251b
get:131b028505251b
Attributes:
IODev ZWAVE1
classes SENSOR_BINARY WAKE_UP ASSOCIATION BATTERY MULTI_CMD CRC_16_ENCAP MANUFACTURER_SPECIFIC VERSION CONFIGURATION MULTI_CHANNEL_ASSOCIATION SENSOR_MULTILEVEL SENSOR_ALARM MARK SENSOR_BINARY SENSOR_MULTILEVEL SENSOR_ALARM BASIC
room ZWave
Würde mich über einen Tipp sehr freuen.
Viele Grüße
vga
Was heißt Du bekommst die Sensorwerte nicht angezeigt?
Bewegungsanzeige sehe ich. Die anderen Werte kommen nicht zwingend sofort.
Hast Du den mal manuell mit 3x B Taste drücken aufgeweckt, damit offene Befehle verschickt werden? Steht viel im Sendstack.
;D ...das wars natürlich, habe den Wakeup-Befehl im Beipackzettel vergebens gesucht und nur einfach klick probiert.
Nach dem Trible-click werden die Readings jetzt komplett angezeigt!
Danke für die Hilfe.
....ich bekomme nun die Sensorwerte in den Readings angezeigt, aber mir ist aufgefallen dass ich keinen Zustand der Batterie angezeigt bekomme. Muss man dafür noch etwas bestimmtes konfigurieren?
Aktuelle List Ausgabe:
Internals:
CFGFN
DEF d344759d 27
IODev ZWAVE1
LASTInputDev ZWAVE1
MSGCNT 540
NAME EyeMS
NR 55
STATE open
TYPE ZWave
ZWAVE1_MSGCNT 540
ZWAVE1_RAWMSG 0004101b079c021b00ff0000
ZWAVE1_TIME 2016-02-22 22:33:36
homeId d344759d
isWakeUp 1
lastMsgSent 1456176750.92338
nodeIdHex 1b
Readings:
2016-02-22 22:32:30 CMD ZW_APPLICATION_UPDATE
2016-02-22 22:33:36 alarm_type_00 level ff node 1b seconds 0
2016-02-21 23:34:22 assocGroup_1 Max 5 Nodes ZWAVE1
2016-02-21 23:34:22 assocGroup_2 Max 5 Nodes
2016-02-21 23:34:22 assocGroup_3 Max 1 Nodes ZWAVE1
2016-02-21 23:34:17 assocGroups 3
2016-02-22 22:31:33 basicSet ff
2016-02-21 23:34:18 configAmbientIlluminationLevelAbove83 1000
2016-02-21 23:34:18 configAmbientIlluminationLevelBelow82 100
2016-02-21 23:34:18 configBASICOFFCommandFrameValue 0
2016-02-21 23:34:18 configBASICONCommandFrameValue 255
2016-02-21 23:34:18 configBasicCommandClassFrames12 BASICONAndBASICOFFCommandFrames0
2016-02-21 23:34:18 configIlluminationReportThreshold 200
2016-02-21 23:34:18 configIlluminationReportsInterval 0
2016-02-21 23:34:19 configIntervalOfTemperatureMeasuring 900
2016-02-21 23:34:19 configLEDBrightness 50
2016-02-21 23:34:19 configLEDIndicatingTamperAlarm LEDIndicatesTamperAlarm
2016-02-21 23:34:19 configLEDSignalingMode LongBlinkThenShortBlinkLEDColour10
2016-02-21 23:34:19 configMaximumTemperatureResultingInRed87 28
2016-02-21 23:34:19 configMinimumTemperatureResultingIn86 18
2016-02-21 23:34:19 configMotionAlarmCancellationDelay 30
2016-02-21 23:34:20 configMotionSensorSBlindTime2 15
2016-02-21 23:34:20 configMotionSensorSSensitivity 10
2016-02-21 23:34:20 configNightDay 200
2016-02-21 23:34:20 configPIRSensorOperatingMode PIRSensorAlwaysActive
2016-02-21 23:34:20 configPIRSensorSPulseCounter 1
2016-02-21 23:34:20 configPIRSensorSWindowTime 2
2016-02-21 23:34:20 configTamperAlarmBroadcastMode TamperAlarmIsNotSentInBroadcast0
2016-02-21 23:34:21 configTamperAlarmCancellationDelay 30
2016-02-21 23:34:21 configTamperOperatingModes Tamper
2016-02-21 23:34:21 configTamperSensitivity 15
2016-02-21 23:34:21 configTemperatureOffset 0
2016-02-21 23:34:21 configTemperatureReportThreshold 10
2016-02-21 23:34:21 configTemperatureReportsInterval 0
2016-02-22 22:32:33 luminance 0 Lux
2016-02-21 20:02:36 model FIBARO System FGMS001 Motion Sensor
2016-02-21 20:02:36 modelConfig fibaro/fgms.xml
2016-02-21 20:02:36 modelId 010f-0800-1001
2016-02-22 22:31:32 reportedState open
2016-02-22 22:31:32 state open
2016-02-22 22:32:34 temperature 22.4 C
2016-02-22 22:32:32 transmit OK
2016-02-22 17:57:47 wakeup notification
Attributes:
IODev ZWAVE1
classes SENSOR_BINARY WAKE_UP ASSOCIATION BATTERY MULTI_CMD CRC_16_ENCAP MANUFACTURER_SPECIFIC VERSION CONFIGURATION MULTI_CHANNEL_ASSOCIATION SENSOR_MULTILEVEL SENSOR_ALARM MARK SENSOR_BINARY SENSOR_MULTILEVEL SENSOR_ALARM BASIC
room ZWave
get EyeMS battery
oder ein DOIF, um bei jedem WakeUp den Batteriestatus abzufragen.
define DI_EyeMS_getBatt DOIF ([EyeMS:"wakeup.*"]) (get EyeMSbattery)
attr DI_EyeMS_getBatt do always
attr EyeMS event-on-update-reading wakeup
Andreas
aha, nach get EyeMS battery sehe ich den Wert nun auch in den Readings, vielen Dank Andreas.
Hat das erklärbare Gründe, weshalb der Wert nicht direkt angezigt wurde?
Jetzt habe ich noch 2 Fragen bezüglich des Snesors:
1. Ich habe den Sensor seit 7 Tagen eingebunden.
Nun wollte ich ein Plot für die Temperatur erstellen, musste dabei aber feststellen, dass vor 2 Tagen (also dem 22.02) der letzte Eintrag in der FileLog_AeoMS war. Davor wurden die Werte immer stündlich geloggt.
Folgendes ergibt "list AeoMS":
Save config
Unsorted
ZWave
icoEverything Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor
Internals:
DEF d344759d 25
IODev ZWAVE1
LASTInputDev ZWAVE1
MSGCNT 1684
NAME AeoMS
NR 22
STATE TRANSMIT_NO_ACK
TYPE ZWave
ZWAVE1_MSGCNT 1684
ZWAVE1_RAWMSG 00131901
ZWAVE1_TIME 2016-02-24 13:36:27
homeId d344759d
isWakeUp 1
lastMsgSent 1456317379.05609
nodeIdHex 19
Readings:
2016-02-17 18:28:53 CMD ZW_APPLICATION_UPDATE
2016-02-24 11:13:31 alarm HomeSecurity: Tampering, product covering removed, arg 0000
2016-02-17 18:28:53 assocGroup_1 Max 5 Nodes ZWAVE1
2016-02-17 18:28:53 assocGroups 1
2016-02-24 10:55:11 basicSet 00
2016-02-24 13:36:18 battery 100 %
2016-02-17 18:22:24 config_9 256
2016-02-24 13:36:17 humidity 40 %
2016-02-24 13:36:18 luminance 49 Lux
2016-02-17 18:22:22 model Aeotec MultiSensor 6
2016-02-17 18:22:22 modelConfig aeotec/multisensor6.xml
2016-02-17 18:22:22 modelId 0086-0002-0064
2016-02-24 13:36:27 state TRANSMIT_NO_ACK
2016-02-24 13:36:17 temperature 19.2 C
2016-02-24 13:36:27 transmit NO_ACK
2016-02-24 13:36:18 ultraviolet 0 UV
2016-02-24 13:36:19 wakeup notification
Attributes:
IODev ZWAVE1
classes ZWAVEPLUS_INFO VERSION MANUFACTURER_SPECIFIC ASSOCIATION_GRP_INFO ASSOCIATION POWERLEVEL ALARM WAKE_UP BATTERY SENSOR_BINARY SENSOR_MULTILEVEL CONFIGURATION FIRMWARE_UPDATE_MD MARK DEVICE_RESET_LOCALLY
room ZWave
BTW, was bedeutet bei state "TRANSMIT_NO_ACK" eigentlich?
Hilft das bei der Fehlersuche, oder kann man woanders etwas genaueres dazu rausfinden?
2.Ich wollte ein watchdog auf den Sensor anlegen mit folgendem vorhaben:
Bei Bewegungserkennung (von Sensor AeoMS) soll das Licht (WallPlug) angehen, wird 20sekunden nicht erneut eine Bewegung registiert geht das Licht wieder aus.
So sieht also meine Abfrage aus:
define watchdog_AeoMS watchdog AeoMS.basicSet:ff 00:00:20 SAME set WallPlug off; setstate watchdog_AeoMS defined
- Da ich im Sensor kein spezielles "motion"-Reading gefunden habe, dachte ich dass basicSet passt, da ich denke das hier die Bewegungserkennung ankommt, oder liege ich falsch?
Hat aber leider nicht funktioniert, "Licht" bleibt an.
also habe ich folgendes probiert:
define watchdog_AeoMS watchdog AeoMS 00:00:20 SAME set WallPlug off; setstate watchdog_AeoMS defined
- Siehte da, so funktioniert es. Aber jetzt werden doch alle Alarme, zb. auch Erschütterungen, dazu führen dass das Licht angeht, oder?
Gibt es hier bei den z-wave Sensoren eine spezielle Schreibweise für den Ausdruck, um auf einen bestimmten Wert des MultiSensors zu hören? quasi vom Sinn her "AeoMS.basicSet:ff" nur eben korrekt ausgeführt ;)
Nicht wirklich eine Anwort, sondern nur Bemerkungen:
ZitatBTW, was bedeutet bei state "TRANSMIT_NO_ACK" eigentlich?
Dass um diese Uhrzeit ein Befehl vom Controller zum Geraet nicht mit ACK beantwortet wurde (wie es sich eigentlich gehoert).
ZitatAeoMS.basicSet:ff
Ich gehe davon aus, dass dieses Event als "basicSet ff", und nicht mit : gemeldet wird.
Zitatalso habe ich folgendes probiert:
Bei watchdog/notify/FileLog/DOIF sollte man nicht probieren, sondern vorher im Event-Monitor anschauen, was kommt, und das dann gezielt spezifizieren.
Zitatdefine watchdog_AeoMS watchdog AeoMS 00:00:20 SAME set WallPlug off; setstate watchdog_AeoMS defined
Ich weiss nicht, wer auf die Idee mit dem setstate kam, aber es ist nicht von mir, ist im commandref nicht dokumentiert, und hat damit auch kein Bestandsschutz. Wollte nur erwaehnen, da ich das schonmal gesehen habe.
Vielen Dank für deine Bemerkungen Rudolf,
solche Anmerkungen sind für mich auch Gold wert! :D
ZitatDass um diese Uhrzeit ein Befehl vom Controller zum Geraet nicht mit ACK beantwortet wurde (wie es sich eigentlich gehoert).
Sollte mich das dann beunruhigen und ich darauf reagieren, wenn ja, wie könnte die Fehlersuche dafür denn aussehen?
ZitatBei watchdog/notify/FileLog/DOIF sollte man nicht probieren, sondern vorher im Event-Monitor anschauen,
das mit dem Event Monitor war mir nicht klar.
Aber wie muss ich mir das vorstellen? Wenn ich den Wiki Eintrag dazu lese ist das für mich einfach nur eine "live" Log ansicht, mit direktem Ergebnis.
Wenn ich die Anweisung dort genauso ausführe, wäre das doch nichts anderes, oder? WIe kann ich dann so eine Anweisung darin "test"?
ZitatIch gehe davon aus, dass dieses Event als "basicSet ff", und nicht mit : gemeldet wird.
Das mit dem Event werde ich heute abend gleich testen, Danke.
ZitatIch weiss nicht, wer auf die Idee mit dem setstate kam
...kann man also den part nach dem "; setstate watchdog_AeoMS defined" weglassen? ...habe mich da auch nach dem Sinn gefragt.
..."AeoMS.basicSet ff" habe ich nun testen können. Das funktioniert leider auch nicht, da der Befehl dann nichtmehr richtig formatiert ist.
ZitatSollte mich das dann beunruhigen und ich darauf reagieren, wenn ja, wie könnte die Fehlersuche dafür denn aussehen?
Ob du unruhig sein sollst, will ich nicht beantworten, ein Funktelegramm konnte halt nicht uebermittelt werden.
Falls das ein Fehler im Modul 10_ZWave.pm ist, dann muesste ich das mit einem "attr ZWAVE1 verbose 5" log-Ausschnitt um die Problem-Uhrzeit herum sehen. Falls das Problem ein ZWDongle-Firmware-Problem ist, dann koennte man das mit einem ZWave@culfw (verbose 5) Mitschnitt sehen. Falls es an der lokalen Gegebenheiten/beschraenkten Reichweite der Geraete/Funkstoerung liegt (ist mAn am wahrscheinlichsten), dann braeuchte man bessere Ausruestung, mit dem ich mich nicht mehr auskenne :)
ZitatAber wie muss ich mir das vorstellen?
Nicht vorstellen, sondern ausprobieren:
- "Event monitor" im Browser anklicken
- danach Knopf druecken
- (ich habe das mit meiner Fernbedienung gemacht, der Knopf heisst bei mir r4.1)
- im Fenster erscheint
Zitat2016-02-24 18:42:21.367 ZWave r4.1 basicSet: ff
- Geraet ist also r4.1, Event ist basicSet: ff (Achtung, Leerzeichen und Doppelpunkt)
- notify/watchdog/FileLog pruefen auf DeviceName oder DeviceName:Event, wobei man kein Leerzeichen angeben kann. Statt Leerzeichen verwendet man .
- Passendes Notify zum testen:
define n notify r4.1:basicSet:.ff { Log 1, "Hello" }
Zitat..kann man also den part nach dem "; setstate watchdog_AeoMS defined" weglassen?
Wenn das so mit einem ; in fhem.cfg steht, dann ja, ist sinnfrei.
Wenn das im FHEMWEB, Detail-Ansicht, DEF-Fenster steht, dann nicht, da hier ;; zu ; gewandelt wird. Dann wird setstate nach Ausloesen des Watchdogs ausgefuehrt, und stellt ihn auf dem Ausganszustand zurueck. Das fuer diesen Zweck in der Doku beschriebene Befehl heisst aber "trigger watchdog_AeoMS .", setstate funktioniert nur aus versehen.
Zitatdefine n notify r4.1:basicSet:.ff { Log 1, "Hello" }
Super!. nun passt das mit der "syntax", vielen Dank :)
Aber das "hello" wird dann nur im LogFile angezeigt, und nicht im Event Monitor, wie ich das gesehen hab.;)
Dann müsste mein Befehl so aussehen, richtig?:
define watchdog_AeoMS watchdog AeoMS:basicSet:.ff 00:00:20 SAME set WallPlug off;; trigger watchdog_AeoMS .Wenn ich diesen Befehl in die GUI Kommandozeile eingebe, habe ich zwei ";" in der Anweisung, wenn ich aber die Anweisungs-Detail Seite öffne, und den CMD editiere, dann ist nur ein ";" vorhanden. Ist das korrekt?
Und gibt es noch eine Möglichkeit rauszufinden, weshalb die Werte nichtmehr in die FileLog protokolliert werden?
Zitat von: vga am 24 Februar 2016, 19:12:29
Und gibt es noch eine Möglichkeit rauszufinden, weshalb die Werte nichtmehr in die FileLog protokolliert werden?
Reichweitenprobleme und deshalb keinen Empfang mehr?
Ansonsten:
ZitatFalls das ein Fehler im Modul 10_ZWave.pm ist, dann muesste ich das mit einem "attr ZWAVE1 verbose 5" log-Ausschnitt um die Problem-Uhrzeit herum sehen.
Gruß, Christian
zur watchdog Anweisung:
ich habe nun beide Methoden ausprobiert:
Auszug aus dem CMD der watchdog-Details:
AeoMS:basicSet:.ff 00:00:20 SAME set WallPlug off; setstate watchdog_AeoMS defined
AeoMS:basicSet:.ff 00:00:20 SAME set WallPlug off; trigger watchdog_AeoMS .
Beide Arten funktionieren zwar anfangs, also wenn ich eine Bewegung verursache. Doch mit der Zeit schaltet sich das zu schaltende Gerät immer wieder an/aus, sporadisch!
So sieht das dann im Event-Monitor aus:
2016-02-25 18:52:39 ZWave WallPlug on
2016-02-25 18:52:39 ZWave AeoMS basicSet: ff
2016-02-25 18:52:39 ZWave WallPlug on
2016-02-25 18:52:39 ZWave AeoMS alarm: HomeSecurity: Motion Detection, Unknown Location, arg 0000
2016-02-25 18:52:59 ZWave WallPlug off
2016-02-25 18:53:02 ZWave WallPlug on
2016-02-25 18:53:02 ZWave AeoMS basicSet: 00
2016-02-25 18:53:02 ZWave WallPlug on
2016-02-25 18:53:02 ZWave AeoMS alarm: HomeSecurity: Previous Events cleared, arg 0000
2016-02-25 18:53:37 ZWave WallPlug on
2016-02-25 18:53:37 ZWave AeoMS basicSet: ff
2016-02-25 18:53:38 ZWave WallPlug on
2016-02-25 18:53:38 ZWave AeoMS alarm: HomeSecurity: Motion Detection, Unknown Location, arg 0000
2016-02-25 18:53:57 ZWave WallPlug off
2016-02-25 18:53:58 ZWave WallPlug on
2016-02-25 18:53:58 ZWave AeoMS basicSet: 00
2016-02-25 18:53:58 ZWave WallPlug on
2016-02-25 18:53:58 ZWave AeoMS alarm: HomeSecurity: Previous Events cleared, arg 0000
2016-02-25 18:54:03 ZWave WallPlug on
2016-02-25 18:54:03 ZWave AeoMS basicSet: ff
2016-02-25 18:54:03 ZWave WallPlug on
2016-02-25 18:54:03 ZWave AeoMS alarm: HomeSecurity: Motion Detection, Unknown Location, arg 0000
2016-02-25 18:54:23 ZWave WallPlug off
2016-02-25 18:54:23 ZWave WallPlug on
2016-02-25 18:54:23 ZWave AeoMS basicSet: 00
2016-02-25 18:54:23 ZWave WallPlug on
2016-02-25 18:54:23 ZWave AeoMS alarm: HomeSecurity: Previous Events cleared, arg 0000
Da bin ich irgendwie ratlos!?
Zum dem Problem der fehlenden Werte:
Der Sensor ist in Reichweite, kann ganz normal Alarme sehen.
Um Welchen Zeitpunkt soll der verbose 5 Logauszug denn sein, wenn ich garkeine Werte bekomme? :o ;)
z.B.: AeoMS Reading für :
state TRANSMIT_NO_ACK 2016-02-25 17:08:25
Log Auszug mit verbose 5 um diesen Zeitpunkt:
2016.02.25 17:08:19 5: ZWDongle_Write 0013190284082519 (d344759d)
2016.02.25 17:08:19 5: SW: 010900131902840825194e
2016.02.25 17:08:19 5: ACK received, WaitForAck=>2 for 010900131902840825194e
2016.02.25 17:08:19 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2016.02.25 17:08:19 5: SW: 06
2016.02.25 17:08:19 5: ZWAVE1 dispatch 011301
2016.02.25 17:08:21 4: no response from device, removing 010900131902840825194e from dongle sendstack
2016.02.25 17:08:25 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00131901
2016.02.25 17:08:25 5: SW: 06
2016.02.25 17:08:25 5: ZWAVE1 dispatch 00131901
2016.02.25 17:08:25 4: ZWAVE1 CMD:ZW_SEND_DATA ID:01 ARG:
2016.02.25 17:08:25 2: ZWAVE1 transmit NO_ACK for 19
2016.02.25 17:08:25 2: ZWave set WallPlug on
2016.02.25 17:08:25 5: ZWDongle_Write 00131a032501FF251a (d344759d)
2016.02.25 17:08:25 5: SW: 010a00131a032501FF251a1b
2016.02.25 17:08:25 2: ZWave set WallPlug on
2016.02.25 17:08:25 5: ACK received, WaitForAck=>2 for 010a00131a032501FF251a1b
2016.02.25 17:08:25 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2016.02.25 17:08:25 5: SW: 06
2016.02.25 17:08:25 5: ZWAVE1 dispatch 011301
2016.02.25 17:08:25 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00131a00
2016.02.25 17:08:25 5: SW: 06
2016.02.25 17:08:25 5: device ack reveived, removing 010a00131a032501FF251a1b from dongle sendstack
2016.02.25 17:08:25 5: ZWAVE1 dispatch 00131a00
2016.02.25 17:08:25 4: ZWAVE1 CMD:ZW_SEND_DATA ID:00 ARG:
2016.02.25 17:08:25 4: ZWAVE1 transmit OK for 1a
2016.02.25 17:08:25 5: ZWDongle_Write 00131a032501FF251a (d344759d)
2016.02.25 17:08:25 5: SW: 010a00131a032501FF251a1b
2016.02.25 17:08:25 5: ACK received, WaitForAck=>2 for 010a00131a032501FF251a1b
2016.02.25 17:08:25 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2016.02.25 17:08:25 5: SW: 06
2016.02.25 17:08:25 5: ZWAVE1 dispatch 011301
2016.02.25 17:08:25 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00131a00
2016.02.25 17:08:25 5: SW: 06
2016.02.25 17:08:25 5: device ack reveived, removing 010a00131a032501FF251a1b from dongle sendstack
2016.02.25 17:08:25 5: ZWAVE1 dispatch 00131a00
2016.02.25 17:08:25 4: ZWAVE1 CMD:ZW_SEND_DATA ID:00 ARG:
2016.02.25 17:08:25 4: ZWAVE1 transmit OK for 1a
2016.02.25 17:20:45 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004001d0a320221440000000c0000
2016.02.25 17:20:45 5: SW: 06
2016.02.25 17:20:45 5: ZWAVE1 dispatch 0004001d0a320221440000000c0000
2016.02.25 17:20:45 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:1d ARG:0a320221440000000c0000sen Ereigniszeitpunkt:
[code]2016.02.25 17:08:19 5: ZWDongle_Write 0013190284082519 (d344759d)
2016.02.25 17:08:19 5: SW: 010900131902840825194e
2016.02.25 17:08:19 5: ACK received, WaitForAck=>2 for 010900131902840825194e
2016.02.25 17:08:19 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2016.02.25 17:08:19 5: SW: 06
2016.02.25 17:08:19 5: ZWAVE1 dispatch 011301
2016.02.25 17:08:21 4: no response from device, removing 010900131902840825194e from dongle sendstack
2016.02.25 17:08:25 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00131901
2016.02.25 17:08:25 5: SW: 06
2016.02.25 17:08:25 5: ZWAVE1 dispatch 00131901
2016.02.25 17:08:25 4: ZWAVE1 CMD:ZW_SEND_DATA ID:01 ARG:
2016.02.25 17:08:25 2: ZWAVE1 transmit NO_ACK for 19
2016.02.25 17:08:25 2: ZWave set WallPlug on
2016.02.25 17:08:25 5: ZWDongle_Write 00131a032501FF251a (d344759d)
2016.02.25 17:08:25 5: SW: 010a00131a032501FF251a1b
2016.02.25 17:08:25 2: ZWave set WallPlug on
2016.02.25 17:08:25 5: ACK received, WaitForAck=>2 for 010a00131a032501FF251a1b
2016.02.25 17:08:25 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2016.02.25 17:08:25 5: SW: 06
2016.02.25 17:08:25 5: ZWAVE1 dispatch 011301
2016.02.25 17:08:25 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00131a00
2016.02.25 17:08:25 5: SW: 06
2016.02.25 17:08:25 5: device ack reveived, removing 010a00131a032501FF251a1b from dongle sendstack
2016.02.25 17:08:25 5: ZWAVE1 dispatch 00131a00
2016.02.25 17:08:25 4: ZWAVE1 CMD:ZW_SEND_DATA ID:00 ARG:
2016.02.25 17:08:25 4: ZWAVE1 transmit OK for 1a
2016.02.25 17:08:25 5: ZWDongle_Write 00131a032501FF251a (d344759d)
2016.02.25 17:08:25 5: SW: 010a00131a032501FF251a1b
2016.02.25 17:08:25 5: ACK received, WaitForAck=>2 for 010a00131a032501FF251a1b
2016.02.25 17:08:25 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2016.02.25 17:08:25 5: SW: 06
2016.02.25 17:08:25 5: ZWAVE1 dispatch 011301
2016.02.25 17:08:25 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00131a00
2016.02.25 17:08:25 5: SW: 06
2016.02.25 17:08:25 5: device ack reveived, removing 010a00131a032501FF251a1b from dongle sendstack
2016.02.25 17:08:25 5: ZWAVE1 dispatch 00131a00
2016.02.25 17:08:25 4: ZWAVE1 CMD:ZW_SEND_DATA ID:00 ARG:
2016.02.25 17:08:25 4: ZWAVE1 transmit OK for 1a
2016.02.25 17:20:45 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004001d0a320221440000000c0000
2016.02.25 17:20:45 5: SW: 06
2016.02.25 17:20:45 5: ZWAVE1 dispatch 0004001d0a320221440000000c0000
2016.02.25 17:20:45 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:1d ARG:0a320221440000000c0000
Hilft das weiter? :)
Mir ist jetzt immerhin aufgefallen, dass Du zwar im Thread FGMS001 schreibst, aber es wohl neben um den AEOTEC Multisensor geht....
Der hat laut Forum ein Problem mit zu schnellem Einschlafen. Als Lösungsmöglichkeit wurde speziell das Attribut WNMI_delay eingeführt. Das solltest Du mal im passenden Thread suchen.
du hast Recht. Ich habe momentan beide Sensoren Fibaro und AeoTech eingebunden, einfach um auch mal beide zu testen.
Ich schau mal nach dem benannten Thread, Danke für den Tipp!
zu Transmit_No_Ack:
Also ich habe nun das Attribut "WNMI_delay" an meinem Sensor AeoMS (das ist derbAeoTech MultiSensor) eingetragen und einmal 0.2 und einmal 0.3 getestet, leider ohne eine Besserung. Transmit_No_Ack bleibt.
Brauche ich da andere Werte?
zu den fehlenden Werten:
Ich bekomme ja defintiv die Readings aktualisiert, die Verbindung ist also da, aber im device-FileLog ist der letzte Eintrag echt vom 22.02, seit 4 Tagen garnichtsmehr.
Wo kann ich da denn noch weiter graben? :D
Haben diese beiden Probleme vielleicht sogar etwas miteinander zu tun?
Das einzige was mir jetzt aus rein physikalischen Aspekten noch eingefallen ist. Ich habe mal mein Controller (RasPi) in einen anderen Raum verlegt (nicht wirklich weit, aber geändert)
Könnte das vielleicht Probleme im "Routing" des z-wave Netzes verursacht haben?
Wobei ich der Meinung bin, dass das nicht erklärt, weshalb ich auf der Detailseite des Sensors aktualisierte Readings bekomme, aber keine Einträge im Device FileLog vorfinde.
ZitatAlso ich habe nun das Attribut "WNMI_delay" an meinem Sensor AeoMS (das ist derbAeoTech MultiSensor) eingetragen und einmal 0.2 und einmal 0.3 getestet, leider ohne eine Besserung. Transmit_No_Ack bleibt.
Brauche ich da andere Werte?
Noch weiter Herunterzuschrauben, halte ich für problematisch. Wenn nur die "wakeupNoMoreInformation"-nachricht von FHEM an Sensor auf Transmit_No_Ack endet und Rest korrekt funktioniert, ist es zwar unschön aber unproblematisch.
Zitat
zu den fehlenden Werten:
Ich bekomme ja defintiv die Readings aktualisiert, die Verbindung ist also da, aber im device-FileLog ist der letzte Eintrag echt vom 22.02, seit 4 Tagen garnichtsmehr.
Wo kann ich da denn noch weiter graben? :D
Ist Definition von http://fhem.de/commandref.html#FileLog noch richtig?
Sollte ich vielleicht etwas weiter hoch gehen mit dem WNMI_delay Wert? ;)
die FileLog des Sonders hat folgende Internals:
Internals
DEF
./log/AeoMS-%Y.log AeoMS
NAME
FileLog_AeoMS
NOTIFYDEV
AeoMS
NR
23
NTFY_ORDER
50-FileLog_ZWave_SENSOR_MULTILEVEL_25
REGEXP
AeoMS
STATE
active
TYPE
FileLog
currentlogfile
./log/AeoMS-2016.log
logfile
./log/AeoMS-%Y.log
Habe das mal mit dem Internal vom EyeMS (Mein Figaro MultiSensor) verglichen und das ist soweit identisch. (übriges hat der keine Probleme und ist physikalisch am an der selben Stelle ;) also wird es sicher etwas mit dem delay zu tun haben.
Was mir gerade noch aufgefallen ist:
In keine meiner Geräte wird in die jeweilige FileLog noch etwas schreiben!??
manche enden am 22.02, und andere am 23.02.
In die Logfile wird aber noch geschrieben. ;)
Irgendwie krieg ich die Sache nicht richtig zum laufen. :-\
Edit:
Also ich habe den watchdog jetzt anstatt auf den AeoTech MultiSensor auf meinen Figaro MultiSensor angepasst. Hier scheint alles jetzt zu funktionieren. :)
Für den AeoTech Sensor und die fehlenden FileLog-Einträge werde ich nun 2 extra Threads machen, der Ordnung zu liebe, falls das gestattet ist. ;)
Zu einem der Ur-Problem des Threads:
"get EyeMS battery" ...gibt mir immer 100% zurück.
ich kann mir das kam vorstellen. Der Sensor hat die Batterie sicher schon gute 2-3Monate drin und ist aktiv.
Da es noch ein Testaufbau ist, war er zwar auch 1-2 Wochen ohne Verbindung zum Controller und in einer dunklen Kiste, aber dafür wird er im Test auch zweitweise über Tage stark beansprucht, und blinkt dabei fröhlich rum.
Wenn ich schätzen würde, wären 90% ein guter Stand aktuell. Hat mit dem Batterie Wert jemand Erfahrung?