Fibaro Roller Shutter FGRM-222 with Venetian Blinds - Lamellas Position

mstormi · August 10, 2018, 10:46am

There’s differences in firmware, too

shorty707 · August 10, 2018, 10:51am

that version (current db released) has no meter_watts1 … so I assumed you had another revision … but maybe also just an old xml when you have that device quite a while

@mstormi mine is 25.25

T.H.S · August 10, 2018, 10:56am

shame on me - you´re right. I have the same device but different revision.

mstormi · August 10, 2018, 11:00am

I need to use blinds_control instead of blinds_shutter to position the shutter.
Yeah you need to play with the available options…

sihui · August 11, 2018, 6:04am

Just a guess: in gate mode, if you want to open the gate but not close it automatically.

Maybe it’s used for the Fibaro command classes, no idea. At some stage during initialization the device did report this channel, so it may be useful for something.

Kellermeister · August 19, 2018, 8:06pm

Hi community
I control my venetian blind with the development version of z-wave with Fibaro FGR222.
I would close the venetian blind and tilt 60%. i don’t now what is the best code for this requirement in the rule.
This is my actually code … i am not happy with this, but i have no idea to improve this.

...
then
   EgWz_JalousieSofa_Shutter.sendCommand(100)
   Thread::sleep(10000)
   EgWz_JalousieSofa_Lamella.sendCommand(60)
end

have anyone a better solution to control the venetian blind with tilt 60%?

mstormi · August 19, 2018, 10:07pm

Omit the sleep(), you don’t need it. You can also set tilt first but that should not make a difference.
FWIW, I’m using the blinds_control channel, not blinds_shutter (and blinds_lamella for tilt).

Chri46 · August 20, 2018, 6:29am

Using shutter & lamella here - no need for sleep()
I am using the same sequence close and then tilt.

e.g. for all venetian blinds upstairs (ShutterPosition in group UpStairsBlinds and LamellaPosition in group gUpStairsBlindsLam)

gUpStairsBlinds.members.forEach[ShutterPosition | ShutterPosition.sendCommand(BlindsClosed)]
gUpStairsBlindsLam.members.forEach[LamellaPosition | LamellaPosition.sendCommand(blindLamella20)]

I was using blinds_control (tried with both UP/DOWN and 0/100) before, but received interesting values reported by FGR-222, which varied over time: https://community.openhab.org/t/z-wave-binding-fibaro-fgr-222-spontaneous-change-of-blindscontrol-state/33860/9 and Shading automation
Which made decision criteria for rules rather hard to predict.
After switching to ShutterPosition no issues whatsoever.

mstormi · August 20, 2018, 7:39am

Note that blinds_shutter and blinds_lamella are of Dimmer type while blinds_control is of Rollershutter type.

Kellermeister · August 20, 2018, 5:35pm

Thanks for the answer. but the following sequence does not work at my system. the shutter goes down and the lamella remain completely closed.

    EgWz_JalousieLinks_Control.sendCommand(100)
    EgWz_JalousieLinks_Lamella.sendCommand(60)

also with item shutter, it doesn’t work.

but I found something. Can it be that the value 100 for position (shutter and control) is out of permitted range? if I try with 99 it works. the following sequence works fine.

    EgWz_JalousieLinks_Control.sendCommand(99)
    EgWz_JalousieLinks_Lamella.sendCommand(60)

does your system works with value 100?

mstormi · August 20, 2018, 5:39pm

ZWave allows for 0-99 only, so you used to send an out of spec value, that’s why. Or send “DOWN”.

Kellermeister · August 20, 2018, 5:44pm

Ok, thanks, that was the readon of my problem

Kellermeister · August 20, 2018, 7:09pm

why do you programm the sequence with .members.forEach ? that’s interesting.

gUpStairsBlinds.members.forEach[ShutterPosition | ShutterPosition.sendCommand(BlindsClosed)]
gUpStairsBlindsLam.members.forEach[LamellaPosition | LamellaPosition.sendCommand(blindLamella20)]

what is better compared to controlling the group via command “sendCommand” directly ?

    gUpStairsBlinds.sendCommand(BlindsClosed)
    gUpStairsBlindsLam.sendCommand(blindLamella20)

is there a reason for this type of programming?

Chri46 · August 21, 2018, 6:36am

laziness mainly

I found it easier to read and edit to use .members.filter[…] and .members.forEach[…]

I am using the rule (example) below to determine if certain actions are required to be executed by FGR222s.

if ((gUpStairsBlinds.members.filter[ShutterPosition| ShutterPosition.state == BlindsClosed].size == 4) && gUpStairsBlindsLam.members.filter[LamellaPosition| LamellaPosition.state == blindLamella20].size == 4)
   {
    logInfo ("StatusUpdate", "LamPos UpStairs NoAction " + blindLamella20 + " %")
   }
   else
   {
     gUpStairsBlinds.members.forEach[ShutterPosition | ShutterPosition.sendCommand(BlindsClosed)]
     gUpStairsBlindsLam.members.forEach[LamellaPosition | LamellaPosition.sendCommand(blindLamella20)]
     logInfo ("StatusUpdate", "Blinds UpStairs Closed, LamPos " + blindLamella20 + " %")
    }
   .......

shorty707 · August 21, 2018, 10:57am

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

Chri46 · August 23, 2018, 4:11pm

@chris

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.

chris · August 23, 2018, 4:20pm

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.

Chri46 · August 24, 2018, 6:37pm

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.

chris · August 24, 2018, 8:14pm

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.