Zwave binding / FGFS101 Flood Sensor issues

Hi,

Yesterday, I have upgraded my OH2 instance to try to fix the my.openhag binding issue (My.openhab.org is online // iOS app doesn’t show sitemap -> Solution: Java update!). The last version of Docker image seems to solve this problem. Great ! But now, there are many errors with my FGFS101 Flood Sensors and the Zwave binding.
Indeed, a FGFS101 flood sensor has the following status : “ONLINE - Node initialising: WAIT”. I have tried to test flood alarm of this sensor, but my log file displays a lot of errors with flood sensor and my rule is not triggered :frowning:

What’s going on @chris ?

openhab.log:

2016-08-23 21:07:45.401 [ERROR] [class.ZWaveMultiInstanceCommandClass] - NODE 30: Endpoint 1 not found. Cannot set command classes.
2016-08-23 21:07:47.624 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 30: Size error 4<>2 from config_10_4
2016-08-23 21:07:47.979 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 30: Size error 4<>2 from config_75_4
2016-08-23 21:07:48.018 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 30: Size error 4<>2 from config_76_4
2016-08-23 21:07:53.059 [ERROR] [ocol.ZWaveController$ZWaveSendThread] - NODE 30: Timeout while sending message. Requeueing - 2 attempts left!

events.log:

2016-08-23 21:07:45.401 [hingStatusInfoChangedEvent] - ‘zwave:device:e663edc3:node30’ changed from ONLINE: Node initialising: WAIT to ONLINE
2016-08-23 21:07:45.428 [hingStatusInfoChangedEvent] - ‘zwave:device:e663edc3:node30’ changed from ONLINE to ONLINE: Node initialising: DETAILS
2016-08-23 21:07:45.473 [hingStatusInfoChangedEvent] - ‘zwave:device:e663edc3:node30’ changed from ONLINE: Node initialising: DETAILS to ONLINE: Node initialising: INCLUSION_START
2016-08-23 21:07:45.475 [hingStatusInfoChangedEvent] - ‘zwave:device:e663edc3:node30’ changed from ONLINE: Node initialising: INCLUSION_START to ONLINE: Node initialising: IDENTIFY_NODE
2016-08-23 21:07:45.519 [hingStatusInfoChangedEvent] - ‘zwave:device:e663edc3:node30’ changed from ONLINE: Node initialising: IDENTIFY_NODE to ONLINE: Node initialising: MANUFACTURER
2016-08-23 21:07:45.557 [hingStatusInfoChangedEvent] - ‘zwave:device:e663edc3:node30’ changed from ONLINE: Node initialising: MANUFACTURER to ONLINE: Node initialising: SECURITY_REPORT
2016-08-23 21:07:45.558 [hingStatusInfoChangedEvent] - ‘zwave:device:e663edc3:node30’ changed from ONLINE: Node initialising: SECURITY_REPORT to ONLINE: Node initialising: APP_VERSION
2016-08-23 21:07:45.599 [hingStatusInfoChangedEvent] - ‘zwave:device:e663edc3:node30’ changed from ONLINE: Node initialising: APP_VERSION to ONLINE: Node initialising: DISCOVERY_COMPLETE
2016-08-23 21:07:45.599 [hingStatusInfoChangedEvent] - ‘zwave:device:e663edc3:node30’ changed from ONLINE: Node initialising: DISCOVERY_COMPLETE to ONLINE: Node initialising: VERSION
2016-08-23 21:07:46.021 [hingStatusInfoChangedEvent] - ‘zwave:device:e663edc3:node30’ changed from ONLINE: Node initialising: VERSION to ONLINE: Node initialising: ENDPOINTS
2016-08-23 21:07:46.139 [hingStatusInfoChangedEvent] - ‘zwave:device:e663edc3:node30’ changed from ONLINE: Node initialising: ENDPOINTS to ONLINE: Node initialising: UPDATE_DATABASE
2016-08-23 21:07:46.141 [hingStatusInfoChangedEvent] - ‘zwave:device:e663edc3:node30’ changed from ONLINE: Node initialising: UPDATE_DATABASE to ONLINE: Node initialising: STATIC_VALUES
2016-08-23 21:07:46.274 [ThingUpdatedEvent ] - Thing ‘zwave:device:e663edc3:node30’ has been updated.
2016-08-23 21:07:46.274 [ConfigStatusInfoEvent ] - org.eclipse.smarthome.config.core.status.events.ConfigStatusInfoEvent@2e7a9e51
2016-08-23 21:07:46.352 [hingStatusInfoChangedEvent] - ‘zwave:device:e663edc3:node30’ changed from ONLINE: Node initialising: STATIC_VALUES to ONLINE: Node initialising: ASSOCIATIONS
2016-08-23 21:07:46.414 [ThingUpdatedEvent ] - Thing ‘zwave:device:e663edc3:node30’ has been updated.
2016-08-23 21:07:46.414 [ConfigStatusInfoEvent ] - org.eclipse.smarthome.config.core.status.events.ConfigStatusInfoEvent@6fbe84d4
2016-08-23 21:07:46.599 [ConfigStatusInfoEvent ] - org.eclipse.smarthome.config.core.status.events.ConfigStatusInfoEvent@1eae0b27
2016-08-23 21:07:46.599 [ThingUpdatedEvent ] - Thing ‘zwave:device:e663edc3:node30’ has been updated.
2016-08-23 21:07:46.675 [hingStatusInfoChangedEvent] - ‘zwave:device:e663edc3:node30’ changed from ONLINE: Node initialising: ASSOCIATIONS to ONLINE: Node initialising: SET_WAKEUP
2016-08-23 21:07:46.676 [hingStatusInfoChangedEvent] - ‘zwave:device:e663edc3:node30’ changed from ONLINE: Node initialising: SET_WAKEUP to ONLINE: Node initialising: SET_ASSOCIATION
2016-08-23 21:07:46.677 [hingStatusInfoChangedEvent] - ‘zwave:device:e663edc3:node30’ changed from ONLINE: Node initialising: SET_ASSOCIATION to ONLINE: Node initialising: DELETE_SUC_ROUTES
2016-08-23 21:07:46.775 [hingStatusInfoChangedEvent] - ‘zwave:device:e663edc3:node30’ changed from ONLINE: Node initialising: DELETE_SUC_ROUTES to ONLINE: Node initialising: SUC_ROUTE
2016-08-23 21:07:46.788 [hingStatusInfoChangedEvent] - ‘zwave:device:e663edc3:node30’ changed from ONLINE: Node initialising: SUC_ROUTE to ONLINE: Node initialising: STATIC_END
2016-08-23 21:07:46.789 [hingStatusInfoChangedEvent] - ‘zwave:device:e663edc3:node30’ changed from ONLINE: Node initialising: STATIC_END to ONLINE: Node initialising: SESSION_START
2016-08-23 21:07:46.790 [hingStatusInfoChangedEvent] - ‘zwave:device:e663edc3:node30’ changed from ONLINE: Node initialising: SESSION_START to ONLINE: Node initialising: GET_CONFIGURATION

Please provide a debug log and I’ll take a look. Also, what version of the FGFS do you have?

Also, when you post the log, please format with the </> button - I’m not sure what button you used, but it’s added > everywhere and it makes it impossible to process.

FGFS properties (from PaperUI):

For debug logs, I don’t know to set in OH2 Docker container… :smirk:

So the issue is that you probably have the old version, but because it’s reporting version 25.25 it’s using the config defintion of the new version. These two versions have different parameter definitions and that’s causing the error.

It’s the same discussion as this thread

We would need to create a new version to solve this - one specifically with the 25.25 version number. Can you please post four XML file?

Ok.
There is no node30.xml file in userdata/zwave/ folder…

I have another FGFS-101 flood sensor with the version 25.25:


N.B: this sensor (node15) worked properly before my OH2 upgrade

Here is the corresponding xml file: node15.xml (14.5 KB)

Thanks - I’ll see if I can generate a new database entry for this.

Thank you. I appreciate :slight_smile:

I have another zwave issue in my log file. Do I post a new thread ?

Yes - it’s probably best so that we have some chance of searching for these threads again later…

I’ve updated the FGFS version 25.25 - try tomorrows version and see how it goes.

Great ! :slight_smile: I’ll try this fix tomorrow

Hi @chris,

I just try your fix (25.25 version). Here, my results:

Tested zwave device: FIBARO FGFS101 / version 25.25
OpenHAB version: 2.0.0-SNAPSHOT / Build #455
Zwave binding version: org.openhab.binding.zwave-2.0.0-20160824.010128-177.jar
Item(s) configuration:
Group groupFloodFrigoInside “Frigo inside” (groupCuisine)
Switch FloodSensor_FrigoInside_Alarm “Fuite” (groupFloodFrigoInside) { channel = “zwave:device:e663edc3:node30:alarm_flood” }
Number FloodSensor_FrigoInside_Battery “Batterie [%s %%]” (groupFloodFrigoInside, groupIntrusionBattery) { channel = “zwave:device:e663edc3:node30:battery-level” }
Switch FloodSensor_FrigoInside_Tamper “Sabotage” (groupFloodFrigoInside) { channel = “zwave:device:e663edc3:node30:alarm_burglar” }
Number FloodSensor_FrigoInside_Temp “Temperature [%.1f °C]” (groupFloodFrigoInside) { channel = “zwave:device:e663edc3:node30:sensor_temperature” }
//DateTime FloodSensor_FrigoInside_LastUpdated “Last updated” (groupFloodFrigoInside) { zwave=“30:command=info,item=LAST_UPDATE”}


Test cases:

  1. Identification: OK (:slight_smile:)
  2. Channel “Binary Sensor” (:sensor_binary) : not tested (no linked item…)
  3. Channel “Sensor (temperature)” (:sensor_temperature): FAILED - No data updated
  4. Channel “Alarm (burglar)” (:alarm_burglar): FAILED - No trace in logs
  5. Channel “Alarm (flood)” (:alarm_flood): FAILED - Item “FloodSensor_FrigoInside_Alarm” in Basic UI not updated (and my alert rule not triggered) - see Logs #1
  6. Channel “Battery Level” (:battery-level): OK (battery level seems updated)
  7. Channel “Alarm (flood)” (:alarm_flood): FAILED - N.B: duplicated channel ?
  8. Channel “Alarm (general)” (:alarm_general): not tested (no linked item…)

Logs #1:

2016-08-25 22:10:06.846 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 30: Application Command Request (ALIVE:DONE)
2016-08-25 22:10:06.846 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 30: Starting initialisation from DONE
2016-08-25 22:10:06.846 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@3b0c811b already registered
2016-08-25 22:10:06.846 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 30: Incoming command class MULTI_INSTANCE
2016-08-25 22:10:06.846 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 30: Received MULTI_INSTANCE command V2
2016-08-25 22:10:06.847 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 30: Requested Command Class = BASIC (0x20)
2016-08-25 22:10:06.847 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 30: Endpoint = 1, calling handleApplicationCommandRequest.
2016-08-25 22:10:06.847 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 30: Received Basic Request
2016-08-25 22:10:06.847 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 30: Basic Set sent to the controller will be processed as Basic Report
2016-08-25 22:10:06.847 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 30: Basic report, value = 0xFF
2016-08-25 22:10:06.847 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2016-08-25 22:10:06.847 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 30: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2016-08-25 22:10:06.847 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 30: Got a value event from Z-Wave network, endpoint = 1, command class = BASIC, value = 255

What’s wrong ?

Thx

The device has no such channel.

No such channel either.

It’s not duplicated in the database, so I don’t know what you mean.

You show 8 channels, but the database only seems to have 6, so I’m not too sure what’s happening.

There’s clearly some major problems with your configuration. Please check the configuration in the database -:

http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/408?layout=openhab2

Indeed, it’s weird… :neutral_face:

Can you tell me the procedure to reset this device ?

I use the UI rather than the item files and I would delete the thing and add it back again, but I’m not sure that will work here.

1 Like

I have reinstall a “fresh” OH2 instance and disable/enable the items of node 30 (FGFS101 flood sensor).

Now, I have executed the following test case: To check the flood sensor alarm
Results: the channel :sensor_binary1 is updated to ON (see the following log) but specific channel (:alarm_flood) is not updated… Is it normal ?

2016-08-26 00:05:23.751 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 30: Application Command Request (ALIVE:DONE)
2016-08-26 00:05:23.751 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 30: Starting initialisation from DONE
2016-08-26 00:05:23.751 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@149f1b87 already registered
2016-08-26 00:05:23.751 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 30: Incoming command class MULTI_INSTANCE
2016-08-26 00:05:23.751 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 30: Received MULTI_INSTANCE command V2
2016-08-26 00:05:23.752 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 30: Requested Command Class = BASIC (0x20)
2016-08-26 00:05:23.752 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 30: Endpoint = 1, calling handleApplicationCommandRequest.
2016-08-26 00:05:23.752 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 30: Received Basic Request
2016-08-26 00:05:23.752 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 30: Basic Set sent to the controller will be processed as Basic Report
2016-08-26 00:05:23.752 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 30: Basic report, value = 0xFF
2016-08-26 00:05:23.752 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2016-08-26 00:05:23.753 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 30: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2016-08-26 00:05:23.753 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 30: Got a value event from Z-Wave network, endpoint = 1, command class = BASIC, value = 255
2016-08-26 00:05:23.753 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 30: Updating channel state zwave:device:e663edc3:node30:sensor_binary1 to ON [OnOffType]

Comment #1: the description “Flood Sensor” of this device (25.25) is missed in Zwave database
Comment #2: in OH1, the Fibaro FGFS-101 flood sensor has a Tamper property (Switch swFibFlood_Tamper "Water-Sensor: Tamper" { zwave="11:command=sensor_alarm, alarm_type=0,respond_to_basic=true" } - from Wiki page https://github.com/openhab/openhab/wiki/Z-wave-Binding-Examples#sensors). What is the channel of this property in OH2 ?

Thx

It looks like the device is sending the BASIC class in the log you show, and there is no endpoint set to basic in the database. It probably should be the sensor_binary that is set to BASIC - please feel free to update the database appropriately.

Please feel free to update the database to add this.[quote=“nokyyz, post:14, topic:13512”]
Comment #2: in OH1, the Fibaro FGFS-101 flood sensor has a Tamper property (Switch swFibFlood_Tamper “Water-Sensor: Tamper”
[/quote]

This would be the Alarm General channel. The database doesn’t know that this is a tamper unless someone actually updates it. Again, please feel freee to update the database.

I doubt that this should have respond_to_basic. That would mean that the main function of this device is a tamper alarm :wink: . As above, it is more likely that the sensor_binary should be set to BASIC.

I don’t know how every device in the database works, so really it needs others to edit the devices to get them correct. If everyone puts in a little time to get their devices correct, it won’t take too much I think :slight_smile: .

I am agree with you. For efficiency, I think we should define test cases for each Zwave device (maybe in your website http://www.cd-jackson.com/index.php/zwave/). The community could then indicate a status validation by device.
What do you think about that ? (but perhaps it already exists…)

Thanks for your responses ! :slight_smile:

What do you mean by ‘test cases’. I’m not really sure what such a test would look like?

There’s no real way to validate the data automatically - it requires people to test them and see if the configurations work. When the database reads the XML files, it creates channels, and sets channel names that are based on the device command classes. We don’t know what they do, so this needs to be edited by people who have the device to customise it for the device. This needs everyone to help - it’s not something that I can do alone ;).

The database provides a comments section - the idea was to allow people to comment on devices so that we could itterate on their configuration.

At some point I’ll likely look to lock down devices that are known to be working well, but in the meantime, there are many updates that could be done, and it would be good if people can contribute to this to improve the device information for devices that they have.

Was this solved? I have the same version and the same issues!

@chris I have removed the html errors from the description but I can see there are are some ’ characters used in the description as well… is that a problem? (parameter #7 http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/408#parameter2509)

I will try to go over the configuration I have this flood sensor and it has the same problems with to many channels.

1 Like

Generally HTML is ok in descriptions - I’m not sure about your question though - is the ’ character causing problems? I can add conversions into the database export if needed, but I think it’s ok isn’t it?

Thanks for going through the config - any issues, just yell :slight_smile: .