Fibaro FGSM-001 Endpoint 1 & 2 not found

Iā€™ve been trying to get the Fibaro Multi-Sensor up and running with OH2 and am having one hell of a time. The numeric values for temp, lux, etc are fine, but the motion and tamper alarms are raising issues.

Iā€™ve finally got it sending the alarm and motion events to OH2, but now Iā€™m seeing this every time for the motion sensor:

NODE 10: Endpoint 1 not found. Cannot set command classes.

Endpoint 2 for the alarm.

Hereā€™s the full trace for the motion sensor:

2016-09-18 17:20:47.812 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Received SOF
2016-09-18 17:20:47.814 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0D 00 04 00 0A 07 60 0D 01 00 20 01 FF 49 
2016-09-18 17:20:47.815 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Creating new SerialMessage from buffer = 01 0D 00 04 00 0A 07 60 0D 01 00 20 01 FF 49 
2016-09-18 17:20:47.815 [TRACE] [wave.internal.protocol.SerialMessage] - Calculated checksum = 0x49
2016-09-18 17:20:47.815 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Checksum matched
2016-09-18 17:20:47.816 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Message payload = 00 0A 07 60 0D 01 00 20 01 FF 
2016-09-18 17:20:47.816 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Message is valid, sending ACK
2016-09-18 17:20:47.817 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT
2016-09-18 17:20:47.818 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2016-09-18 17:20:47.820 [TRACE] [wave.internal.protocol.SerialMessage] - Calculated checksum = 0x49
2016-09-18 17:20:47.821 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0D 00 04 00 0A 07 60 0D 01 00 20 01 FF 49 
2016-09-18 17:20:47.822 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0D 00 04 00 0A 07 60 0D 01 00 20 01 FF 49 
2016-09-18 17:20:47.822 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 0A 07 60 0D 01 00 20 01 FF 
2016-09-18 17:20:47.822 [TRACE] [ve.internal.protocol.ZWaveController] - Incoming Message type = REQUEST
2016-09-18 17:20:47.823 [TRACE] [ssage.ApplicationCommandMessageClass] - Handle Message Application Command Request
2016-09-18 17:20:47.823 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 10: Application Command Request (ALIVE:DONE)
2016-09-18 17:20:47.824 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 10: Starting initialisation from DONE
2016-09-18 17:20:47.824 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@5ff5f2f6 already registered
2016-09-18 17:20:47.824 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 10: Incoming command class MULTI_INSTANCE
2016-09-18 17:20:47.825 [TRACE] [ssage.ApplicationCommandMessageClass] - NODE 10: Found Command Class MULTI_INSTANCE, passing to handleApplicationCommandRequest
2016-09-18 17:20:47.825 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 10: Received MULTI_INSTANCE command V0
2016-09-18 17:20:47.825 [TRACE] [class.ZWaveMultiInstanceCommandClass] - Process Multi-channel Encapsulation
2016-09-18 17:20:47.827 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 10: Requested Command Class = BASIC (0x20)
2016-09-18 17:20:47.827 [ERROR] [class.ZWaveMultiInstanceCommandClass] - NODE 10: Endpoint 1 not found. Cannot set command classes.
2016-09-18 17:20:47.827 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=10, callback=78, payload=0A 02 84 08 
2016-09-18 17:20:47.828 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 0A 07 60 0D 01 00 20 01 FF 
2016-09-18 17:20:47.829 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationCommandHandler, callback id=78, expected=SendData, cancelled=false      MISMATCH

And the alarm:

2016-09-18 17:23:26.080 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Received SOF
2016-09-18 17:23:26.081 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 11 00 04 00 0A 0B 60 0D 02 00 9C 02 0A 00 FF 00 00 EF 
2016-09-18 17:23:26.083 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Creating new SerialMessage from buffer = 01 11 00 04 00 0A 0B 60 0D 02 00 9C 02 0A 00 FF 00 00 EF 
2016-09-18 17:23:26.083 [TRACE] [wave.internal.protocol.SerialMessage] - Calculated checksum = 0xEF
2016-09-18 17:23:26.083 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Checksum matched
2016-09-18 17:23:26.083 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Message payload = 00 0A 0B 60 0D 02 00 9C 02 0A 00 FF 00 00 
2016-09-18 17:23:26.084 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Message is valid, sending ACK
2016-09-18 17:23:26.084 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT
2016-09-18 17:23:26.085 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2016-09-18 17:23:26.085 [TRACE] [wave.internal.protocol.SerialMessage] - Calculated checksum = 0xEF
2016-09-18 17:23:26.086 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 11 00 04 00 0A 0B 60 0D 02 00 9C 02 0A 00 FF 00 00 EF 
2016-09-18 17:23:26.086 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 11 00 04 00 0A 0B 60 0D 02 00 9C 02 0A 00 FF 00 00 EF 
2016-09-18 17:23:26.086 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 0A 0B 60 0D 02 00 9C 02 0A 00 FF 00 00 
2016-09-18 17:23:26.087 [TRACE] [ve.internal.protocol.ZWaveController] - Incoming Message type = REQUEST
2016-09-18 17:23:26.087 [TRACE] [ssage.ApplicationCommandMessageClass] - Handle Message Application Command Request
2016-09-18 17:23:26.087 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 10: Application Command Request (ALIVE:DONE)
2016-09-18 17:23:26.087 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 10: Starting initialisation from DONE
2016-09-18 17:23:26.087 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@5ff5f2f6 already registered
2016-09-18 17:23:26.087 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 10: Incoming command class MULTI_INSTANCE
2016-09-18 17:23:26.088 [TRACE] [ssage.ApplicationCommandMessageClass] - NODE 10: Found Command Class MULTI_INSTANCE, passing to handleApplicationCommandRequest
2016-09-18 17:23:26.088 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 10: Received MULTI_INSTANCE command V0
2016-09-18 17:23:26.088 [TRACE] [class.ZWaveMultiInstanceCommandClass] - Process Multi-channel Encapsulation
2016-09-18 17:23:26.089 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 10: Requested Command Class = SENSOR_ALARM (0x9c)
2016-09-18 17:23:26.090 [ERROR] [class.ZWaveMultiInstanceCommandClass] - NODE 10: Endpoint 2 not found. Cannot set command classes.
2016-09-18 17:23:26.090 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=10, callback=78, payload=0A 02 84 08 
2016-09-18 17:23:26.091 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 0A 0B 60 0D 02 00 9C 02 0A 00 FF 00 00 
2016-09-18 17:23:26.091 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationCommandHandler, callback id=78, expected=SendData, cancelled=false      MISMATCH

Apologies if thereā€™s anything thatā€™s not relevant in there, firing the tamper alarm also fires the motion sensor so Iā€™ve had to pick that out of quite a lot of log lines.

Iā€™m using the generated items for it currently, sometimes Iā€™ll see the motion/alarm ā€œswitchesā€ turn on, but itā€™s not very often they actually do.

Anyone know whatā€™s up here? The sensor is running firmware version 2.7 from what I can see.

What does the XML file for this node look like? I wonder if the discovery didnā€™t complete properly for some reasonā€¦

Here you go

I did have a lot of problems getting it added, had to disable security on the controller to even get it thinking about recognising it as what it is.

@chris
Is this the same issue I have with the Fibaro FWGP101 ?

Is there any more info I can provide chris? I would be happy to provide you with anything that could sort this thing.

Would it be possible to have the z-wave binding to do a poll on the device/node when it gets a unknown end point (or command class that is not implemented). I do realize that my knowledge in the binding is extremely limited, this was just a thought.

Regards, S

Sorry - I missed this (lost of travel at the moment :frowning: ).

The problem seen in the XML is this -:

    <entry>
      <commandClass>MULTI_INSTANCE</commandClass>
      <multiInstanceCommandClass>
        <version>0</version>
        <instances>0</instances>
        <versionSupported>0</versionSupported>
        <endpoints/>
        <useDestEndpointAsSource>false</useDestEndpointAsSource>
        <endpointsAreTheSameDeviceClass>false</endpointsAreTheSameDeviceClass>
      </multiInstanceCommandClass>
    </entry>

This indicates to me that there was a problem during the initialisation and the device interrogation was not completed.

I would suggest to delete the XML file and reinitialise the thing (ether by restarting the binding, or thereā€™s a config option in HABmin if you click on things and then enable advanced mode). If the same XML results, then thereā€™s a systematic problem and Iā€™ll need to see a debug log to find out why.

I donā€™t think this would be a good idea and it wonā€™t help. If there are unknown endpoints, then something is wrong so polling the device wonā€™t help (since we donā€™t know the endpoints exist).

I deleted the XML and reinitā€™d the node, that block for MULTI_INSTANCE is completely gone from the XML now, thereā€™s just MULTI_INSTANCE_ASSOCIATION. Iā€™m still getting issues with the endpoint errors though.

Hereā€™s the log, sorry thereā€™s some Node12 spam in there also, I tried to remove a lot of it but Iā€™m not sure where some of the messages start and end so I thought it would be best to leave it in in case itā€™s Node10 related.

Ok - if itā€™s gone, thatā€™s just as bad - MULTI_INSTANCE_ASSOCIATION is totally different.

I just had a quick look at the log and there doesnā€™t seem to be much in there at all for node 10. I think it needs to be woken up a few times to get things moving as itā€™s not woken up yetā€¦

Sorry for the delay on this, been a busy week.

Hereā€™s the log, hope you like big files

Iā€™m not sure why itā€™s so big, it just suddenly emptied half of War & Peace into the logfile when I woke it up. Iā€™ve had it with the battery removed since I last powered it up.

Thanks - Iā€™ll take a look when I get a chance. Iā€™m out in the US at the moment so it might not be until the weekendā€¦ (if you donā€™t hear from me by Sunday, please feel free to ping me again :wink: ).

Perhaps a day early but letā€™s call it a margin of error :wink:

Didnā€™t realise you were a Brit too until I looked at your profile! Might have to pick your brain on hardware recommendations at some point - finding moment retroactive switches here is a right pain

Hey @chris, any updates on this?

Sorry - meant to respond to this one.

The problem is the device is reporting version 0, which means it doesnā€™t support multiple endpoints - the binding removes this class when a device says itā€™s not supportedā€¦

We can force the version in the database if needed, but it might be worth completely resetting the device to see if it fixes the problem first.

Iā€™ll have a go when I get the chance cheers. Shall have to dig out the manual to find out the reset button

@chris I reset the sensor, included it again (as a new node) and now it just shows as an unknown device. I sat waking the thing over and over with the B button in hope of making it work with no luck.

Grabbed the OZW panel and removed it fully just to be sure (kept getting not found in network from HABmin), it was showing as a routing device interestingly.

Even weirder is it populated the XML at one point, still no MULTI_INSTANCE but it did populate. It didnā€™t show any info on the UI though

I would make sure you get the latest binding from last night, or this morning - just to make sure it includes the use of NIF as wakeup again as otherwise this could be an issue for batter devicesā€¦

Chris

Where can I find the nightlies for bindings?

You just need to uninstall the binding and reinstall it again - itā€™s easy in OH2ā€¦ This can be done in either PaperUI or HABmin.

Got it cheers. Does it matter that Iā€™m not on the snapshot branch of OH2?

Yes, it does unfortunately. This wonā€™t work if you are not using the snapshot runtime.