[gelöst] Fibaro Fenstersensor - keine Temperatur

Begonnen von lixilian, 10 Juni 2015, 14:01:38

Vorheriges Thema - Nächstes Thema

rudolfkoenig

ZitatHatte gestern noch festgestellt, dass das set-Command "ConfigSirenSoundAndVolume" ... nicht funktioniert.

Ist wohl eine Aufzaehlung mit Werten > 255. Habs gefixt und eingecheckt.

rudolfkoenig

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.

krikan

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.

micha80

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 mit passender Wetterstation unterstüzt?)

War zwar keine Abstimmung und wir sind eh im falschen Thread, aber das musste ich einfach los werden...

mfg
micha

krikan

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 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.
 

rudolfkoenig

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.

krikan

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 ;)

rudolfkoenig

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.

deligo

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

krikan

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.

deligo

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

krikan

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

deligo

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.

krikan

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.

tomspatz

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