Fibaro FGDW-002 not fully discovered by Binding

Setup, Configuration and Use Installation
,
1
  • Platform information:
    • Hardware: RaspberryPI
    • OS: openhabian
    • openHAB version: 2.4
  • Issue of the topic: Trying to add a new Zwave node Fibaro Door/window sensor 2 (FGDW-002). I’m using the Z-Stick Gen5. Did the inclusion steps ok. In Paper UI inbox I get "Zwave Node x; Unknown device. When adding as thing and opening, I get this message:

Z-Wave Node 008

Unknown Device

Blockquote

This device has not been fully discovered by the binding. There are a few possible reasons for this -:

  • The device is not in the database. If the device attributes show that this device has a valid manufacturer ID, device ID and type, then this is likely the case (eg. you see a label like " Z-Wave node 1 (0082:6015:020D::2.0) "). Even if the device appears to be in the database, some manufacturers use multiple sets of references for different regions or versions, and your device references may not be in the database. In either case, the database must be updated and you should raise an issue to get this addressed.

Blockquote

I tried all I could (remove the node and reinclude on Zwave controler; wait long enoug to allow for discovery to complete (battery powered) to no avail. Could it be that the issue is relating to “Even if the device appears to be in the database, some manufacturers use multiple sets of references for different regions or versions, and your device references may not be in the database. In either case, the database must be updated and you should raise an issue to get this addressed” in which case I’ll need your help.

Thanks!
Luc.

2

Just adding some log info relating to the issue:

Blockquote

2019-03-27 18:01:58.611 [ERROR] [ing.zwave.handler.ZWaveSerialHandler] - Got I/O exception Input/output error in writeArray during sending. exiting thread.

2019-03-27 18:02:00.872 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 8: Device discovery could not resolve to a thingType! Manufacturer data not known.

Blockquote

thanks for any help

3

This is a battery powered device, which will require several wakeups to initialize. The device was also updated at the end of October, so whatever changes were made, possibly fixes(?), would not be in the 2.4 version of the binding.

4

Thanks Scott for the info. It actually took all night for the binding to discover it. It worked fine for a few hours with item reacting to open and close and then suddenly it kind of froze and stayed open. I tried removing and re-include, but it looked like the binding was not reading from the stick anymore but rather from some cached data. I decided to uninstall and reinstall ZWAVE binding and to reset the Aeotec stick entirely and re-include all my ZWAVE devices from scratch including the FGDW-002. All devices have been initialized ok immediately but the FGDW-002 which is still pending. I’ll post results as soon as FGDW-002 fully initialized.

5

Initialization has completed. I added as thing, linked to a new item (contact) and tested. I get no reaction from open-close. However, when pressing the tamper button I get:
“2019-03-29 14:39:57.730 [me.event.ThingUpdatedEvent] - Thing ‘zwave:device:89f22ddc:node5’ has been updated”
However, a thing linked to Alarm (Tamper) does not get any update.

Not sure what to do. Any help appreciated. Txs!

6

OK. I found the solution. Still can’t explain why but it works:

So when hitting the tamper button, I get this message:
2019-04-10 09:31:23.025 [me.event.ThingUpdatedEvent] - Thing ‘zwave:device:89f22ddc:node11’ has been updated.
After this I don’t get any reaction from the FGDW-002 in OpenHab
Solution I found is to go to the related Thing in PaperUI and use the “Reset the Device” action and then go back and use the “Heal the device” action.
Then after getting following messages, it all works again.

2019-04-10 09:27:59.889 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:89f22ddc:node11' has been updated.

2019-04-10 09:28:00.036 [vent.ConfigStatusInfoEvent] - ConfigStatusInfo [configStatusMessages=[ConfigStatusMessage [parameterName=group_1, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=group_3, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=group_2, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null]]]

2019-04-10 09:28:00.125 [hingStatusInfoChangedEvent] - 'zwave:device:89f22ddc:node11' changed from ONLINE: Node initialising: EMPTYNODE to ONLINE: Node initialising: IDENTIFY_NODE

2019-04-10 09:28:00.781 [hingStatusInfoChangedEvent] - 'zwave:device:89f22ddc:node11' changed from ONLINE: Node initialising: IDENTIFY_NODE to ONLINE: Node initialising: REQUEST_NIF

2019-04-10 09:29:10.661 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:89f22ddc:node11' has been updated.

2019-04-10 09:29:10.684 [vent.ConfigStatusInfoEvent] - ConfigStatusInfo [configStatusMessages=[ConfigStatusMessage [parameterName=wakeup_node, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=wakeup_interval, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=group_1, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=group_3, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=group_2, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null]]]

2019-04-10 09:29:36.659 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:89f22ddc:node11' has been updated.

2019-04-10 09:29:36.969 [hingStatusInfoChangedEvent] - 'zwave:device:89f22ddc:node11' changed from ONLINE: Node initialising: REQUEST_NIF to ONLINE: Node initialising: SECURITY_REPORT

2019-04-10 09:29:36.975 [hingStatusInfoChangedEvent] - 'zwave:device:89f22ddc:node11' changed from ONLINE: Node initialising: SECURITY_REPORT to ONLINE: Node initialising: MANUFACTURER

2019-04-10 09:29:37.006 [hingStatusInfoChangedEvent] - 'zwave:device:89f22ddc:node11' changed from ONLINE: Node initialising: MANUFACTURER to ONLINE: Node initialising: APP_VERSION

2019-04-10 09:29:37.066 [hingStatusInfoChangedEvent] - 'zwave:device:89f22ddc:node11' changed from ONLINE: Node initialising: APP_VERSION to ONLINE: Node initialising: DISCOVERY_COMPLETE

2019-04-10 09:29:37.072 [hingStatusInfoChangedEvent] - 'zwave:device:89f22ddc:node11' changed from ONLINE: Node initialising: DISCOVERY_COMPLETE to ONLINE: Node initialising: VERSION

2019-04-10 09:29:37.765 [hingStatusInfoChangedEvent] - 'zwave:device:89f22ddc:node11' changed from ONLINE: Node initialising: VERSION to ONLINE: Node initialising: ENDPOINTS

2019-04-10 09:29:37.770 [hingStatusInfoChangedEvent] - 'zwave:device:89f22ddc:node11' changed from ONLINE: Node initialising: ENDPOINTS to ONLINE: Node initialising: UPDATE_DATABASE

2019-04-10 09:29:37.797 [hingStatusInfoChangedEvent] - 'zwave:device:89f22ddc:node11' changed from ONLINE: Node initialising: UPDATE_DATABASE to ONLINE: Node initialising: STATIC_VALUES

2019-04-10 09:29:37.959 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:89f22ddc:node11' has been updated.

2019-04-10 09:29:37.962 [vent.ConfigStatusInfoEvent] - ConfigStatusInfo [configStatusMessages=[ConfigStatusMessage [parameterName=group_1, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=group_3, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=group_2, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null]]]

2019-04-10 09:29:38.077 [hingStatusInfoChangedEvent] - 'zwave:device:89f22ddc:node11' changed from ONLINE: Node initialising: STATIC_VALUES to ONLINE: Node initialising: ASSOCIATIONS

2019-04-10 09:29:38.310 [hingStatusInfoChangedEvent] - 'zwave:device:89f22ddc:node11' changed from ONLINE: Node initialising: ASSOCIATIONS to ONLINE: Node initialising: SET_WAKEUP

2019-04-10 09:29:38.317 [hingStatusInfoChangedEvent] - 'zwave:device:89f22ddc:node11' changed from ONLINE: Node initialising: SET_WAKEUP to ONLINE: Node initialising: SET_ASSOCIATION

2019-04-10 09:29:38.384 [hingStatusInfoChangedEvent] - 'zwave:device:89f22ddc:node11' changed from ONLINE: Node initialising: SET_ASSOCIATION to ONLINE: Node initialising: SET_LIFELINE

2019-04-10 09:29:38.389 [hingStatusInfoChangedEvent] - 'zwave:device:89f22ddc:node11' changed from ONLINE: Node initialising: SET_LIFELINE to ONLINE: Node initialising: GET_CONFIGURATION

2019-04-10 09:29:39.152 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:89f22ddc:node11' has been updated.

2019-04-10 09:29:39.160 [vent.ConfigStatusInfoEvent] - ConfigStatusInfo [configStatusMessages=[]]

2019-04-10 09:29:39.349 [hingStatusInfoChangedEvent] - 'zwave:device:89f22ddc:node11' changed from ONLINE: Node initialising: GET_CONFIGURATION to ONLINE

2019-04-10 09:29:42.818 [vent.ItemStateChangedEvent] - FenetreSebSensorDoor changed from OPEN to CLOSED

2019-04-10 09:29:45.444 [vent.ItemStateChangedEvent] - FenetreSebSensorDoor changed from CLOSED to OPEN

2019-04-10 09:29:47.321 [vent.ItemStateChangedEvent] - FenetreSebSensorDoor changed from OPEN to CLOSED

If someone could explain why, it would really help me understand this stuff a bit better (I’m not a Geek and just use PaperUI and some rules and item files for my home automation)

Txs!

Luc.

7

There is a bug in the 2.4 version of the binding where associations would be lost or not set. There was a fix in later builds to force the associations. In your case, the reinitilaize set the association, which allowed the device to report events to the comtroller. The heal is likely not part of the equation.

If this is repeatable, some logs where the device goes from working to not working may be valuable, but let’s check. @chris, are the lost associations fully understood, or are you happy with the fix in 2.5?

8

Personally, I don’t think the bug is in the binding, but it’s a little academic :wink: .

The issue is that different UIs, or maybe people sending direct REST commands, or whatever, all appear in the binding in different formats - not the format that is defined by ESH. This causes all sorts of problems, and in the latest binding I’ve taken measures to try and handle different formats that I’ve seen in peoples logs - there may still be more formats that can cause problems…

1 Like
9

All works fine now since I updated to 2.5
Txs!