Interesting…
I’m just wanted to create a rule like that with the conditional filter to execute for “each” member of the group when the item “switch_automode” is true for that blind…
I guess your rule can be modified for that 
I guess you stumbled over this https://github.com/OpenZWave/open-zwave/commit/9270fd92e7b666329a72aa5214c0105b12474ac8#diff-93a42c4304f18d0325fe0bf4f09bd382 before.
Not a developer myself, but I reckon it might be useful.
In case is this of any use, adding support for status feedback on venetian blinds tilt and position (blinds_shutter, blinds_lamella) would be greatly appreciated.
As far as I’m aware, that is what was implemented a long time ago. I just double checked the code, and the reports are being handled, so either there is a bug, or the device is not sending the reports.
I don’t have these devices, so can’t test - without something to work with, it’s difficult to comment. If you provide a debug log I can take a look.
bad news - no feedback whatsoever from FGR-222 when using HW switches 
Zwave binding used:
223 │ Active │ 80 │ 2.4.0.201808210909 │ ZWave Binding
node13: network_e117085e__node_13.xml (16.9 KB)
logfile when blinds are raised via openhab: openhab lower-raise.xml (38.6 KB)
logfile when blinds raised by HW switches: switch lower-raise.xml (198.5 KB)
Additionally the HABadmin view of node 13:
Open for any advise to change parameters.
Unfortunately I’m not familiar with these devices. Reports are normally configured through associations - I don’t know if there’s another association group specifically for these reports, or if they are sent through the standard features like the lifeline. Unless the device sends something though, the binding can’t update itself.
Sorry - I know that’s not so useful, but I’m not sure what else the binding can do to resolve this - I would just suggest to update all associations to point them all at the controller and see if one of them starts the reporting.
with changing the associations groups to:
I am receiving updates from FGR-222 when using the HW switches:
node13_associations_set_up-down.xml (17.3 KB)
Additionally I changed “Self-Measurement” to active, to see which impact that setting has - unfortunately none
node13_associations_set_self_measure_ON_down-up.xml (20.5 KB)
I guess the updates on shutter position and lamella tilt are hidden in the „MANUFACTURER_PROPRIETARY“ messages.
@chris
Did you manage to identify a bug as suggested earlier?
FGR-222 are sending updates to controller now, but the “MANUFACTURER_PROPRIETARY” are not handled, which they should if I did understood your post https://community.openhab.org/t/fibaro-roller-shutter-fgrm-222-with-venetian-blinds-lamellas-position/9396/239 correctly.
Sorry - I didn’t see this before.
The system should normally process the manufacturer proprietary command responses, but this log shows it’s not working. I thought you said earlier that you were able to send commands from OH to set the position, or am I wrong and in fact it is not working? If it sends, then it should also receive as the command class should be added, but please let me know if sending is working so I can have a look.
from OH -> FGR222 is not an issue at all.
I am able to raise/lower/tilt the venetian blinds just fine.
The issue I am reporting like @steinerl before
post from Apr 3
I am after the Fibaro proprietary reports, which FGR-222 is obviously sending when HW switches are used:
The logs provide do show MANUFACTURER_PROPRIETARY sent from FGR-222 -> OH.
It’s very strange then that we have the error that the command class is not found when this is received. I’ll have to have a look at this some more, but unfortunately it probably won’t be until next week unless I can sneak in a few minutes on holiday.
thanks a lot.
Just let me know if you need any traces, logs
i try to send a command to the venetian blinds only if a change of the position is required.
var TargetPos = 98
var CmpPos = TargetPos - 3
if(EgWz_JalousieLinks_Shutter.state < CmpPos || EgWz_JalousieLinks_Shutter.state == NULL) EgWz_JalousieLinks_Shutter.sendCommand(TargetPos)
if(EgWz_JalousieLinks_Lamella.state < 80 || EgWz_JalousieLinks_Lamella.state == NULL) EgWz_JalousieLinks_Lamella.sendCommand(80)
but this rule sometimes work, but not at every call. sometimes the sendCommand will be called and then the state variable are changed to the new values, but the blind doesn’t move.
Does anyone have any idea what that could be?
Is it probably not allowed to read the state and call a sendcommand at the same line with the same item?
add some logging to figure out why rule is not executed.
something like:
var TargetPos = 98
var CmpPos = TargetPos - 3
if(EgWz_JalousieLinks_Shutter.state < CmpPos || EgWz_JalousieLinks_Shutter.state == NULL)
{
logInfo ("Debug", "EgWz_JalousieLinks_Shutter " + EgWz_JalousieLinks_Shutter.state)
logInfo ("Debug", "CmpPos " + CmpPos)
EgWz_JalousieLinks_Shutter.sendCommand(TargetPos)
}
if(EgWz_JalousieLinks_Lamella.state < 80 || EgWz_JalousieLinks_Lamella.state == NULL)
{
logInfo ("Debug", "EgWz_JalousieLinks_Lamella " + EgWz_JalousieLinks_Lamella.state)
EgWz_JalousieLinks_Lamella.sendCommand(80)
}
For improved readability I am using following syntax for IF all the time - even if only one command is executed.
if ( value == true )
{
execute stuff
}
else
{
execute other stuff
}
in an entry above i mentioned that i have problems if i only control the shutter when the target position is not equal to the actual position.
but now I have noticed that the problem also exists when I always send the command.
rule "Jalousien Sonnenschutz ein"
when
Item Sonnenschutz changed from OFF to ON
then
EgWz_JalousieSofa_Control.sendCommand(99) // Node 11
EgWz_JalousieSofa_Lamella.sendCommand(60) // Node 11
Thread::sleep(50)
EgWz_JalousieLinks_Control.sendCommand(98) // Node 13
EgWz_JalousieLinks_Lamella.sendCommand(60) // Node 13
Thread::sleep(50)
OgSm_JalousieFenster_Control.sendCommand(98) // Node 4
OgSm_JalousieFenster_Lamella.sendCommand(60) // Node 4
Thread::sleep(50)
OgSm_JalousieTuere_Control.sendCommand(80) // Node 5
OgSm_JalousieTuere_Lamella.sendCommand(60) // Node 5
Thread::sleep(50)
OgSr_JalousieFenster_Control.sendCommand(98) // Node 7
OgSr_JalousieFenster_Lamella.sendCommand(60) // Node 7
Thread::sleep(50)
OgSr_JalousieTuere_Control.sendCommand(80) // Node 8
OgSr_JalousieTuere_Lamella.sendCommand(60) // Node 8
Thread::sleep(50)
DgZr_Jalousie_Control.sendCommand(98) // Node 15
DgZr_Jalousie_Lamella.sendCommand(60) // Node 15
end
According to me, the code of this rule should fit. Unfortunately this rule does not work stable. The shutters Node 5, Node 7 and Node 15 partly do not close.
once only Node 5, once Node 5 and Node 7, …
in case of a mistake, the shutters only make a very short movement and stop again immediately.
Z-Wave Log Node 5 if it works
Z-Wave Log Node 5 if it does not work
Does anyone have any experience with what this could be and how I can solve the problem? I am at the end of my rope and have no more ideas.
Thank you very much for your tips.
Openhab Version: 2.3.0 Release Build
Z-Wave Binding: Development Version 2.4.0 (2018-09-08)
Never seen anything like that and I am addressing multiple FGR-222 at the same time, both individually as well as in groups, but mainly in groups with my latest version - even if there is just one member in the group.
(readability).
gDownStairsBlinds.members.forEach[ShutterPosition | ShutterPosition.sendCommand(BlindsClosed)]
gDownStairsBlindsLam.members.forEach[LamellaPosition | LamellaPosition.sendCommand(blindLamella0)]
gWZrechtsBlinds.members.forEach[ShutterPosition | ShutterPosition.sendCommand(BlindsClosed)]
gWZrechtsBlindsLam.members.forEach[LamellaPosition | LamellaPosition.sendCommand(blindLamella0)]
logInfo ("StatusUpdate", "Closing DownStairsBlinds for night")
I am not using and actual advising against:
Thread::sleep(50)
There is no need to artificially delay the execution - zwave stack is perfectly able to handle all the commands sent sequentially.
any change to look into and share an update on:
1 Like
Sorry - I can’t find the logs that show the received messages. This thread is full of links, that link to other links, and then to other links, before linking back to a link I already linked to… 
Can you provide a clean log showing the issue please.
When you get a chance, please provide a log with the latest binding and I’ll take a look.
Thanks.