Abus SHBW10000 PIR funktioniert nicht

[Peter19]

Hallo,
ich konnte mit der z-wave binding den Abus Multisensor SHBW10000 erfolgreich einbinden.
Temperatur, Luftfeuchte, Helligkeit funktionieren problemlos. Leider kriege ich den ebenfalls in den Multisensor eingebauten Bewegungsmelder (PIR) nicht zum fliegen.
Der Channel dazu und das Item lassen sich problemlos anlegen, allerdings kriege ich bei Bewegung keinerlei Reaktion/Event erfasst.(/var/log/openhab2/event.log usw.)
Ich habe das Gerät bereits getauscht. Könnte dies ein Binding Problem sein. Was mache ich falsch.

Umgebung: OpenHAB2, Raspberry PI2, raspbian und dem Aeotec z-wave Gen 5 Stick.

Danke für Eure Hilfe,
Peter

[sihui]

Leider kriege ich den ebenfalls in den Multisensor eingebauten Bewegungsmelder (PIR) nicht zum fliegen.

Korrekten Channel mit korrektem Itemtype verlinkt?

https://www.openhab.org/addons/bindings ... 0_0_0.html

Mit älteren openHAB Versionen als 2.5 musst du die korrekte Assoziationsgruppe auf deinen Controller setzen. Ab 2.5 wird das für Zwave Plus Geräte automatisch gemacht.

Sensitivität in Parameter 12 korrekt gesetzt?
Parameter 14 und 15 auf default gelassen?

[Peter19]

Korrekten Channel mit korrektem Itemtype verlinkt?

Item ist "Switch", Category "Door". Ich hoffe es ist auch "alarm_buglar" als Channeltyp. Habe dies über PaperUI gemacht, da sehe ich den Channeltyp nicht. Evtl. gibt es da noch eine andere Konfig (in HABmin steht auch nichts weiter darüber)
So sieht das Log beim Adden aus:

Code: Alles auswählen

Link 'ZWaveNode002SHBW10000PIRMultisensor_AlarmBurglar-zwave:device:c8a57e4f:node2:alarm_burglar' has been added.
Thing 'zwave:device:c8a57e4f:node2' has been updated.
ZWaveNode002SHBW10000PIRMultisensor_AlarmBurglar changed from NULL to OFF

Mit älteren openHAB Versionen als 2.5 musst du die korrekte Assoziationsgruppe auf deinen Controller setzen. Ab 2.5 wird das für Zwave Plus Geräte automatisch gemacht.

Assoziationsgruppe ist "Controller".

Sensitivität in Parameter 12 korrekt gesetzt?
Parameter 14 und 15 auf default gelassen?

Sensivität ist 10. 14 und 15 so belassen.

[sihui]

Ich hoffe es ist auch "alarm_buglar" als Channeltyp.

Ich habe diesen Sensor nicht aber ich würde im Zweifel einmal sensor_binary mit einem Switch itemtype versuchen.
Ansonsten einmal mit den Parametern 14 und 15 spielen, nach jeder Änderung den Sensor manuell aufwecken bis die "in Arbeit" Meldung verschwindet und der Sensor die geänderte Konfiguration gespeichert hat.
Bei diesem Sensor gibt es sehr viele Einstellmöglichkeiten, da muss man sich durchwühlen.

[Peter19]

Ich habe jetzt noch Rules getestet, die auf Item und Channel des Sensors triggern. Das Motion Item- und der Channel Trigger feuern bei Bewegung einfach nicht. Daher die Frage in die Runde: Wer hat den Motion Sensor des Abus SHWB10000 Multisensor mit OpenHAB 2.5 und z-wave Binding zum Fliegen gekriegt? Wenn ja, bitte wie?
Danke

[udo1toni]

Wie sieht denn die Rule aus?

[Peter19]

Wie sieht denn die Rule aus?

Als Item Trigger:

Code: Alles auswählen

rule "test1"
when
Item ZWaveNode002SHBW10000PIRMultisensor_AlarmBurglar received update
then
if ( ZWaveNode002SHBW10000PIRMultisensor_AlarmBurglar.state == ON ) {
ZWaveNode003TZ68WallPlug_Switch.sendCommand("ON")
} else {
ZWaveNode003TZ68WallPlug_Switch.sendCommand("OFF")
}
end

[Peter19]

Ich habe jetzt auch mal das erweiterte Logging des zwave Binding eingestellt, man sieht das der Kanal "alarm_buglar" geprüft wird. Bei Bewegungen vor dem Sender keinerlei Reaktionen im Log. Irgendeine Einstellung ist hier falsch (die Assoziierungsgruppe ist "Controller", ich nehme mal an, dies ist der z-wave stick:

Code: Alles auswählen

05:31:37.521 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - lastTransaction null
05:31:37.527 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 2: Application Command Request (ALIVE:DYNAMIC_VALUES)
05:31:37.532 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 2: Incoming command class COMMAND_CLASS_SENSOR_MULTILEVEL, endpoint 0
05:31:37.538 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 2: SECURITY NOT required on COMMAND_CLASS_SENSOR_MULTILEVEL
05:31:37.542 [DEBUG] [otocol.commandclass.ZWaveCommandClass] - NODE 2: Received COMMAND_CLASS_SENSOR_MULTILEVEL V5 SENSOR_MULTILEVEL_REPORT
05:31:37.549 [DEBUG] [ass.ZWaveMultiLevelSensorCommandClass] - NODE 2: Sensor Type = RelativeHumidity(5), Scale = 0
05:31:37.553 [DEBUG] [ass.ZWaveMultiLevelSensorCommandClass] - NODE 2: Sensor Value = 5E+1
05:31:37.558 [TRACE] [ave.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveMultiLevelSensorValueEvent
05:31:37.563 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 2: Got an event from Z-Wave network: ZWaveMultiLevelSensorValueEvent
05:31:37.568 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 2: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SENSOR_MULTILEVEL, value=5E+1
05:31:37.575 [TRACE] [nding.zwave.handler.ZWaveThingHandler] - NODE 2: Checking channel=zwave:device:c8a57e4f:node2:sensor_binary, cmdClass=COMMAND_CLASS_SENSOR_BINARY, endpoint=0
05:31:37.583 [TRACE] [nding.zwave.handler.ZWaveThingHandler] - NODE 2: Checking channel=zwave:device:c8a57e4f:node2:sensor_luminance, cmdClass=COMMAND_CLASS_SENSOR_MULTILEVEL, endpoint=0
05:31:37.588 [TRACE] [nding.zwave.handler.ZWaveThingHandler] - NODE 2: Checking channel=zwave:device:c8a57e4f:node2:sensor_relhumidity, cmdClass=COMMAND_CLASS_SENSOR_MULTILEVEL, endpoint=0
05:31:37.595 [DEBUG] [verter.ZWaveMultiLevelSensorConverter] - NODE 2: Sensor conversion not performed for RELATIVE_HUMIDITY.
05:31:37.602 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 2: Updating channel state zwave:device:c8a57e4f:node2:sensor_relhumidity to 50 [DecimalType]
05:31:37.608 [TRACE] [nding.zwave.handler.ZWaveThingHandler] - NODE 2: Checking channel=zwave:device:c8a57e4f:node2:sensor_temperature, cmdClass=COMMAND_CLASS_SENSOR_MULTILEVEL, endpoint=0
05:31:37.616 [TRACE] [nding.zwave.handler.ZWaveThingHandler] - NODE 2: Checking channel=zwave:device:c8a57e4f:node2:alarm_burglar, cmdClass=COMMAND_CLASS_ALARM, endpoint=0
05:31:37.620 [TRACE] [nding.zwave.handler.ZWaveThingHandler] - NODE 2: Checking channel=zwave:device:c8a57e4f:node2:battery-level, cmdClass=COMMAND_CLASS_BATTERY, endpoint=0
05:31:37.624 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 2: Commands processed 1.
05:31:37.629 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 2: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@4af653.
05:31:37.633 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
05:31:37.637 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
05:31:37.642 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
05:31:37.645 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
05:31:37.649 [TRACE] [ing.zwave.internal.protocol.ZWaveNode] - NODE 2: listening == false, frequentlyListening == false, awake == false
05:31:37.653 [TRACE] [rnal.protocol.ZWaveTransactionManager] - NODE 2: Node not awake!
05:31:37.657 [TRACE] [rnal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage nothing

[sihui]

Irgendeine Einstellung ist hier falsch

Was hat denn das Ändern der Konfig-Parameter ergeben?

(die Assoziierungsgruppe ist "Controller", ich nehme mal an, dies ist der z-wave stick:

Ja, aber bitte DEBUG, nicht TRACE, Rest der Antwort im englischen Forum zum gleichen Thema.

[Peter19]

Was hat denn das Ändern der Konfig-Parameter ergeben?

Keine Änderung am Verhalten.

Auch das Einbinden als Item Binary Sensor hat nichts gebracht, dass hatte ich vergessen zu erwähnen, sorry dafür. Interessant ist hier, das lt. Ref. der Binary Sensor bei jeder Änderung am Sensor (Temperatur, Lichtstärke..) triggern sollte. Das macht dieser aber auch nicht, obwohl er definitiv Änderungen an den (funktionierenden) Parametern gemeldet hat.

Ja, aber bitte DEBUG, nicht TRACE, Rest der Antwort im englischen Forum zum gleichen Thema.

OK. Vielen Dank für die umfassenden Antworten.

Ich werde auf jeden Fall das Problem weiter analysieren. Ich vermute, das das Motionereignis an die "falsche" Stelle geschickt wird.
Blöd ist, das man nirgends sieht, ob am Sensor selbst ein Motion-Ereignis eingetreten ist - oder geht dies?
Danke nochmal für deine Hilfe.