Fibaro FGR-223 Rollershutter 3 % status updates

Setup, Configuration and Use Installation
Tags: #<Tag:0x00007efec6da2110>
#1

Openhab 2.5.4 on raspbian
Fibaro rollershutter 3 frg-223 FW5.1
2.5.4 openHAB Add-ons :: Bundles :: ZWave Binding

10:12:55.601 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘shutter_bad_julie’ received command 100
10:12:55.628 [INFO ] [arthome.event.ItemStatePredictedEvent] - shutter_bad_julie predicted to become 100
10:12:55.643 [INFO ] [smarthome.event.ItemStateChangedEvent] - shutter_bad_julie changed from 0 to 100
10:12:57.341 [INFO ] [smarthome.event.ItemStateChangedEvent] - shutter_bad_julie changed from 100 to 8

So it only sends one status update after 1 sec … time to move from 0% to 8%, but it doesn’t send final/end status “changed from 8 to 100” when rollershutter is at 100% …

When real/physical buttons are used … no zwave status % update is send (?)

(Also have an old Fibaro Rollershutter 2 frg-222 and there both cases are ok)

Saw workarounds with REFRESH and so … but is there a real solution for his?
So that FRG-223 does send status itself?

#2
1 Like
#3

Tried that … but no improvement :

From 0 to 100

1 2:10:21.925 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘shutter_bad_julie’ received command 100
12:10:21.929 [INFO ] [arthome.event.ItemStatePredictedEvent] - shutter_bad_julie predicted to become 100
12:10:21.955 [INFO ] [smarthome.event.ItemStateChangedEvent] - shutter_bad_julie changed from 0 to 100
12:10:23.695 [INFO ] [smarthome.event.ItemStateChangedEvent] - shutter_bad_julie changed from 100 to 8

Rollershutter shutter_bad_julie “Julie Rolluik Bad [%d %%]” {channel=“zwave:device:e6a56118:node5:blinds_control1”}

#4

Try changing the poll time to a higher value.

#5

Full movement takes 20sec and max that can be set is 15sec poll
(this also doesn’t solve the physical switch status)

12:27:54.446 [INFO ] [arthome.event.ItemStatePredictedEvent] - shutter_bad_julie predicted to become 0
12:27:54.466 [INFO ] [smarthome.event.ItemStateChangedEvent] - shutter_bad_julie changed from 100 to 0
12:28:09.685 [INFO ] [smarthome.event.ItemStateChangedEvent] - shutter_bad_julie changed from 0 to 32

(15sec to reach 32%)

At end of the motion it should send status update (?)

#6

Yes.
I am out of ideas.
Please note that this device with firmware version 5.0 has general issues. You will need at least firmware version 5.1.

1 Like
#7

ok thx … and FW is at 5.1
Did set polling interval to 60sec for now as workaround.
Hope @chris will have a look

#8

Please can you provide a debug level log for this. What I can’t tell is if the updates are from polling, or if the updates are coming from autonomous association notifications (which should be the case, but possibly this isn’t happening).

1 Like
#9

Hi,

2020-05-13 12:13:41.787 [ome.event.ItemCommandEvent] - Item ‘shutter_julie_links’ received command 100
2020-05-13 12:13:41.798 [nt.ItemStatePredictedEvent] - shutter_julie_links predicted to become 100
2020-05-13 12:13:41.817 [vent.ItemStateChangedEvent] - shutter_julie_links changed from 0 to 100
2020-05-13 12:13:43.967 [vent.ItemStateChangedEvent] - shutter_julie_links changed from 100 to 7

a
a1188×628 158 KB
b
b1183×508 126 KB

When using the physical switches an update is send
12:28:14.663 [INFO ] [smarthome.event.ItemStateChangedEvent] - shutter_julie_links changed from 56 to 25

#10

Hi Peter,

have you ever found a working solution?

My FGR-233 (FW5.1) is working pretty good. When I send command UP the blinds are moving up full open (0), but then reported 41. On DOWN they are closing full(100), but reported 93. When I send 35 it moves to the position I want, but reports 52.

BTW at that position the blinds are fully closed, but opened as much as needed to let the air flow thru. The lowest blind has not moved in this position at all. I figured out 35% is the value to bring the blinds in this position by try and error.

Any hint how get the readings more reliable would be highly appreciated.

best regards
Jan

#11

Did you

#12

Hi sihui,

Thanks for the hint. I think that’s the right direction, but the maximum value for the poll delay is 15000 (=15 sec.). The blinds needs about 30 sec. for a full run.
In the log you can see the polling is done after 15 seconds and the blinds reported 58%, which is pretty ok for that time. 15 seconds later the motor stopped, but the state is not updated anymore.
Do you know, if this 15000 limit is from the device or from the thing definition and could be changed?

2020-11-29 15:09:36.258 [nt.ItemStatePredictedEvent] - SZRoll_BCtrl predicted to become UP
2020-11-29 15:09:36.321 [vent.ItemStateChangedEvent] - SZRoll_BCtrl changed from 58 to 0
2020-11-29 15:09:39.346 [vent.ItemStateChangedEvent] - SZRoll_Meter_w changed from 0 to 126.1
2020-11-29 15:09:51.495 [vent.ItemStateChangedEvent] - SZRoll_BCtrl changed from 0 to 58
2020-11-29 15:09:51.503 [GroupItemStateChangedEvent] - gBlinds changed from 0 to 58 through SZRoll_BCtrl
2020-11-29 15:10:06.746 [vent.ItemStateChangedEvent] - SZRoll_Meter_w changed from 126.1 to 0

Jan

#13

Neither - it’s defined in the binding. If it’s too short at 15 seconds, you probably should just disable it as it’s meant to provide a quick poll after the command and long delays were never intended.

2 Likes
#14

Hi Chris,
disabling the poll solved the issue. Thanks a lot for the advise

Jan

1 Like