Can't change parameter on Fibaro FGFS-101 Flood Sensor

Hardware Home Automation
1

openHAB 3.3.0

I can’t change one of (or, presumably, any of) the parameters on one of my Fibaro FGFS-101 flood sensors. It’s currently set at 2, and if I type 0, the value I want, it reverts back to 2 as soon as I press “save” in Main UI. The sensor is awake because I’m always pressing the button to make sure (this particular one is mains powered, anyway, so it shouldn’t be a problem). I don’t see “pending” - it says “thing configuration updated” immediately.

I’ve seen this problem of flood sensor values immediately reverting before. Any idea how to get around it?

2

I have one of those flood sensors as well. And I am still on OH 3.3, too. The difference to your situation: my sensor is battery powered.
I tried to change parameter “73: Temperature measurement compensation” from 0 to 2 and back. No issues.
Which parameter did you try to change?

3

74 (tamper alarm)
I’ve had this happen in the past, too, and previously they’ve always been battery-powered.

4

Changed parameter 74 without issues as well here.

You can change the log setting for ZWAVE to a higher level, then try to change the parameter. Maybe the log will give you an idea of what is happening.

5

OK, I’ll try that

6

I finally got around to trying this :man_facepalming:.

None of the device’s parameters are being updated. The problem seems to be a missing command in the device’s configuration:

2023-03-11 16:46:31.372 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 47: Configuration update received
2023-03-11 16:46:31.401 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 47: Error getting configurationCommandClass
2023-03-11 16:46:31.403 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 47: Configuration update set config_73_2 to 0 (BigDecimal)
2023-03-11 16:46:31.405 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 47: Error getting configurationCommandClass
**2023-03-11 16:46:31.407 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 47: Configuration update set config_74_1 to 0 (BigDecimal)**
2023-03-11 16:46:31.410 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 47: Error getting configurationCommandClass

Looking at this thread, the problem appears to be that there are missing commands from the device’s xml file. I have five of these flood sensors, and two appear to have the complete set of commands, and three are missing quite a few. Complete command set:

  <nodeInformationFrame>
    <commandClass>COMMAND_CLASS_ZWAVEPLUS_INFO</commandClass>
    <commandClass>COMMAND_CLASS_APPLICATION_STATUS</commandClass>
    <commandClass>COMMAND_CLASS_ASSOCIATION</commandClass>
    <commandClass>COMMAND_CLASS_ASSOCIATION_GRP_INFO</commandClass>
    <commandClass>COMMAND_CLASS_BATTERY</commandClass>
    <commandClass>COMMAND_CLASS_CONFIGURATION</commandClass>
    <commandClass>COMMAND_CLASS_CRC_16_ENCAP</commandClass>
    <commandClass>COMMAND_CLASS_DEVICE_RESET_LOCALLY</commandClass>
    <commandClass>COMMAND_CLASS_FIRMWARE_UPDATE_MD</commandClass>
    <commandClass>COMMAND_CLASS_MANUFACTURER_SPECIFIC</commandClass>
    <commandClass>COMMAND_CLASS_MULTI_CHANNEL_ASSOCIATION</commandClass>
    <commandClass>COMMAND_CLASS_ALARM</commandClass>
    <commandClass>COMMAND_CLASS_POWERLEVEL</commandClass>
    <commandClass>COMMAND_CLASS_SECURITY</commandClass>
    <commandClass>COMMAND_CLASS_SENSOR_ALARM</commandClass>
    <commandClass>COMMAND_CLASS_SENSOR_MULTILEVEL</commandClass>
    <commandClass>COMMAND_CLASS_VERSION</commandClass>
    <commandClass>COMMAND_CLASS_WAKE_UP</commandClass>
  </nodeInformationFrame>

Incomplete:

<nodeInformationFrame>
    <commandClass>COMMAND_CLASS_ZWAVEPLUS_INFO</commandClass>
    <commandClass>COMMAND_CLASS_APPLICATION_STATUS</commandClass>
    <commandClass>COMMAND_CLASS_ASSOCIATION_GRP_INFO</commandClass>
    <commandClass>COMMAND_CLASS_CRC_16_ENCAP</commandClass>
    <commandClass>COMMAND_CLASS_FIRMWARE_UPDATE_MD</commandClass>
    <commandClass>COMMAND_CLASS_MANUFACTURER_SPECIFIC</commandClass>
    <commandClass>COMMAND_CLASS_POWERLEVEL</commandClass>
    <commandClass>COMMAND_CLASS_SECURITY</commandClass>
    <commandClass>COMMAND_CLASS_SENSOR_MULTILEVEL</commandClass>
    <commandClass>COMMAND_CLASS_VERSION</commandClass>
  </nodeInformationFrame>

Is this because something went wrong during device discovery when the sensors were added?

Is this quickest fix to delete and re-add them, or just edit the xml files? Since deleting and adding is such a pain, editing the xml by copying from one of the two good files sounds easier to me right now.

7

Try simply deleting the thing (not exclude) and then rescan. This should refresh the XML (after waking the device) I do not think editing the xml will work.

1 Like
8

The result is the same, unfortunately. No sign of the missing command classes in the xml. I’m going to look at what the PC-Controller software says about what command classes the device supports.

9

That’s a good idea. Something is amiss.

10

What I see is that the command classes missing from the xml are listed as “secure command classes” in the PC Controller utility. What does that mean?

11

On the face of it, it sounds like maybe some of the devices were included with security? That’s not an area I have much experience.

Edit: you may have to exclude one after all :frowning_face:
Edit2: looking at the DB there are three FGFS-101. What version do you have? And are the ones that work the same version?

12

Is that the Z-wave version in properties? Or deviceid in the xml?

The Z-Wave versions are 3.2, 3.2, 3.2, 3.3 and 3.4. In any case I don’t see a pattern because the sensor that I excluded and re-included formerly showed the complete set of command classes in the xml, but now doesn’t. I wonder if there’s some difference between including it from OH and from PC Controller.

13

Cracked it, I think. I can never get them to exclude from Main UI, which is why I end up doing the whole process from PC Controller, but this time I just excluded it from PC Controller, and included it from Main UI, which does work. And bingo, the command classes are back. And I can alter the parameters.

I’ve just tried with the one from earlier. I’ll now try with the original sensor that caused me to start this thread.

14

What’s the trick to exclude them from Main UI? It would life much easier if I could do that. I hit remove from controller, confirm and then tap three times, but nothing happens.

15

You are probably right. All these are the same device in the DB.

Fibaro
Fibaro754×319 16.3 KB

1 Like
16

Are you using “exclude Devices” on the controller UI page? or the remove from controller on the device? Need to use the “exclude”

1 Like
17

Ahhh. That explains it.

In PC Controller, the devices that don’t work properly are marked as having the Security Scheme S0. I’d noticed it before but not realised its significance. There’s also a Security Scheme button that shows a list including “NONE”, but it’s inactive unless an already-included device is selected, so I don’t know how to include a device without the security scheme. That’s what’s going on.

Anyway, if I can exclude and include from Main UI the problem goes away.

1 Like
18

Definitely solved. Another sensor is now also responding to parameter changes. Two down, two to go.

And “exclude devices” from the controller works. What does “Remove device from controller” do?

Thanks for all the help.

19

I’ll get in trouble for saying this, but it is hard to get that to work and really will not work at all on a battery device. It is the second part of a two-step process. First you need to have a successful “mark device as failed” then the remove device from controller will work, IF there is no response from the device. However, the binding will not send a message to a battery device, so the first step can’t be completed.

Glad it is working :smiley:

1 Like