Fibaro Roller Shutter 3 (FGR-223) - cannot get it to work properly

So I switched to Zwave-JS without an issue for the roller shutter. Position looks also correct (slider). One quick question - is there a way to report position as a numeric value? I can only see them as status open from the attributes (as they are never fully shut in my home). I would like to check the position of multiple Shutters on an overview pane.

There is a nice roller shutter lovelace card which displays the position as a percentage.

Hey thanks a lot!

Also, you should have the position as a numeric value in the state attributes.

eg:

ahhhh rught! Thanks - did not see it!

Hi all,

I started having issues with the FGR223 not updating the position in lovelace. I’m not sure when this started, but it’s consistently not updating any of the blinds.
When operating the shutters via the lovelace buttons, or even via the hardware switches (s1/s2) connected to the FGR223, I can see the update coming in the aeontec zwave controller and into zwavejs (diver version 8.0.6, zwave 0.1.34, latest). However the entity representing the current position in homeassistant is not updated.
I have some logs here:

2021-08-07T10:08:24.664Z CNTRLR   [Node 009] [~] [Multilevel Switch] targetValue: 59 => 55          [Endpoint 0]
2021-08-07T10:08:24.667Z CNTRLR   [Node 009] [~] [Multilevel Switch] duration: "unknown" => "unknow [Endpoint 0]
                                  n"
2021-08-07T10:08:24.671Z CNTRLR   [Node 009] [~] [Multilevel Switch] currentValue: 59 => 55         [Endpoint 0]
2021-08-07T10:08:24.674Z DRIVER « [Node 009] [REQ] [ApplicationCommand]
                                  └─[SecurityCCCommandEncapsulation]
                                    │ sequenced: false
                                    └─[MultilevelSwitchCCReport]
                                        current value: 55
                                        target value:  55
                                        duration:      unknown
2021-08-07T10:08:25.129Z SERIAL « 0x0108000400040298402d                                              (10 bytes)
2021-08-07T10:08:25.133Z SERIAL » [ACK]                                                                   (0x06)

The Entity yaml looks like this:

current_position: 53
friendly_name: Roller Shutter 9
supported_features: 15
device_class: window

Now, if I set the position via the position slider (in lovelace), the shutter will move to the correct position (the shutters are calibrated). The entity will update to the correct position too. But as soon as I use any button, the blind will move and zwave will receive the new position but the entity will keep the old one.

their lifeline for group 0, 1 and 2 are set to the Aeontec node ID (1) and the messages come in as shown above.

This seems like an issue in HA. On the same Zwave network I have a qubino smart meter. It’s values are correctly updated in HA. It’s only the damn fibaros that don’t work.

any ideas?

PS> I’ve been using the FGR223 for two years now. After buying a fibaro home center just to be able update their firmware to 5.1, I’ve been mostly out of luck. Using openzwave2mqtt directly, then forking my own version to be able to patch the issues in the beginning. Zwave-js has fixed most of the problems but the FGR223 keeps figthing back. Shall I just throw them in the bin and get some zigbee controller instead?

Help needed here :slight_smile:

Look at the network dump. There will be a value for Multilevel Switch CC named currentValue. Is the value for endpoint 0 or endpoint 1?

What happens if you refresh the entity manually? Does that fix the entity state? Does the report come from endpoint 0 or 1?

@freshcoast thanks for looking into this.
Checking the network dump, the currentValue for MultilevelSwitch is on endpoint 1 and 2. However, the updates from button operation come from endpoint 0. Calling the update service will update the value of the currentValue and it will be correctly reflected in the entity and thus in lovelace.
Here’s a log from the service update:

Log Level changed to: Verbose
2021-08-07T18:21:17.081Z DRIVER » [Node 009] [REQ] [SendData]
                                  │ transmit options: 0x25
                                  │ callback id:      31
                                  └─[SecurityCCNonceGet]
2021-08-07T18:21:17.098Z DRIVER « [RES] [SendData]
                                    was sent: true
2021-08-07T18:21:17.114Z DRIVER « [REQ] [SendData]
                                    callback id:     31
                                    transmit status: OK
2021-08-07T18:21:17.134Z DRIVER « [Node 009] [REQ] [ApplicationCommand]
                                  └─[SecurityCCNonceReport]
                                      nonce: 0xebb819a2c91a0652
2021-08-07T18:21:17.150Z DRIVER » [Node 009] [REQ] [SendData]
                                  │ transmit options: 0x25
                                  │ callback id:      32
                                  └─[SecurityCCCommandEncapsulation]
                                    │ nonce id: 235
                                    └─[MultiChannelCCCommandEncapsulation]
                                      │ source:      0
                                      │ destination: 1
                                      └─[MultilevelSwitchCCGet]
2021-08-07T18:21:17.167Z DRIVER « [RES] [SendData]
                                    was sent: true
2021-08-07T18:21:17.185Z DRIVER « [REQ] [SendData]
                                    callback id:     32
                                    transmit status: OK
2021-08-07T18:21:17.233Z DRIVER « [Node 009] [REQ] [ApplicationCommand]
                                  └─[SecurityCCNonceGet]
2021-08-07T18:21:17.251Z DRIVER » [Node 009] [REQ] [SendData]
                                  │ transmit options: 0x05
                                  │ callback id:      33
                                  └─[SecurityCCNonceReport]
                                      nonce: 0x046c184dc835a004
2021-08-07T18:21:17.266Z DRIVER « [RES] [SendData]
                                    was sent: true
2021-08-07T18:21:17.283Z DRIVER « [REQ] [SendData]
                                    callback id:     33
                                    transmit status: OK
2021-08-07T18:21:17.315Z DRIVER « [Node 009] [REQ] [ApplicationCommand]
                                  └─[SecurityCCCommandEncapsulation]
                                    │ sequenced: false
                                    └─[MultiChannelCCCommandEncapsulation]
                                      │ source:      1
                                      │ destination: 0
                                      └─[MultilevelSwitchCCReport]
                                          current value: 79
                                          target value:  79
                                          duration:      unknown
Log Level changed to: Info

And here’s the network dump from one FGR223

          {
            "nodeId": 9,
            "index": 0,
            "installerIcon": 6400,
            "userIcon": 6400,
            "status": 4,
            "ready": true,
            "isListening": true,
            "isRouting": true,
            "isSecure": true,
            "manufacturerId": 271,
            "productId": 4096,
            "productType": 771,
            "firmwareVersion": "5.1",
            "zwavePlusVersion": 1,
            "deviceConfig": {
              "filename": "/data/db/devices/0x010f/fgr223.json",
              "isEmbedded": true,
              "manufacturer": "Fibargroup",
              "manufacturerId": 271,
              "label": "FGR223",
              "description": "Roller Shutter 3",
              "devices": [
                {
                  "productType": 771,
                  "productId": 4096
                },
                {
                  "productType": 771,
                  "productId": 12288
                }
              ],
              "firmwareVersion": {
                "min": "0.0",
                "max": "255.255"
              },
              "paramInformation": {
                "_map": {}
              },
              "proprietary": {
                "fibaroCCs": [
                  38
                ]
              }
            },
            "label": "FGR223",
            "endpointCountIsDynamic": false,
            "endpointsHaveIdenticalCapabilities": false,
            "individualEndpointCount": 2,
            "aggregatedEndpointCount": 0,
            "interviewAttempts": 0,
            "endpoints": [
              {
                "nodeId": 9,
                "index": 0,
                "installerIcon": 6400,
                "userIcon": 6400,
                "deviceClass": {
                  "basic": {
                    "key": 4,
                    "label": "Routing Slave"
                  },
                  "generic": {
                    "key": 17,
                    "label": "Multilevel Switch"
                  },
                  "specific": {
                    "key": 6,
                    "label": "Motor Control Class B"
                  },
                  "mandatorySupportedCCs": [
                    32,
                    38,
                    37,
                    114,
                    134
                  ],
                  "mandatoryControlledCCs": []
                }
              },
              {
                "nodeId": 9,
                "index": 1,
                "installerIcon": 6400,
                "userIcon": 6400,
                "deviceClass": {
                  "basic": {
                    "key": 4,
                    "label": "Routing Slave"
                  },
                  "generic": {
                    "key": 17,
                    "label": "Multilevel Switch"
                  },
                  "specific": {
                    "key": 6,
                    "label": "Motor Control Class B"
                  },
                  "mandatorySupportedCCs": [
                    32,
                    38,
                    37,
                    114,
                    134
                  ],
....
              {
                "endpoint": 1,
                "commandClass": 38,
                "commandClassName": "Multilevel Switch",
                "property": "currentValue",
                "propertyName": "currentValue",
                "ccVersion": 4,
                "metadata": {
                  "type": "number",
                  "readable": true,
                  "writeable": false,
                  "label": "Current value",
                  "min": 0,
                  "max": 99
                },
                "value": 52
              },

Before I send you elsewhere, are you using zwavejs2mqtt or the HA official addon?

@freshcoast, hi, I’m using the official HA zwavejs addon. I however have installed and used a zwavejs2mqtt instance. I use it mainly to replace/rejoin dead nodes, check the network topology and the things HA cannot currently do.
The system is a Rpi3 running from SSD. The zwavejs addon is managed by the supervisor. HA core is updated to 2021.8.3 and I’m not using any other addons (except influxdb, official).

PS: I used zwave2mqtt in the past but not any more since the advent of the zwavejs addon.

I would submit a bug report with the node-zwave-js project. With release v8, the behavior of multi-channel devices has changed. There are several Fibaro devices with similar problems, that either require an update to the device config file, or new associations. If you provide the logs and dumps there, they should be able to solve it.

Thank you, I’ll do that.
For a better bug report, I need to know what HA expects to see from the fibaro devices.
Does it expect the level update to come from endpoint 1 instead of coming from Endpoint 0 ?
What else can I add there?
Thank you.

Basically, node-zwave-js knows about endpoints 1 and 2, and it expects messages from those endpoints. When it gets messages from endpoint 0 (root), it doesn’t handle them. There are different ways of addressing the problem.

For a good bug report you don’t need to diagnose the problem. Just describe your problem (HA entities are not updating) and provide the requested information in the bug report template. To accelerate the process, provide debug logs of a) the device re-interview, b) the device operating, showing when the updates are occurring, and c) a network dump from HA. If more information is needed, it will be requested.

To get debug logs, you can go to Configuration → Integrations → Z-Wave JS → Configure → Logs. Set log level to “Silly”. You can download the log file from there as well.

Just a quick update.
The issue with FGR223 has been fixed with driver version 8.0.8. A re-interview of all nodes in necessary, but now updates from into HA.
Thanks @freshcoast for helping out.

Just FYI: The slat position is a separate entity which only works if the FGR is set to Venetian Blind mode and then calibrated (again).

I am quite new to HA and am currently looking into automating our venetian blinds in our flat. I have been looking at a couple of solutions starting w/ Shelly 2.5, Sunricher and Fibaro Roller Shutter 3. All of them seem(ed) to have their flaws, however the Fibaro seems to be the best bet. However I am still not sure if all hickups have been resolved and the FGR-223 can be used with it’s entire capabilities.

So I would highly appreciate to get some feedback on the following questions:

  1. Can you trigger up/down movement from within the UI?
  2. Can you pause movement from within the UI?
  3. Once calibrated: is the position within the UI always correctly reported?
  4. Referring to 3.: also when the movement was not triggert from 0 or 100%, e.g. from 50%?
  5. Does tilting the slats work?
  6. Does movement + tilt work, e.g. go to 50% and tilt to 30%?
  7. Does all of this work with the hardware buttons as well, i.e. updating position and tilt?
  8. Which Z-Wave integration are you using with the Fibaros, i.e. which works the best and most reliable?
  9. Can automatic shading including blind position and tilt be used and can you maybe guide me into the right direction on how to set this up?

@NamCisum any chance you could share your experience?

Thank you so much for your reply already in advance!

Best wishes,
Markus

  1. Sure - but be advised, that depending on the load of the Z-Wave network the delay ranges from instant reaction up to 30 seconds. Fine adjustments are usually not possible using the UI.
  2. Sure - see 1.
  3. Yes. If the shutter runs into a problem and stops, it will be reported as fully down. In that case you might need to re-calibrate. I have been using roughly 30 shutters over 18 months, so far 3-5 recalibrations necessary (one being a motor defect).
  4. Yes.
  5. I can confirm it works using ZWaveJStoMQTT connected via Websocket to the “new” ZWave JS integration (there is a separate entity for the tilt position). It should also work with the official ZWave JS Server add-on is it wraps the same software, but I haven’t tested it. It does not work with the deprecated ZWave 1.4 native integration.
  6. Yes. I would suggest to 1st move the blind into position, then give it an adequate amount of time (because the controller itself will then reset the tilt position to the previous tilt position), then set the tilt position you want. In any case it will be two commands, so I would use a script that you can call with two arguments (blind position, tilt position).
  7. Yes.
  8. See above - ZWaveJStoMQTT and ZWave JS integration - no MQTT (it’s disabled).
  9. Depending on the cloud coverage and expected max temperature for the day I activate some automations in the morning setting the blinds and tilt positions of the house following the sun. You can do this depending on the position of the Sun, certain time of the day (but this will change during the year) or by measuring luminance inside/outside the house. The technical part is really simple: You call the service to set the cover position and that’s it. The rest really depends on your daily life: for example I close the blinds in the kids rooms at a certain time of day before they go to bed. Then I open them at a certain point of time in the morning, but only if the automations for closing them are not activated (e.g. because it’s too cold or not sunny).

Let me know if you have any questions, good luck on this journey, it will take some time, but it’s very educative and worth it in the end! After some reservation my wife now loves the fact that if she comes home the house is always cool on a hot day and she didn’t have to do anything while she was gone. :slight_smile:

1 Like

Thanks a lot @NamCisum for the rapid and detailed answers to my questions! This sounds like the FGR-223 finally fits the bill and is fully operational from within HA!

1 Like

Just for reference, I wrote a small script that does exactly what I wrote 6. above:

UPDATE (2/1/22): I was underestimating the FGR223 - you actually don’t have to wait for the blind to reach the desired position and then set slats, it does work if both positions are being set at the same time. The controller appears to adhere to the desired slat position and does not revert to the previous position before setting the new one.

zw_setcover:
  alias: Z-Wave Set Cover
  icon: mdi:window-shutter
  description: 'Z-Wave Set Cover with Slats'
  mode: parallel
  sequence:
    # - conditions: "{{ is_state_attr(zw_setcover_coverent, 'current_position', zw_setcover_coverpos) }}" Muss noch auf NOT umgebaut werden
    - service: cover.set_cover_position
      data:
        entity_id: "{{ zw_setcover_coverent }}"
        position: "{{ zw_setcover_coverpos }}"
    - service: cover.set_cover_position
      data:
        entity_id: "{{ zw_setcover_coverent }}_2"
        position: "{{ zw_setcover_slatpos }}"

OLD VERSION (waiting for run to complete):

zw_setcover:
  alias: Z-Wave Set Cover
  icon: mdi:window-shutter
  description: 'Z-Wave Set Cover with Slats'
  mode: parallel
  sequence:
    - service: cover.set_cover_position
      data:
        entity_id: "{{ zw_setcover_coverent }}"
        position: "{{ zw_setcover_coverpos }}"
    - wait_template: "{{ is_state_attr(zw_setcover_coverent, 'current_position', zw_setcover_coverpos) }}"
      timeout: "00:01:30"
    - service: cover.set_cover_position
      data:
        entity_id: "{{ zw_setcover_slatent }}"
        position: "{{ zw_setcover_slatpos }}"

This waits for the controller to update the position and then sets the slats. If that doesn’t work because iE the position slightly differs after the move it runs into the time-out (set for longest possible run-time of blinds) and sets the slats anyway.

You can call it like this:

service: script.zw_setcover
data:
  zw_setcover_coverent: cover.name
  zw_setcover_coverpos: 50
  zw_setcover_slatent: cover.name_2
  zw_setcover_slatpos: 50

This sets the cover to 50% and turns the slats into middle position.

1 Like

I am using Fibaro Roller Shutter 2 and I do not see additional entity after setting switch to Venetian Blind mode and calibrating it.
I am able to control position using cover services (open, close, set position), but nothing with tilt.

I am using official HA ZwaveJS addon and separate ZwaveJS2MQTT server. Within the ZwajveJS, I am able to see both position and slat, and if I set slat position in the ZwaveJS2MQTT gui, and execute it, slats will position accordingly. But the only way how how can I call that from the HA is to call service: Z-Wave JS: Set a value on a Z-Wave device (Advanced)

Therefore I have only made few predefined values and execute it as a script, after selecting value from dropdown in the lovelace UI.

Anyone found better method?