@chris I’m having a problem with my Fibaro Wall plugs since about 2 weeks. I have 2 of these plugs and I cannot seem to add them using the ZWave binding.
I’m using a Raspberry Pi 3 with OpenHAB2.3-SNAPSHOT(I also tested this with 2.2) and using the Zwave 2.3-SNAPSHOT binding. (Again, also tested with the 2.2 zwave binding). I’m using a Aeotec Z-stick Gen5 as a controller. Just to clarify, these modules have worked perfectly in the past using OpenHAB and your z-wave binding. I also updated the firmware for the Wall plugs today (using a Fibaro HCL) to make sure that it wasn’t an outdated firmware problem.
Steps taken :
Reset the Fibaro Wall plugs to their factory defaults
Excluded/Included the wall plugs from the controller
Updated the firmware of the wall plugs
Tried OpenHAB 2.2 and 2.3-SNAPSHOT along with the respective zwave binding
Verified that the wall plugs were working correctly by adding them to a Fibaro HCL controller
Completely re-installed OpenHAB
Tried to use a text based (.thing) config to force the device type from the database **
** : This worked ‘somewhat’ in that I could interact with the plugs - only I couldn’t receive any power metering reports so it wasn’t a solution for me.
As you can see the manufacturer ID and the device ID match the Fibaro wall plug in your database; so it’s not clear to me why these plug do not get recognized… Maybe the firmware version (25.25) is not properly formatted? According to the Fibaro HCL the plugs are installed with firmware version 2.5, so maybe that’s a clue?)
The above screenshots are taken on a freshly installed OpenHAB installation with no other bindings installed except for your zwave binding. Also no other zwave modules have been added or included to the network; just one Fibaro Wall plug that is plugged in near my zwave controller.
Is there a specific log that I can show you to help you solve my problem? It seems that the devices are in fact in your database, but somehow the binding does not recognize my wall plugs.
I hope you can help me - I’ve been going at this issue for over a week now and nothing seems to work. I’d be more than happy to share any/all logs that could shed some light on this issue.
I have the problem exactly with the FGWP101 plug. Other devices get recognized correctly. So I assume it is a database related issue, but that is speculation from me.
I just tried to use an old version of the dev binding and it worked. For this I replaced the most recent binding version with the old jar from August (20170819) and inclusion went smooth, the device is recognised as FGWP101. So this definitely appears to me like a messup of the database.
After including the device you can reinstall the most recent version (20180102) and use the device. You just need to get the xml and JSON entries by first including it with the old version.
Looking at the database in GH there was a versionMax = 2 added a couple of weeks ago. It looks like someone has consolidated the versions - I’ve not checked who yet but we can see that the different versions have been made “consistent” to remove overlaps.
From the above posts I assume the problem is with the FGWP101
My FGWP101 has a device type and id 0600:1000 and a firmware version of 2.5 (it’s an older one, around three years old)
So to solve the problem for the 101 we just need to change the versionMax to 2.5 and it should work again.
But what happens to the 102 in this case? I hope it will not be affected because it has a different unique reference (thing id)…
@chris Can you make this change to the FGWP001 device or is this something I should do? And can you tell me when there will be a build available to download with the change incorporated?
Since I use .thing files for a text config I presume it has to be the test build? (And a related question, when will the release or snapshot binding container the possibility of using text configuration?)
Yes, but if you look in the database, the first FGWP102 has the same ID. The database uses the IDs and the version - the names just come along for the ride
Previously there was no upper version on the 101 in the database - someone added the version limitation 2 weeks or so ago so I’m assuming that this is what is causing the problems here. The FGWP102 devices have not changed the database for 9 to 12 months.
It doesn’t have a unique ID in the database -:
From the above, you see the FGWP101 has the same ID as the FGWP102 version 2.1 to 2.5. Up until 2 weeks ago, there was no firmware version in the 101, so, if you had a 101 with V25.25 it would have been detected as this (0600:1000 v25.25). Now we have the restriction of the version number (25.25 is a bigger number than 2.0 so there’s no longer a match). Additionally, the FGWP102 that would have matched the version (All after 3.2) doesn’t have the same device IDs so it also doesn’t match.
I’ve not looked at the differences in all these devices, so I’m not sure what the options are to resolve this. Why is the FGWP10-2 V2.1 to 2.5 have one set of device ids (which is the same as the 101) which the >3.2 have a different set? There are a number of ways this could be configured, but I don’t know what is the right way without either checking the zwave products website (which might not have the info either) or for people to list their device here, along with the type/id/version and we update with that information.
When I get home later today I can supply you with more information on the modules; what are you looking for specifically? Is there a debug option that spews out the info needed? Or do I need to use the Zensys tools and query the controller with the node information?
| Data | Value |
|--------|--------|
| Device name | data goes here |
| Device Type | data goes here |
| Device Id | data goes here |
| Version | data goes here |
