Jump to content

Welcome to Smart Home Forum by FIBARO

Dear Guest,

 

as you can notice parts of Smart Home Forum by FIBARO is not available for you. You have to register in order to view all content and post in our community. Don't worry! Registration is a simple free process that requires minimal information for you to sign up. Become a part of of Smart Home Forum by FIBARO by creating an account.

 

As a member you can:

  •     Start new topics and reply to others
  •     Follow topics and users to get email updates
  •     Get your own profile page and make new friends
  •     Send personal messages
  •     ... and learn a lot about our system!

 

Regards,

Smart Home Forum by FIBARO Team


  • 4

FGR-223 and percent position feed-back


Question

Posted

Dear Support,

 

  I instal Fibaro FGR-223 new Roller Shutter 3 on my Domoticz system. I hd some painfull to add new xml OpenZWave but now is working well with all options. But I see a problem about percent opening status. Exemple :

 

  Roller is close at 7% and I ask to go level 50% ...that work more or less fine because

  1) Immediatly percent level gauge look 50% (instead 7%) on my Domoticz => Normal
  2) Roller move from position 7% to 50% => Normal
  3) But... percent level gauge on DOmoticz show again 7% (but roller is positionned on 50% like action was asked) => It's not normal !

 

  My suspicion it's than Fibaro device fgr-223 send after the starting move the old position only (and never new percent position level) ... it's possible ? How to solve it ?

Recommended Posts

  • 1
Posted
1 hour ago, bardi said:

Is there a more fundamental solution to this problem? A bug-fix on the Open ZWave / Hass.io roadmap?

Due to lack of time and resources, I haven't done a decent analysis yet and AFAIK nobody has done this. I can say this with some confidence because I recently started to work on OZW and I also contacted HASS maintainers. At the moment, I can say two important things about "getting this fixed". When I write this, there is no active maintainer of Z-Wave component, and OZW very recently moved from version 1.4 to 1.6 which is unfortunately not an easy upgrade (but worth it because of the large numbers of improvements. The move to 1.6 does not affect HASS because it is running on a fork of OZW. As you probably can imagine, people are now debating on how to move forward.

 

Is this is hass or ozw issue? I can say the device works properly on a Fibaro HC... What is a bit special about is, last time I checked it does report motion while the blinds are moving (checked with Zniffer on a device with older firmware) and I am reasonable sure that OZW handles this correctly. Some dimmers do this as well and I see people report a similar issue: when you set dimming level to eg 0 then hass reports some low value instead of 0. This is similar to the positioning problem seen on the FGR-223. For dimmers there is an option in the hass config to do a single update request after X seconds. I have the details somewhere, haven't used it myself yet. For the FGR-223, an automation triggering on a delay after a change or triggering on power == 0 sounds like a possible workaround. I am too new to hass and I'd refer you to the solutions posted above. Setting polling to 10 seconds will very likely cause Z-Wave issues but that depends on the size of your network

 

That said... I am not 100% sure but I would say the device is OK, but because it is new it does "unexpected things" it causes trouble on some gateways.

 

BTW nothing wrong about debating it here, after all it is a Fibaro module, but you might attract more attention if you discuss it on eg the Home Assistant forum:

 

Please login or register to see this link.

 

Or discord chat, check #zwave channel:

 

Please login or register to see this link.

 

Or if you are convinced that it is an OpenZWave issue, comment on OZW github. BTW there is an older issue but I don't think reopening is a good idea, because since then OZW has switched from 1.4 to 1.6...

 

Please login or register to see this link.

 

There are quite a few layers of software between the device and what you see in your browser, so although this is open-source software it is not very easy to see what is going on, let alone write a proper fix.

  • 0
  • Inquirer
  • Posted

    Nobody from Fibaro can confirm me this problem ?

    Best regards

    • 0
    Posted
    On 12/29/2018 at 10:57 AM, Funmsa said:

    Roller is close at 7% and I ask to go level 50% ...that work more or less fine because

      1) Immediatly percent level gauge look 50% (instead 7%) on my Domoticz => Normal

    Try the following:

    1. Set the blind to 10% using the physical button. Check if the gateway reports the status of 10%.

    After that

    2. Set the blind to 50% using the physical button. Check if the gateway reports the status of 50%

     

    On 12/29/2018 at 10:57 AM, Funmsa said:

    percent level gauge on DOmoticz show again 7% (but roller is positionned on 50% like action was asked) => It's not normal !

    Most probably the Domoticz does not receive the report after the blind stopped and it reverse to the initial (last) report. Taking a look at the logs from your gateway would be helpful.

     

    Did you contact our Support regarding your findings?

     

     

    • 0
    Posted

    I use FGR223 with openHAB 2.4 and i have the same experience like Funmsa said.

    After sending positioning command the module reports immediately a useless status update. When the blind finally reaches the target position, the expected ststus update fail to appear. The same effect if the blind is moved manually by the S1/S2 Switch. So it is impossible to read the current position.

    • 0
    Posted

    So you both have open-zwave as underlying Z-Wave engine...

     

    When I tested this device, if my memory serves me well, the FGR-223 sends several position updates while the motor is on. So (theoretically) the slider should (could) move from old to new setting while the blinds are moving. I have to check that and unfortunately we do not have the same  module firmware (mine is older). But let's assume it still does that. Maybe open-zwave or your automation engine does not handle this? Pure speculation but I might be able to test that next week.

     

    Here is  an idea: can you enable pollino (eg every 60s) and see if the value is corrected after a polling cycle?

     

    You can also post the relevant part of your OZW_log here as a file and I'll have a look at it. I am rather new to OpenZwave but I can try!

    • 0
    Posted

    Thank you for your answer, but i don't know how to enable "pollino" or to provide a OZW_log. I guess open-zwave is embedded in openHAB but these tools are not available.
    In the event.log of openHAB are no entries if the S1/S2 switch is pressed, but if i do

    sudo cat /dev/ttyAMA0

    then i get a lot of data for the S1/S2 event. These events seems to be swallowed somewhere ...

     

    • 0
    Posted

    Unfortunately I don't know much about openhab... I did find this page and it indeed suggest Z-Wave debugging is part of openhab. 

    Please login or register to see this link.

     - I am not sure if I would make sense of it - but if you can get some data I'll have a look at it.

     

    FWIW Random openhab google result on "polling":

     

    Please login or register to see this link.

     

    There's a screenshot, it suggests "Polling Period" is under Device settings.

     

    24 minutes ago, HABuser said:

    sudo cat /dev/ttyAMA0

    Interesting test! The Z-Wave dongle follows a specific serial protocol (I know how to decode it), and it will repeat messages several times (4 times of I am correct) because you are not answering with the correct status. On the other hand, if you see a lot off messages while the motor is "on" then that indeed might confirm what I said about "frequent position updates".

    • 0
    Posted (edited)
    On 12/29/2018 at 10:57 AM, Funmsa said:

    Roller is close at 7% and I ask to go level 50% ...that work more or less fine because

      1) Immediatly percent level gauge look 50% (instead 7%) on my Domoticz => Normal
      2) Roller move from position 7% to 50% => Normal
      3) But... percent level gauge on DOmoticz show again 7% (but roller is positionned on 50% like action was asked) => It's not normal !

     

    I use Fgr-223 with Home Assistant (hassio, open zwave) and i have the same problem.

     

    Quote

     

    Try the following:

    1. Set the blind to 10% using the physical button. Check if the gateway reports the status of 10%.

    After that

    2. Set the blind to 50% using the physical button. Check if the gateway reports the status of 50% 

     

     

    Work like a charm

     

    Quote

    Here is  an idea: can you enable pollino (eg every 60s) and see if the value is corrected after a polling cycle?

     

    If I have set polling intensity : 1 or 10 or 15 or 20 or 60 the value is corrected from 30 to 40 seconds (random) after roller is stoped. Tested in position 100% to 50% and 50% to 100%.

    Edited by bobsilesia
    • 0
    Posted (edited)
    1 hour ago, bobsilesia said:

    If I have set polling intensity : 1 or 10 or 15 or 20 or 60 the value is corrected from 30 to 40 seconds (random) after roller is stoped. Tested in position 100% to 50% and 50% to 100%.

    Thank you for testing and reporting... I have had a quick look at open-zwave and I am still not 100% sure but I think it gets confused by a device, which changes the % level "quite fast". When you use a dimmer and set for example 25 then although the level might ramp up, all devices I know immediately say "25". The FGR-223 changes the level, while the blind is moving, and I see in OZW log files of dimmers (sorry, cannot test with FGR right now!) that open-zwave re-checks the value and probably gets 2 different readings while the blind is moving. Then after those 30-40 seconds a "poll" happens and then open-zwave does get the correct and final position. I have made no attempts yet to fully diagnose this... or fix it... If I find the time I might try to find out more about this. AFAIK there is no parameter to change this behaviour. Sorry for so much speculation, I have misplaced one of my FGR modules and the other one is in use and I cannot test right now :(

    Edited by petergebruers
    • Thanks 1
    • 0
    Posted (edited)
    18 hours ago, petergebruers said:

    If I find the time I might try to find out more about this.

     

    Thanks. I will add that poling with the value 0 ( of course does not indicate the current position.

    And if I`ll find time, I`ll connect my fourth (not yet used) fgr223 to Smartthings Hub.

    There is a new device handler for fgr223

     

    Once again, thank you

     

    edit:

    Value 1 is too short but 5 is OK.

    Sometimes the waiting time for reading the position is shorter than 30s and sometimes longer than 40s.

    Most often 30-40 seconds.

     

    Please login or register to see this link.

    edit:

     

    After all tests (3 x fgr223) something happened and for a correct reading you have to wait about 10 minutes. :(

     

    Edited by bobsilesia
    • 0
    Posted (edited)

    I've run on exactly same issue running Home Assistant, couldn't figure out why is that happening so I've came with a decent band-aid solution.

     

    So to anyone still struggling and not giving up on those modules:

     

    Rather than polling on interval ( which is things we rather avoid and don't want in our networks ) I've set an automation trigger on entity's power change to 0 - so exactly after the motor has stopped to force z-wave entity refresh on level value ( in home-assistant: zwave.refresh_entity ). The downside? When you use physical switch, you will be polling that entity unnecessary ( only when you stop the motor ), but you won't be spamming your network when shutters are idle.

     

    So as a result I'm having a level position update within few seconds of shutter finishing the job.

    Edited by xTr
    • Thanks 2
    • 0
    Posted

    The topic has been moved from "

    Please login or register to see this link.

    " to "

    Please login or register to see this link.

    ".

     

    Temat został przeniesiony z "

    Please login or register to see this link.

    " do "

    Please login or register to see this link.

    ".

    • 0
    Posted (edited)
    On 3/16/2019 at 7:40 AM, xTr said:

    I've run on exactly same issue running Home Assistant, couldn't figure out why is that happening so I've came with a decent band-aid solution.

     

    So to anyone still struggling and not giving up on those modules:

     

    Rather than polling on interval ( which is things we rather avoid and don't want in our networks ) I've set an automation trigger on entity's power change to 0 - so exactly after the motor has stopped to force z-wave entity refresh on level value ( in home-assistant: zwave.refresh_entity ). The downside? When you use physical switch, you will be polling that entity unnecessary ( only when you stop the motor ), but you won't be spamming your network when shutters are idle.

     

    So as a result I'm having a level position update within few seconds of shutter finishing the job.

     

    Can you share HA automation for this?

    I need to buy some roller shutters, but don’t want to buy an old model...

     

    Also, is this Roller shutter 3 firmware issue or open zwave issue?

    Edited by nicko3
    • 0
    Posted
    Godzinę temu, nicko3 napisał:

     

    Can you share HA automation for this?

    I need to buy some roller shutters, but don’t want to buy an old model...

     

    Also, is this Roller shutter 3 firmware issue or open zwave issue?

     

    I'm using Node-Red for automations. I'm creating one instance of this per shutter.

     

    Heres the flow:

    Please login or register to see this code.

     

    According to Open-Z-Wave issue:

    Please login or register to see this link.

     

    It's a software ( HomeAssistant ) issue where it should be possible to set SetChangeVerified to true on level value id.

    But afaik there is no such ability atm in HA so I can't test whatever it would fix the issue.

     

     

    • 0
    Posted (edited)
    W dniu 16.03.2019 o 07:40, xTr napisał:

    I've run on exactly same issue running Home Assistant, couldn't figure out why is that happening so I've came with a decent band-aid solution.

     

    So to anyone still struggling and not giving up on those modules:

     

    Rather than polling on interval ( which is things we rather avoid and don't want in our networks ) I've set an automation trigger on entity's power change to 0 - so exactly after the motor has stopped to force z-wave entity refresh on level value ( in home-assistant: zwave.refresh_entity ). The downside? When you use physical switch, you will be polling that entity unnecessary ( only when you stop the motor ), but you won't be spamming your network when shutters are idle.

     

    So as a result I'm having a level position update within few seconds of shutter finishing the job.

    Hi,

    would it look like this?

    Which entity needs to be refreshed?

    Please login or register to see this code.

    I can see levels in HA, however values aren't proportinal to actual blinds position.

     

    Regards,

    majstermod

    Edited by majstermod
    • 0
    Posted
    2 godziny temu, majstermod napisał:

    Hi,

    would it look like this?

    Which entity needs to be refreshed?

    Please login or register to see this code.

    I can see levels in HA, however values aren't proportinal to actual blinds position.

     

    Regards,

    majstermod

     

    Yeah, it should be triggered on power = 0 and refresh on level.

    That's how it works for me, but like I said I'm using Node-Red for automations.

    Make sure the entity is set to report power tho - iirc it was by default for me.

    • 0
    Posted

    I have the same problem. Using the Roller Shutter 3 in Home Assistant with an old firmware. However, I can't even get it to update the position by polling or by using zwave.refresh_entity. Does the refresh work for anybody else than @xTr?

    • 0
    Posted

    Hello,

     

    I tested the same automation as mentioned by 

    Please login or register to see this link.

     

    Please login or register to see this link.

    Here are my findings:

    1. Position / level is correctly presented when the position is changed manually via the pushbuttons
    2. Changing the position via Hass.io UI controls is not reliable. When I set the roller shutter to fully open or fully closed (by clicking the up/down arrow in the UI) the position is sometimes not updated after the roller shutter reached it's final position (and the motor has stopped).

    I'm testing this second case, because I want to be able to change the position with my Google Home (via Hass.io)...

     

    So now my current 'working' setup is without the suggested automation, but is polling the "cover.fibaro_system_fgrm223_roller_shutter_controller_3_level" with a 'Polling intensity' setting of 10s. I know this is a sub-optimal 'solution'...

     

    Are there others which can confirm these findings?

    Is there a more fundamental solution to this problem? A bug-fix on the Open ZWave / Hass.io roadmap?

     

    Best regards,

    Bart

    • 0
    Posted

    Thank you for your elaborate response / status update. It's these kind of insights I was looking for...

     

    Regarding " For the FGR-223, an automation triggering on a delay after a change or triggering on power == 0 sounds like a possible workaround.": I tried a 2s delay earlier, but this didn't make it more reliable. I agree that a larger delay might at some point become a quite reliable workaround, even though it's not a fundamental fix.

     

    I have, according to your recommendations, posted my findings as well on the Home Assistant forum...

    • 0
    Posted (edited)

    After all, I bought roller shutter with firmware 5.0.

    It calibrated correctly, just won’t report position back to home assistant.

    And also won’t react on succesive commands. You just need to wait about 10 seconds.

     

    I “fixed” position with proposed automation, and everything works ok.

    Edited by nicko3
    • Like 1

    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.

    Guest
    Answer this question...

    ×   Pasted as rich text.   Paste as plain text instead

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.

    ×
    ×
    • Create New...