Fibaro FGR222 Roller Shutter 2 in Venetian Blind mode - use of manual switch no updates sent to OH2.4

Opening a dedicated topic for an issue, which I am chasing since quite a while.

I am not getting any updates to OH (now uplifted to OH2.4 release build) when using the manual switches connected to my Fibaro FGR222 Roller Shutter 2 in Venetian Blind mode.
To be precise the position of the blinds is not updated both Lamella_Position and Shutter_Position are not updated in OH2.4 when raising, lowering or changing the tilt of the venetian blinds.

As stated in previous posts I do suspect the Manufacturer Proprietary messages, which is not (properly) decoded by OH2.4 to hold the missing information.


node13_manual.log (11.3 KB)

For reference the previous posts on this topic:

1 Like

@chris: Are you able to take a look?
@sihui: FYI
@steinerl: FYI

Can you please change to normal mode and see what is happen? I do not use lamella mode can only speak for normal mode and here all is working well.

Normal mode is working just fine - see https://community.openhab.org/t/solved-fibaro-rollershutter-222-no-updates-on-manual-switch/50349 - no need to validate in my set-up (again).

The reason for raising this ticket is that in the mode I do require to fully control my venetian blinds the use of the manual switches is not reported back to OH.
According to previous posts (linked above) the functionality was there in OH1.8.3 before, but ever since moving to OH2.x the functionality is missing.
Since I started with OH2.2 I am not able to confirm that in my set-up.

When I remember correctly @mstormi is using venetian blind mode …

yes but I have no switches so cannot comment here

@Chri46 I have the same observation with OH 2.4. I’ve tried number of configurations mentioned in above posts without success. I have 20 of FGR-222 used in Venetial blinds mode, and I’ve deliberately purchased FGR-222 instead of FGR-223 which is not working at all with OH. I’m happy to help debugging this is there is any idea how to move this forward.

@AdamS - to be honest I gave up on that long ago. I did provide multiple logs already and the only way to fix that is to update the zwave device definition in zwave binding.
If someone (@sihui or @chris) is either able to reverse engineer the Manufacturer Proprietary messages or get hold of the manufacturers definition, there is a chance to have that issue fixed.
Without that this functionality will never be implemented in OH.

@sihui or @chris: is there anything we can do to help getting this implemented?

As I think is mentioned above - someone would need to reverse engineer the protocol. The manufacturer specific clusters are not documented, and I think I implemented some of this a while ago, but without the documentation it’s not very easy for me to do anything.

If someone can provide the documentation, either from the manufacturer, or by reverse engineering it, then we can look at it.

Hello all

I’m sorry to revive this topic, but it fits exactly to my problem (fgr222 in venetian blinds mode not getting updated when controlled by physical buttons), so no need to create a new one.
Also, I can confirm that the update is working for my roller shutters (without lamellas) if I use the zwave command, the proper associations and the proper channel i.e. Blinds Control, as opposed to Shutter position.

I had a quick look at the source code of the zwave binding and as far as I understand (my Java skills are not quite up to date - I’m a .Net developer), there seems to be code which should already be capable of parsing those manufacturer proprietary report messages:
CommandClassManufacturerProprietaryFibaroFgrm222V1.handleFgrm222Report(byte[] payload) looks like it would be able to parse the message, which is very simple:
01 0E 00 04 00 0B 08 91 01 0F 26 03 03 16 63 3A
third-to-last byte contains the shutter position, the second-to-last byte contains the lamella position (the last byte probably is a checksum, I assume).

The only problem I see in the code is that it looks to me like this function is never actually called: the other functions in this class are called by ZWaveManufacturerProprietaryConverter, but this one is not referenced anywhere in the code.
Another thing which struck me as odd is the class ZWaveManufacturerProprietaryCommandClass which has a method handleManufacturerSpecificReport(...) but it looks kind of incomplete:

@ZWaveResponseHandler(id = 0, name = "DEFAULT_HANDLER")
public void handleManufacturerSpecificReport(ZWaveCommandClassPayload payload, int endpoint) {
    // If we don't have an implementation specified then just return
    if (classType == null) {
        return;
    }
}

To me that looks like there should be some code after the ‘if’ block which would actually do something…

Maybe you could take a quick look at it and tell me if I’m completely wrong?

Best regards from Switzerland!
Patrik

Hello

Well, never mind my previous post - I’ve now changed the code to get it to work (tested - both lamella position and shutter position are now updated even when operated by the manual controls) and will create a pull request for it.

I hope it will find it’s way into the main branch sometime…

Kind regards
Patrik

1 Like

Hi Patrik,

Thanks a million for fixing this issue, I gave up long ago on this.
Eagerly awaiting the fix in main branch.
@chris: please merge the pull request asap and let us know with release has this fix.

Hi Christian

Let’s not get ahead of ourselves - this fix probably needs a bit more work before it can be merged into the main branch…
In the meantime, I’ve opened an issue where you can track the progress https://github.com/openhab/org.openhab.binding.zwave/issues/1334

Best regards
Patrik

Years of no progress on this issue without any update I gave up on Openhab´s Zwave implementation.
After receiving a valuable tip to look into Zwave JS all my issues are resolved.
Zwave JS UI is supporting all the proprietary commands required to achieve full control for Venetian Blinds, regardless if controlled via physical switches or via Zwave.
The move to Zwave JS UI was completed within a couple of hours, making good use of my existing mqtt setup.