Fibaro FGR 223 wrong percent report

[eumats]

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.

[bobsilesia]

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.

[LooSik]

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?

2019-03-03 03:56:27.839 Warning, Exception: Manager.cpp:2499 - 102 - ValueID passed to GetValueFloatPrecision is not a Decimal Value 2019-03-03 03:56:27.839 Warning, Exception: Manager.cpp:2499 - 102 - ValueID passed to GetValueFloatPrecision is not a Decimal Value

[norbertohenriques]

Is there any news regarding this issue?

[Fishwaldo]

The log messages you posted are a application problem. (The application is trying to retrieve the value with the wrong type).

[LooSik]

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. OZW_Log.txt

Would be really nice to get this working properly as having to poll these values currently is adding unncessary bottleneck to the network.

[Fishwaldo]

Enable SetChangeVerified on the ValueID in question (the level) or poll after changing the position. That’s the only way todo it currently.

[Fishwaldo]

http://www.openzwave.com/dev/classOpenZWave_1_1Manager.html#ac26cc3c1b37cf068ac9eee23ef343c30

[LooSik]

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.

[Fishwaldo]

You need to change it via the API. If its not in HA, then you need to ask them to add support for it.

[lelikg]

calling setChangeVerified with true did not fix the issue unfortunately. Anything else we should try in order to fix this issue?

[lelikg]

Problem still persists, pressing up, then stop, then down, (or vice versa): Shutter opens, stops, and doesn't respond to the down command

here is an excerpt of OZW_Log.txt

2019-05-30 14:53:31.716 Info, Node002, Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Bright - 1 - 1 - true
2019-05-30 14:53:31.716 Info, Node002, SwitchMultilevel::StartLevelChange - Starting a level change
2019-05-30 14:53:31.716 Info, Node002,   Direction:          Up
2019-05-30 14:53:31.716 Info, Node002,   Ignore Start Level: True
2019-05-30 14:53:31.716 Info, Node002,   Start Level:        0
2019-05-30 14:53:31.716 Detail, Node002, Queuing (Send) SwitchMultilevelCmd_StartLevelChange (Node=2): 0x01, 0x0b, 0x00, 0x13, 0x02, 0x04, 0x26, 0x04, 0x20, 0x00, 0x25, 0x30, 0xf6
2019-05-30 14:53:35.381 Error, Node002, ERROR: Dropping command, expected response not received after 1 attempt(s)
2019-05-30 14:53:35.384 Detail, Node002, Removing current message
2019-05-30 14:53:35.384 Detail, Node002, Notification: Notification - TimeOut
2019-05-30 14:53:35.392 Detail,
2019-05-30 14:53:35.392 Info, Node002, Sending (Send) message (Callback ID=0x29, Expected Reply=0x04) - MultiChannel Encapsulated (instance=2): MeterCmd_Get (Node=2): 0x01, 0x0e, 0x00, 0x13, 0x02, 0x07, 0x60, 0x0d, 0x01, 0x01, 0x32, 0x01, 0x00, 0x25, 0x29, 0xb5
2019-05-30 14:53:35.400 Detail, Node002,   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2019-05-30 14:53:35.400 Detail, Node002,   ZW_SEND_DATA delivered to Z-Wave stack
2019-05-30 14:53:35.421 Detail, Node002,   Received: 0x01, 0x07, 0x00, 0x13, 0x29, 0x00, 0x00, 0x03, 0xc1
2019-05-30 14:53:35.421 Detail, Node002,   ZW_SEND_DATA Request with callback ID 0x29 received (expected 0x29)
2019-05-30 14:53:35.421 Info, Node002, Request RTT 29 Average Request RTT 28
2019-05-30 14:53:35.421 Detail,   Expected callbackId was received
2019-05-30 14:53:45.394 Error, Node002, ERROR: Dropping command, expected response not received after 1 attempt(s)
2019-05-30 14:53:45.394 Detail, Node002, Removing current message
2019-05-30 14:53:45.394 Detail, Node002, Notification: Notification - TimeOut
2019-05-30 14:53:45.402 Detail,
2019-05-30 14:53:45.402 Info, Node002, Sending (Send) message (Callback ID=0x2a, Expected Reply=0x04) - MultiChannel Encapsulated (instance=2): MeterCmd_Get (Node=2): 0x01, 0x0e, 0x00, 0x13, 0x02, 0x07, 0x60, 0x0d, 0x01, 0x01, 0x32, 0x01, 0x10, 0x25, 0x2a, 0xa6
2019-05-30 14:53:45.410 Detail, Node002,   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2019-05-30 14:53:45.410 Detail, Node002,   ZW_SEND_DATA delivered to Z-Wave stack
2019-05-30 14:53:45.431 Detail, Node002,   Received: 0x01, 0x07, 0x00, 0x13, 0x2a, 0x00, 0x00, 0x03, 0xc2
2019-05-30 14:53:45.431 Detail, Node002,   ZW_SEND_DATA Request with callback ID 0x2a received (expected 0x2a)
2019-05-30 14:53:45.431 Info, Node002, Request RTT 29 Average Request RTT 28
2019-05-30 14:53:45.431 Detail,   Expected callbackId was received

[Fishwaldo]

I need to see log files

[lelikg]

complete log, look at node number 2.. number 3 is not connected.

1. system init
2. press down button - worked
3. stop - worked
4. press up - didn't work, only reacted after about 30 seconds

OZW_Log.txt

[Fishwaldo]

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?

[Fishwaldo]

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... @petergebruers might be able to shed some insight as he has a lot of experience with their gear.

[petergebruers]

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.

[lelikg]

@Fishwaldo

I also see no setChangeVerified behavior, which ValueID did you set it on?

All of the ones related to the specific fibaro module

[lelikg]

workaround is to ask an update X seconds after setting the blind position. That is all information I have for now.

@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.

[petergebruers]

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.

[Expaso]

Hello :) Same problem!

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.

1. End-position is not reported (now using the automation-workaround)
2. Z-Wave network freezes (10 secs) when doing a direction-change (so down->stop->up==freeze)

See the attachted log when doing this sequence. You can see the RTT's going up very rapidly for some commands, leading to a time-out. After that, the RTT suddenly drops significantly, and all is well again. I can repeat this process over and over.

Can this be a firmware issue?

OZW_Log.txt

[eddriesen]

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

[Fishwaldo]

@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.

End-position is not reported (now using the automation-workaround)

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. Two options, one, your automation, second, would be to enable SetChangedVerified on the level ValueID, but I don't think HASS exposes this API, so your automation may be the only way.

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.

[Expaso]

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 will post the results shortly.

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? I'm new to ZWave and still have a lot to learn, but can 1 node in a test setup of 5 be too much? I will see if I can disable power info.. see if that helps.

[petergebruers]

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.

[pquan]

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:

• open-zwave - 1.6-latest (compile from hub).
• zwave2mqtt - 2.0.3 - latest

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.

1. FGR223 will report "current" level on topic 38/1/0 AND 38/1/9. It will accept "SET" command on topic
2. FGR223 will report "final" level on topic 38/1/9 and will accept "set" there too, but never use it because this messes up the physical buttons.
3. Topic 38/1/0 reports some value right after the start of the movement. Sometimes this is the final value set by openzwave, but other times it's an intermediate (often beginning) of the movement. This is reported usually only ONCE.
4. When the movement stops, the final opening value will be reported on 38/1/9, but ONLY if it was set on 38/1/0. Otherwise the thing works unpredictably.

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:

cover mywindow:
  platform: mqtt
  qos: 2
  position_topic: zwave2mqtt/mywindow/38/1/9
  set_position_topic: zwave2mqtt/mywindow/38/1/0/set
  position_open: 99
  position_closed: 0

Warning

It 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 issues

I've been unable to add the UP/DOWN/STOP actions. If anyone has an idea on how to do them, please help.

Final words

If 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.

[EvilEls]

I can confirm the issue with Qubino Dimmer Initially posted here: https://github.com/ioBroker/ioBroker.zwave/issues/84#issue-498239421 Log: log.txt

[AlCalzone]

@Fishwaldo I have a solution for the FGR 223, but it involves Supervision CC, which is not yet implemented in OZW: When sending the MultilevelSwitchSet command encapsulated in a SupervisionGet with the status updates flag set, FGR 223 sends a SupervisionReport when the target level has been reached, so it can be queried again.

[ThomasBoettner]

Just for information: I have tested the Qubino ZMNHCD1 Flush Shutter Flush Micromodule EU Z-Wave Plus, they work as expected and provide all information without any problems.

[piitaya]

Any update of this issue ? Is it an openzwave issue or a fibaro issue ?

[AlCalzone]

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.