@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.
Hi @chris
Upgraded to latest snapshot:
openhab> bundle:list |grep -i zwave
223 │ Active │ 80 │ 2.4.0.201809282128 │ ZWave Binding
Same behavior - using HW switches in combination with lamella support is not updating OH.
Attached are 3 log files - naming describes the use-case.
node13_tilt_viaHWswitch.xml (5.6 KB)
node13_up_down_viaOpenHab.xml (89.0 KB)
node13_up_down_viaHWswitch.xml (22.2 KB)
Also attached the node.xml:
network_e117085e__node_13.xml (17.0 KB)
In all 3 log files the MANUFACTURER_PROPRIETARY message seems to hold the response back to OH, but is not decoded properly:
Thanks - I’ll take a look at this tomorrow. Hopefully it won’t be hard to find, but I’ll need to write some tests to see why the CC isn’t being found.
Just some feedback on this - I know what the issue is at least. I need to have a bit more of a think about how to implement this so it will be a few days at least…
any progress?
Just let me know if you need some to test your latest build
Hello,
I have been trying for several days to activate the protection mode of my Fibaro FGR222. Unfortunately I can not get it.
Here is my procedure:
item:
sitemap:
Unfortunately, this does not work and I’m just too inexperienced.
My daughter has discovered the blinds switch, so I would like to lock them locally.
I hope you could help me.