Hallo,
ich experimentiere ein wenig mit Z-Wave (UZB-Stick + Fibaro FGK-101) herum und habe gleich mal einen Temperatursensor 18B20 nach Anleitung in den Fensterkontakt eingebaut. Inklusion sieht aus meiner Sicht richtig aus - allerdings meldet der Fibaro bei Config15 eine 255, was bedeutet, dass kein Sensor angeschlossen ist. Zur Verdeutlichung meine Readings:
CMD ZW_APPLICATION_UPDATE 2015-06-10 13:52:21
basicSet 00 2015-06-10 13:52:36
config_15 255 2015-06-10 13:46:00
reportedState closed 2015-06-10 13:52:36
state closed 2015-06-10 13:52:36
transmit OK 2015-06-10 13:48:55
Hab den Fensterkontakt schon entfernt und neu inkludiert - Fehler bleibt aber. Fensteröffnungen meldet er anstandslos. Was mach ich falsch? (Sowohl der Z-Wave Stick als auch der Fensterkontakt wurden automatisch in FHEM eingebunden)
Du musst mit mcAdd ein zusätzliches Gerät anlegen. Außerdem die Assoziationsgruppe 3 hinzufügen...
@micha80: Könntest Du bitte kontrollieren, ob die Infos unter http://www.fhemwiki.de/wiki/Z-Wave#FGK-101_T.C3.BCr.2FFensterkontakt korrekt sind? Danke, Christian
Ja. Passt soweit. Außer dass es basicSet ist und nicht mehr basicReport.
Ich habe das bei mir so gelöst:
eventMap ff:open 00:closed
stateFormat basicSet
Und die Temperatur wird auf den 2. endpoint gemeldet, den ich jede Stunde per at abfrage.
(Siehe Handbuch. Am ersten endpoint könnte ein Schalter angeschlossen werden)
z_Door_Sensor mcCapability_01: BASIC UNKNOWN_01 SENSOR_BINARY
z_Door_Sensor mcCapability_02: CONTROLLER_REPLICATION UNKNOWN_01 SENSOR_MULTILEVEL
2015-06-11_12:22:53 z_Door_Sensor mcEndpoints: total 2, different
Frag mich aber nicht, wie das Kommando dazu war :(
Mfg
Micha
Die basic Klasse koennte man auch automatisch hinzufuegen, indem man in zwave_deviceSpecial einen init Eintrag fuer das Geraet macht. Ich muesste dazu modelId wissen.
Gerne
model FIBARO System FGK101 Door Opening Sensor
modelConfig fibaro/fgk001.xml
modelId 010f-0700-1000
Korrekterweise fgk-101 - 107
http://www.pepper-one.de/zwavedb/device/430
@micha80: Danke, werde dann bei Gelegenheit anpassen
@Rudi:
Kann man die Info zu den fehlenden Classes nicht direkt aus den Config-XMLs ziehen: https://github.com/OpenZWave/open-zwave/blob/master/config/fibaro/fgk001.xml ? Für den Fibaro ist das ebenso wie für andere Devices dort enthalten.
Btw: Hatte gestern noch festgestellt, dass das set-Command "ConfigSirenSoundAndVolume" aus dieser XML https://github.com/OpenZWave/open-zwave/blob/master/config/aeotec/dsd31.xml nicht funktioniert. Details kann ich Dir erst heute abend liefern, wenn es so nicht erkennbar ist.
Zitat von: micha80 am 11 Juni 2015, 11:30:44
Du musst mit mcAdd ein zusätzliches Gerät anlegen. Außerdem die Assoziationsgruppe 3 hinzufügen...
Ich fürchte, bei mir gehts noch um die Grundlagen ... mcAdd ist bei mir nicht auswähl- bzw. ausführbar (Unknown argument mcAdd, choose one of...).
Bei solchen Aussagen musst du immer mehr Futter liefern ;)
Poste mal den Output von "list" bzw das Attribut classes...
Nur wenn das richtig gefüllt ist, kannst du die Kommandos ausführen.
Zitat von: krikan am 11 Juni 2015, 13:55:07
@Rudi
Btw: Hatte gestern noch festgestellt, dass das set-Command "ConfigSirenSoundAndVolume" aus dieser XML https://github.com/OpenZWave/open-zwave/blob/master/config/aeotec/dsd31.xml nicht funktioniert. Details kann ich Dir erst heute abend liefern, wenn es so nicht erkennbar ist.
So funktioniert es:
2015.06.11 18:14:58 2: ZWave set ZWave_SWITCH_BINARY_6 configWord
2015.06.11 18:14:58 5: ZWDongle_Write msg 1306067004250201010506Das macht Fhem derzeit:
2015.06.11 18:16:10 2: ZWave set ZWave_SWITCH_BINARY_6 configSirenSoundAndVolume
2015.06.11 18:16:10 5: ZWDongle_Write msg 130605700425011010506
@lixilian
Micha80 meint vermutlich nicht mcaAdd (oder Micha?) , sondern die Befehle zur Ermittlung und Anlage der Endpoints aus Class MULTI_CHANNEL "mcEndpoints" und "mcCapability". Für Details zu den Befehlen schau bitte in die commandref.
Hallo Micha und krikan,
der Vollständigkeit halber hier mal die Ausgabe von list:
Internals:
DEF e5bfdec6 6
IODev ZWDongle_0
LASTInputDev ZWDongle_0
MSGCNT 17
NAME ZWave_SENSOR_BINARY_6
NR 44
STATE TRANSMIT_NO_ACK
TYPE ZWave
ZWDongle_0_MSGCNT 17
ZWDongle_0_RAWMSG 00040406028407
ZWDongle_0_TIME 2015-06-11 18:30:29
homeId e5bfdec6
id 06
lastMsgTimestamp 1434040229.76976
Readings:
2015-06-11 14:57:46 CMD ZW_APPLICATION_UPDATE
2015-06-11 14:57:46 assocGroup_01 Max 05 Nodes 01
2015-06-11 14:57:46 assocGroup_02 Max 05 Nodes
2015-06-11 14:50:51 assocGroup_03 Max 01 Nodes 06
2015-06-11 08:21:12 basicReport ff
2015-06-11 14:59:27 basicSet 00
2015-06-11 08:15:18 battery 92 %
2015-06-11 08:21:08 configTypeOfInputNo1 NONormalOpen
2015-06-11 08:15:19 config_15 0
2015-06-11 08:16:48 mcEndpoints total 2, different
2015-06-11 08:08:56 model FIBARO System FGK101 Door Opening Sensor
2015-06-11 08:08:56 modelConfig fibaro/fgk001.xml
2015-06-11 08:08:56 modelId 010f-0700-1000
2015-06-11 08:16:48 reportedState closed
2015-06-11 08:19:54 state TRANSMIT_NO_ACK
2015-06-11 14:58:32 transmit OK
2015-06-11 18:30:29 wakeup notification
WakeUp:
Attributes:
IODev ZWDongle_0
classes BASIC SENSOR_BINARY SENSOR_ALARM MULTI_CHANNEL ASSOCIATION MANUFACTURER_SPECIFIC CONFIGURATION VERSION BATTERY CRC_16_ENCAP WAKE_UP FIRMWARE_UPDATE_MD MARK SCENE_ACTIVATION
room ZWave
Die Class BASIC hab ich manuell ergänzt - das hatte ich hier im Forum irgendwo gelesen. Dass ursprüngliche Problem, dass der Fensterkontakt der Meinung war, keinen Temperatursensor zu haben (Code 255) ist übrigens gelöst. Der Temperatursensor muss VOR der ersten Inbetriebnahme eingebaut werden. Temperatur sehe ich aber immer noch keine.
Ich stochere momentan noch ein wenig mit Halbwissen rum - wahrscheinlich bei diesem Thema nicht so hilfreich. :-[
Danke für die Antworten!
Ich hab und kenn den Sensor zwar nicht, aber
- Hast Du den Controller mit Assoziationsgruppe 3 des Sensor assoziiert: http://www.fhemwiki.de/wiki/Z-Wave#Assoziation
- Hast Du mal "get ZWave_SENSOR_BINARY_6 mcCapability 02" ausgeführt? Wurde dann ein 2. Fhem-Device angelegt?
Das habe ich vergessen: laut Handbuch muss das Gerät rebootet werden (Batterie entfernen) und neu inkludiert werden, damit der Sensor erkannt wird. (Steht im Kleingedruckten)
Wieso steht bei Group 3 Device 6? Das dürfte nicht stimmen.
Ja, krikan, dass mit dem Multi Channel ist mir noch etwas verwechslungswürdig.
Ich habe auch das Gefühl, dass der Sensor bei jedem wakeup nur auf ein Kommando antwortet...
Zitat von: krikan am 11 Juni 2015, 19:40:25
Ich hab und kenn den Sensor zwar nicht, aber
- Hast Du den Controller mit Assoziationsgruppe 3 des Sensor assoziiert: http://www.fhemwiki.de/wiki/Z-Wave#Assoziation
- Hast Du mal "get ZWave_SENSOR_BINARY_6 mcCapability 02" ausgeführt? Wurde dann ein 2. Fhem-Device angelegt?
Bin so vorgegangen und schwupps, wurde jeweils (habe 2 Kontakte) ein neues Device angelegt mit einem Reading temperature. Vielen Dank!
Zitat von: micha80 am 11 Juni 2015, 20:28:42
...
Wieso steht bei Group 3 Device 6? Das dürfte nicht stimmen.
...
Das ist mein Fehler gewesen, weil ich ohne Hintergrundwissen rumgespielt habe. Habe die Assoziation jetzt entfernt.
Vielen Dank auch Dir!
ZitatHatte gestern noch festgestellt, dass das set-Command "ConfigSirenSoundAndVolume" ... nicht funktioniert.
Ist wohl eine Aufzaehlung mit Werten > 255. Habs gefixt und eingecheckt.
ZitatKann man die Info zu den fehlenden Classes nicht direkt aus den Config-XMLs ziehen
Das sollte wir machen, allerdings haette ich gerne von dir ein Kommentar zu folgenden Punkten, bevor ich zu viel Unheil anrichte:
- Fuer BASIC (id="32") habe ich action="remove" und setasreport="true" gesehen, in insg. 32 Faellen. Ich wuerde bei remove die Klasse entfernen und bei setasreport hinzufuegen. Vmtl. soll setasreport was anderes ausdruecken, weiss aber nicht was.
- action Attribut gibt es auch fuer andere Klassen (ALARM, SCENE_ACTIVATION, CENTRAL_SCENE). Diese wuerde ich auch hinzufuegen bei action="add" bzw. loeschen bei action="remove".
- es gibt weitere Attribute wie scenecount (CENTRAL_SCENE), getsupported="false" (ALARM, SCENE_ACTIVATION), create_vars="false". Hier bin ich unsicher, und werde erstmal nix unternehmen.
Zitat von: rudolfkoenig am 14 Juni 2015, 11:10:57
- Fuer BASIC (id="32") habe ich action="remove" und setasreport="true" gesehen, in insg. 32 Faellen. Ich wuerde bei remove die Klasse entfernen und bei setasreport hinzufuegen. Vmtl. soll setasreport was anderes ausdruecken, weiss aber nicht was.
- action Attribut gibt es auch fuer andere Klassen (ALARM, SCENE_ACTIVATION, CENTRAL_SCENE). Diese wuerde ich auch hinzufuegen bei action="add" bzw. loeschen bei action="remove".
Stell es bitte noch mal zurück. Ich muss es mir in Ruhe anschauen, da bei einem meiner Geräte setasreport="true" angegeben ist, obwohl BASIC im NIF enthalten ist. Der Zusammenhang zwischen https://github.com/OpenZWave/open-zwave/blob/master/config/device_classes.xml und den Angaben in den Geräte-XMLs ist mir noch nicht klar.
Zitat von: rudolfkoenig am 14 Juni 2015, 11:10:57
- es gibt weitere Attribute wie scenecount (CENTRAL_SCENE), getsupported="false" (ALARM, SCENE_ACTIVATION), create_vars="false". Hier bin ich unsicher, und werde erstmal nix unternehmen.
Halte ich für Fhem derzeit für irrelevant, da in Fhem (zum Glück) nicht per Interview die Funktionen der Geräte ermittelt werden, sondern der Benutzer gefragt ist.
Hallo zusammen,
Zitat von: rudolfkoenig am 14 Juni 2015, 11:10:57
Vmtl. soll setasreport was anderes ausdruecken, weiss aber nicht was.
sieht nach open-zwave spezialität aus:
Zitat
Basic Set should be treated as Basic Report for some devices
siehe 3. Antwort unter https://github.com/OpenZWave/python-openzwave/issues/61
Zitat von: krikan am 14 Juni 2015, 14:21:11
Halte ich für Fhem derzeit für irrelevant, da in Fhem (zum Glück) nicht per Interview die Funktionen der Geräte ermittelt werden, sondern der Benutzer gefragt ist.
spontan wollte ich fragen, warum nicht automatisch? (auto. klingt doch normalerweise besser)
+1 für automatisch ermitteln
Aber dann sind mir die ganzen Spezialitäten bewusst geworden:
Insgesamt sehr unbefriedigend für ein weltweit eingesetztes Protokoll. Und bei jedem 2. Gerät muß ein special eingetragen werden?
Dann lieber -1 für automatisch ermitteln: ich muß ja sowieso kontrollieren, ob alles passt!
(wird dieses Fenster (http://www.fakro.de/produkte/alle-produkte/dachfenster/schwingfenster-z-wave/) mit passender Wetterstation (http://www.fakro.de/produkte/alle-produkte/elektrische-steuerung/steuergerate/) unterstüzt?)
War zwar keine Abstimmung und wir sind eh im falschen Thread, aber das musste ich einfach los werden...
mfg
micha
Zitat von: rudolfkoenig am 14 Juni 2015, 11:10:57
Das sollte wir machen, allerdings haette ich gerne von dir ein Kommentar zu folgenden Punkten, bevor ich zu viel Unheil anrichte:
- Fuer BASIC (id="32") habe ich action="remove" und setasreport="true" gesehen, in insg. 32 Faellen. Ich wuerde bei remove die Klasse entfernen und bei setasreport hinzufuegen. Vmtl. soll setasreport was anderes ausdruecken, weiss aber nicht was.
- action Attribut gibt es auch fuer andere Klassen (ALARM, SCENE_ACTIVATION, CENTRAL_SCENE). Diese wuerde ich auch hinzufuegen bei action="add" bzw. loeschen bei action="remove".
Nach meinem Verständnis werden in openzwave die unterstützten Command Classes von Geräten folgendermaßen ermittelt:
- Pflicht-Classes der Geräte werden anhand der NIF-Angaben Basic/Generic/Specific Device Class aus der XML https://github.com/OpenZWave/open-zwave/blob/master/config/device_classes.xml (https://github.com/OpenZWave/open-zwave/blob/master/config/device_classes.xml) gesetzt
- Die im NIF enthaltene Aufzählung der Command Classes wird nur zur Ergänzung von wahlweisen Classes genutzt. Pflicht-Classes werden anhand dieser Angaben nicht gelöscht; XML bleibt entscheidend
- Besonderheiten werden im letzten Schritt aus den Geräte-XMLs, die auch Fhem verwendet, berücksichtigt:
a) action="add" bzw. action="remove" fügt Classes hinzu bzw. entfernt diese
b) setasreport="true": die Nachricht von Geräte an Controller kommt per (Fhem)basicSet und nicht per (Fhem)basicReport
Angaben kommen aus diversen Posts der ozw-Entwickler
Für Fhem:
- man könnte System von ozw übernehmen; bin dagegen, da zu starr
- ohne Übernahme des Systems von ozw könnte Fhem die Angaben in den Geräte XMLs folgendermaßen nutzen:
- action="add": Class immer hinzufügen, wenn nicht schon vorhanden
- action="remove" ignorieren, da unter Umständen wegen des anderen Konzeptes von ozw Fehler auftreten
- setasreport="true" BASIC hinzufügen, wenn nicht schon vorhanden (hilft bei Fibaro FGK-101, Aeotec ALMS; deckt aber aufgrund des anderen Konzeptes von ozw nicht alle (unbekannten) Problemfälle ab)
ODER
- nur action="add" berücksichtigen und BASIC hinzufügen, wenn Pflicht-Class nicht vorhanden. - ohne Berücksichtigung von ozw-Infos: BASIC bei allen Slave-Geräten hinzufügen, wenn fehlend.
Nach langem Grübeln bevorzuge ich derzeit 3. Bei den mir bekannten Problemgeräten fehlt immer BASIC. Und jetzt andere ;)
@Micha80: Danke für Deine Info.
Die Alternative 3 hat den Charme, dass es einfach ist. Was genau meinst du mit "slave" Geraet?
Zitat- action="remove" ignorieren, da unter Umständen wegen des anderen Konzeptes von ozw Fehler auftreten
Das verstehe ich auch nicht ganz: Falls eine Klasse nicht vorhanden ist, dann wird es (stillschweigend) auch nicht entfernt.
Ich wuerde die Klassen wie bisher aus dem NIF nehmen (das Geraet weiss es ja besser, was es kann, als der ZWave Standard), und die Korrekturen von ozw hinzufuegen: add/setasreport hinzufuegen, remove entfernen, alles ohne Fehlermeldung.
Zitat von: rudolfkoenig am 15 Juni 2015, 17:50:05
Die Alternative 3 hat den Charme, dass es einfach ist. Was genau meinst du mit "slave" Geraet?
"slave" kannst Du streichen, sollte "alle" Geräte heißen.
Einfach war der Grund, dass ich das bevorzugte. Die Frage ist nur, wievielen Geräten man BASIC dadurch zwangsweise zuweist, die bisher auch ohne funktionierten und welche Verwirrung das auslöst.
ZitatDas verstehe ich auch nicht ganz: Falls eine Klasse nicht vorhanden ist, dann wird es (stillschweigend) auch nicht entfernt.
remove entfernt auch Classes "nur" um besser in das Konzept von ozw zu passen, bspw:
https://github.com/OpenZWave/open-zwave/blob/8731f708878fd68fa5d259222b5a81469a81719d/config/aeotec/keyfob2.xml
https://github.com/OpenZWave/open-zwave/blob/a4ea66b253e14c92dd16f01d7e45827650ff2fad/config/fibaro/fgwpe.xml
Darum möchte ich nicht, dass per NIF gemeldete Classes durch remove entfernt werden. Ich möchte alles nutzen könne. Auch wenn nur Teile der Class unterstützt werden, hätte ich die gerne.
ZitatIch wuerde die Klassen wie bisher aus dem NIF nehmen (das Geraet weiss es ja besser, was es kann, als der ZWave Standard), und die Korrekturen von ozw hinzufuegen: add/setasreport hinzufuegen, remove entfernen, alles ohne Fehlermeldung.
Ja, finde ich -bis auf remove entfernen- in Ordnung.
Bottom Line: Was für ein Aufwand für kaputte Geräte ;)
Ab sofort werden nach einem "get model" Klassen hinzugefuegt, wenn diese in openzwave_deviceconfig.xml.gz mit setasreport="true" oder action="add" markiert sind. Bei der Inklusion wird get model automatisch ausgefuehrt, wenn das NIF die Klasse MANUFACTURER_SPECIFIC enthaelt.
Moin,
bin noch frisch im Thema FHEM und arbeite mich so langsam ein. Hab seit gestern diesen Fenstersensor und inkludieren hat auch soweit funktioniert. Hab einmal den Fenstersensor und als zweites Gerät den Temperatursensor.
Hätte da jetzt mal noch ein bis zwei Fragen zu diesem Sensorgespann.
Glaube dem Sensor gesagt zu haben, das er alle 300 Sekunden aufwachen soll.
DEF c39dc3ac 5
IODev ZWAVE1
NAME WZ.Balkontuer
NR 120
STATE associationAdd 3 01
TYPE ZWave
homeId c39dc3ac
nodeIdHex 05
Readings
CMD ZW_APPLICATION_UPDATE 2015-12-18 20:25:41
assocGroups 3 2015-12-18 19:20:33
basicSet ff 2015-12-18 18:25:43
battery 79 % 2015-12-18 19:24:20
config_15 0 2015-12-18 19:44:54
model FIBARO System FGK101 Door Opening Sensor 2015-12-18 16:47:48
modelConfig fibaro/fgk001.xml 2015-12-18 16:47:48
modelId 010f-0700-1000 2015-12-18 16:47:48
state associationAdd 3 01 2015-12-18 16:47:49
transmit OK 2015-12-18 20:25:43
wakeupReport interval 300 target 5 2015-12-18 20:25:41
Doch wenn ich mir das FileLog vom Temperatursensor ansehe, dann sind da nur wenige und unregelmässige Einträge vorhanden.
2015-12-18_16:56:09 WZ.Balkontuertemperatur temperature: 20.43 C
2015-12-18_20:59:27 WZ.Balkontuertemperatur temperature: 20.00 C
2015-12-18_23:03:33 WZ.Balkontuertemperatur temperature: 19.50 C
2015-12-19_04:09:41 WZ.Balkontuertemperatur temperature: 19.00 C
2015-12-19_10:54:21 WZ.Balkontuertemperatur temperature: 19.50 C
Hier noch die Daten vom Temperatursensor:
Internals
DEF c39dc3ac 1282
IODev ZWAVE1
LASTInputDev ZWAVE1
MSGCNT 4
NAME WZ.Balkontuertemperatur
NR 122
STATE ???
TYPE ZWave
ZWAVE1_MSGCNT 4
ZWAVE1_RAWMSG 000400050c600d0202310501440000079e
ZWAVE1_TIME 2015-12-19 10:54:21
homeId c39dc3ac
nodeIdHex 0502
Readings
temperature 19.50 C 2015-12-19 10:54:21
Das Wakeup-Intervall steht in keinem zwingenden Zusammenhang mit der Temperaturmeldung. Beim WakeUp ist der Sensor nur empfangsbereit für Befehle. 300Sek sind für das WakeUp-Interval übrigens im Dauerbetrieb mMn viel zu kurz, dann kannst Du vermutlich alle paar Tage Batterien wechseln.
Irgendwie komme ich mit Deinen Device-Angaben auch nicht klar: Hat Dein Controller die NodeID 5? Falls nicht, was ich vermute, ist die targetID im WakeupInterval falsch und müsste angepasst werden.
Wie häufig die Temperatur gemeldet wird, kannst Du vermutlich über die Konfiguration festlegen. Typischerweise ist das bei bestimmten Temperaturänderungen oder vielleicht auch in bestimmten Intervallen.
Gruß, Christian
PS: Es wäre schön, wenn Du zur Erhöhung der Lesbarkeit zukünftig Codetags für list verwenden könntest. Danke.
Das WakeUp Intervall hab ich zur Zeit zu Testzwecken auf 300 Sekunden gestellt.
Internals
CallbackNr 0
Clients :ZWave:
DEF /dev/ttyAMA0@115200
DeviceName /dev/ttyAMA0@115200
FD 14
MaxSendRetries 3
NAME ZWAVE1
NR 44
PARTIAL
RAWMSG 0004000206310504220000
ReadTime 1450525371.66333
STATE Initialized
SendRetries 0
SendTime 1450471372.86366
TYPE ZWDongle
WaitForAck 0
ZWAVE1_MSGCNT 41
ZWAVE1_TIME 2015-12-19 12:42:51
homeId c39dc3ac
nodeIdHex 01
nrNAck 0
Readings
caps
Vers:5 Rev:0 ManufID:0147 ProductType:0400 ProductID:0001 SERIAL_API_GET_INIT_DATA SERIAL_API_APPL_NODE_INFORMATION APPLICATION_COMMAND_HANDLER ZW_GET_CONTROLLER_CAPABILITIES SERIAL_API_SET_TIMEOUTS SERIAL_API_GET_CAPABILITIES SERIAL_API_SOFT_RESET UNKNOWN_09 UNKNOWN_0a ZW_SET_R_F_RECEIVE_MODE ZW_SET_SLEEP_MODE ZW_SEND_NODE_INFORMATION ZW_SEND_DATA ZW_SEND_DATA_MULTI ZW_GET_VERSION ZW_SEND_DATA_ABORT ZW_R_F_POWER_LEVEL_SET ZW_SEND_DATA_META ZW_GET_RANDOM MEMORY_GET_ID MEMORY_GET_BYTE MEMORY_PUT_BYTE MEMORY_GET_BUFFER MEMORY_PUT_BUFFER FLASH_AUTO_PROG_SET UNKNOWN_28 NVM_GET_ID NVM_EXT_READ_LONG_BUFFER NVM_EXT_WRITE_LONG_BUFFER NVM_EXT_READ_LONG_BYTE NVM_EXT_WRITE_LONG_BYTE ZW_GET_NODE_PROTOCOL_INFO ZW_SET_DEFAULT ZW_REPLICATION_COMMAND_COMPLETE ZW_REPLICATION_SEND_DATA ZW_ASSIGN_RETURN_ROUTE ZW_DELETE_RETURN_ROUTE ZW_REQUEST_NODE_NEIGHBOR_UPDATE ZW_APPLICATION_UPDATE ZW_ADD_NODE_TO_NETWORK ZW_REMOVE_NODE_FROM_NETWORK ZW_CREATE_NEW_PRIMARY ZW_CONTROLLER_CHANGE ZW_SET_LEARN_MODE ZW_ASSIGN_SUC_RETURN_ROUTE ZW_REQUEST_NETWORK_UPDATE ZW_SET_SUC_NODE_ID ZW_DELETE_SUC_RETURN_ROUTE ZW_GET_SUC_NODE_ID ZW_SEND_SUC_ID ZW_EXPLORE_REQUEST_INCLUSION ZW_REQUEST_NODE_INFO ZW_REMOVE_FAILED_NODE_ID ZW_IS_FAILED_NODE ZW_REPLACE_FAILED_NODE UNKNOWN_66 UNKNOWN_67 UNKNOWN_78 GET_ROUTING_TABLE_LINE LOCK_ROUTE_RESPONSE UNKNOWN_92 UNKNOWN_93 UNKNOWN_98 UNKNOWN_b4 ZW_WATCHDOG_ENABLE ZW_WATCHDOG_DISABLE ZW_WATCHDOG_CHECK ZW_SET_EXT_INT_LEVEL ZW_RF_POWERLEVEL_GET ZW_TYPE_LIBRARY ZW_SEND_TEST_FRAME ZW_GET_PROTOCOL_STATUS WATCHDOG_START WATCHDOG_STOP UNKNOWN_d4 UNKNOWN_ef ZME_FREQ_CHANGE ZME_BOOTLOADER_FLASH UNKNOWN_f5
2015-12-18 20:44:47
homeId HomeId:c39dc3ac CtrlNodeId:01 2015-12-18 20:44:47
random 8aabd75eca7464045375162b29f612ab69557094ef0023fb7d811467763b2ae2 2015-12-18 20:44:47
state Initialized 2015-12-18 20:44:47
Du müsstest bitte die targetID für Wakeup korrigieren, da die wakeUpNotification nicht an den Controller (NodeId 1) geschickt wird.
wakeupReport interval 300 target 5 2015-12-18 20:25:41
Bitte korrigieren mit:
set <name> wakeupInterval 300 1
Auf die Abfrage:
get <name> wakeupInterval
Solltest Du anschließend soetwas erhalten:
wakeupReport interval 300 target 1
Erst dann kommen die wakeUpNotification beim Controller an. Bisher sind die Nachrichten an NodeID 5 (Sensor slbst) gegangen.
Gruß, Christian
Vielen Dank für deine Hilfe. Der Sensor schickt jetzt mehr oder minder regelmässig Infos.
Eine der nächsten Baustellen ist dann noch das selbe für den Temperatursensor im Fibaro Flood Sensor.
Hinweis am Rande: Bei einem aktuellen FHEM, wird während der Inklusion automatisch das wakeupInterval auf einen Tag und als Empfänger der Controller festgelegt (habe das noch nicht im Wiki eingepflegt). Am besten direkt mit "get<device> wakeupInterval" abfragen und ggfs. die Zeitspanne verkürzen.
Hallo Christian
Auch wenn es gelöst ist....
Ich beschäftige mich selbst mit den Fenstersensoren. Laut Fibaro, Manual auf der Homepage, ist das wakeupInterwal in den Standardeinstellungen 4000.
Könnte man das nicht anstatt 86400 auch so während der Inklusion in fhem einpflegen?
LG Tom
Zitat von: tomspatz am 10 Januar 2016, 16:17:24
Könnte man das nicht anstatt 86400 auch so während der Inklusion in fhem einpflegen?
Hallo Tom!
Das ist eigentlich eher ein Thema für Rudi. Er hat das Setzen von wakeupInterval auf ControllerNodeId während der Inklusion (nur) auf meinen Wunsch eingebaut. Aus Vereinfachungsgründen ist das wakeupInterval fix auf 86400, ansonsten müsste vorher das Standardintervall vom Gerät abgefragt werden . Und das macht es komplizierter und fehleranfälliger. Details stehen im Thread in dem wir das diskutiert haben (finde ich auf die Schnelle nicht).
Das Setzen des Intervalls auf Controller während der Inklusion ist aus meiner Sicht wichtig, um die Anwender vor dem typischen Fehler (es nicht zu machen!) zu bewahren und hier nicht in langen Diskussionen den recht unspezifischen Fehler (Funkprobleme) zu suchen. Derjenige der sich mit wakeupInterval beschäftigt, fragt sowieso ab und ändert es nach seinen Wünschen. Im Wiki ist es ja auch erläutert.
Hoffe ich habe es verständlich rübergebracht..
Gruß, Christian
Hallo zusammen,
ich finde 86400 ist ein ganz passabler Wert. Einige Hersteller (siehe KFOB) schalten wakeUp schon per default ab. Ich habe zur Zeit 8 batteriebetriebene Geräte, davon 3 FGK101 und genau bei dem mit Temperatursensor, wo ich ein 1/2 Std. wakeUp Interval mit Temperaturreport hinterlegt hatte, war die Batterie nach 3 Monaten leer.
Das hab ich dann aber schnell wieder auf ca. 2 mal pro Tag geändert.
Grüße,
Josef
Moin
die Werte habe ich mir nicht ausgedacht. Fibaro sagt auch:
ZitatDer Fibaro Door/Window Sensor kann bei
standardgemäßer Konfiguration bis zu 2 Jahren
mit einer Batterie arbeiten.
Ja, ja Papier ist geduldig, und es ist ja auch vom Nutzungsverhalten different.
Mache mit Einbruchmeldeanlagen viel, dort sind die Funksensoren auch alle Batterie betrieben. Max. Lebensdauer bis zu zwei Jahren. Das klappt auch ganz gut, wenn diese nicht an einer ein/ausgang Tür z.B. hängen. Diese sind eher alle als die am Fenster in der Ecker welcher selten geöffnet wird.
@Christian ich dachte das diese Werte während der Inklusion einfach nach dem erkanntem Gerät zugeordnet werden könnten.
Klar ist ein gesetztes wakeupInterwal besser wie keines. Gerade Anfangs stellte ich bei mir fest das man immer wieder irgendwelche Sachen noch abfragen muss oder will, schon wieder zu dem device gehen, aufwecken Settings ändern, aufwecken prüfen. Wenn es erstmal läuft ist es ja jedem selbst überlassen. Doch wenn es zu den jeweiligen Geräten eine Vorgabe seitens des Herstellers gibt könnte man diese auch beachten.
Zitat von: tomspatz am 10 Januar 2016, 19:18:22
ich dachte das diese Werte während der Inklusion einfach nach dem erkanntem Gerät zugeordnet werden könnten.
Könnte man schon, würde aber ein manuelles Einpflegen bspw. in die XMLs für alle Wakeup-Geräte bedeuten. Das ist aber angesichts der geringen Anzahl an dauerhaft Aktiven nicht leistbar und halte ich persönlich aus diversen anderen Gründen auch nicht für sinnvoll.
Entscheidend ist, dass FHEM bei der Inklusion den Empfänger der wakeupNotification auf die ControllerNodeId setzt. Das trägt zur Batterieschonung und wichtiger zur Verhinderung von Funkproblemen bei. Machen wir das nicht, führt das zu "unnötigen" Supportproblemen, die vorher permanent auftraten, und unnötig Ressourcen binden. Das eingestellte Intervall ist letztlich uninteressant, aber mit 86400 bewusst batterieschonend hoch. Wer es ändern will, soll es nach Inklusion ändern.
Bedeutet ja alles nicht, dass es nicht evtl. irgendwann optimiert/geändert wird. Aber alles braucht seine Zeit.
Gruß, Christian