FGFS-101 device not recognized anymore (firmware 2.5)

Don’t know if this can be helpful in understanding the issue: I performed some “regression” tests in the last days to identify what was the last SNAPSHOT build of the zwave binding able to properly recognize the device. What I found out was that between these two builds something went awry:

  • org.openhab.binding.zwave-2.0.0-20160724.010140-136
  • org.openhab.binding.zwave-2.0.0-20160729.010130-140
    Build 136 (performed on the 24th of July) correctly recognizes the device, while build 140 (performed on the 29th of July) does not and exhibits the behavior mentioned in earlier posts.
    I could test build 137 and 138 too if deemed useful.

Sorry to ask a stupid question, but what is “the issue”. Above it states that this device is now discovered ok, but the channels don’t work - so do you mean that between 136 and 140 it stopped recognising the device, or channels aren’t discovered?

Since the builds you mention are all from the old repository it’s hard to trace the history - can you provide a log showing the problem please.

Sorry chris, I think I was too hasty (and, therefore, a little cryptic) in writing down my last post. I’ll try to better explain what I meant.
Given that:

  1. until “recent” builds, the binding was able to correctly identify the FGFS-101 device with firmware 2.5 in my possession
  2. after an accidental reset of the controller bound to the device and several updates to the zwave binding, I found myself unable to reconnect it again to the same system it was connected to just minutes before the reset because the binding was not able to recognize it

I assumed that something in the binding changed in a way that broke the correct discovery of the device and indeed what changed between the 2 builds I reported before was the entry inside the database, where the versionMax property was capped to 3.0 (while before it was unbounded) and a new entry for newer firmware versions was added for firmware version 3.2 (as requested here).
Given the now evident “peculiar” version string (25.25) of the device and the new maximum version limit (3.0) for applicability of the right database entry, I guess we cannot blame the code that compares the firmware versions and finds 25.25 to be greater than 3.0. :slight_smile:
Could this explain the problem?
I haven’t had time to test the latest versions of the binding, but I’ll do it ASAP to see if all is OK now and, if not, to collect all relevant logs. :+1:

I’m not sure I completely understand. Does the device get discovered at all? If it’s version 25.25, then it should be discovered as the newer (firmware 3.2) version.

What I don’t know is if version 25.25, which while I agree is peculiar, is a real version - it shows up in their documentation and is in the pepper1 database. If version 25.25 is really the same as 2.5, and not 3.2, then we will need to create a new version which is a copy of 2.5.

Let’s see what the new binding does, and if it’s not working let’s get a log so that I can understand what’s happening… Thanks.

Exactly that is the case … Discovery works for 25.25 … No channels get any Update.

Since i am on vacation I could not send a log yet. I will once I am back.

Is this using the version from yesterday?

There are now two threads on this topic so I’m getting confused about who is using what.

My binding Version is from Aug 12th.
There it got recognized again.
I will update to latest binding and update here when i am back from vacation

I can now confirm that in recent 2.0.0-SNAPSHOT versions of the binding the device is recognized again.
However, as already mentioned here, I get these strange association groups after the device is included in the network:

   "group_1": [
      "node_179_0"
    ],
    "group_2": [
      "node_177_0"
    ],
    "group_org.openhab.binding.zwave.internal.protocol.ZWaveAssociationGroup@e902fe": [
      "node_179_0"
    ],
    "group_org.openhab.binding.zwave.internal.protocol.ZWaveAssociationGroup@a837a9": [
      "node_177_0"
    ],

with the result that the controller doesn’t receive flood alarm events.
Putting node_1_0 in group_1 makes it work again, although the alarm is now received on the Binary sensor 1 channel instead of the Alarm (flood) one.

I can’t say too much without a log during startup - my initial reaction is that the device has these nodes configured somehow…

What file is this (is it from my json storage?).

No, that output is from the /rest/things/zwave:xyz API call.
As I’m currently performing some experiments, I’ll retry the association from scratch and attach complete logs soon.

I don’t understand why the second two groups have a full class name specified. They should all by lists of strings so this is confusing me how this can happen. The code looks like this -:

                        List<String> group = new ArrayList<String>();
        ...
                        configuration.put("group_" + groupId, group);

so I don’t see how the ZWaveAssociationGroup class gets used? How are you configuring the system?

Here is a complete log (of course not an XML): fgfs101.log.zip.xml (110.9 KB)

Here’s what I’ve done:

  1. start from scratch with a controller that has been hard reset
  2. inclusion of the FGFS-101 device (node 2)
  3. exclusion of the device
  4. re-inclusion of the same device (node 3)

As you can see from the log, the association groups set in the device are different between the two runs:

  • node_181_0 and node_182_0 for node 2
  • node_174_0 for node 3
    They also do not include node_1_0 in both cases.

Thanks - I’ll try and look at this, but as I mentioned on Github, you are using a totally different format for the logging and it means I can’t process logs from you. Is there any chance you can make it more standard - otherwise it’s really going to be a lot of work for me :frowning: .

Me neither, I never noticed it until i updated the zwave binding to the latest snapshot and the ESH runtime we’re using to the 0.9.0b1 version… :confused:
From your code and my REST output, it seems like sometimes groupId is not an integer but an instance of org.openhab.binding.zwave.internal.protocol.ZWaveAssociationGroup. Is this possible?

I thought the logs would be good now… :sweat:
If by “standard” you mean like the openhab ones, I’ll try using the same conversion pattern from the openhab project, as I can see there are some differences…
Here are new logs using the OH log format: fgfs101.log-OH.zip.xml (111.3 KB) Is this ok?
In this log, I repeated the same experiment as before and the nodes are now node 4 and 5 (I didn’t reset the controller), while the “abnormal groups” are:

  • node_185_0 and node_191_0 for node 4
  • node_187_0 and node_184_0 for node 5

Not “sometimes” - it should never be an integer. It should be a string - always - but for some reason it’s something else in this case and I’ve no idea why or how this is possible. Maybe I need to do a better check in the binding as there’s another place where this is set…

I think it has a log of differences! :slight_smile: I should say that I quite like your formatting in that it’s easier to read visually, but it breaks the assumptions in the log reader which searches the string for the date (which you have formatted differently), and then the break to the main text which uses a - instead of your |. Maybe if you can change the last | to - and fix the formatting of the date it might work.

I’ll take a look at your new log, but probably tonight as I have to travel soon…

Thank you Chris, as always. :slight_smile: