Hallo,
habe leider einige Probleme mit meiner FHEM-Umgebung.
Einer meiner Sorgen-Sensoren ist der Fibaro Motion Sensor (erstere Generation).
Habe ein DOIF gestern gebaut, damit wenn eine Bewegung erkannt wird, es finster und jemand zuhause ist, das Licht an geht.
Hat soweit funktioniert, jedoch dürfte heute das Licht die ganze Zeit angeblieben sein, weil der state nach wie vor auf open ist.
Auch der letzte Wakeup ist um 09:53 Uhr erfolgt, trotz zweistündigen Intervalls - dh. 11:53 und 13:53 wurden ausgelassen.
Lux, Temperatur werden aber nach wie vor munter gesendet...
Internals:
DEF e349cd07 2
IODev ZSTICK
LASTInputDev ZSTICK
MSGCNT 124
NAME KU_motion_sensor
NR 21
STATE open
TYPE ZWave
ZSTICK_MSGCNT 124
ZSTICK_RAWMSG 00041002063105030a0073
ZSTICK_TIME 2017-01-11 14:58:02
ZWaveSubDevice no
homeId e349cd07
isWakeUp 1
nodeIdHex 02
Readings:
2017-01-11 13:54:59 alarm_type_00 level 255 node 2 seconds 0
2016-06-07 07:40:16 alarm_type_03 level 0a
2016-12-24 01:13:11 alarm_type_10 level 255 node 2 seconds 0
2016-03-28 15:14:37 assocGroup_1 Max 5 Nodes
2016-03-28 15:14:37 assocGroup_2 Max 5 Nodes
2016-03-28 15:14:37 assocGroup_3 Max 1 Nodes ZWDongle_0
2016-03-28 15:14:34 assocGroups 3
2016-10-25 05:10:26 barometricPressure 19.6 kPa
2016-12-15 21:14:33 basicReport 255
2017-01-09 21:39:29 battery 100 %
2016-12-26 14:39:07 cmdGet wakeupInterval
2016-12-30 02:53:21 configAmbientIlluminationLevelAbove83 1000
2016-04-01 22:06:36 configAmbientIlluminationLevelBelow82 100
2016-04-01 22:06:36 configBASICOFFCommandFrameValue 0
2016-12-30 02:53:22 configBASICONCommandFrameValue 255
2016-12-30 02:53:23 configBasicCommandClassFrames12 BASICONAndBASICOFFCommandFrames0
2016-12-30 02:53:23 configIlluminationReportThreshold 200
2016-12-30 02:53:24 configIlluminationReportsInterval 900
2016-12-30 02:53:24 configIntervalOfTemperatureMeasuring 900
2016-12-30 02:53:24 configLEDBrightness 50
2016-12-30 02:53:24 configLEDIndicatingTamperAlarm LEDDoesNotIndicateTamperAlarm
2016-12-30 02:53:24 configLEDSignalingMode LongBlinkThenShortBlinkLEDColour10
2016-12-30 02:53:25 configMaximumTemperatureResultingInRed87 28
2016-04-01 22:06:38 configMinimumTemperatureResultingIn86 18
2016-12-30 06:54:10 configMotionAlarmCancellationDelay 30
2016-04-01 22:06:38 configMotionSensorSBlindTime2 15
2016-04-01 22:06:39 configMotionSensorSSensitivity 10
2016-12-30 06:54:10 configNightDay 200
2016-04-01 22:06:39 configPIRSensorOperatingMode PIRSensorAlwaysActive
2016-04-01 22:06:39 configPIRSensorSPulseCounter 1
2016-12-30 08:54:35 configPIRSensorSWindowTime 12Seconds
2016-04-01 22:06:39 configTamperAlarmBroadcastMode TamperAlarmIsNotSentInBroadcast0
2016-12-30 08:54:39 configTamperAlarmCancellationDelay 30
2016-12-30 12:55:11 configTamperOperatingModes Tamper
2016-12-30 12:55:12 configTamperSensitivity 15
2016-12-30 12:55:12 configTemperatureOffset 0
2016-12-30 12:55:12 configTemperatureReportThreshold 10
2016-12-30 12:55:12 configTemperatureReportsInterval 900
2017-01-10 12:03:10 generalPurpose 505
2017-01-11 14:58:02 luminance 115 Lux
2016-04-06 18:47:13 mcaSupportedGroupings 2
2016-04-06 18:47:17 model FIBARO System FGMS001 Motion Sensor
2016-04-06 18:47:17 modelConfig fibaro/fgms.xml
2016-04-06 18:47:17 modelId 010f-0800-1001
2017-01-11 06:06:41 reportedState open
2017-01-11 06:06:41 state open
2017-01-11 14:55:11 temperature 20.2 C
2017-01-11 09:53:29 timeToAck 0.070
2017-01-11 09:53:29 transmit OK
2016-04-06 18:47:14 version Lib 3 Prot 3.67 App 2.7 HW 1 FWCounter 1 FW 2.7
2017-01-11 09:53:24 wakeup notification
2016-04-06 18:47:17 wakeupReport interval 7200 target 1
SendStack:
get:13020285052501
get:13020220022502
get:13020284052503
get:1302037005532504
get:1302037005522505
get:1302037005102506
get:13020370050e2507
get:13020370050c2508
get:1302037005282509
get:13020370052a250a
get:13020370053e250b
get:130203700551250c
get:130203700559250d
get:130203700550250e
get:130203700557250f
get:1302037005562510
get:1302037005062511
get:1302037005022512
get:1302037005012513
get:1302037005092514
get:1302037005082515
get:1302037005032516
get:1302037005042517
get:13020370051a2518
get:1302037005162519
get:130203700518251a
get:130203700514251b
get:130203700542251c
get:13020370053c251d
get:130203700540251e
set:13020485010101251f
Attributes:
IODev ZSTICK
classes SENSOR_BINARY WAKE_UP ASSOCIATION BATTERY MULTI_CMD CRC_16_ENCAP MANUFACTURER_SPECIFIC VERSION CONFIGURATION MULTI_CHANNEL_ASSOCIATION SENSOR_MULTILEVEL SENSOR_ALARM BASIC
group Sensor
icon people_sensor
room 1.2_Kueche
Im Einsatz ist ein aeotec z-stick.
Danke schon mal für eure Unterstützung,
LG
pairo
Bin jetzt zuhause und habe den Wakeup manuell angestoßen, aber der sendstack wird nicht abgearbeitet und auch der Wert von wakeup wird nicht aktualisiert...
cGroup_3 Max 1 Nodes ZWDongle_0
2016-03-28 15:14:34 assocGroups 3
2016-10-25 05:10:26 barometricPressure 19.6 kPa
2017-01-11 15:55:13 basicReport 0
2017-01-11 20:33:38 battery 74 %
2016-12-26 14:39:07 cmdGet wakeupInterval
2017-01-11 17:55:47 configAmbientIlluminationLevelAbove83 1000
2016-04-01 22:06:36 configAmbientIlluminationLevelBelow82 100
2017-01-11 17:55:49 configBASICOFFCommandFrameValue 0
2016-12-30 02:53:22 configBASICONCommandFrameValue 255
2016-12-30 02:53:23 configBasicCommandClassFrames12 BASICONAndBASICOFFCommandFrames0
2016-12-30 02:53:23 configIlluminationReportThreshold 200
2016-12-30 02:53:24 configIlluminationReportsInterval 900
2017-01-11 17:55:53 configIntervalOfTemperatureMeasuring 900
2017-01-11 17:55:53 configLEDBrightness 50
2016-12-30 02:53:24 configLEDIndicatingTamperAlarm LEDDoesNotIndicateTamperAlarm
2017-01-11 17:55:54 configLEDSignalingMode LEDInactive
2017-01-11 19:56:11 configMaximumTemperatureResultingInRed87 28
2016-04-01 22:06:38 configMinimumTemperatureResultingIn86 18
2016-12-30 06:54:10 configMotionAlarmCancellationDelay 30
2017-01-11 20:29:40 configMotionSensorSBlindTime2 15
2017-01-11 20:29:40 configMotionSensorSSensitivity 50
2017-01-11 20:29:41 configNightDay 200
2016-04-01 22:06:39 configPIRSensorOperatingMode PIRSensorAlwaysActive
2017-01-11 20:50:51 configPIRSensorSPulseCounter 2Pulses
2017-01-11 20:50:51 configPIRSensorSWindowTime 12Seconds
2017-01-11 20:50:51 configTamperAlarmBroadcastMode TamperAlarmIsNotSentInBroadcast0
2017-01-11 20:50:52 configTamperAlarmCancellationDelay 30
2017-01-11 20:50:52 configTamperOperatingModes Tamper
2017-01-11 20:50:54 configTamperSensitivity 15
2016-12-30 12:55:12 configTemperatureOffset 0
2016-12-30 12:55:12 configTemperatureReportThreshold 10
2016-12-30 12:55:12 configTemperatureReportsInterval 900
2017-01-10 12:03:10 generalPurpose 505
2017-01-11 21:02:44 luminance 0 Lux
2016-04-06 18:47:13 mcaSupportedGroupings 2
2016-04-06 18:47:17 model FIBARO System FGMS001 Motion Sensor
2016-04-06 18:47:17 modelConfig fibaro/fgms.xml
2016-04-06 18:47:17 modelId 010f-0800-1001
2017-01-11 20:36:34 neighborList ZSTICK
2017-01-11 21:16:45 reportedState open
2017-01-11 21:16:45 state open
2017-01-11 21:02:45 temperature 25.8 C
2017-01-11 20:50:54 timeToAck 0.176
2017-01-11 20:50:54 transmit OK
2016-04-06 18:47:14 version Lib 3 Prot 3.67 App 2.7 HW 1 FWCounter 1 FW 2.7
2017-01-11 19:56:11 wakeup notification
2016-04-06 18:47:17 wakeupReport interval 7200 target 1
SendStack:
get:1302037005532501
get:1302037005522502
get:1302037005102503
get:13020370050e2504
get:13020370050c2505
get:1302037005282506
get:13020370052a2507
get:13020370053e2508
get:1302037005512509
get:130203700559250a
get:130203700550250b
get:130203700557250c
get:130203700556250d
get:130203700506250e
get:130203700502250f
get:1302037005012510
get:1302037005092511
get:1302037005082512
get:1302037005032513
get:1302037005042514
get:13020370051a2515
get:1302037005162516
get:1302037005182517
get:1302037005142518
get:1302037005422519
get:13020370053c251a
get:130203700540251b
Attributes:
IODev ZSTICK
classes SENSOR_BINARY WAKE_UP ASSOCIATION BATTERY MULTI_CMD CRC_16_ENCAP MANUFACTURER_SPECIFIC VERSION CONFIGURATION MULTI_CHANNEL_ASSOCIATION SENSOR_MULTILEVEL SENSOR_ALARM BASIC
group Sensor
icon people_sensor
room 1.2_Kueche
Dann ist die wakeupNotification-Nachricht wohl nicht beim Controller angekommen.
Die neigborList des Sensors ist ziemlich sparsam besetzt. Wenn die Direktverbindung Controller-Sensor nicht kurz ist, hast Du schon ein Problem.
Hallo,
leider nein - habe den Motionsensor soeben 20cm neben dem Stick liegen und da tut sich nix.
Lux, Temp und Co. werden aber brav gemeldet...
Hmm, zu kurz geht auch 8) . Eigentlich ist mir das alles noch zu "nebelig".
Würde mal einen Neustart von FHEM durchführen, damit der Sendstack sich leert, verbose 5 am Dongle setzen und dann einmal Assoziation mit Controller kontrollieren.
Betrifft das nur den Sensor oder wie im anderen Thread erwaehnt mehrere Sensoren?
War das vor DOIF-Einbau anders? Ist das DOIF eventuell die Ursache?
Ist das wirklich der alte z-Stick von Aeotec?
Hi,
ich kann nicht sagen warum und weshalb, aber nach mehrmaligen Neustart sowie entfernen der Batterie vom Sensor und abermaligen manuellen Wakeup, als auch anschließenden neighborupdate wo nun mehrere Devices verfügbar sind funktioniert er nun wieder. Habe das Neighborupdate auf allen Devices durchgeführt, was mE. Verbesserungen gebracht hat - so wird statt "TRANSMIT_NO_ACK" bei den Schaltern wieder Lampen angezeigt. Durchaus aber möglich, dass ua. auch als Störungsursache das DOIF Mitanteil hatte (wobei ich nicht verstehen würde, wie ein "set on"-DOIF darauf Auswirkung haben sollte).
Ich werde mal alles genau beobachten und die Kommunikation genau beobachten und mich ggf. nochmals melden.
Danke jedenfalls für den Hinweis mit dem Neighbrupdate :).
LG
pairo
Hi,
da hänge ich mich doch mal drauf...
Also ich habe mittlerweile 2 Bewegungsmelder Fibaro, also die "hübschen" Augen...
Liefen eigentlich immer/bislang sehr gut.
Seit kurz vor Weihnachten haben sie aufgehört die Batteriewerte zu liefern.
Also ich habe ein notify auf wakeup und dann die Abfrage der Batteriewerte.
Hat immer gut funktioniert, habe so jeden Tag ca. 1-3 Batteriewerte erhalten...
...am 21.12. morgens von beiden zum letzten Mal...
Das nur so am Rande...
Das eigentlich störende (weil sonst wäre mir das mit den Batteriewerten verm. gar nicht [so schnell] aufgefallen) war, dass das Licht in den Schränken (wo ich per Bewegung das Licht anschalte und dann bei keiner Bewegung mehr wieder ausschalte) nicht mehr zuverlässig aus ging.
Und nicht ganz so häufig auch nicht an...
Ich war auch schon drauf und dran alles mal zu resetten etc.
Bis ich dann bei einiger Suche drauf gekommen bin, nicht mehr "open/closed" zu verwenden sondern den basicSet.
Habe im Log gesehen, dass der basicSet öfter kommt als open/closed...
Also notify von state open|closed auf basicSet 255|0 geändert, seither alles wieder gut...
...bis auf die Batteriewerte, da werde ich mal noch mal analysieren...
Gruß, Joachim
@pairo:
Wenn Du wirklich den "alten" schwarzen AEOTEC Z-Stick 2 haben solltest: der kann afaik wegen des verwendeten SDKs keine Explorer Frames und damit ist neigborUpdate Pflicht.
@MadMax-FHEM:
Ist das die alte oder neue Gen5-Variante? Bei der alten würde ich auf eine unnötige Assoziierung des Controllers mit Gruppe 1 (Gruppe 3 reicht) und eventuellen Telegrammverlusten wegen Funkkollisionen tippen. Auch notifys auf wakeup können zu unnötigen Funkkollisionen führen. Würde dazu mal das Log analysieren.
Zitat von: krikan am 12 Januar 2017, 11:54:01
@MadMax-FHEM:
Ist das die alte oder neue Gen5-Variante? Bei der alten würde ich auf eine unnötige Assoziierung des Controllers mit Gruppe 1 (Gruppe 3 reicht) und eventuellen Telegrammverlusten wegen Funkkollisionen tippen. Auch notifys auf wakeup können zu unnötigen Funkkollisionen führen. Würde dazu mal das Log analysieren.
Hmmm, ich bin nicht sicher, glaube aber (leider) keine Gen5.
Wo/wie sehe ich das??
Ich muss auch gestehen, dass ich hauptsächlich Homematic habe und mich da (sehr) gut auskenne.
Die Fibaro Bewegungsmelder habe ich eigentlich nur, weil meine Freundin die soooo hübsch findet (gut ich auch ;-) und die Homematic Fensterkontakte [die ja auch gehen würden um zu "sehen", ob Schrank auf/zu] ihr nicht gefallen)...
Wie sehe ich in welcher AssocGroup der Controller ist?
Das Reading assocGroups steht auf 3 und bei wakeupReport steht target 1.
Da diese bei meiner Freundin verbaut sind kann ich auch nicht soo leicht nachschauen...
Und das mit dem Batterieauslesen habe ich irgendwo gesehen, dass man auf wakeup ein notify macht und dann den get Batterisstatus absetzt...
...und hat ja auch immer funktioniert (bis kurz vor Weihnachten).
Die Homematic-Geräte schicken ja selbsständig ab und an (oder auch mal öfter) eine Meldung zum Batteriestand...
...ginge das hier auch?
Und seit umstellung von state open|closed auf basicSet 0|255 läuft zumindest die Erkennung für Licht an/aus wieder einwandfrei...
Vielen Dank schon mal und sorry wegen noch mehr Fragen zurück, Joachim
Zitat von: krikan am 12 Januar 2017, 11:54:01
@pairo:
Wenn Du wirklich den "alten" schwarzen AEOTEC Z-Stick 2 haben solltest: der kann afaik wegen des verwendeten SDKs keine Explorer Frames und damit ist neigborUpdate Pflicht.
Nein hab eh den weißen Stick.
Wodurch wird der State eigentlich aktualisiert?
Habe da einige Geräte noch mit einem alten "TRANSMIT_NO_ACK", die aber ohne Probleme ihre Werte melden:
state TRANSMIT_NO_ACK 2016-05-17 20:16:09
Zitat von: krikan am 12 Januar 2017, 11:54:01
@MadMax-FHEM:
Ist das die alte oder neue Gen5-Variante? Bei der alten würde ich auf eine unnötige Assoziierung des Controllers mit Gruppe 1 (Gruppe 3 reicht) und eventuellen Telegrammverlusten wegen Funkkollisionen tippen. Auch notifys auf wakeup können zu unnötigen Funkkollisionen führen. Würde dazu mal das Log analysieren.
Also ist wohl (leider!?) die alte Variante...
Log analysieren?
Verbose bei was? USB-Stick, Gerät selbst, beides auf 5!?
Aktuell steht im Log (weder fhem noch Gerät beim USB-Stick hab ich noch nicht geschaut) nichts drin was mich auf einen Fehler deuten ließe.
Nach was soll ich da schauen??
Danke, Joachim
Zitat von: pairo am 12 Januar 2017, 13:30:15
Wodurch wird der State eigentlich aktualisiert?
Durch das, was das Modul vorgibt. Bei manchen Geräten in 10_ZWave.pm gibt es keine Vorgabe, dann mit dem Attribut stateFormat anpassen.
Hatte das hier (https://wiki.fhem.de/wiki/Z-Wave#Warum_bleibt_der_Status_.28STATE.29_des_neu_inkludierten_Ger.C3.A4tes_dauerhaft_auf_.22associationAdd_.3CassociationGroup.3E_.3CCtrlNodeId.3E.22_stehen.3F) versucht darzustellen. Müsste das evtl. mehr generalisieren. Verbesseungsvorschläge willkommen.
Zitat von: MadMax-FHEM am 12 Januar 2017, 13:59:24
Log analysieren?
Verbose bei was? USB-Stick, Gerät selbst, beides auf 5!?
Nach was soll ich da schauen??
Zunächst würde ich mit "get <device> associationAll" alle Assoziationen abrufen. Wenn bei dem (nicht schlechten) alten Auge <ZWdongle> nicht nur in Assogroup 3, sondern auch in Assogroup 1 steht, würde ich <ZWdongle> mit "associationDel" aus 1 löschen. Das ist überflüssig; notify natürlich wieder anpassen. Dann würde ich ohne trifftigen Grund die Abfragen von "get-battery" herausnehmen. Dadurch spart man sich Funktelegramme, spart eventuell Batterien und verhindert potentiell unnötige Probleme. Ich handle dabei immer nach dem vereinfachenden Motto: Nur notwendige Funknachrichten = wenig Probleme. Man kann mich aber gerne vom Gegenteil überzeugen. :) Bspw. kenne ich keinen batteriebetriebenen Sensor, der zur Neige gehende Batterien nicht automatisch über die Assoziationsgruppe des Controllers meldet.
Zur Detail-Analyse von ZWave generell "attr <ZWdongle> verbose 5" setzen. Im Endeffekt kann man zur Anlayse auch für eigene Zwecke das https://wiki.fhem.de/wiki/Z-Wave#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F anwenden. Dann im Logfile suchen, wann es "knallt". Häufiges NO_ACK, CAN, TRANSMIT_NO_ACK, resending usw. sind Indizien für weitere Forschungen. Zwar auch nicht immer "böse", aber bei gehäuftem und regelmäßigem Auftreten auf jeden Fall einen genaueren Blick wert.
Obiges schließt aber nicht Gerätedefekte, ungünstige Empfangsbedingungen usw. aus. Es bleibt ein Einzelfallproblem. 8)
Gruß, Christian
Zitat von: krikan am 12 Januar 2017, 14:38:27
Zunächst würde ich mit "get <device> associationAll" alle Assoziationen abrufen. Wenn bei dem (nicht schlechten) alten Auge <ZWdongle> nicht nur in Assogroup 3, sondern auch in Assogroup 1 steht, würde ich <ZWdongle> mit "associationDel" aus 1 löschen. Das ist überflüssig; notify natürlich wieder anpassen. Dann würde ich ohne trifftigen Grund die Abfragen von "get-battery" herausnehmen. Dadurch spart man sich Funktelegramme, spart eventuell Batterien und verhindert potentiell unnötige Probleme. Ich handle dabei immer nach dem vereinfachenden Motto: Nur notwendige Funknachrichten = wenig Probleme. Man kann mich aber gerne vom Gegenteil überzeugen. :) Bspw. kenne ich keinen batteriebetriebenen Sensor, der zur Neige gehende Batterien nicht automatisch über die Assoziationsgruppe des Controllers meldet.
Zur Detail-Analyse von ZWave generell "attr <ZWdongle> verbose 5" setzen. Im Endeffekt kann man zur Anlayse auch für eigene Zwecke das https://wiki.fhem.de/wiki/Z-Wave#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F anwenden. Dann im Logfile suchen, wann es "knallt". Häufiges NO_ACK, CAN, TRANSMIT_NO_ACK, resending usw. sind Indizien für weitere Forschungen. Zwar auch nicht immer "böse", aber bei gehäuftem und regelmäßigem Auftreten auf jeden Fall einen genaueren Blick wert.
Obiges schließt aber nicht Gerätedefekte, ungünstige Empfangsbedingungen usw. aus. Es bleibt ein Einzelfallproblem. 8)
Gruß, Christian
Danke noch mal!
Werde ich mal prüfen/ausführen, wenn ich wieder Zugriff habe...
@pairo: vielleicht hilft bei dir ja auch schon die Umstellung von state auf basicSet. Dieser ist bei closed 0 und bei open 255 (und wie gesagt der kam schon immer öfter als state und seit der Umstellung funktioniert das Auge wieder wie es soll).
Bzgl. Batteriestatus. Es wird ja in Prozent übermittelt und das aber nur, wenn ich den Batterystate "abfrage". Irgendwo im Netz habe ich dann das mit der Abfrage auf wakeup gefunden. Also wakeup macht der Sensor ja eh (er wird ja nicht extra durch mich geweckt) gut ich setze einen Befehl ab und erwarte eine Antwort. Aber 1-3mal am Tag kann nicht so schlimm sein (die Homematic Geräte machen das mit unter alle 3min und die Batterien halten auch).
Der wakeup ist auf Standard (65535)...
Wenn ich sicher weiß/wüßte, dass der Sensor echt meldet, wenn die Batterie zur Neige geht (am besten mit etwas Vorlauf), dann würde ich das wieder raus nehmen.
Blöd nur, wenn ich (bzw. meine Freundin) das erst merken würde, wenn das Auge nichts mehr macht und auch nicht mehr blinkt...
...weil dann ist bestimmt Samstagabend und keine Batterie zur Hand... ;)
Gruß, Joachim
Zitat von: MadMax-FHEM am 12 Januar 2017, 14:49:27
vielleicht hilft bei dir ja auch schon die Umstellung von state auf basicSet.
:'( , bitte nicht...
Neuer Versuch: :)
basicSet gibt es afaik nur, wenn beim alten FGMS001 der Controller in der Assogroup 1 aufgenommen ist. Das ist überflüssig.
Der Controller gehört grds. nur in Assogroup 3, die über eine andere Class die gleiche Info wie Assogroup 1 liefert.
Bei Assoziierung mit 1 und 3 können unnötige Störungen wegen der zu vielen Nachrichten entstehen, die vielleicht genau zum bemängelten teilweisen Verlust der Nachrichten aus Assogroup 3 führen.
-> wirkliche Ursache suchen
Gruß, Christian
Ok, ich kontrollier das mal mit den AssocGroups...
Und schau mal ins Log.
Kann aber dauern weil das System nicht bei mir ist...
Warum nicht basicSet?
Habe das auf der Suche nach einer Lösung der Problematik gefunden.
Also dort nicht als Lösung sondern dort wurde generell gleich per basicSet eingebunden...
Gruß, Joachim
Sorry, ok.
Wenn ich das mit den Gruppen gerade gezogen hab, dann ist basicSet weg...
Würde mich aber auch interessieren, weshalb man nicht auf basicset triggern sollte.
Weil das primitiv ist. Man isst auch nicht mit den Fingern :)
Aber wenn's doch mit den Fingern besser/zuverlässiger funktioniert... ;)
...oder zu funktionieren scheint...
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
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
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
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