Zwave / Java Exception / Fibaro Smoke Sensor V2

when I trigger a test alarm for the fibaro smoke sensor this happens:

7:56:25.664 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 04 10 0B 0A 71 05 00 00 00 FF 01 00 01 03 72 
07:56:25.678 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
07:56:25.686 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 10 00 04 10 0B 0A 71 05 00 00 00 FF 01 00 01 03 72 
07:56:25.697 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 04 10 0B 0A 71 05 00 00 00 FF 01 00 01 03 72 
07:56:25.708 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 10 00 04 10 0B 0A 71 05 00 00 00 FF 01 00 01 03 72 
07:56:25.715 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=10 0B 0A 71 05 00 00 00 FF 01 00 01 03 
07:56:25.721 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 11: Application Command Request (ALIVE:DONE)
07:56:25.726 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 11: Starting initialisation from DONE
07:56:25.732 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@e4e9fa already registered
07:56:25.740 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 11: Incoming command class ALARM
07:56:25.747 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 11: Received ALARM command V3
07:56:25.750 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 11: Process NOTIFICATION_REPORT V3
07:56:25.756 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 11: NOTIFICATION report - 0 = 0, event=0, status=255
07:56:25.759 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 11: Alarm Type = SMOKE (0)
07:56:25.760 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmValueEvent
07:56:25.762 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 11: Got an event from Z-Wave network: ZWaveAlarmValueEvent
07:56:25.764 [ERROR] [ve.internal.protocol.ZWaveController] - Exception during ZWave thread: Input 2. {}
java.lang.ClassCastException: org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass$Alarm cannot be cast to java.lang.Integer
	at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass$ZWaveAlarmValueEvent.getValue([190:org.openhab.binding.zwave:]
	at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass$ZWaveAlarmValueEvent.getValue([190:org.openhab.binding.zwave:]
	at org.openhab.binding.zwave.handler.ZWaveThingHandler.ZWaveIncomingEvent([190:org.openhab.binding.zwave:]
	at org.openhab.binding.zwave.internal.protocol.ZWaveController.notifyEventListeners([190:org.openhab.binding.zwave:]
	at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass.processNotificationReport([190:org.openhab.binding.zwave:]
	at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAlarmCommandClass.handleApplicationCommandRequest([190:org.openhab.binding.zwave:]
	at org.openhab.binding.zwave.internal.protocol.serialmessage.ApplicationCommandMessageClass.handleRequest([190:org.openhab.binding.zwave:]
	at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingRequestMessage([190:org.openhab.binding.zwave:]
	at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingMessage([190:org.openhab.binding.zwave:]
	at org.openhab.binding.zwave.internal.protocol.ZWaveController.access$7([190:org.openhab.binding.zwave:]
	at org.openhab.binding.zwave.internal.protocol.ZWaveController$[190:org.openhab.binding.zwave:]

I’ll take a look tonight - this is likely associated with the NOTIFICATION command class updates.

great - it works again ! thx !

another question… is there a way I can use the Smoke Detector also as an “alarm”.

currently when I switch the “item” “alarm smoke” manually from the UI … there is no alarm sound…
not sure if that is possible at all

Not with the Fibaro, but the Popp is able to do that.

I’m not completely sure I understand so let me ask another way… So you want from OH UI to change the item to alarm, and for this to make the smoke detector create the alarm sound? If so, then no, this isn’t possible. I think that channels can be set to read-only, so I should change them actually to make that clearer (although I suspect that UIs probably don’t rested that so it might not change anything!).

Yes that was my Intention. To use it in a rule … Like when Motion is detected make the Smoke Sensor give alarm

There might be a way to do this, but not through the notification channel… If the device supports it, then I can take another look though as currently I don’t have sending of notifications.

Great :slight_smile:

Thats the device

I can’t immediately see anything in the manual that says it can trigger the alarm - if you can find something, I’ll look at it further…

i wonder if the device can be triggered by an incoming notfocation in group 4
… could I add the zwave controller to group 4 and send a notification manually?

Associations are for the device to send notifications - not receive them. So this means that once smoke is detected, the smoke sensor will send a notification to the devices in this group.

thats clear :slight_smile:

but is there a way to that I manually send a notfication of this kind? eg. a rule triggers this?

to achieve this:

I don’t know - not that I know of unless the manual says there is (I guess). At the moment the binding can’t send notifications - it’s on the list of things to do, but not near the top as there’s only one device that I currently know of that needs this (a doorbell I think). If you can find a way to do what you want - either something in the manual, or maybe someone on another forum has mentioned it, then I’m happy to help implement something…

is this added in the current build?

Add option to send notifications to a node (commit: 58ed7e07388654254e1999ee2b45debde689e744) (details)

Yes - I’ve implemented this tonight.

so how does it work?
add “notification_send” in the DB as a channel? which class?

thanks :smiley:

Yes…[quote=“shorty707, post:16, topic:14360”]
which class?

To the ALARM class.

You will need some config with that. What the converter does, is appends the value of the state to the work event, and then looks this up in the config setting. The state must currently be a number, so -:


will send NOTIFICATION type SMOKE, event 1 when the command value is 1. Multiple events can be separated by a comma.

Check here for the (untested!) siren command setting.

I need to work out how to best document this sort of thing - I hope to be able to automate some of this from the source at some stage, but that’s not quite there yet!

well most possible I did something wrong ;)) but this is what I did

  1. I added the send_notification for in the DB and updated the binding this morning

  2. I created a Number item for that channel

  3. I set the item to “1” and expected that the event Smoke is parsed

this happens really:

08:37:08.509 [INFO ] [smarthome.event.ItemCommandEvent    ] - Item 'node11_IncomingNotification' received command 1
08:37:08.514 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 11: Command for unknown channel zwave:device:15348538564:node11:notification_send with DecimalType

sorry - I am pretty sure I messed something up :-/

Yep - it won’t have been me ;)…

Ok - so maybe not true. I found the database is exporting the incorrect type - I’ll update this morning.

However, I’m not convinced what you are trying to do will work, but I think we discussed that right? There’s no indication that the device will receive notifications… Still, worth trying as you never know, and I guess if it doesn’t work you will remove this channel right?

correct - I will try to process that incoming notfication like the device received an incoming notification in association group 4 which would trigger a smoke alarm

if this will not work out I will clean up the DB for sure.