Hi,
I am thinking about buying a couple of FGR-223 Roller shutters, however I have read that the device is not reporting the state of the roller shutter after movement. Does anyone have the device with a current firmware (>= 5.1) and can confirm that the device sends the current position after movement (manual or through openhab).
Thank you!
Did you get any information about this?
I’m about to buy FGR-223 FW 5.1 along with UZB1 Z-Wave USB key.
Are they working reliably with Raffstores
-venetian mode
-slats angle (Lamellenstellung)
-position feedback und movement through physical keys
-possibility to upgrade firmware of z-wave devices?
I have both FGR222 and FGR223. They both works for me in venetian mode and other modes. Slates angle works as desired. I had some troubles detecting a state after a movement but after disabling “Command Poll Period” - the work as a charm.
Though I don’t control them via assiociations nor s1/s2.
I have some FGR-223 FW 5.1 now, and I’m trying to get them working.
Openhab 2.5.3
org.openhab.binding.zwave-2.5.5-20200504.110626-5.jar
These are the problems I’m facing:
Those all sound like they could be device firmware issues. Without debug logs as outlined in the binding documentation we can only guess.
Here are the logs
or should i upload them?
I’m currently trying with node 3
(Sliders are working, edited my previous post)
Until our experts arrive, the log viewer may provide some insight.
https://www.cd-jackson.com/index.php/openhab/zwave-log-viewer
Thank you.
I forced a new calibration,
Now movement seems to work, even updating position and slats after using S1/S2.
But the issue with Parameter 150 is still there.
Hi,
how did you get the position update running? Did you just recalibrate?
I have 3 of these Roller Shutters 3 and all are not updating position after finishing the movement.
If I press stop, they update their position, so I was thinking I could send a stop from OH after movement is finished as a work around.
Very old thread to put a new post
Anyway, for slow moving things lengthen the command poll on the UI page for how long the moving takes (default is 1.5 seconds (1500). (A little trial and error required). Another option is to disable completely and let autoupdate do its thing. Your “stop” is a new command and the poll from that command is accurate because the blinds are no longer moving after 1.5 seconds.
Thanks for answering!
I tried increasing the command poll time, but 15s seems to be the maximum and this is not big enough for a blind to move completely.
If I disable it completely, how often does autoupdate poll the device?
And why does autoupdate not update if i leave command poll time at the 1500ms?
@rlkoshak is the autoupdate guru, but in generic terms an example that I believe is accurate;
Say you set to 100% from 0%. Autoupdate will set the state to 100%. However, the Zwave command poll will return whatever the state is @ 1.5 seconds (default) (say 45%) and override the autoupdate value. So you will have to disable the command poll completely to get the autoupdate value to “stick”.
If 15 seconds (I also wasn’t aware it was a max) is not long enough you could keep doing what you are doing or create a rule with a timer or expire (for how long you need) to “refresh” the item (or send the “stop” command)
The openHAB autoupdate service does not poll the device. The way it works is when you send a command to the Item, when autoupdate is enabled, it will predict what state the Item should become as a result of that command and update the Item based on that prediction.
This provides a bit more reactivity on the UI and such (e.g. when you flip a switch ON it changes to ON immediately). That’s why it’s enabled by default. However, this means that the state of the Item may not match the state of the device. Sometimes this is required because the device doesn’t report back. Sometimes this absolutely should be turned off because you end up with all sorts of weirdness as the Item updates by autoupdate and then the device reports different states (e.g. autoupdate predicts 100% but the device gradually ramps up to 100% so the Item jumps to 100% and then back to 10% and then 20% and so on).
Autoupdate has nothing to do with polling the device, polling periods, or anything like that.
By default autoupdate is pretty dumb and straight forward. However, individual bindings can override autoupdate to provide a more reasonable guess.
If the device reports back it is usually better to disable autoupdate instead of disabling the device polling. It’s always going to be more accurate if the device tells you what state it’s in than it is to guess.
Thanks for the more detailed answer. Sorry to ping you directly
My only quibble here is that in many cases it is not a guess. If the blinds (in this case) appear to be 100% by visual inspection everything is ok. I generally disable the command poll (to reduce the zwave traffic) for lights where I can see that they are ON, but that is a personal preference.
I believe to remember to have read years ago, that the Z-Wave binding deactivates autoupdate by default. At least when I trigger the blinds to go from 0% to 100%, the item is not set to 100% first and then set back by the command poll. So it is actually deactivated, but not by my in the item definition.
I have implemented a rule now that will trigger on the power consumption of the device and send a stop to update the position. Works fine.
The guess is usually accurate, especially if it’s implemented in the binding, but it’s still a guess. Given the Item’s current state and this command, the Item should become X. However, it’s a prediction. It’s independent from the end device. If the command never gets there the Item and the device’s states won’t match. If the end device encounters a problem, the Item and the device’s states won’t match. That’s what I mean by it’s a guess.