-
-
Notifications
You must be signed in to change notification settings - Fork 916
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fibaro FGR 223 wrong percent report #1705
Comments
As a roller shutter the same situation. It does not show the current status just one step back of the current one. If you have 0 on the scale and you set 75 blinds go to 75 and the indicator returns to 0. You set the 0 indicator returns to 75 etc. |
Got few FGR223 installed as well. Stuck with same issues, only reports previous level when set to next level ( probably because it instantly receives update with "current" level. Trying to pinpoint, hardware, OZW or software issue. I am not really sure which one is at fault. OZW Log reports some decimal issues with value id during shutter work, maybe related?
|
Is there any news regarding this issue? |
The log messages you posted are a application problem. (The application is trying to retrieve the value with the wrong type). |
So I did a bit more testing, according to fibaro it should be updating dynamically during the shutter work, I did not see anyone using Fibaro Home Center to be reporting this kind of issue so I suspect the issue is in software. The power usage updates perfectly on time, but level/percent does not. The controller receives the message from the module when shutter is about to start working with a proper percent level of current position, but is never updated afterwards - hence issue like you set shutters to 50% from 100% then module sends value 100% when it's about to start working, reaches 50% level and you only get power report but no level report. So from here if you send level of 25%, you will receive then 50% ( correct ) on beginning, shutter moves to 25% and situation repeats - no updates, level is stuck on 50% until you poll it. Oddly enough when you call SwitchMultilevelCmd_StopLevelChange, it also updates the level properly after few seconds. Here is the log from the moment of controller set level message to the end of shutter module work. Would be really nice to get this working properly as having to poll these values currently is adding unncessary bottleneck to the network. |
Enable SetChangeVerified on the ValueID in question (the level) or poll after changing the position. That’s the only way todo it currently. |
I've changed verify_changes to true of ValueID level in zwcfg file ( would that be that? couldn't find anything to access that via homeassistant ). But sadly no luck here either, value still doesn't update. Decided to use automation trigger hooked to power change to 0 ( aka motor finished working ) to force refresh level entity via controller. I guess that's gonna be the best band-aid for the issue for me for now and for anyone struggling with same issue. The side effect of this is using physical switch to move/stop the motor will also trigger that refresh, even tho that one seems to worked fine. Better than polling on interval, and updates the value within few seconds only. |
You need to change it via the API. If its not in HA, then you need to ask them to add support for it. |
calling setChangeVerified with true did not fix the issue unfortunately. |
Problem still persists, pressing up, then stop, then down, (or vice versa): here is an excerpt of OZW_Log.txt
|
I need to see log files |
complete log, look at node number 2.. number 3 is not connected.
|
I'm seeing a LOT of timeout issues in the log, and in addition, the Node has no Neighbors registered. So I can't deduce from the logs whats going on. it could be a Network/RF issue, or it could be a device compatibility issue. Any way to reposition the controller closer to the node (or move it around etc) I also see no setChangeVerified behavior, which ValueID did you set it on? |
Based on what I do see in the Logs, it accepts both UP/Down and Stop commands (when we don't get a timeout) so OZW is sending the right messages, its just not making it to the device. (or there are some other devices on the market that get "busy" and drop RF packets when they are doing something else - Although I've never seen a Fibaro device do that, I can't deduce exactly whats going on). Sadly - I've attempted to Contact Fibaro numerous times about helping us test OZW, and all I get is crickets back from them... |
I have indeed noticed reports, mostly by HASS users both on their forum and the Fibaro forum. I own a test version of the device, and a few moths ago I did try to use it with HASS, saw position and control issues, and quickly decided that it would be easier to use my spare FGRM-222... Since then, it has been on my "todo" list to fully investigate what is wrong and where. As said, Fibaro HomeCenter has no issues with this module. One thing I can say is this, when I first looked at the device with Zniffer, several months ago and I did not use HASS nor OZW, I noticed it sends level updates, while the blinds are moving, so on Fibaro HC and Z-Way you can see the slider move. I am not saying this is problematic, I only thought "that is something the old module did not do...". I've read quite few users saying, when the blinds close, the end value is not 0, as expected, but a random low number, and the workaround is to ask an update X seconds after setting the blind position. That is all information I have for now. |
All of the ones related to the specific fibaro module |
@petergebruers I've added an "automation" workaround, triggered when the rolling shutter engine power consumption drops to zero, that requests a refresh of the module, it helps a little bit, but not consistent, and I am still seeing delays. |
Thank you for clarifying, I'll investigate next week. The fact that you don't always see the right value after drop to zero and refresh is interesting and odd at the same time. Maybe we are diagnosing more than one problem. Communication looks weird in your log, as Fishwaldo pointed out. I saw no such behaviour when I tested FGR223 on my HC2. From the low node-count I deduce you have a test setup, so I wonder if it would be possible to test for example OZW 1.6 (that is the master branch now) + open-zwave-control-panel. I don't know if ozwcp + FGR223 would work, although simple tests should pass. But there is something interesting in 1.6 called "extended status". Your controller needs to have a recent firmware to support it so I am not sure if it is worth the trouble. All want to say is, if you're interested in Z-Wave, this might be an additional tool in your toolbox. With extended status we get information about eg how long the packets took to travel, which route was used, and signal strength. |
Hello :) I have 2 of these devices in a test-setup of 5 nodes very close to each other and experiencing the same issues. So we can pratically rule-out interference or signal-strength.
See the attachted log when doing this sequence. Can this be a firmware issue? |
I'm having exactly the same problem as @expaso. Also , if i try to give a level via slider in HA, the shutter's feedback is always the previous setting |
@expaso firstly, re-include this device without Security. Its a very chatty device, and the overhead of encrypting every packet is what is driving up your response times.
Its reporting the "instant" value after a SET is sent to the device. Some devices report this instant value rather than the final value, others report final value rather than instant values. Finally - Not sure if this is you, HASS or something else, but something is requesting a lot of updates when making a level change. (Notification CC, Meter CC) thats just driving up the amount of traffic on your network. Combined with encrypting packets (two packets in plain text means 7 packets when encrypted) its driving up the utilization of your network. |
Hi @Fishwaldo , Thanks for your reply! I appreciate! I will test this device without security, but only for testing. This module is used for entrance gates and roller-shutter, so if ANY zwave device is in need of some encryption, this one would be it :) I can see that this device is a chatty one, but is it that chatty that it will bring the whole network down for 10 seconds? |
Slat/Tilt issues reported by Andre Richter, possibly related: https://groups.google.com/d/msg/openzwave/dC261ocwUnA/E1zKZSrXCQAJ It is about FGRM222 - but he also mentions issues with timeouts and secure mode. |
Hi all, I'll want to add some insight on this issue. I have numerous FGR223 and lost a lot of sleep hours trying to make them work. I also have the home center from fibaro, and they have occasional issues with that one too (not reporting values). What my conclusion is that their firmware is buggy/patchy when used without their original controller and can work inconsistently. First of all, it's mandatory to update the firmware to 5.1 using the fibaro HC or HCL. They will not work with old firmware, as they overload the zwave network during movement. With the new firmware, it's better (but still there're things to consider). With that said, I'm using them in the following environment:
The behavior:There're different "topics" where the same values are reported, and there's different behavior depending on which end point is used on set commands via Zwave and/or the physical push-buttons of the device.
Note: The FGR223 must be calibrated every time you include it in a network. It will report 254 as position when uncalibrated, or when excluded/included. Note 2: Sometimes it's necessary to SET topic 38/1/0 via zwave2mqtt before some meaningful data comes on 38/1/9. Some other times it's not necessary. So far, here's my yaml configuration for a working shutter via mqtt:
WarningIt will not work with openzwave 1.4. Forget it. The best way is to setup a local mosquitto or remote mosquitto server and use it that way. Residual issuesI've been unable to add the UP/DOWN/STOP actions. If anyone has an idea on how to do them, please help. Final wordsIf you read this, save yourself the headake and sleepless hours. Buy another product. This one does not work, is not supported, and has issues with their OEM controllers. Until it's fixed, it's better to steer clear. |
I can confirm the issue with Qubino Dimmer |
@Fishwaldo I have a solution for the FGR 223, but it involves Supervision CC, which is not yet implemented in OZW: |
Just for information: |
Any update of this issue ? Is it an openzwave issue or a fibaro issue ? |
I would say it's an OZW issue. To my knowledge, those devices work flawlessly in the Fibaro Home Center and with alternative software if you use SupervisionCC to find out when the level change is done. |
Does it have a chance to work in HA on in OZW one day ? |
Hi Everyone, i am having the same issues with my Roller Shutters, I am using iobroker. I would also be interested in knowing if this is going to be resolved? |
Try iobroker.zwave2 :) |
Lets not discuss this here, that has nothing to do with openzwave. Leave me a comment in the iobroker forum and we can figure it out. |
@ThomasBoettner It's not reporting the position automatically after changes. I had to ask HA to poll it. |
Same issue here, no feedback of status after opening or closing. Also with FGR223
|
Any news on this issue ? Same here. It looks like the state update is always one step behind the current state (i.e. if the blinds are at level 20 and I send a command to level 99, it shows a state of 20 after that and if then I send a command to level 60 it shows a state of 99). |
Hello,
the state report of Fibaro FGR 223 of the blinds is not correct / not updated.
F.e. I moved the shutter to 25% via multi-state switch and it shows the old position f.e. 5%.
With the older version Fibaro FGR 222 everything is working well.
The text was updated successfully, but these errors were encountered: