thx, works now 
as you said I was on wrong binding:
202 | Active | 80 | 2.1.0.201706222153 | ZWave Binding
right one:
211 | Active | 80 | 2.1.0.201706182030 | ZWave Binding
1 Like
Thanks - I’m glad we got there… (finally 
).
In the latest dev branch from 2.1.0.201706242319 a fix is not included yet, so I thought I open an issue that it is not being forgotten:
Good idea. This isn’t so simple to resolve though so it might not be super quick. I’m not sure if it’s possible to change some setting in the device, or change the association groups or something to stop the BASIC messages?
I tried different settings with each of my six FGRM, but unfortunately I could not get the BASIC messages to stop.
We could update the database to stop BASIC messages being interpreted in this way (i.e. uncheck the BASIC tick box in the ML switch)- I guess the question is if the device is sending enough other messages that it’s still useful? I think from the logs I saw that it is, but…….
I checked all six FGRM222 devices in that 90 min debug log for any incoming
NODE XX: Received COMMAND_CLASS_BASIC...
messages and I only found reports for the shutter position like
NODE XX: Basic report, value = YY, it seems no other values are reported through BASIC command class.
Because the shutter position is also coming through the MULTILEVEL command class (correctly inverted if that option is checked) I think disabling the BASIC command class could be a valid option.
BUT: I don’t know if my interpretation of the debug log is correct 
Sounds good. If there’s always a multilevel command at the same time as the basic command then I think we can expect this to work ok. Can you update the database and I’ll do an update as soon as I can - might be Wednesday as I’m travelling, but if VPN works I’ll do it sooner.
Checked that too (now), within around half of a second after the BASIC report the MULTILEVEL report is coming in.
Done.
No need to rush, I still have a physical switch to move the shutters. Otherwise my wife would already have killed me
After working two days with the dev branch from 20170701 I can confirm that the database update (removing BASIC messages from SWITCH_MULTILEVEL command class) for the FGRM222 solved the issue.
Git issue updated.
Thx a lot.
Thanks for the feedback 
@chris
When will those changes be merged to main branch and available with official (and stable) openhab release?
I’m not sure when the next release is planned - I would guess it’s toward the end of the year, or early next year.
So we are looking at minimum Openhab 2.2
Does the snapshot release available now include the lamella support?
I might consider testing…
(and let´s hope that openhab 2.2 also has proper homekit support for blinds)
Yes - wasn’t that effectively your question? When is 2.2 going to be available? Or maybe I’ve misunderstood?
No - it’s in the development version only.
… was hoping for a bug-fix release in 2.1, which as lamella support…
any plans to merge the development release with snapshot release for 2.2?
I would like to get clarification on the inclusion of the development binding enabling lamella support to the 2.2 snapshot release of zwave binding, before moving to OH2.2 snapshots.
Also would the 2.1 dev binding work with OH2.2 snapshots.
Are there plans to support proprietary messages for FGRM-222 in OH2.2 binding?
At the moment I’ve not merged this while I look at some other changes. The reason is it’s a breaking change and I’d like to avoid multiple sets of breaking changes to avoid upsetting everyone…
Alright - seems like I am stuck with OH2.1, since you did not answer the question if the 2.1 dev build would work with OH2.2(snaphot).
Which is far from ideal, due to stability issues in OH2.1 and lack of homekit support for new accessories.
I guess I need to search for alternatives to OpenHab to handle my requirements 
I have used this combination for a couple of months without any problems.
As an alternative you may use the 2.2 dev zwave binding with 2.2 snapshot runtime: