Everspring HSM02 wird als SM103 erkannt

Begonnen von Lars, 28 Februar 2016, 14:54:05

Vorheriges Thema - Nächstes Thema

Lars

Ich habe Probleme mit dem HSM02. Nach der Assoziation wird das Gerät als SM103 erkannt.
modelId wird mit 0060-0002-0001 ausgegeben. Öffnen und Schließen des Kontakts wird nicht angezeigt.
Ist das ein Fehler in der Z-Wave Konfigurationszuordnung?

Gruß
Lars
FHEM Hauptsystem auf ESXi VM | dblog | 3 rPi für Nebensysteme | 2 Beaglebone Black Test- / Integrationssystem

krikan

Könntest Du bitte ein "list <device>" des Sensors posten und einen Link zu einer Anleitung des HMS02, damit ich mir das anschauen kann. Laut ozw ist 0060-0002-0001 der SM103. Dein Problem des fehlenden Reports muss keinesfalls mit den Configs zusammenhängen.
Gruß, Christian

Lars

Danke für die Hilfe:

Internals:
   CFGFN
   DEF        f52ca478 6
   IODev      ZWDongle_2
   LASTInputDev ZWDongle_2
   MSGCNT     18
   NAME       sensor.briefkasten
   NR         1320
   STATE      wakeupInterval 86400 01
   TYPE       ZWave
   ZWDongle_2_MSGCNT 18
   ZWDongle_2_RAWMSG 00040006057006030163
   ZWDongle_2_TIME 2016-02-28 14:41:49
   homeId     f52ca478
   isWakeUp   1
   lastMsgSent 1456666909.23364
   nodeIdHex  06
   Readings:
     2016-02-28 14:41:48   basicReport     00
     2016-02-28 14:41:48   configOffTime   0
     2016-02-28 14:41:49   configOnLevel   99
     2016-02-28 14:41:49   configPowerSaving 99
     2016-02-28 14:40:13   model           Everspring SM103 Door/Window Sensor
     2016-02-28 14:40:13   modelConfig     everspring/sm103.xml
     2016-02-28 14:40:13   modelId         0060-0002-0001
     2016-02-28 14:40:11   state           wakeupInterval 86400 01
     2016-02-28 14:41:51   transmit        OK
     2016-02-28 14:41:48   wakeup          notification
   SendStack:
     get:1306037005022506
     get:1306037005012506
     get:1306037005032506
     get:1306037005022506
     get:1306037005012506
     get:1306037005032506
     get:1306037005022506
     get:1306037005012506
     get:1306037005032506
Attributes:
   IODev      ZWDongle_2
   classes    SENSOR_BINARY CONFIGURATION WAKE_UP MANUFACTURER_SPECIFIC VERSION ASSOCIATION BATTERY BASIC ALARM
   room       ZWave

Hier die Anleitung: http://www.uk-automation.co.uk/content/pdf/HSM02.pdf
FHEM Hauptsystem auf ESXi VM | dblog | 3 rPi für Nebensysteme | 2 Beaglebone Black Test- / Integrationssystem

krikan

Bitte kontrolliere, ob die Assoziationsgruppe 1 den Controller enthält. Am Besten, damit man alle Assoziationsgruppen sieht, mit:
get <device> associationAll
Dann bitte den Sensor manuell aufwecken, damit der Befehl verarbeitet wird. Wenn Controller nicht in 1 bitte manuell aufnehmen und noch mal probieren.

Das Reading "basicReport" könnte zwar schon für Öffnen/Schließen-Signalisierung ausreichen, laut Anleitung sollte in Assoziationsgruppe 1 aber auch der Zustandsreport über SENSOR_BINARY kommen. Erkenne ich bei Dir nicht.

ABER: Die modelId ist bei pepper1, ozw und openhab für den SM103 geführt. Der HSM02 hat eine andere. Jedoch gibt es eine komische Auffälligkeit, wenn ich die Conifg-XMLs für SM103 vergleiche: Laut openhab hat der SM103 2 Assoziationsgruppen und Assogroup 2 ist für Controllerreports während bei dene anderen Datenbanken nur eine  Assoziationsgruppe 1 geführt wird. -> irgendetwas ist durcheinander, aber ich wage keine Entscheidung.


Lars

get <device> associationAll
gibt keine Bestätigung "Scheduled for sending...". get basicStatus liefert das.
Ich habe die Assoziation noch einmal durchgeführt und nun das Reading assocGroup_1 mit Wert Max 1 Nodes ZWDongle_2

Hier komplett
Internals:
   DEF        f52ca478 6
   IODev      ZWDongle_2
   LASTInputDev ZWDongle_2
   MSGCNT     34
   NAME       sensor.briefkasten
   NR         1070
   STATE      wakeupInterval 86400 01
   TYPE       ZWave
   ZWDongle_2_MSGCNT 34
   ZWDongle_2_RAWMSG 00040006058503020500
   ZWDongle_2_TIME 2016-02-28 18:51:00
   homeId     f52ca478
   isWakeUp   1
   lastMsgSent 1456681860.23931
   nodeIdHex  06
   Readings:
     2016-02-28 18:50:56   alarm_type_01   level 11
     2016-02-28 18:51:00   assocGroup_1    Max 1 Nodes ZWDongle_2
     2016-02-28 18:51:00   assocGroup_2    Max 5 Nodes
     2016-02-28 18:50:59   assocGroups     2
     2016-02-28 18:51:00   basicReport     00
     2016-02-28 18:50:59   configOffTime   0
     2016-02-28 18:50:59   configOnLevel   99
     2016-02-28 18:51:00   configPowerSaving 99
     2016-02-28 14:40:13   model           Everspring SM103 Door/Window Sensor
     2016-02-28 14:40:13   modelConfig     everspring/sm103.xml
     2016-02-28 14:40:13   modelId         0060-0002-0001
     2016-02-28 14:40:11   state           wakeupInterval 86400 01
     2016-02-28 18:51:02   transmit        OK
     2016-02-28 18:50:59   wakeup          notification
   SendStack:
     get:13060285052506
Attributes:
   IODev      ZWDongle_2
   classes    SENSOR_BINARY CONFIGURATION WAKE_UP MANUFACTURER_SPECIFIC VERSION ASSOCIATION BATTERY BASIC ALARM
   room       ZWave
FHEM Hauptsystem auf ESXi VM | dblog | 3 rPi für Nebensysteme | 2 Beaglebone Black Test- / Integrationssystem

krikan

Zitat von: Lars am 28 Februar 2016, 18:54:15
get <device> associationAll
gibt keine Bestätigung "Scheduled for sending...". get basicStatus liefert das.
Alle "get <device> xyzAll"-Befehle geben keine  "Scheduled for sending..."-Bestätigung aus, werden aber dennoch korrekt in Wakeup-Sendstack gelegt und bei der nächsten wakeupNotification verarbeitet. Die Befehle haben eine Sonderstellung.

Hast Du mal Öffnen/Schließen probiert und die Readings/Events beobachtet? Ändert sich basicReport und kommen andere Readings/Events? Nach Querlesen der Anleitung bin ich der Meinung Assoziation sollte so korrekt sein und Du müsstest etwas erkennen. Zur Not Controller auch in Assogroup 2 aufnehmen und probieren.

Zu den Config-XMLs: Die haben in Deinem Fall keinen Einfluß auf die korrekte Assoziation. Jedoch könnten die  configXYZ-Befehle nicht stimmen; habe ich mir nicht im Detail angeschaut.

Lars

Ich habe den Sensor noch einmal komplett neu angelernt, jetzt funktioniert es.
Danke für die Hintergrundinformationen.
FHEM Hauptsystem auf ESXi VM | dblog | 3 rPi für Nebensysteme | 2 Beaglebone Black Test- / Integrationssystem