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! - #4 by sihui). 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
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.
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?
Channel “Binary Sensor” (:sensor_binary) : not tested (no linked item…)
Channel “Sensor (temperature)” (:sensor_temperature): FAILED - No data updated
Channel “Alarm (burglar)” (:alarm_burglar): FAILED - No trace in logs
Channel “Alarm (flood)” (:alarm_flood): FAILED - Item “FloodSensor_FrigoInside_Alarm” in Basic UI not updated (and my alert rule not triggered) - see Logs #1
Channel “Battery Level” (:battery-level): OK (battery level seems updated)
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 ?
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 . 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 .
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…)
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.
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 .
)
. As above, it is more likely that the sensor_binary should be set to BASIC.