Deconz-rest-plugin: IKEA smart blinds FYRTUR and KADRILJ

I am afraid we have to wait till Feb 2...

In few days should hit the stores here. I will buy one for sure. If I am not mistaken they are battery operated, so end-devices

I'm planning on getting two on 2nd of February.

The reasoning for the repeater must be if the blind is not paired with the gateway right? There is no direct control of end-device to end-device without the repeater?

There is no direct control of end-device to end-device without the repeater?

Without a router. The repeater is definitely needed when you want to control the smart blind standalone, without a hub. However, the coordinator is also a router, so I think/hope you can ditch the repeater if you connect both the remote and the smart blind to deCONZ (or, if possible, to an IKEA hub).

Ikea told us they where postponed 'till summer due to manufacturing issues and problems with the implementation to the IKEA bridge. I am also very interested in these blinds and hope they are controllable via deconz.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Still waiting on IKEA...

According Reddit the release of the blinds might happen in October in the Netherlands:
https://www.reddit.com/r/tradfri/comments/c8e7ge/blinds_kadrilj_fyrtur_on_sale_in_october

In Sweden they will arrive within a month (hopefully)

End of August in the Netherlands, according to IKEA, see:
https://www.ikea.com/nl/nl/catalog/categories/departments/Textiles/10701/:

Vanaf eind augustus 2019 zijn de elektrische FYRTUR en KADRILJ rolgordijnen verkrijgbaar bij IKEA. Met een afstandbediening open en sluit je eenvoudig de rolgordijnen. Ook te gebruiken in combinatie met de TRÅDFRI verbindingshub en bijbehorende app.

Hm, they removed the text from the web site...

EDIT (Aug 1st) And it's back... still end of August.

Looks like we need to look at Xiaomi Aqara Rolling shutter motor
https://s.click.aliexpress.com/e/J1vGk12

Released today, hopefully this will be integrated fast. I want to buy a few :D

No custom sizing :/. Too bad.

In Italy they released the spare battery Braunit only :p

Should now be available soon. They have appeared on the site in the Netherlands this week; initially it said available on august 18th. I will be buying some fyrturs.

I've bought them this weekend. If someone can provide me a step by step guide about what I need
to do. I will send the information.

I guess this link is about it.

I also bought 2 Fyrtur, but I don't know when I will have time to play with them.

I've gotten two Fyrtur smart blinds today as well. Unfortunately I am running deconz headless, so haven't got access to the GUI, but if theres any other way I might help - just say the word :)

If you run deconz in docker you can actually enable desktop gui to be viewable over vnc

No custom sizing :/. Too bad.

I think they are ;)

https://youtu.be/PL6LPZZoFlo

I need length 240cm. Ikea sells only 195:/.

I'm running Deconz as an Addon in Hassio. So I'm affraid I cannot access the gui.

I'm running Deconz as an Addon in Hassio. So I'm affraid I cannot access the gui.

Yes you can; https://github.com/home-assistant/hassio-addons/tree/master/deconz#accessing-the-deconz-application-and-viewing-the-mesh-via-vnc

I'm able to login via VNC now. I've pressed the two buttons on the Ikea blinds (step 2). I also set permit join (255). But I don't see any changes in the VNC view. Is there something else I should do?

ADDING DEVICES TO YOUR
WIRELESS OPEN/CLOSE REMOTE
When the wireless Open/Close remote is sold
together with a wireless roller blind and a
Signal Repeater (in the same package), they
are already paired.
To add more wireless roller blinds, just repeat
the steps below:
Make sure that your wireless roller blind is
turned on.
1 Open the back cover of the Open/Close
Remote and find the pairing button.
2 Short press on both buttons on the blind.
This will make the device awake and ready
for pairing for 2 minutes.
3 Hold the Open/Close remote very close to
the wireless roller blind you want to add: no
more than 5 cm away from .
4 Press and hold the pairing button for at
least 10 seconds on the wireless Open/
Close remote.
5 A red light will shine steadily on the Open/
Close remote. On your wireless roller blind
a white light will begin to dim and flash until
the devices have been successfully paired.
Up to 4 wireless roller blinds can be paired
with 1 Open/Close remote.

For those who come from Berlin and are interested in a FYRTUR, they have some in Berlin Walterdorf.

You also can check online in what shop they are available :)

Still waiting for the Fyrtur to become available in Amsterdam...

As I understand, pressing the two buttons sets the blind in touch-link pairing mode. That’s not going to help pairing it to deCONZ. If its like any of the Trådfri devices, resetting it to factory settings should do the trick. For the controls, this is done by holding the pairing button for 10 seconds.

If you cannot get the blind to join the deCONZ network after a reset, you might try and pair the remote to deCONZ (again, by resetting it) and then touch-link the blind to the remote.

Still waiting for the Fyrtur to become available in Amsterdam...

As I understand, pressing the two buttons sets the blind in touch-link pairing mode. That’s not going to help pairing it to deCONZ. If its like any of the Trådfri devices, resetting it to factory settings should do the trick. For the controls, this is done by holding the pairing button for 10 seconds.

If you cannot get the blind to join the deCONZ network after a reset, you might try and pair the remote to deCONZ (again, by resetting it) and then touch-link the blind to the remote.

Hereby the connected remote information

And the information of the blinds:

To reset and pair the blind itself you most press both buttons on the blind for 5 seconds (not on the remote) and thus the blind should appear in the GUI as and end device. After this you have to manually pair the remote to the blind. At least that's my understanding as i currently can not access the GUI myself. Might reinstall my pi to desktop version to test later today...

Edit: Seems you beat me to it Thoit :)

Edit edit: I shortened one of my blinds following the video posted earlier, went fine.

@Thoit looks like deCONZ hasn’t yet read the descriptors in full. Can you try and read them from the _left_ of the two dropdown rounds on the node? Make sure to wake the device first. Also, can you please post the other info from https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Request-Device-Support? Please read the _Basic_ cluster attributes before making the screenshot. Again, make sure the device is awake when reading.

Is this the information you need?

And the remote:

The remote is looking good. As I would expect, it has a client _Window Covering_ cluster, to send comands to the blind. This means that it can only control (directly) the blind, and that the blind cannot be controlled (directly) by the other control devices. Not too happy about the 0xFC7C cluster, which is probably used for some IKEA-specific configuration.

Can you also post the node an clusters for the blind? And the _Basic_ cluster after reading the attributes. The radio on the blind needs to be awake for the read to succeed; I’m not sure how to achieve that. Hopefully the blind polls its parent every couple of seconds or it wouldn’t be able to react to the controller.

Hello !
I'm happy about the progress including the ikea blinds :)
One question about the blinds: can the Endposition be customized ? --> my windows i want to use them for are less than 1,95.
--> I couldn't find any info about that in the ikea manual

Hello !
I'm happy about the progress including the ikea blinds :)
One question about the blinds: can the Endposition be customized ? --> my windows i want to use them for are less than 1,95.
--> I couldn't find any info about that in the ikea manual

Yes, that's possible. Set the end position and click 2 times on one of the buttons on the blinds.

Hello !
I'm happy about the progress including the ikea blinds :)
One question about the blinds: can the Endposition be customized ? --> my windows i want to use them for are less than 1,95.
--> I couldn't find any info about that in the ikea manual

Yes, that's possible. Set the end position and click 2 times on one of the buttons on the blinds.

Thx ! .. so as soon as they're available i'll get some :)

@manup will you support in getting proper Ikea cover support in deconz possible in the short term?

I couldn't find how to get more information about the blinds. Already pushed the 2 buttons each, simultaneously, double clicked but don't see more information then provided in the screenshot.

I have managed to get my hands of some of them today. I'm happy to provide any technical detail that can help with the implementation :)

@manup any progress or plan for this?

Today I finally paired one of my blinds to deconz, but same as Thoit I do not see how to get more information from it. I can get the node info, but there is apparantly no clusters to show or read from...

deCONZ hasn’t read the descriptors. You might try and read these manually from the (only visible) left drop-down (on the right side of the node). Depending on how sleepy the blind is, you might need to wake it before it responds. Not sure how that’s done, I guess/hope by pressing a button on the blind.

Blind clusters & Basic cluster read

Cool! Could you try and read the _Window Covering_ cluster? And check whether you can control the blind through its _Open_ and _Close_ commands?

How did you connected the blinds with Deconz @Revorge? Ik tried a couple of Times, but couldn't get it to work :(

@ebaauw here’s my multi-adapter Homebridge blind implementation. It could be useful for implementing the blinds support on Homebridge-hue
https://github.com/paolotremadio/homebridge-webshades

Which makes me wonder: should it be part of Homebridge-Hue? It is technically not hue... :)

homebridge-hue has been supporting smart blinds since v0.10.3.

Cool! Could you try and read the _Window Covering_ cluster? And check whether you can control the blind through its _Open_ and _Close_ commands?

I can control the blind from deconz GUI using the "Up / Open", "Down / Close" and "Go to lift percentage" exec buttons - works a treat :)

Not sure if the attributes read completed properly, but this was all I got no matter what I tried:

How did you connected the blinds with Deconz @Revorge? Ik tried a couple of Times, but couldn't get it to work :(

Open the network via deconz GUI or "add new lights" in phoscon and hold both buttons on the blind for about 5 seconds - the blind appeared instantly.

Looks good, I like that the blinds also provide a Poll Control cluster. The remote seems to be the same as the on/off remote that was sold before and is supported since 2.05.58.
https://github.com/dresden-elektronik/deconz-rest-plugin/releases/tag/V2_05_58

There is sure some additional code needed, for setup a binding in order to let the remote control control the blinds directly.

As short term goal I guess it makes sense to support the blinds via the existing /lights hack. Not my favorite but the v2 REST-API will take some time, so lets do the hack first and add a proper blinds API in v2 later :)

Yesterday I got an email notification that the 140cm FYRTUR was available at IKEA Amsterdam. I went there straight away, but they couldn't find the FYRTURs - they were "lost". As the stock had changed, I figured they found them. Made another trip this morning, but they had only some 60cm and 80cm units on left. The remaining 140cm unit listed on the website went MIA. They don't know when new stock will arrive. None of the other IKEA stores within decent driving distance currently have any stock, so I guess I'll wait another week...

Anyway, whitelisted the FYRTUR (and, I hope, the KADRILJ) so the REST API plugin should create the /lights resource with type Window covering device. I hope some-one can compile and test my latest commit.

Exposing the battery level will be a bit more challenging, as there's no config on /lights resources. I could introduce a ZHABattery /sensors type or maybe better wait for API v2 /devices.

The remote seems to be the same as the on/off remote

No, it has different firmware, a different device type, and I suspect it sends _Window Covering_ commands instead of _On/Off_ and _Level Control_ commands.

I added the remote device type to general.xml and whitelisted it for creating a /sensors resoruce. I think that's enough, as it also advertises a client _On/Off_ cluster. For full support, I need to see which commands it sends. Could some-one please run deconz with --dbg-info=2 and capture the commands, including the asdu?

Really great to see that some progress and commits are being made :) If I might be of any further help in adding support - just say the word. I am currently testing all this on a "burner" SD-Card anyway, so I do not mind doing some "tinkering" :)

Great @ebaauw how can I test your code via the Hassio add on? Or isn't that possible?

You need to get my latest commit, compile the REST API plugin and install it, see https://github.com/dresden-elektronik/deconz-rest-plugin#get-and-compile-the-plugin.

You need to get my latest commit, compile the REST API plugin and install it, see https://github.com/dresden-elektronik/deconz-rest-plugin#get-and-compile-the-plugin.

I tried compiling from your repo, but I am getting an error

I added the remote device type to general.xml and whitelisted it for creating a /sensors resoruce. I think that's enough, as it also advertises a client On/Off cluster. For full support, I need to see which commands it sends. Could some-one please run deconz with --dbg-info=2 and capture the commands, including the asdu?

How would one - "step by step" do what you asked above?

Damn, I forgot about that. That's a known issue with the post-v2.05.66 commits, which should be fixed in v2.05.67. See #1732 and https://github.com/dresden-elektronik/deconz-rest-plugin/commit/1777accdc688a2a72f762f6e8d38df68dec34fef.

Damn, I forgot about that. That's a known issue with the post-v2.05.66 commits, which should be fixed in v2.05.67. See #1732 and 1777acc.

That helped :)

And visible in HomeAssistant - the reported state and position is incorrect, but the blind is controllable using the position slider.

Lets get this released!

What are the issues with the Home Assistant slider? Wrong scale?

What are the issues with the Home Assistant slider? Wrong scale?

The only "problem" is that Home Assistant is completely unaware of the blind state. The slider scale is correct but Home Assistant has no clue what the current position of the blind is. You might temporarily solve this simply by having Home Assistant remember the last position set, but that is a matter for the Home Assistant community.

Is the state reflected in state.bri in the REST API? It should match the _Current Position Lift Percentage_ attribute. The Xiaomi curtain controller and, I think, the ubysis J1 only report the current position after successful calibration.

What position is 0%? Completely open, or closed? I need to check the code what it’s supposed to be; I forget which is which, as the Xioami had them reversed and HomeKit had them reversed vis-a-vis ZigBee.

The attribute (and state.bri) should update automatically. If not, Could you try to create a binding manually from the blind’s _Window Covering_ cluster to the RaspBee/ConBee.

What position is 0%? Completely open, or closed? I need to check the code what it’s supposed to be; I forget which is which, as the Xioami had them reversed and HomeKit had them reversed vis-a-vis ZigBee.

0% is completely open. I'll look at state.bri later.

If I perform a read on the attributes of the _Window Covering Cluster_ the state and position is updated in Home Assistant - though reversed, so 0% (Open) is shown as closed and 100% (closed) shown as open... The blind itself seems to polls its parent every second.

If I perform a read on the attributes of the Window Covering Cluster the state and position is updated in Home Assistant

The read shouldn't be necessary, once you create a binding from the _Window Covering_ cluster to the RaspBee/ConBee, and configure attribute reporting for _Current Position Lift Percentage_.

so 0% (Open) is shown as closed and 100% (closed)

Open should be 0% alright, see https://github.com/dresden-elektronik/deconz-rest-plugin/pull/746#issuecomment-427590830. Please double-check state.bri. It should be 0 for open and 255 for closed. If that's the case, Home Assistant should reverse the values (also when opening/closing the blind). HomeKit also uses 100% for open and 0% for closed, so I had to do the same in homebridge-hue.

The blind itself seems to polls its parent every second.

That's good news. I'd hoped it would (or it couldn't respond to the remote), but it's good to have confirmation.

The read shouldn't be necessary, once you create a binding from the Window Covering cluster to the RaspBee/ConBee, and configure attribute reporting for Current Position Lift Percentage.

That sounds excellent, but afraid I lack the know-how.

To create a binding, open the _Bind Dropbox_ panel in the deCONZ GUI. Drag the _Window Covering_ cluster from the blind to the _Source_ field in the dropbox. Drag the 0x01 endpoint from the RaspBee to the _Destination_ field. Then press _Bind_. The dropbox should display success for a brief while. It might take a few attempts. Here's a screenshot (for the Xiaomi curtain controller):

To configure attribute reporting, open the _Cluster Info_ panel in the deCONZ GUI. Select the _Window Covering_ cluster from the blind and scroll down. Double-click on the _Current Position Lift Percentage_ attribute to popup the _Attribute Editor_ window. Enter the reporting values and press _Write Config_. Close the popup window, re-open it and press _Read Config_ to check that the values were stored. It might take a few attempts.

After this, the _Current Position Lift Percentage_ value should change automatically when opening or closing the blind. If this works, we can enhance the REST API plugin to setup the binding and attribute reporting configuration automatically.

nice work guys, I just picked up 2 blinds today, need to cut them a bit first though, but once I have them up I'll be happy to assist if any more info is needed.

@ebaauw Thanks a lot - really appreciate the help and detailed explanation :) I'm of to a birthday in a few minutes, but will give it at go tonight. Seems it is all thats needed for fixing basic functioning with HA 👍

According to ikea.nl there is one 140cm blind in stock at Ikea Amsterdam, but might be the phantom blind from before ;)

@ebaauw I followed your instructions for creating the binding and the position is now updated automatically 👍 Now i just have to figure out how to invert the open / close state in Home Assistant.

I'll try and pair the open/close remote to deCONZ later and test if it works for controlling the blind as well

@Revorge to fix Hass we just need to add the model in https://github.com/home-assistant/home-assistant/blob/d4bd5a180ce9c7dc39b0a00000307148ca6b6303/homeassistant/components/deconz/cover.py#L17

I would just like to figure out which way is the default way as to not need to specify all devices following the proper order

The remote seems to be the same as the on/off remote

No, it has different firmware, a different device type, and I suspect it sends _Window Covering_ commands instead of _On/Off_ and _Level Control_ commands.

Interesting, when I recall correctly the on/off remote also provided window covering capabilities.

I'll merge https://github.com/dresden-elektronik/deconz-rest-plugin/pull/1774 for 2.05.67. The automatic binding creation for the Window Covering cluster can be added for the next version.

@manup do we have an easy way of knowing which covers have reversed up/down logic?

@manup do we have an easy way of knowing which covers have reversed up/down logic?

I'm not sure, but would suggest the REST-API only provides one logic for all covers. And if a cover has reversed logic this should be cared for internally to keep the applications simple.

The REST API plugin normalises the logic... to the ZigBee standard. So depending on what “your” home automation systems uses, it’s either all no none.

@ebaauw ok so all uses zigbee spec? Then there is no reason to keep inverted support for the hass component? I'll have to go through my old PRs to see why it was necessary originally

Could some-one please run deconz with --dbg-info=2 and capture the commands, including the asdu?

I am trying do the above (not sure i understand the "asdu" part though), but am only getting a "no botton handler" message when pressing a botton on the remote... What do I need to do?

There should be an APS-DATA message with the asdu just before this one. See e.g. https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1676#issuecomment-511347951.

This message already confirms my suspicion that the remote sends _Window Covering_ commands (cluster 0x0102). We need to capture the different commands for pressing, releasing, holding the different buttons, to create a button handler.

--dbg-info=2

That’s the remote reporting its battery percentage (cluster 0x0001, attribute 0x0021).

Maybe I mixed up the deCONZ options. Could you try --dbg-info=2 in addition to --dbg-aps=2?

--dbg-aps=2 - before and after one up and one down press

I need to double-check the ZCL spec when I’m home, but that looks like simple _Open_ and _Close_ commands, without any parameters. Does the remote send anything else when holding up or down?

Does the ZHASwitch resource for the remote show config.group? Does the blind already react to the remote?

I need to double-check the ZCL spec when I’m home, but that looks like simple Open and Close commands, without any parameters. Does the remote send anything else when holding up or down?

Holding down button for a few seconds

Does the ZHASwitch resource for the remote show config.group? Does the blind already react to the remote?

Had not thought about this before, but just assigned blind and remote same group id via deCONZ GUI and the blind responds perfectly to remote input - both "single press up and down" and "long press up and down". As expected the range extender / repeater is not required :)

Keep in mind that the behaviour of the remote is the following:

• single press up: open the blinds all the way up
• long press up: keep opening until the button is released (or the fully open position is reached)
• single press down: close the blinds all the way down
• long press down: keep closing until the button is released (or the fully closed position is reached)

Keep in mind that the behaviour of the remote is the following:

• single press up: open the blinds all the way up
• long press up: keep opening until the button is released (or the fully open position is reached)
• single press down: close the blinds all the way down
• long press down: keep closing until the button is released (or the fully closed position is reached)

Sure - that is the behavior I am getting 👍

And this is consistent with the commands I see in the log: _Up / Open_ (0x00) or _Down / Close_ (0x01) when pressing a button, and _Stop_ (0x02) when releasing the button after a while. This is atypical: the remote sends the same command on press/release as on press/hold, to I cannot distinguish between button events x001 and x002. I still think it makes sense to send x003 on long release.

I can see why: no matter if you press or long press, the blind will start move. If it is just a press, it will stop at the end of the roll. If it is long press, it will stop on release of the button.

I agree with you, long press is more descriptive (as long as we get an event when the button has been released). It will also make the codes more consistent with the Ikea 5-buttons remote

The above commit should create a group for the open/close remote on pairing (causing config.group to appear) and update state.buttonevent when pressing buttons:

• 1002: _Up_ press/release or press/hold;
• 1003: _Up_ long release;
• 2002: _Down_ press/release or press/hold;
• 2003: _Down_ long release.

Would appreciate if some-one can test this.

Still to do: setup binding and attribute reporting for the blind.
And below commit should setup the binding and attribute reporting. Untested.

@ebaauw I compiled the latest changes yesterday evening / night. It seems I still have to manually setup the binding and reporting for the position to update in HA - don't know if I might be doing something wrong...

Not entirely sure what or where to look for about the group creation, but the remote is visible in the old webapp and the blind can be added to it, but that does not make the blind respond to remote input.

Finally got my very own FYRTUR.

Not entirely sure what or where to look for about the group creation, but the remote is visible in the old webapp and the blind can be added to it, but that does not make the blind respond to remote input.

There's always one more place to whitelist a new device. The group was created alright, but the remote wasn't yet bound to it. Also found some more bugs, causing the button events not to be generated, and an error in general.xml, causing the device type not to be shown.

It seems I still have to manually setup the binding and reporting for the position

Same here. The REST API plugin seems to setup attribute reporting for _SW Build ID_ (0x0000/0x4000), but nothing more. Probably yet another place to whitelist...

The FYRTUR does support attribute reporting for _Battery Percentage Remaining_ (0x0001/0x0021) and, as we already figured out, for _Current Position Lift Percentage_ (0x0102/0x0008). I manually configured 7200/7200/0 for the battery and 1/300/1 for the position. The REST API issues web socket notifications as the blind moves - cool. It does react to group commands, as we already figured out.

It does support ZigBee scenes storing and recalling the current position with the scene. I don't think the REST API understands this, as we map the position to state.bri. Something for API v2, I would say, similar to exposing the battery percentage.

As I expected, homebridge-hue already supports window covering devices and happily exposes the FYRTUR. I'll need to add support for the open/close remote.

Just got the blinds and pairing was successful on the first try.
They are fully controllable, but my problem is that they show up as closed when they are fully opened, and vice versa, in home assistant as well as in Homekit. How do I change this?

Just got the blinds and pairing was successful on the first try.
They are fully controllable, but my problem is that they show up as closed when they are fully opened, and vice versa, in home assistant as well as in Homekit. How do I change this?

This requires changes in a Home Assistant component - I think @Kane610 is looking at this when time allows :)

There's always one more place to whitelist a new device. The group was created alright, but the remote wasn't yet bound to it. Also found some more bugs, causing the button events not to be generated, and an error in general.xml, causing the device type not to be shown.

The groups and controlling the blinds via remotes is working now :) But it seems that the blinds are not "meshing" which might be what is causing some significant input delay for one of my blinds...?

@jeopold or @revorge if you can just give me the type and model id and I will make sure that they are a part of next hass release

my problem is that they show up as closed when they are fully opened, and vice versa, in home assistant as well as in Homekit.

How do you expose them to HomeKit? Did you manually bind the _Window Covering_ cluster to the RaspBee/ConBee and setup attribute reporting for _Current Position Lift Percentage_? Otherwise the value reported by the REST API is not current.

the blinds are not "meshing"

Of course not; they're end-devices (grey nodes). These connect to a single router (yellow node) [or coordinator (blue node)], their "parent".

some significant input delay for one of my blinds

Which one? Do you control all blinds from all remotes, or do you use one remote per blind?

@ebaauw maybe you can share type and model id of the covers?

the blinds are not "meshing"

Of course not; they're end-devices (grey nodes). These connect to a single router (yellow node) [or coordinator (blue node)], their "parent".

Dohh, just goes to show what a novice I still am about all things zigbee :) Don't know why I had not noticed the node colors....

some significant input delay for one of my blinds

Which one? Do you control all blinds from all remotes, or do you use one remote per blind?

One remote per blind. The remote for that specific blind connects to the farthest away router (Yellow Node :) ) Don't know if that might have something to do with the delay...

@jeopold or @Revorge if you can just give me the type and model id and I will make sure that they are a part of next hass release
@Kane610 Sure, just give me a hint where to look :)

How do you expose them to HomeKit? Did you manually bind the _Window Covering_ cluster to the RaspBee/ConBee and setup attribute reporting for _Current Position Lift Percentage_? Otherwise the value reported by the REST API is not current.
@ebaauw I use the Home Assistant HomeKit component. Just added the blind through Phoscon, and it showed up in Home Assistant and HomeKit, no further configuration made. I noticed that it shows as a light in Phoscon though.

@jeopold
put this in hass configuration.yaml, restart hass and look in the logs, there you should find lights and inside that you could just share the whole part about the covers

logger:
default: info
logs:
pydeconz: debug
homeassistant.components.deconz: debug

The remote for that specific blind connects to the farthest away router (Yellow Node :) ) Don't know if that might have something to do with the delay...

Is that ChildBulb1? By look look of it, the GardinEntre blind connects to the same router. Is that the blind you're controlling from this remote? What type of light is the router? What type of light is KantorBulb1 that GardinStue and the other remote connect to?

Do you still need the repeater after pairing the covers to deconz?

Do you still need the repeater after pairing the covers to deconz?

No :)

The remote for that specific blind connects to the farthest away router (Yellow Node :) ) Don't know if that might have something to do with the delay...

Is that ChildBulb1? By look look of it, the GardinEntre blind connects to the same router. Is that the blind you're controlling from this remote? What type of light is the router? What type of light is KantorBulb1 that GardinStue and the other remote connect to?

Thanks for you help @ebaauw The blind with the delay is GardinKoekken and its remote connects to KontorBulb1, so does the remote of GardinStue (Gardinstue is almost right next to KontorBulb1). Kontorbulb1 is a "Trådfri GU10 Bulb". The remote of GardinEntre connects to ChildBulb1 and this is a "Trådfri E27 WS".

How do you pair the blinds with deCONZ? via "Add new lights" in phoscon?

How do you pair the blinds with deCONZ? via "Add new lights" in phoscon?

Yes or by opening the network from DeCONZ GUI or the old webapp :)

The blind with the delay is GardinKoekken

According to the screenshot, that blind is connected to the RapsBee/ConBee; the other two (without delay) are connected to IKEA Trådfri bulbs. I would theorise that the Trådfri firmware handles groupcasts for child devices differently than the RaspBee/ConBee firmware and/or deCONZ core, causing the delay. I would try and re-pair the blind with the ConBee/RaspBee far away, in an effort to force it to select a Trådfri bulb as parent.

How do you pair the blinds with deCONZ? via "Add new lights" in phoscon?

Yes or by opening the network from DeCONZ GUI or the old webapp :)

Do _not_ open the network from the GUI. Devices will join the network alright, but no REST API resources will be created.

The blind with the delay is GardinKoekken

According to the screenshot, that blind is connected to the RapsBee/ConBee; the other two (without delay) are connected to IKEA Trådfri bulbs. I would theorise that the Trådfri firmware handles groupcasts for child devices differently than the RaspBee/ConBee firmware and/or deCONZ core, causing the delay. I would try and re-pair the blind with the ConBee/RaspBee far away, in an effort to force it to select a Trådfri bulb as parent.

Thanks alot for your kind help :) I'll try that later tonight.

@jeopold
put this in hass configuration.yaml, restart hass and look in the logs, there you should find lights and inside that you could just share the whole part about the covers

logger:
default: info
logs:
pydeconz: debug
homeassistant.components.deconz: debug

Is this it? @Kane610

Ikea instructions are a bit crap.

Here's how to reset the blinds and get them in pairing mode:

• Keep pressing both the buttons on the blinds for 5 seconds or more
• The light slowly flashes 3 times and then off
• Release the buttons, the light will slowly flash
• Open the network from phoscon by using "Add new lights"

It now works!

@Revorge that's it!

According to the screenshot, that blind is connected to the RapsBee/ConBee; the other two (without delay) are connected to IKEA Trådfri bulbs. I would theorise that the Trådfri firmware handles groupcasts for child devices differently than the RaspBee/ConBee firmware and/or deCONZ core, causing the delay. I would try and re-pair the blind with the ConBee/RaspBee far away, in an effort to force it to select a Trådfri bulb as parent.

@ebaauw That solved it :) Thanks once again for the excellent help 👍

The API not to update the current blind position (bri), unless I manually read the attributes for the "window covering" cluster from the deCONZ GUI. Is that normal?

See above:

It seems I still have to manually setup the binding and reporting for the position

Same here. The REST API plugin seems to setup attribute reporting for SW Build ID (0x0000/0x4000), but nothing more. Probably yet another place to whitelist...

@manup, I could really use your help here.

@paolotremadio You currently need to manually create a binding between raspbee / conbee and blinds window covering cluster + setup reporting for the position. Ebaauw posted an excellent guide earlier in this issue.

See above:

It seems I still have to manually setup the binding and reporting for the position

Same here. The REST API plugin seems to setup attribute reporting for SW Build ID (0x0000/0x4000), but nothing more. Probably yet another place to whitelist...

@manup, I could really use your help here.

So the Window Covering cluster binding is missing?
Do the logs show any indication what is happening?

Unfortunately we don't have a Fyrtur in the office yet :/

@jeopold & @Revorge fixed Hass, waiting for Balloob to cherry pick PR to 0.98 release branch

Here's the log, starting from when I paired the FYRTUR:
log.gz

I got impatient and created the bindings and reporting configuration manually. Not sure exactly when.

I needed I can empty out my test network and re-pair the blind to capture a clean log.

Hello, while waiting for the ikea smart blinds to be available in my country, I have some questions for the users that already have installed them:
-Does the ikea smart blinds support setting the position (for example, 15%, 45% or 80%)?
-Is the current position reported by the smart blind?
-Is it controllable in HA/hassio? Any issues a part of the inversion of the state open/close reported a few messages before?

1. You only can set the end position. When you single press the down button the curtain will go down till the endpoint. If you hold the down button, it will go down until the down button is released.
2. I believe no.
3. Not yet, if you read the comments, there is a first release to test a couple of thing. Unfortunately it isn't available in HA / Hassio. Hopefully the next release.

• yes, you can set the position in percentage
• yes, it gets reported even when the blind is moving
• a patch for HA is on its way

Does the ikea smart blinds support setting the position (for example, 15%, 45% or 80%)?

Yes it does, both directly in phoscon app or third party software. I got it working with Home Assistant and a fix for the reversed open / close state is prepared for a coming version of HA.

Is the current position reported by the smart blind?

Yes, with correct binding and reporting configured in deconz. A solution to automate this is currently under "investigation"

Is it controllable in HA/hassio? Any issues a part of the inversion of the state open/close reported a few messages before?

Yes it is and no issues beside the incorrect open / close state and the inversion of the up / down button controls. Again, a fix is already made and will hopefully be included in the 0.98 branch of HA.

Thank you for the quick replies! I'll try to get a couple of smart blinds when they are available!

Sounds great!
I've already installed my blinds so I'm ready to test this :)

Here's the log, starting from when I paired the FYRTUR:
log.gz

I got impatient and created the bindings and reporting configuration manually. Not sure exactly when.

I needed I can empty out my test network and re-pair the blind to capture a clean log.

The binding verification seems to be processed, would be interesting to see what happens when the binding isn't intakt with a freshly joined Fyrtur.

Aug 27 15:26:12 pi1 deCONZ[18679]: 15:26:12:517 binding for cluster 0x0102 of 0x000D6FFFFE9E00AA exists (verified by reporting)
Aug 27 15:26:12 pi1 deCONZ[18679]: 15:26:12:517 skip configure report for cluster: 0x0102 attr: 0x0008 of node 0x000D6FFFFE9E00AA (seems to be active)
Aug 27 15:26:12 pi1 deCONZ[18679]: 15:26:12:517 Force binding of attribute reporting for node Bathroom Blind

I’ll setup a test this weekend.

I just installed a Fyrtur blind today, and it seems to work OK. It gos up and down as I want to, and reports status after I did the manual binding.
My system is Ubuntu 18.04, HomeSeer 3.0.0.534, JowiHue 2.0.4.6 and deConz 2_05_67
So the blinds works just fine.

However, I cannot connect the IKEA remote to my system. Is there a special trick to get it connected, or is something that will come in the future?
Right now the remote seems to be in some kind of limbo - I can see it in deConz GUI, bot not in Phoscon, and I cannot control anything with it.

However, I cannot connect the IKEA remote to my system. Is there a special trick to get it connected, or is something that will come in the future?
Right now the remote seems to be in some kind of limbo - I can see it in deConz GUI, bot not in Phoscon, and I cannot control anything with it.

In Phoscon app open menu -> help and "Old Webapp" The remote should show up here as a group. Add blind(s) to group.

Is it controllable in HA/hassio? Any issues a part of the inversion of the state open/close reported a few messages before?

Fix just released and everything is now working as intended :)

Thanks for verifying @Revorge

I still don't get a group for the remote. On raspbee 26330500 deconz 2.05.67

See above, https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1121#issuecomment-525257414: You’ll need the post v2.05.67 commit for that.

Oh ok thanks.

The binding verification seems to be processed, would be interesting to see what happens when the binding isn't intakt with a freshly joined Fyrtur.

Emptied my test network, except for the Fyrtur and the open/close remote, then reset the Fyrtur. Attached the deCONZ log:
fyrtur.log.gz
and the sniffer log:
fyrtur.pcapng.gz

The REST API did eventually create the binding and reporting config, but I think only after reading the _Window Covering_ cluster in the GUI.

I had it running for 24 hours with no binding. Could not create bindings today, timed out. Blinds unreachable. Deleted them, factory reset, rejoined the network and created the bindings. All working now. Hope they are stable.
Wondering what the 1 sec reporting interval does to battery life though (not sure what Ikea had in mind).

What do I have to do to see the blinds in Home Assistant? I do see them in deCONZ and they are connected to the controller, but thats the only place that I see them. I'm using Home Assistant 0.91.1. Do I have to upgrade to a newer version? Do I have to create a binding to get it to work? And if I have to create a binding, how do I do that? I dont see it as i light in the Phoscon app or in the Web app.

IIRC 0.91 should support covers. But if you're asking for support you should start with the latest versions of the software

But shouldn't I see them in the web app or in Phoscon? If I should see them there, I think the error is in deCONZ. I have firmware version 26330500 on the ConBee stick, think that is the latest.

Haven't added mine to deconz yet, but certain devices doesn't show in frontend right when support has been added, can't say in this case

See above, #1121 (comment): You’ll need the post v2.05.67 commit for that.

Any indication when the remote group creation is going to be tagged to the next version?

I have a question on the remote for the blinds. The REST API info shows a ZHASwtich with an "on":true/false attribute where I would expect a buttonevent value normally. Is this going to change soon or is theis on attribute staying?

{
"state": {
"lastupdated": "none"
},
"config": {
"on": true,
"alert": "none",
"battery": 74,
"reachable": true
},
"name": "TRADFRI open/close remote ",
"type": "ZHASwitch",
"modelid": "TRADFRI open/close remote",
"manufacturername": "IKEA of Sweden",
"swversion": "2.2.008",
"uniqueid": "00:0d:6f:ff:fe:d0:9b:30-01-1000",
"ep": 1,
"etag": "f2ce80986cee1a9c6b19d54431c145c3",
"mode": 1
}

That’s config.on to enable/disable the sensor. state.buttonevent and config.group Should appear, once the group binding is in place. Unfortunately, that isn’t yet created by v2.05.67, see above.

Clear, got confused on the config part. Age thing I guess :-)

Is it created in the new version 2.05.69 or we better wait now?

Hey.
When will this be part of the stable release, so it is just plug and play? I have bought a conbee stick 2 and just installed the software on my pi, but have no experience in using this stuff, so I guess I'll wait until it becomes part of the stable release.

Both the blind and the open/close controller should be fully supported by the REST API plugin as of deCONZ v2.05.69.

The blind is exposed as a /lights resource:

{
  "etag": "c26cb3cb86b9c5a77211b6c724c364b4",
  "hascolor": false,
  "manufacturername": "IKEA of Sweden",
  "modelid": "FYRTUR block-out roller blind",
  "name": "Bathroom Blind",
  "state": {
    "alert": "none",
    "bri": 0,
    "on": false,
    "reachable": true
  },
  "swversion": "2.2.007",
  "type": "Window covering device",
  "uniqueid": "00:0d:6f:ff:fe:9e:00:aa-01"
}

Notes:

• Setting state.bri to 0 (and/or state.on to false) will open the blind; setting state.bri to 254 (or state.on to true) will close it. Setting state.bri to 127 will open the blind for 50%;
• Note that the battery percentage remaining isn't exposed, but you can view it in the deCONZ GUI;
• The REST API plugin should eventually setup attribute reporting for the _Current Position Lift Percentrage_ atrribute 0x0008 in the _Window Covering_ cluster 0x0102, but this could take a long time. If state.bri doesn't update, you might want to setup attribute reporting manually in the deCONZ GUI. See https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1121#issuecomment-524617659 above.

The remote is exposed as a /sensors resource:

{
  "config": {
    "alert": "none",
    "battery": 87,
    "group": "316",
    "on": true,
    "reachable": true
  },
  "ep": 1,
  "etag": "8bd7fb8dc52097da8ebc2d167b2c8caf",
  "manufacturername": "IKEA of Sweden",
  "mode": 1,
  "modelid": "TRADFRI open/close remote",
  "name": "Bathroom Blind Control",
  "state": {
    "buttonevent": 2002,
    "lastupdated": "2019-09-02T21:49:50"
  },
  "swversion": "2.2.008",
  "type": "ZHASwitch",
  "uniqueid": "00:0d:6f:ff:fe:e3:f4:90-01-1000"
}

Notes:

• It supports state.buttonevent values 1002 (open press), 2002 (close press), 1003 (open long release), and 2003 (close long release). Note that there's no events for short release nor for hold. When long pressing, you'll see a 1002 (on press), followed by a 1003 (on release);
• You might need to press a button after pairing for the REST API plugin to populate config.group and create the group;
• You can add blinds (and other window covering devices, like the Xioami curtain controller) to the group to control them, even when deCONZ is down. Note that the remote sends _Window Covering_ commands, so the group can only be used to control _Window Covering_ devices.

How to set limit for blinds position directly in deCONZ? I know that I can set the sensor in HA and use stop service but there will always be a delay.

Set limits on the blind. Set them to what you want, double click either up or down button and that will be the new 100%.

The FYRTUR only supports setting the limit on the device itself, see the manual. This functionality is not exposed over ZigBee.

Is there a way to get battery attribute exposed to hass btw?

Not in v2.05.69, but see my latest PR.

How do I pair my FYRTUR control?

I got it into Home Assistant, and can see in the logs that when I press the buttons, different websocket data is comming. However I cant see it in the deCONZ webapp.

Look for https://www.home-assistant.io/components/deconz/ and deconz_event :)

I had to reboot my RPI today and the blind is not reporting updates anymore. I've done the unbind/bind manually + the reporting but it still doesn't. Any clues?

Before reboot I could see a blinking green circle on the deCONZ UI on the Blinds node. Now it is grey, unless I read attributes (then is Blue)

Are the attributes actually being read? If yes, it’s the binding/attribute reporting setup. If no, the blind lost connectivity to/from the RaspBee. If this happened after resetting / power cycling the RaspBee, most likely the blind reconnected to a parent router that doesn’t like it. If you can find the router, you might power it off and see if the blind selects another parent. Otherwise, try to reset the blind and re-pair it.

It seems like, as a possible artifact of the reversing logic being removed, the state of the blind is reported as closed whenever it's anything but at 100% open (fully retracted). It seems to me (and going by this fix to a HA lovelace card), it should be the opposite, and it should only report closed when it is at 0% (fully extended).

Are the attributes actually being read? If yes, it’s the binding/attribute reporting setup. If no, the blind lost connectivity to/from the RaspBee. If this happened after resetting / power cycling the RaspBee, most likely the blind reconnected to a parent router that doesn’t like it. If you can find the router, you might power it off and see if the blind selects another parent. Otherwise, try to reset the blind and re-pair it.

The attributes have been read. The blind is connected to an Ikea tradfri outlet instead of directly to the deCONZ conbee. I'll try to unplug the socket and see how it goes. About resetting: do you mean just resetting the blind or also removing the node from deCONZ?

I've fixed it by doing the following:

• Unplug the ikea tradfri outlet that was the parent router for the blind
• Woke up the blinds using the buttons on the blind itself
  And that was it: the blind selected the conbee as new parent and it is now reporting.

Should it not just work, no matter who's the parent?

Guys do you have correct open/close logic with latest Home Assistant? I am still on 0.95.4 but the Fyrtur blind logic is reversed. I have several other blinds in HA like Fibaro roller shutter (z-wave), and all of them have the logic 0% is closed (down) and 100% is fully open (up). Apple HomeKit follows the same principle. All my devices are exposed to HomeKit, I want to use Fyrtur blind as well.

Fyrtur works and position reporting also works. After manual binding it is instantaneous. But the logic is reversed. When the blind is fully up it reports 0% and therefore in HomeKit it is closed, also the icon is a closed blind. Can I reverse this somehow?

I have the latest Phoscon and Conbee firmware (2.05.69 and 26330500). For the time being I postponed updating Home Assistant to the latest release as I have to get rid of some breaking changes but if the logic is fixed in the current release I have no other choice. Thanks

It seems like, as a possible artifact of the reversing logic being removed, the state of the blind is reported as closed whenever it's anything but at 100% open (fully retracted). It seems to me (and going by this fix to a HA lovelace card), it should be the opposite, and it should only report closed when it is at 0% (fully extended).

I think you are probably right about this... Perhaps @Kane610 can chime in?

I have the latest Phoscon and Conbee firmware (2.05.69 and 26330500). For the time being I postponed updating Home Assistant to the latest release as I have to get rid of some breaking changes but if the logic is fixed in the current release I have no other choice. Thanks

This is fixed in HA 0.98

@A320Peter it is common and expected to use the latest version of software before reporting issues. Following those guidelines it will probably work out for you :)

@Kane610 you are right :) I have just updated to HA 0.98 and now the logic is correct. However there is something else came up again.

On 0.95.4 regardless of the reversed logic moving the blind with the position slider worked perfectly.

On 0.98 closing the blind (moving down) is okey. But when I open the a blind (moving up) by a few percentage (or completely) initially it starts to move down (closing direction) then stops and a second later it moves up to the target position. It does like this all the time.

Actually, I've experienced the same behaviour with it moving in the other direction first, but I thought it was related to slider entity row, but if @A320Peter isn't using that, then maybe not?

I use HomeKit component too and if I control the blind from the Apple Home app it has the same behavior. Initially it moves in the other direction then stops and changes to the correct direction.

@ebaauw I am terribly sorry to ask such a basic question but I am looking at getting the Ikea FYRTUR blinds and have a Hue v2 square hub, I do not have any other Tradfri devices, would this blind and switch work directly with this hub and homebridge-hue? Or do I need the Raspbee and deCONZ?
I am using a Raspberry Pi4 for my Homebridge service.
Many thanks if you can help :)

No, the Hue bridge doesn’t support it.

No, the Hue bridge doesn’t support it.

Oh Ok thanks @ebaauw So should I get a Tradfri Bridge and Blinds and use homebridge-ikea-tradfri-gateway ?
Or get Raspbee and deCONZ to use on my RPI4 and use homebridge-hue and deconz-rest-plugin ?

Sorry I am quite new to this, and ultimately want to get the blinds, use them natively in the Home App on my iPhone with Siri. So what ever is the best and most stable solution. The reason I have steered clear from Tradfri in the past, is the stability of the Ikea software implementation, it was no where near my Hue implementation (99% of my home) when I bought it all, the responsiveness was woeful, I am hopeful to get the blinds and it will work really well with one of the above solutions.

I haven’t checked myself how the FYRTUR works with the Trådfri hub. I understand the hub would expose the blind natively to HomeKit. I don’t know the homebridge plugin for the hub.

Stability can be challenging in a multi-vendor ZigBee network, but my FYRTUR is exceeding my expectations. It picked a Hue light as it’s parent router and I haven’t had any issues. I’m not using the Trådfri repeater that came with the blind. I sort of expect it to have similar issues with deCONZ as the Trådfri lights, but it’s behaving nicely in my small test network.

Since this is turning into a discussion/support thread, I've moved the two issues discovered, into separate issues.

I haven’t checked myself how the FYRTUR works with the Trådfri hub. I understand the hub would expose the blind natively to HomeKit. I don’t know the homebridge plugin for the hub.

Stability can be challenging in a multi-vendor ZigBee network, but my FYRTUR is exceeding my expectations. It picked a Hue light as it’s parent router and I haven’t had any issues. I’m not using the Trådfri repeater that came with the blind. I sort of expect it to have similar issues with deCONZ as the Trådfri lights, but it’s behaving nicely in my small test network.

Erik, what do you mean by '_....It picked a Hue light as it’s parent router_'?
I bought myself 2 KADRILJ blinds and want to controle them like @Jbb08 ? by HomeKit. I have a Philips hue-bridge, but this does not support the Ikea blinds. And I use your homebridge-hue plugin for Trafi lamps, connected to my philips hue bridge.
So, I was wondering what solution do you have for the blinds? Using deCONZ? Probably I have to add a deCONZ-usb to my network?!

@skipper79 this was what I was trying to work out.
From what I can decipher from Erik is that he uses a Hue Hub and and Raspbee (or similar) which is installed on his Pi and uses the deCONZ plugin and software to create a new ‘hub’ whereby you don’t need the ikea tradfri hub (although I think you still need it if you want to update the firmware of the ikea products)
The blinds can be connected to the deCONZ enabled Pi and then using his Hue homebridge plugin can wrap it all together and add to HomeKit.

His Hue bulb is using the Zigbee ZLL protocol which most mains powered zigbee devices bounce off as it creates a mesh network, but the blinds come with a zigbee repeater effectively doing just that, making the network bigger.
All sounds a little too much, in the UK the tradfri hub is £20 on sale.
And the blinds once connected can be added to HomeKit (in the future via Ikea Home Smart app) via the tradfri homebridge plugin as it supports blinds. (You need the tradfri hub however)

I’m off to ikea tomorrow to see if I can get all this installed.

@Jbb08, using a tradfri hub looks as the most simple solution, but I prefer to have less hubs.... I already have a philips hue bridge and an aqara hub. Maybe a deCONZ usb could be add.
Please let me know your experince after you get all this installed ;-)

Hi all,
thought I'd post my experience of trying to use one of these blinds.
It seems that there are differences in experience here, possibly down to the firmware or maybe even a different set of hardware.

Anyway, onto what I had to battle with....

1. The remote switch
   Pairing is very hit and miss. You press 4 times and it flashes 4 times to reset. It then starts to pulse slowly. Pairing may work if you get a double flash, but it needs to be touching the blind to the side of it - ridiculously short range.
   If you press and hold the pair button and do not get the slow pulse of the LED on the switch, then it will not pair. You may need to wait a random amount of time.

1. The repeater.
   My version (might be UK specific, but this is what I was getting https://www.youtube.com/watch?v=KsBYDNMvE-g
   If you've got the switch paired with the blind, it will stop working if the repeater is switched off.
   The only way I could get the switch to pair with the blind was to first "pair" it with the repeater, then the blind.
   Interesting behaviour - the switch will always pulse slowly when holding the pair button near the repeater. It looks like there's some kind of initial comms that has to take place before it attempts to pair, probably why it fails so easily pairing to the blind.

2. The blind.
   Pairs fine with the conbee. Press and hold until flashes 4 times, turns off for a few seconds, then pulses. Kick discovery off and it gets picked up.
   However, pressing both buttons on the blind to pair additional switches? Doesn't work at all.
   In fact, if I wake the blinds and then just let it time out, the blind is no longer able to be controlled by conbee.
   Worst of both worlds - if the switch is already paired and you wake the blind, it also stops that from working too.
   One more thing - the remote switch is ridiculously low range to the blind to pair.
   Like seriously, it won't pair unless the switch is butted straight up to the side of the blind with the button battery facing you.

So, going to get a hub and see if theres a firmware update to get the same experience everyone here has.

Alternatively, any suggestions will be welcome, you may have an idea I haven't tried yet :)

When you connect the blinds to deCONZ, you want to pair the remote controller(s) with deCONZ as well. No need for the repeater in this case.

Blind clusters & Basic cluster read

How you managed to get that can't get read cluster and basic luster

Blind clusters & Basic cluster read

How you managed to get that can't get read cluster and basic luster

I have the same issue, did you get it to work?
My only guess is that i need to upgrade firmware, and for that i need ikea gateway..

i need to upgrade firmware, and for that i need ikea gateway.

No, you don't.

Erik is right, you don't need the Ikea Gateway. I upgraded the Firmware over deCONZ just fine.
You can use these Instructions for Osram. The Steps are the same

https://phoscon.de/en/support#ota-update-osram-devices

Make sure the use the Ikea download script to get the files to your OTA folder before you try to upgrade.

https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/ikea-ota-download.py

Yeah, thanks.
I found that after some Google, apparently i mixed up Hue with Ikea..

My blinds finally connected after a random amount of factory resets, i guess it could be interference.
One of them i had to take down and pair it close to the conbee, so i recommend pair the blinds before installing them.

The blind seems somewhat picky on what parent they want to work with. My Hue bulbs seem fine, but my Xiaomi curtain controller doesn't (which, unfortunately, is the closest router). I had to power down the Xioami when (re-) pairing the blind to force it to connect to one of the Hue bulbs.

I've had mixed success updating firmware of battery-powered devices using deCONZ on my production network (> 100 nodes). It seems too busy for the update to succeed. Updating from my test network (with only a view devices) works fine, without exception. It takes a couple of hours; make sure to charge the battery up front.

I updated both blinders, both succeed.
But inside deconz web gui it say one have "Version 20190311" and the other "Version 2.2.009"
Inside VNC deconz application it says they have the same version and Image.

The one with "Version 20190311" is behaving alittlebit wierd, i cant set maximum extension inside Home assistant, but other then that it works..

Not sure how to reflash the firmware cause all i get is "idle" when pressing "Update".

The REST API sets swversion to the value of _Date Code_ or of _SW Build ID_, whichever attribute has been read most recently. If you read the attribute in the _Cluster Info_ panel (for the _Basic_ cluster), the API resource is updated.

Note that _Date Code_ (according to the spec) is supposed to be hardware manufacturing date, and should remain unchanged over firmware updates. Some devices use it as the firmware date, though.

After another factory reset it now they both show the same version..
All these wierd problems is just fixed by factory reset, but it also seems like deconz just accept anything even if it doesnt make any sense (like the first problem i had when they showed up in deconz, but not as a blinder)
Oh well, i hope if anyone experiance the same thing as me and now has some information to find :)

TL:DR
Make sure you have good connection to the blinder (IKEA Kadrilj in this situation)
If it doesnt show up as "Window Covering Device" and it only show "000dXXXXXXX": Do a factory reset and make sure you have even better connection, like litterly as close as possible to the Conbee.
Like ebaauw mentioned, other products in the mesh might be the problem also. Mine Ikea Trådfri could also contributed with the problems i had.

Hey! Just added a Fyrtur blind to deCONZ and it paired nice and all but I don't get any signalling over web socket when controlling the blinds. I run 2.05.71

Do you see a web socket notification when reading the _Window Covering_ attributes in the GUI? If so, attribute reporting hasn't been setup.

Running headless right now so can't see it, but probably not. Wasn't that fixed for 71?

My blinds didn‘t show up in phoscon - I try it the last 2 hours with different Typ of action on the blind (press both 10sec / 5sec - 5cm close to the Raspbee and so on) but nothing show up in phoscon - what is the Trick?

i can see it on deconz-gui but not on phoscon / homekit

@mink2k
As I also had some troubles understanding and implementing this, let me just describe how I solved this in my setting:

1. At the moment, you won't see the blinds and remotes in the Phoscon Web App.

2. You can see them in the old web gui (IP/login.html) or with Apps such as Hue Essentials (HE; in Android)

3. You can add the blinds as lamps and the remotes as sensors in Phoscon (they still won't show up there)

4. To add the remote you must add the blind to the remote corresponding group (it's automatically created; see also 2)

5. To make blind control properly working you need to connect to the DeCONZ GUI and follow the instructions posted above. In short: Bind Window Covering to the Gateway manually. Then write a configuration that allows to control lifting and covering to the device. This will enable you to control the blinds via brightness (not in the Phoscon App itself) e.g., with HE

The fifth step is explained above including screenshots.

To create a binding, open the _Bind Dropbox_ panel in the deCONZ GUI. Drag the _Window Covering_ cluster from the blind to the _Source_ field in the dropbox. Drag the 0x01 endpoint from the RaspBee to the _Destination_ field. Then press _Bind_. The dropbox should display success for a brief while. It might take a few attempts. Here's a screenshot (for the Xiaomi curtain controller):

To configure attribute reporting, open the _Cluster Info_ panel in the deCONZ GUI. Select the _Window Covering_ cluster from the blind and scroll down. Double-click on the _Current Position Lift Percentage_ attribute to popup the _Attribute Editor_ window. Enter the reporting values and press _Write Config_. Close the popup window, re-open it and press _Read Config_ to check that the values were stored. It might take a few attempts.

After this, the _Current Position Lift Percentage_ value should change automatically when opening or closing the blind. If this works, we can enhance the REST API plugin to setup the binding and attribute reporting configuration automatically.

Thanks a BILLION for this. It fixed it for me, however there's something odd. In HA the values are higher than what deconz reports. So for one of the blinds deconz Cluster Info is reporting 45, while HA: cover.blinds_door | closed | current_position: 56 friendly_name: Blinds Door supported_features: 15 device_class: window

Is this normal?

@MrHollowPS i have also done this in deCONZ gui like you described (bind & set report values).
Sadly the blind does'nt report the current state periodically or when it changes.

But i can read the current state when i click the "read" button (upper half of the window).
The reporting configuration was set like described:

Is there anything i am doing wrong?
@ the evening i will try to power cycle the device and see if than the changes take effect.
Any other hint?

Did you create a binding as well?

Yes i did. Several times. Manuall reading was ok but automatic reporting was not.
After reading several thread regarding the reporting issue, i restarted my fyrtur (disconnecting and reconnecting the battery) and now reporting is working.

I have another question regarding this blinds:

When i send on/off to get it up/down stop they react really weird.
Sometimes they move correctly completly up/down but sometimes they just moves a few cm and the n stops. That seems completly random when this happens.
When i leave them alone and dont send anything for a while, the seems to work again.

Sending an absolute position with bri/pct works always as it should.

Is this a known issue or i am doing something wrong?
There is a new firmware 2.2.009, anybody has experience with this? Maybe that solves my issue?

This is how the blinds work: a second _Open_ or _Close_ command stops the movement in progress. I suppose it’s for controlling them with the _open/close remote_.

I suspect deCONZ re-sends the command when it doesn’t receive a timely ACK on the first attempt. That would appear pretty random. Indeed, you might want to set the percentage instead (thru state.bri), or use broadcasts (thru /groups) instead of unicast (thru /lights).

I upgraded my Fyrtur to .009. It seems a bit more stable, but the blind still loses its parent (or the parent loses the blind?) every other week or so. Usually fixed by disconnecting the battery for a few seconds.

thx a lot for your thougths on this.
That really could be the issue.
The blind is hopping/connected over an philips light bulb because the conbee II is too far away.
In deCONZ the lines to the blind are green, means that the rssi is good.

Is there another way to increase the timeout in deCONZ (just for this device) or disable the retrys?

Sure i will try your suggestion and try to send the on/off commands (from switches) thru /groups.
Is it sufficient to just put the blind in a seperate group and control the group?
Or must at least two devices in there for a group broadcast to work?

A question regrading upgrade to 009:
I ran the python script (above) on my rpi and it downloaded the files.
After i activated the UOTA server in the old webinterface and entered the uota plugin in deconz-gui, it says no files after pressing query.
Is there anything else i can do to start the upgrade?
Should ill manually select the "blind" file and press upgrade?

Thx a lot for help on getting this blind stable in my setup

In deCONZ the lines to the blind are green, means that the rssi is good.

The blind is a ZigBee end device, which only connects to a single router (its parent). If the GUI shows multiple lines to/from the blind, it’s showing outdated info from the neighbour tables of the routers.

Or must at least two devices in there for a group broadcast to work?

I think it even works when there’s no devices in the group. Note that group membership is stored on the device, the /groups resource only lives in the REST API plugin. A ZigBee group is like a multicast address that the device subscribes to.

A question regrading upgrade to 009:

You need to restart deCONZ after downloading the firmware files. The file will be copied under a new name in the ~/otau directory, that’s how you can tell that the OTAU plugin has picked it up. You need select the blind and press _Query_ in the _Standard OTAU plugin_ panel. The OTAU plugin should populate the device type and firmware revision, and show that a new file is available. For end devices, you need to start the upgrade manually. This will take a couple of hours, make sure the battery is fully charged. Also, it might be challenging to upgrade the firmware over a large mesh.

ok i got you regarding mesh, so i rechecked and now the parent is devinitive an hue ligth bulb and no other route is shown. Should i'll try to repair directly to the conbee? Maybe the retry thing over the parent (hue bulb) is the issue. But the blind is two rooms away from the conbee II so hoping thats not another problem...

Regarding groups:
I am using fhem in combination with deCONZ. When i got you right i am creating a group in deCONZ/phoscon, put the blind in it and use this group in fhem, right?

I have now activated the OTAU plugin again, selected the blind and pressed "Query", then the version and image was filled out. After pressing "Update" the update is running... will see how it goes with 009.

@ebaauw i have now updated the blind to 009 (man that takes long, about ~18h) and repaired it directly to the conbee II.
The behaviour seems a bit better.

You was speaking to not send it as unicast rather i should send it to a group as broadcast.
How can i achieve this with fhem?
I have tried to create a group, add the blind and control this group with on/off on fhem -> nothing happens.
Can you please guide me in the right direction?

Another question i have is regarding battery state of the blind.
I have added the sensor ZHABattery from the blind into fhem but it gets not updated.

Is the battery reporting from the device possible or do i have also bind some cluster & enable reporting?

thx a lot
pOpY

I have tried to create a group, add the blind and control this group with on/off on fhem -> nothing happens.

Damn, I didn’t realise this earlier. The blind supports groups (that’s how the open/close remote communicates with it), but it doesn’t understand _On_ or _Off_. The REST API plugin translates state.on to _Open_ and _Close_ for the blind (or any window covering device), but to _On_ and _Off_ for groups (and obviously for lights). It doesn’t know that this is a group of window covering devices.

Is the battery reporting from the device possible or do i have also bind some cluster & enable reporting?

Yes it is, and the REST API plugin should set it up. You can do this manually by binding the _Power Configuration_ cluster to the coordinator and setting up attribute reporting for _Battery Percentage Remaining_.

ok thx for clarifing that group issue for the blinds.
Is there any workaround for this?

ok, will try to bind the Power Configuration cluster to the coordinator. Can you please post your attribute reporting settings for "Battery Percentage Remaining"? Dont want to set wrong (woo low values) and draining the battery :-)

PS.: readded the bulb (which sits in between the conbee and the blind) and after a few minutes the zigbee mash changed -> now the bulb is repeater again for the blind and the issue with On/Off is back as it was.

So i think the only way to go is really send an broadcast without ack/retry machnism. But how can i achieve this?

The blind is a light sleeper; it polls its parent every five seconds. You would have to set extreme reporting values to influence battery life. Anyways, I use 7200/7200/0, report once every two hours. This is the setting the Hue bridge uses for the Hue motion sensor, and I have no reason to use anything else.

To make the broadcast work from the REST API, the plugin would have to keep track of what devices are in a group, and apply the window covering logic when the group contains (only?) window covering devices. Unlike the Hue bridge, deCONZ shows colour state attributes for a group of only dimmable lights, so there’s nothing to build upon.

As I mentioned above, the alternative to using the broadcast is setting the lift percentage, which the API does on changing state.bri.

@ebaauw

The blind is a light sleeper; it polls its parent every five seconds. You would have to set extreme reporting values to influence battery life. Anyways, I use 7200/7200/0, report once every two hours. This is the setting the Hue bridge uses for the Hue motion sensor, and I have no reason to use anything else.

I have bound the cluster and set the reporting values according to your post.
When i manually read the percentage deCONZ receives it, see screenshots.
But i dont get the reading in fhem to the ZHABattery device?
Is this an deCONZ issue or fhem?

To make the broadcast work from the REST API, the plugin would have to keep track of what devices are in a group, and apply the window covering logic when the group contains (only?) window covering devices. Unlike the Hue bridge, deCONZ shows colour state attributes for a group of only dimmable lights, so there’s nothing to build upon.

So when i got you right this is a change in the deCONZ/Phoscon, how can i achieve that is gets picked up? Open an issue?

As I mentioned above, the alternative to using the broadcast is setting the lift percentage, which the API does on changing state.bri.

Currently i am using thr pct from fhem to set absolute positions on events like sunrise/alexa commands. Will this pct translated to bri from the REST API plugin an sent an unicasts? It seems so because also on pct changes the blind sometimes stops, but then contiunes to execute the absolute transition and correctly ends at the set pct position.

But sadly i only two button events free for the blinds (up/down short press, no long press).
So i can not use pct/bri for that, because how could i stop it then?

The best solution to this would be to work with broadcasts (as the original switch works with the blind). But for that, as i asks above, is a REST API change needed, right?

thx a lot

Is this an deCONZ issue or fhem?

If the ZHABattery sensor shows the value it's an fhem issue.

So when i got you right this is a change in the deCONZ/Phoscon

It's a change in the REST API plugin for sure. I don't expect the API client app needs to be changed, if it already supports groups.

But sadly i only two button events free for the blinds

I don't understand. You would change the rule that sets state.on to true to set state.bri to 255 instead, and the rule that sets state.on to false to set state.bri to 0. No need for additional button events.

If you control the blinds from the open/close remote, you don't use button events at all. You simply add the blind to the remote's group (in config.group of the ZHASwitch resource). After that, the remote controls the blind directly (using broadcasts), without interaction with deCONZ or fhem. If the REST API plugin hasn't created a /groups resource for the remote's group, best add the blind to the group in the deCONZ GUI (in the _Cluster Info_ panel for the _Groups_ cluster). The REST API plugin will eventually create the resource, when reading the _Groups_ cluster (probably after restarting deCONZ, or power cycling the blind).

If the ZHABattery sensor shows the value it's an fhem issue.

thx for confirming.
Already reported and fixed in tomorrows update of fhem.
See here: https://forum.fhem.de/index.php/topic,95424.msg1016154.html#msg1016154
and here: https://svn.fhem.de/trac/changeset/21039/

It's a change in the REST API plugin for sure. I don't expect the API client app needs to be changed, if it already supports groups.

thx for the info.
How can i report this so it gets picked up for a next release?
Should ill open a new issue/ticket?

I don't understand. You would change the rule that sets state.on to true to set state.bri to 255 instead, and the rule that sets state.on to false to set state.bri to 0. No need for additional button events.

Yeah i know. This way i can open/close the blind completely, but how can i stop it?

If you control the blinds from the open/close remote, you don't use button events at all. You simply add the blind to the remote's group (in config.group of the ZHASwitch resource). After that, the remote controls the blind directly (using broadcasts), without interaction with deCONZ or fhem. If the REST API plugin hasn't created a /groups resource for the remote's group, best add the blind to the group in the deCONZ GUI (in the _Cluster Info_ panel for the _Groups_ cluster). The REST API plugin will eventually create the resource, when reading the _Groups_ cluster (probably after restarting deCONZ, or power cycling the blind).

Sorry i am a deCONZ newbie and searched in the GUI / Phoscon and the old Web Interface.
Could not find the part where i can set the group for the Ikea Tradfri Switch (Two buttons).
Also i have 3x HUE Dimmer in this room which controls already different lights and are paired to the HUE Bridge. Those DImmers will be migrated to deCONZ later and currently just fhem has the state and button events of it. Thats the way i want to send and command:

HUE Dimmer -> HUEBridge -> fhem -> deCONZ -> blinds

And when i am using the on/off i have the retry/ack issue i described.

So i have to wait for the API change so can send broadcasts instead of unicasts?

Hey, i'm having trouble getting the Kadrilj to properly show up in the decoznGui. It is only visible as a hex-code not a real name. I can control it via the deconz-gui but it does not show up in Homeassistant. The open/close switch has a proper name. I've tried resetting it a couple of times. Any ideas?

Search for new devices in Phoscon (or open the network in the old web app), and Read the _Basic_ cluster attributes in the _Cluster Info_ panel in the GUI. That should trigger the creation of the REST API resource, and change the name of the node.

If that doesn't work, please post a screenshot of the node, with endpoints and clusters, of the _Basic_ cluster attributes (after having read them) and of the _Node Info_ panel.

It is connected to my conbee2 and one tradfri light.

OK, looks like your unit has a mac address from the new Silabs range, but otherwise it looks OK. What's its firmware version (double-click on _SW Build ID_ and press _Read_ in the _Attribute Editor_ popup window)? 2.2.009?

I don't understand why no resources are created. Did you open the network from Phoscon or the old web app before reading the _Basic_ cluster attributes? With the network open, can you double click on _Model Identifier_ and press _Read_ in the popup window? There should be a message when the read is successful.

2.2.007

Clicking Model Identifier and "read" just says "reading done". I tried while "search for new lights" was active as well.

Yes, the way i added it was by using Phoscon search new lights. I also started the "search light function" and before clicking the "read"-button in the GUI. I am not getting any indication of it actually doing anything when i click read though. A blinking blue-light maybe in the GUI.. This is the first time with the GUI so im not sure how its supposed to look like.

Should have asked this earlier, but what version of deCONZ are you running? Support for the FYRTUR and KADRILJ was introduced in v2.05.67. But so was support for the open/close remote.

Clicking Model Identifier and "read" just says "reading done".

That's good.

Yes, the way i added it was by using Phoscon search new lights. I also started the "search light function" and before clicking the "read"-button in the GUI.

That should do the trick.

2.2.007

You might want to upgrade the firmware to 2.2.009, but I'm not sure if that'll solve your issue.

Hello.

2.05.72 / 12/12/2019
Firmware: 26490700

Is there anyway to force it to forget and reconnect to the network except the double-press 5s thing?

No, that's how to reset the blind.

Hm, alright, i tried resetting it again. But it is still visible in the GUI. Reading teh SW Build Id fails though so i guess it has been forgotten? Or is there something in the factory reset that might cause some lingering issue?

@ebaauw so regarding my issue (retry/ack issue, see posts above) i have to wait for an deCONZ update? right?
How can i achieve that this get's picked up and maybe in one of the next releases?

so regarding my issue (retry/ack issue, see posts above) i have to wait for an deCONZ update? right?

Yes, the REST API plugin needs to be updated to support that. You might be in for a long wait: this is a big change, and there's plenty of other issues which I would deem more urgent.

How can i achieve that this get's picked up and maybe in one of the next releases?

Make the change yourself and submit a pull request.

i tried resetting it again. But it is still visible in the GUI.

Bluntly resetting a device makes the device forget the network, but the network will only forget the device on a _Leave_ message from the device. The deCONZ GUI still remembers the device: you need to delete the node yourself. Other routers in the network still remember the device, so it might re-appear in the GUI, when deCONZ reads the neighbour tables of these routers.

Reading teh SW Build Id fails though so i guess it has been forgotten?

The device is no longer in the network, since it has deleted the network key on reset.

ok, thx. I will wait.
Just meant if i should open an issue so it gets not forgotten?

You guys really seem to be cracking the Fyrtur + Remote combo. I've been struggling with the same over with Zigbee2MQTT. I don't have a way to sniff, but currently Z2M works fine to control over MQTT Fyrtur blinds which are directly bound, and can also see the bound remote Up/Down/Stop commands. But when you bind the remote to a group of the blinds directly, this binding only _sort of_ works. That is, you can open or close the blinds with the remote, but you cannot hold-to-open/release-to-stop, nor can you interrupt an opening/closing blind by pressing the remote button again. You have to wait until it opens entirely or closes entirely. It's also a 1-2s delay before the remote command is registered.

Do you see this behavior with deconz? If not, any theory as to what could be causing it?

I also see the delay, which is probably caused by the blind sleeping and only waking up once every five seconds. The interrupt and hold/release do work for me. You might want to check if the blind and remote have the same parent router. I don’t think this is a hard requirement, but the IKEA hub sets them up with the repeater as common parent.

Thanks. It's interesting that there is no delay when the remote is bound to the blind via the repeater directly (no coordinator); presumably the blinds would be sleeping then as well.

I checked and both remote and blinds are bound to the same parent: the coordinator. I'm not clear how Z2M on the coordinator could "intercept" the remote commands which are bound to the group and interfere with them. My basic (vague) understanding of the way the group-binding works is the remote sends a message to the blinds via the coordinator directly.

Do you happen to have any logs from sniffing traffic between the remote and a bound group of blinds that might be useful for our debugging of this interaction in Z2M?

I'm not clear how Z2M on the coordinator could "intercept" the remote commands which are bound to the group and interfere with them. My basic (vague) understanding of the way the group-binding works is the remote sends a message to the blinds via the coordinator directly.

No, "directly" means exactly that, not: "via the coordinator". The remote sends a broadcast message to the group address, which is picked up by the blind(s) in that group (or rather: that subscribed to the group address). This works even when the coordinator is down.

No, "directly" means exactly that, not: "via the coordinator". The remote sends a broadcast message to the group address, which is picked up by the blind(s) in that group (or rather: that subscribed to the group address). This works even when the coordinator is down.

Interesting, for me the coordinator must be powered on, but with no Z2M running on it for "full" functionality. So maybe that indicates the remote is not in fact being bound to the group in this direct manner. BTW, for _direct_ remote -> blind interactions, the remote wakes up and sends out a broadcast message, then who hangs on to the message while the blinds sleep? And why then would IKEA require a repeater in that scenario? It must serve this role...

who hangs on to the message while the blinds sleep?

The parent router to the blind. In the IKEA setup, that's the repeater (and not the hub). Because of the touch linking IKEA has full control over which device fulfils this role. In deCONZ, on the other hand, you don't have much control over which router the blind will select as it's parent (other than powering down the routers you don't want). If the blind happens to select the coordinator as parent, then yes, it needs to be up and running for the blind to be controlled. That is, the ZigBee router function in the device firmware needs to be up and running, not the gateway function as application software on the system the device is plugged into (in your case Z2M; in our case the deCONZ core application).

@ebaauw is it possible to bind my remote to both my blinds from deconz and not reroute all commands through automations in Home Assistant?
If so how?

No need to mess with the bindings. Simply add both blinds to the group of the remote.

The parent router to the blind. yes, it needs to be up and running for the blind to be controlled. That is, the ZigBee router function in the device firmware needs to be up and running, not the gateway function as application software on the system the device is plugged into (in your case Z2M; in our case the deCONZ core application).

Thanks, that's was my understanding as well. It's odd that my gateway software is somehow interfering with the device firmware's normal action when running. Seems sort of impossible.

BTW, when you say add blinds to the "group of the remote", does the remote occupy a special group id on its own, _a priori_?

Depends on the device firmware. The older ZLL Trådfri firmware picks a group id at random on factory reset. The newer ZigBee 3.0 firmware doesn’t, and you need to create a binding to a group (it sends broadcast until the binding has been made). The REST API plugin should take care of that when pairing a new-firmware device. Either way, the REST API populates config.group when it sees a group command. It should create the /groups resource when pairing the device. If it hasn’t, add the blind to the group in the deCONZ GUI, and the resource will be created next time the plugin queries the blind’s group table (probably on device announce or on restarting deCONZ).

Unfortunately the Remote DOES NOT show up in DECONZ at all. It shows up in home assistant though.

One more thing, for some reason the OTAU plugin does not find any new firmwares for any device that i QUERY. I just manually downloaded the Blinds firmware and updated it. Is there a certain port that it needs to be set in the firewall?

This is my docker-compose config for deconz:
deconz:
container_name: deconz
restart: always
image: marthoc/deconz:latest
networks:
- web
devices:
- /dev/ttyACM1:/dev/ttyACM1
ports:
- '${IP_ADDRESS}:8447:8447'
- '${IP_ADDRESS}:8446:8446'
- '${IP_ADDRESS}:8445:8445'
volumes:
- './config/deconz:/root/.local/share/dresden-elektronik/deCONZ'
- '/etc/localtime:/etc/localtime:ro'
- '/etc/timezone:/etc/timezone:ro'
environment:
- TZ=${TZ}
- USER_ID=${PUID}
- GROUP_ID=${PGID}
- DECONZ_WEB_PORT=8446
- DECONZ_WS_PORT=8445
- DEBUG_INFO=1
- DEBUG_APS=0
- DEBUG_ZCL=0
- DEBUG_ZDP=0
- DEBUG_OTAU=0
- DECONZ_VNC_MODE=1
- DECONZ_VNC_PORT=8447
- DECONZ_VNC_PASSWORD=PASSWORD
- DECONZ_DEVICE=/dev/ttyACM1
- DECONZ_UPNP=1
labels:
- 'traefik.enable=false'

Hi.
Yeah, the remote is a issue. It does not show up in deconz webpage. I have it bound, I see it through vnc and it works on home assistant but would like to make it work directly without creating automation on home assistant.
What am I doing wrong?

Hi.
Yeah, the remote is a issue. It does not show up in deconz webpage. I have it bound, I see it through vnc and it works on home assistant but would like to make it work directly without creating automation on home assistant.
What am I doing wrong?

You can see it in the old gui as a group

@Kane610 is it possible to DISABLE the old GUI after enabling it?

It is just another we page. Nothing special

Hey guys. YOu are talking from an zigbee group which the blind & remote should have, so the retry/sop issue shoul not occur.

Can please anybody of you explain how ill set this up in deCONZ gui exactly?
Step by Step guide incl. scrrenshots would be really nice :-)

Sorry, but dont have much experience with zigbee/deCONZ.

Read the GUI user guide (from the help menu). Use the _Cluster Info_ panel for the server (blue) _Groups_ cluster of the blind.

@ebaauw Sadly the blind lost its connection/binding after i have added another few hue bulbs.
Repaired it iwth the 5second double press, created the bindings & actovated reporting fro percentage lift & battery.

Sadly "pct" will not be updated anymore in fhem but bri will.
Also when i send pct the "retry" issue strikes back also for "pct" will was before stable.

Am i missing some binding/reporting setting?

thx alot

After I found out how to get to the old gui using the rpi and grouped blind with remote they work fine.
Home assistant can also see both devices, good stuff, but i am missing some step the get the blind battery level on home assistant. Anyone knows what am I missing ?

Thank you

EDIT: This is getting old.. now I have it!! sensor.fyrtur_block_out_roller_blind_battery_level .. I could swear iI didnt have it available. Sorry to bother you guys 🥇

After I found out how to get to the old gui using the rpi and grouped blind with remote they work fine.
Home assistant can also see both devices, good stuff, but i am missing some step the get the blind battery level on home assistant. Anyone knows what am I missing ?

Thank you

EDIT: This is getting old.. now I have it!! sensor.fyrtur_block_out_roller_blind_battery_level .. I could swear iI didnt have it available. Sorry to bother you guys 🥇

@adfolfotregosa how did you manage to add it?

After I found out how to get to the old gui using the rpi and grouped blind with remote they work fine.
Home assistant can also see both devices, good stuff, but i am missing some step the get the blind battery level on home assistant. Anyone knows what am I missing ?
Thank you
EDIT: This is getting old.. now I have it!! sensor.fyrtur_block_out_roller_blind_battery_level .. I could swear iI didnt have it available. Sorry to bother you guys 1st_place_medal

@adfolfotregosa how did you manage to add it?

I didn't. I must haven't looked correctly at the sensor list in home assistant. I think I didn't do anything that I can recall. Is it missing on your home assistant?

After I found out how to get to the old gui using the rpi and grouped blind with remote they work fine.
Home assistant can also see both devices, good stuff, but i am missing some step the get the blind battery level on home assistant. Anyone knows what am I missing ?
Thank you
EDIT: This is getting old.. now I have it!! sensor.fyrtur_block_out_roller_blind_battery_level .. I could swear iI didnt have it available. Sorry to bother you guys 1st_place_medal

@adfolfotregosa how did you manage to add it?

I didn't. I must haven't looked correctly at the sensor list in home assistant. I think I didn't do anything that I can recall. Is it missing on your home assistant?

yeah, it's not showing up at all, just the blinds and the battery for the remotes.

Maybe... Using vnc, open the "power configuration" cluster info of the blind and click "read" on "attributes". It should populate "battery percentage remaining".

Maybe that is what I did to make it appear. Honestly I don't know what triggered it but I could swear I didn't had it also

Guys, you have to bind the cluster to the conbee endpoint and setup battery reporting like descibed here: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1121#issuecomment-577537449

Otherwise the reading wont get updated!

Guys, you have to bind the cluster to the conbee endpoint and setup battery reporting like descibed here: #1121 (comment)

Otherwise the reading wont get updated!

Sorry for the offtopic.. but do we have to bind every "power configuration" to the conbee of each Ikea device that as it for it to update battery level? I have remotes battery level so I'm confused

I think just for the blinds, but did not tested with any other product.
Also for the remotes i have the battery and no additional ZHABattery device.

See here: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1827

I think just for the blinds, but did not tested with any other product.
Also for the remotes i have the battery and no additional ZHABattery device.

See here: #1827

Got it. Thank you

Maybe... Using vnc, open the "power configuration" cluster info of the blind and click "read" on "attributes". It should populate "battery percentage remaining".

Maybe that is what I did to make it appear. Honestly I don't know what triggered it but I could swear I didn't had it also

It showed up now with Home Assistant 104.3, with 103.6 it wasn't showing up.

@MrHollowPS
Dont forget to setup reporting as described above, otherwise the value does'nt get updates from the device.

Hi,

I am having a question to the remote E1766.
I could pair it with the conbee2 and I put it in a group together with the blinds. The blinds only moves while I am pressing the button and stops a shortly after I released it.
Is it possible to completely open the blind with a longpress or double press and if yes what do I have to do?

Another thing I would be interested in, is the regarding the bindings. I already did one binding to get position percentage. If I now create another binding will this delete the old one?

Thanks

@MrHollowPS
Dont forget to setup reporting as described above, otherwise the value does'nt get updates from the device.

Yup, thanks.

Hi,
I read the whole thing through, twice, but I can‘t get the remote control my blinds.
The blinds are working fine, they report their states to homeassistant!
To group the remote to the blinds I went to the old WebUI and in the remote group I added the blinds.
When I press a button on the remote, nothing happens.
In Deconz I can see, that the remote is sending something.
Can someone, who got it working, can help me?

After a few days of trials and errors I managed to get both the blind and the remote linked in deconz and working in home assistant o/ Thank you everyone for your comments here !

@yan14 for the remote here is how I got it working
You don't need the ikea zigbee repeater at all (leave it unplugged in the box)

• VNC to deconz/Raspbee
• remove any existing zombie remote (I actually had it in the deconz interface but it was not working)
• set permit join (255)
• Press the pairing button 4 times within 5 seconds.
• web interface/switch add device
• Press and hold the pairing button (for at least 10 seconds?) on the wireless Open/Close remote. Give it enough time to fully join the network! A red light will shine steadily on the Open/Close remote.
• from the vnc interface, you should see a new device binded to the raspbee (if not delete and try again, you most probably need to give it more time to fully join
• once there, you can listen to deconz-event in home assistant and you should see events in HA when you press the remote. You can create automations to open/close the blind when you press the remote buttons.

For the blinds (note for myself when I'll come back here to pair more of them :) )

• VNC to deconz/Raspbee
• remove any existing zombie blind (if any)
• set permit join (255)
• Press on both buttons for 5 seconds. A LED will blink once to confirm the reset.
• web interface/lights add device and wait for the new device to fully join (Can check in VNC interface too)
• open the Cluster Info panel in the deCONZ GUI. Select the Window Covering cluster from the blind and scroll down. Double-click on the Current Position Lift Percentage attribute to popup the Attribute Editor window. Enter the reporting values (1/300/1) and press Write Config. (credits to @ebaauw above)
• can do the same for the remote battery remaining percentage attribute
• in HA, call deconz.device_refresh service (may also need to restart HA) and enjoy!

Home Assistant 0.105.2
Phoscon 2.05.72
Firmware 264A0700

And... I forgot to ask the question I was actually coming here to ask for...
Is there a way to define the close limit of the blind? For my case, it should never go down lower that 150 cm. Can we define this somewhere (150cm = 100% and never go beyond that limit) ?
There is a "Physical closed limit - Lift" attribute in the window covering cluster but it's read only.
Any idea ?

You need to set the limit using the button on the blind - see the manual. It’s not exposed over ZigBee.

ah, RTFM then :)
I haven't seen that, I'll definitely look into it. Thank you.

edit: (if anyone else looking for it)
Set maximum level of extension:
Move the blinds to the desired position using the Open/Close remote or the buttons on blind. When blind is at the desired position, you can double press the up or down button on the blind to save this position as the new maximum level of extension.
If you would like to clear the maximum level of extension setting, first move the blind to the top position. Afterwards, double press either up or down button on the blind .
You cannot perform this setting using the Open/Close remote.

I recently bought two of the FYRTUR smart blinds, but installation was not as easy as my other Zigbee devices. I encountered the following issues:

1. The blinds show up as lights in the Phoscon web interface

This is a minor issue, but since Phoscon has nice images for almost all available products, this is IMHO an oversight

2. IMHO the brightness is inverted in the Phoscon web interface

Also a minor issue. I get the implementation, but it seems odd to me that the 0% brightness setting correlates to the blinds being open.

3. The state of the blinds did not update

For me this was the first major issue I encountered (with deCONZ). With the help of this thread and some trial and error I found out that this is fixable by reading the _Window Covering_ attribute of the device in the deCONZ GUI.

after which you can read the _Window Position_ attribute in the _Cluster Info_ tab

and finally set the reporting configuration

which I have set to the values @cben0ist provided. I'm still doubting whether to use the values he provided or the ones from @ebaauw.

4. The blind stops working after a deCONZ restart

Reading out the _Power Configuration_ and _Window Covering_ seems to fix this

but this is not ideal. IMHO this is unexpected behaviour in deCONZ.

5. The current battery level is not visible in the Phoscon web interface

6. Pairing a on/off remote fails in the Phoscon web interface

When trying to pair an on/off remote it fails within the Phoscon web interface, but the switch is added as can be seen in the old web interface as well as in the deCONZ GUI.

7. The on/off remote does not show up in the Phoscon web interface

I see all my switches, but not these ones.

8. The deconz_event id in Home Assistant for the on/off remote is always TRADFRI open/close remote

I renamed my groups and my sensor to reflect the correct name, but in Home Assistant I always get this event source id: tradfri_open_close_remote. It is possible to work around by using the MAC address that is also send as an unique_id. In an automation this could be used like this:

- id: remote_blind_close
  alias: Close blind
  trigger:
    platform: event
    event_type: deconz_event
    event_data:
      id: tradfri_open_close_remote
      unique_id: "ec:1b:bd:ff:fe:00:00:00"
      event: 2002
  action:
    service: cover.close_cover
    data:
      entity_id: cover.fyrtur_blind

So far some of the above mentioned issues are only visual, others are a bit annoying and most of them I have a workaround available. The only thing that is bothering me currently is that the blinds are not controllable after a deCONZ restart.

Maybe @ebaauw can provide some additional insight for these issues or perhaps a more permanent solution for others. I just notice these issues, because the rest of deCONZ and Phoscon provide such a great, initiative experience.

I cannot help with Phoson (which is not open source and which I hardly use) nor with HA (which I neither use nor know).

Ad 2. That's a philosophical discussion: is the blind 0% closed or 0% open? Different standards look at this differently: ZigBee uses % closed (hence the REST API values); HomeKit uses % open. Of course, Xiaomi don't follow the ZigBee standard here either, so to expose my lumi.curtains from HomeKit, the value gets inverted twice.

Ad 3. It remains challenging to setup battery-powered devices from the REST API plugin. It should setup the attribute reporting, but sometimes it doesn't, or only later, after restarting deCONZ. Luckily you can set it up manually, and luckily this only needs to be done once. Not the most urgent problem.

Ad 4. Seen that sometimes as well. Don't know what's causing this. I try not to restart deCONZ (except after crash or when updating).

@ebaauw Thanks for responding.

Regarding the Phoscon issues, I understand completely. And about the Home Assistant issue, I just want it to be written down somewhere. Perhaps it can be useful for someone else in the future 😄.

Ad 2. Fair enough. Also not a very big issue for me honestly. Just wanted to let you know.

Ad 3. Most of my battery powered Zigbee devices (mostly Lumi / Xiaomi) work prretty well out of the box. It's just not something I'm used to when using deCONZ / Phoscon. Especially with such a popular prodoct.

Ad 4. I hardly restart deCONZ. Only on updates, and it has never crashed on me. So it should be alright. But it's just one more thing to remember, which I try to avoid.

I just wanted to say, that the blind level reporting to homeassistant worked at the beginning, but after an upgrade to .72 it stopped. I couldn’t get it working afterwards.
The battery status would be great but it is a nice to have.
The same thing is with the remote. It would be great to configure it with phoscon but it is just a nice to have for me.

We have the KADRILJ now here for testing (window covering devices will get their own section in the Phoscon App). Seen the same issues that the state can be set but the value isn't read back.

Binding and attribute reporting for 0x0008 wasn't established automatically, this can be fixed.

However reading the attribute manually always yields a value of 0 for some reason. The firmware version is the same as above 20190311 / 2.2.007, we are currently updating to 2.2.009 hopefully this fixes the empty value.

@yan14 I'm currently on 2.05.74 and reading the state of the blinds is working fine for me. But you will need to read those attributes as I have described above to get it working. I'm wondering though if you are experiencing the same issue as @manup on an older firmware.

@manup I'm currently running the latest firmware version 2.2.009, which seem to work correctly when the attributes are manually read once. It seems I have (accidentally) updated my blinds after I have made the screenshot above.

Are you also working on getting the on/off remote working correctly? My remotes seem to lose the association to the cluster once in awhile, which is a bit annoying.

Are you also working on getting the on/off remote working correctly? My remotes seem to lose the association to the cluster once in awhile, which is a bit annoying.

Yes, in short all IKEA device integrations need to be refined as good as possible. There are currently various IKEA related issues in investigation some are tricker then others but I hope they can be all solved.

I'm currently really having issues with one of my blinds. Both of them disappeared over night within deCONZ. After trying to re-add both of them, only one is showing up. The other one isn't showing up in Phoscon and in the deCONZ GUI the device doesn't seem to have any properties:

I cannot read / change anything. I have tried moving the blinds very close to my ConBee II (30cm) and also removing / re-adding them multiple times. Including factory resets. Only to have the same outcome. I'm currently at a loss here...

Regarding phoscon it's quite small changes to get the TRADFRI open/close remote working. The TRÅDFRI on/off switch can be used as template when doing changes to the source code.
Since it's a web app the source code is available.

Regarding my issue with one of my blinds not pairing anymore, a user on the Dutch Gathering of Tweakers forum provided me with a solution, which worked for me:

• Put Phoscon in pairing mode
• Put the FYRTUR / KADRILJ in pairing mode (short press both buttons)
• Long press both buttons on the FYRTUR / KADRILJ until paired with deCONZ

According to my knowledge and the manual this should only trigger a factory reset, but appearently this also does something else... At least it worked for me and I can again control my blinds now from deCONZ / Phoscon / Home Assistant.

I have been investigating the mysteries around the my IKEA FYRTUR rollershades. As I said in my last updates, one of my blinds (_Bedroom east_ in the image below) wouldn't pair anymore. Which I fortunately could solve with the instructions above. It seems the rollershades go in some sort of Zigbee Touchlink pairing mode, but they do pair correctly.

Unfortunately now my other FYRTUR blind (_Bedroom south_ in the image below) is acting up. The blind has issues with reporting the current state. Both of the blinds are connected to the ConBee II coördinator through a TRADFRI E27 WW bulb as seen here:

Before the Bedroom east blind was connected through a TRADFRI Smart Plug, which was a total disaster of it's own. Having it routed through the E27 bulb seems already quite a bit better.

However I'm currently testing with the following attribute configuration set:

Power Configuration

Battery Percentage Remaining, Reporting Configuration

| Configuration | Value |
| --- | --- |
| Min Report Interval | 7200 |
| Max Report Interval | 7200 |
| Reportable Change | 0 |

Poll Control

| Attribute | Value | Value 2 |
| --- | --- | --- |
| Check In Interval | 3600 | 1400 |
| Long Poll Interval | 20 _(0x14)_ | 20 _(0x14)_ |
| Short Poll Interval | 2 _(0x02)_ | 2 _(0x02)_ |
| Fast Poll Interval | 10 | 40 |

Window Covering

Current Position Lift Percentage, Reporting Configuration

| Configuration | Value |
| --- | --- |
| Min Report Interval | 1 |
| Max Report Interval | 300 |
| Reportable Change | 1 |

Both of my blinds are updated with the latest IKEA firmware 2.2.009 (20190311). The Signal Monitor indicated that my both my links have an RSSI of about -65 and a LQI of about 250.

I figured maybe there was something wrong with the factory defined values in the Poll Control attributes. Zigbee defaults recommend the following values:

| Attribute | Value |
| --- | --- |
| Check In Interval | 14400 |
| Long Poll Interval | 20 _(0x14)_ |
| Short Poll Interval | 2 _(0x02)_ |
| Fast Poll Interval | 40 |

but I wanted to try out a more aggressive approach at first. I really like to have more functional blinds with less battery life than half or even none functional blinds with good battery life.

_Edited (13-04-2020) to add value 2 to poll control, which I use for testing._

Hi,

I'm trying to include a FYRTUR blind, and have stumbled upon some difficulties.
After a bit of trying and failing, I finally got the FYRTUR included in deConz via the Phoscon app.
The problem is that the FYRTUR is not showing in the phoscon app.
I can control the blind from the deConz GUI, but not phoscon.

Any advice what the problem can be?
I can also see the blind in Homeseer 3 with JowiHue, but I can't control or get any status in HS3 either.

@StoricU For me pairing always works when I use the method I described above.

You don't have to remove the blinds from deCONZ to make this work.

After updating my deCONZ install to 2.05.75 both of my blinds seem to be working perfectly now. I paired them using the method above and they seem very stable for a couple of days now. I don't know if this has something to do with my settings or the new deCONZ version.

So with the last update (2.05.75) the open close remote is visual in phoscon, but it can't be used in groups.
The second thing is, that my blind is not visible in deconz anymore. So I can't add it to groups.
I can see the blind in the deconz gui and I can control it, most of the times, with home assistant.
Sometimes, the blinds can't be controlled. They lose the connection, even if zigbee mesh routers are nearby.

It just says like this:

I tried permit join and then add light, only add light, open network.
5s double button, 15s double button...

Maybe it's too far away from the raspbee? I do have nearby 3 osram lights and the repeater itself.

Can I set a max-length on the blinds? Some of them are placed in a window where max is 51%. But when i use google assistant to say, "close blind", it will go to full length 100%

Can I set a max-length on the blinds? Some of them are placed in a window where max is 51%. But when i use google assistant to say, "close blind", it will go to full length 100%

@dwarf-rbi , you have to set max length on the blind itself. Follow the manual.
I think you find the correct position, either with deconz or by pressing the buttons on the blind.
When you have the position you want as max, I think you had to double press the physical down button on the blind. Then it sould go up a few centimeters and go down again.

@StoricU Thanks, that worked!

Well the situation doesn't seem very stable at least for me, I just opened vnc to see status and now the blind has a link to a nearby lamp, without doing anything. Now I can control it from deconz but it's not in the rest api.
I'm afraid of doing anything else so it might loose the pairing. Any sugestion?

I have same issue, I got 11 blinds, almost everyday atleast 2 blinds dosnt react from HA, but I can control them through VNC. I like they are going in standby mode and needs to be pinged before working again either by push the "read attributes" button or up/down.
Can i somewhere in deconz/vnc set it so it automatically pings the blinds every hour maybe?

I finally got the Ikea smart blinds connected to DeCONZ, but I have 1 problem and 1 question.

Problem: The level is always "100", thus Home Assistant always shows Open and never Closed :-( This is a bug or feature?
Question: I am running firmware 2.2.007, how do I upgrade to 2.2.009 with DeCONZ? For main powered Ikea stuff is a power cycle the trigger, but what is it for battery powered devices?

The FURTUR and KADRILJ weren't whitelisted for setting up attribute reporting, my bad. @SwoopX had fixed that in https://github.com/dresden-elektronik/deconz-rest-plugin/pull/2668/commits/0151f6fe61f25a2158fb03d7ebf1afe0b4d42ec8. Best setup manually binding and report configuration manually in the GUI, until this change is merged and included in the next release. Alternatively, compile the plugin from that commit and re-pair the blind.

Press _Update_ in the _OTAU plugin_ panel in the GUI. You might try a power cycle (disconnect and reconnect the battery), but I doubt it'll work.

@ebaauw thanks, the manual configuration did it. I can see the level now in HA. I am updating the firmware via the DeCONZ GUI now (1% out of 100% done ;))

@ebaauw thanks, the manual configuration did it. I can see the level now in HA. I am updating the firmware via the DeCONZ GUI now (1% out of 100% done ;))

Hello, I am in the same situation where the blind is fully functional in deCONZ VNC but never added to Phoscon and only the battery appears in Home Assistant.

Could you give me more details on this "manual configuration" ?

Thank you very much !

Could you give me more details on this "manual configuration" ?

Read the User Manual of the deCONZ GUI, under the _Help_ menu.

Blinds aren't supported by Phoscon; I don't know about Home Assistant.

Thank you for this quick answer @ebaauw but it won't help me.

It seems I quoted the wrong message as I intended to ask the question to @alex3305 as he faced the same issue as me and is using home assistant.

@lbrichet Just saw I missed your mention. But you can follow the steps as described here when pairing a 'light' in Phoscon.

However, I just checked my Phoscon install, which I have updated to Little Walter after that guide and I noticed that I don't see the blinds in the Lights overview anymore. I do, however see them in the Blinds group that I have created before. Which is kind of odd IMHO. It seems something is amiss here:

I'm currently eagerly awaiting a new (beta) release that contains 0151f6fe61f25a2158fb03d7ebf1afe0b4d42ec8.

Thank you @alex3305 ! Indeed, if other people arrives to this thread while trying to pair Fyrtur, they don't have to focus on Phoscon as, for me, they don't appear at all. I did everything via deCONZ VNC and they are now working more or less as expected in Home Assistant :)

@lbrichet i have dem in deConz GUI but not in phoscon - but i also dont see them in HomeAssistant. What did you do to have them in HA?

In the GUI i can move the blinds up and down and to given positions. but thats all.

The remote ist present in phoscon and under the switch sektion. but not in the switch editor. and also not in HA.

Any pointers would be appreciated.

Hello @rufinus !

I think my biggest issue was to be patient enough, probably remove deCONZ integration and add it back.

Also, I added the Ikea repeater in the same room.

Hi All,

I have been trying to get my Fyrtur blind to connect with deconz in HA, but so far no luck.
What I did was:

• Starting the pairing on my conbee II
• short press the pairing buttons on the blind
• light turns on
• long press the pairing buttons on the blind

There was a moment that it found it for just a second, but then it was gone and since then it won't pop-up anymore...

Do you guys have an idea what i'm doing wrong?

@Bladian

Im pairing with:

Hold both buttons down on the fyrtur for 8-10seconds. The blinds will go up, and LED will be pulsing white.
Not it’s ready for pairing.
Star the search in HA/Deconz. Use the New Sensor so find it. It will find it even though it’s not a sensor, but it will show in deconz ui when it’s located the blind.
The blind will not show op in deconz because of a current bug, but if you login through VNC to deconz, you can see the device

@dwarf-rbi

Thanks a lot! Just downloaded VNC to take a look and seems it was paired with deconz from the start. Were could i find an explanation of VNC? I want to try to connect the switch to the smart blind.

I would also like to be able to add the open/close switch to my group with two blinds and one repeater.
The thing is, my remote switch (open/close switch/ is not available to be added as a switch? But I can se it in phoscon as a swicth? When I add the switch it seams that it is not pairing? But when I close the dialog it shows up under switches??

@chichin79 If you speak about Home Assistant you can always do automation based on deconz_event.
You go in DeveloperTools, Events, fill in deconz_event and start listening.
You press the switch, and you can use the result as trigger of your automation.

@chichin79 If you speak about Home Assistant you can always do automation based on deconz_event.
You go in DeveloperTools, Events, fill in deconz_event and start listening.
You press the switch, and you can use the result as trigger of your automation.

Ahh, excellent, I will try that.

The Open/Close remote controls the blinds natively - no need for automation. Just add the blinds to the group of the remote. Works even when deCONZ is down.

The Open/Close remote controls the blinds natively - no need for automation. Just add the blinds to the group of the remote. Works even when deCONZ is down.

Thats the thing, the open/close switch does not show up as a switch that I can add to the group. The switch is shown under "switches" in phoscon GUI but I cant add them to a group..

I have a trådfri regular on/off switch and a remote control, and they show up.

The switch is shown under "switches" in phoscon GUI but I cant add them to a group.

I don't know Phoscon. The REST API Plugin creates a group when pairing the Open/Close remote and binds the remote to that group. The group is reported as config.group in the ZHASwitch /sensors resource.

Ok, thanks for the answers, will continue to try to get the switch in to phoscon the "correct" way.

Well in my case I got to add the remote and the blind, and then manually binded them via the bind dropbox. It's kinda working (I need to wait >7s between one button press and the next if not it gets ignored).

The FURTUR and KADRILJ weren't whitelisted for setting up attribute reporting, my bad. @SwoopX had fixed that in 0151f6f. Best setup manually binding and report configuration manually in the GUI, until this change is merged and included in the next release. Alternatively, compile the plugin from that commit and re-pair the blind.

Hi @ebaauw , if I'm not wrong this fix is now included in V2_05_76, which is the one I'm using with home assistant. Some time ago (I can't say if it's this update) the attribute of current_position was updating instantly. Now nothing is updating but the blind stil works. Also should @SwoopX fix make the battery attribute update?
Do I have to reset the blind and re-pair with deconz to take advantage of this fix?

There where some bugs introduced with 76. 77 should fix those

Am I correct to assume that the blinds earlier were controlled by the "bri"-attribute and that the "lift"-attribute has been added in the last few versions? I've included a Fyrtur and successfully control it with the "lift"-attribute in the REST API. I'm using HomeSeer and the JowiHue-plugin there identifies the blind as a light and tries to control it as one. There are reports of this working earlier, and my guess is that JowiHue tries to control it through "bri", which I'm guessing isn't working in .77?

Could the "bri"-attribute be an "alias" of the "lift"-attribute? I guess that would solve the problem?
I've also posted on the JowiHue-forum to see if JowiHue could be changed to use the (correct) "lift"-attribute instead (https://forums.homeseer.com/forum/lighting-primary-technology-plug-ins/lighting-primary-technology-discussion/jowihue-w-vuyk/1389436-ikea-fyrtur-blinds-not-fully-supported)

EDIT:
Ok, just tried to send ""bri": 254" through the REST API and it got correctly translated to ""lift": 100", so I guess the issue is with JowiHue then.

Wim has fixed the problem with JowiHue (HomeSeer) now. :)

Different question, how can I send a stop-command with the REST API? With the switch, it stops when pressing the same button again, is that possible to do with REST?

And could someone explain in a few steps how to add the switch and the blind to the same group, using the REST API?

Different question, how can I send a stop-command with the REST API.

PUT {"lift": "stop"}, (deprecated) {"bri": "stop"}, or (deprecated) {"bri_inc": 0}.

how to add the switch and the blind to the same group, using the REST API?

• GET /sensors/_n_ and notice value _g_ for config.group;
• GET /groups/_g_ and notice the /lights resource IDs under lights;
• PUT /groups/_g_ with a body of {"lights": [_list_]}, where list is the previous list with the id of the light added.

• GET /sensors/_n_ and notice value _g_ for config.group;
• GET /groups/_g_ and notice the /lights resource IDs under lights;
• PUT /groups/_g_ with a body of {"lights": [_list_]}, where list is the previous list with the id of the light added.

I did that now, but it still doesn't respond to the remote...?

sensors/45:
{
"config": {
"alert": "none",
"battery": 87,
"group": "7",
"on": true,
"reachable": true
},
"ep": 1,
"etag": "e7c0d8ebfe9287b260ad61b33dd0e100",
"lastseen": "2020-05-31T08:39:07.985",
"manufacturername": "IKEA of Sweden",
"mode": 1,
"modelid": "TRADFRI open/close remote",
"name": "TRÅDFRI open/close hovedsov",
"state": {
"buttonevent": 2002,
"lastupdated": "2020-05-29T17:50:12.040"
},
"type": "ZHASwitch",
"uniqueid": "ec:1b:bd:ff:fe:df:cc:f9-01-1000"
}

groups/7 (after PUTing {"lights": ["14"]):
{
"action": {
"bri": 127,
"colormode": "hs",
"ct": 0,
"effect": "none",
"hue": 0,
"on": false,
"sat": 127,
"scene": null,
"xy": [
0,
0
]
},
"devicemembership": [
"45"
],
"etag": "6a7ad3330dceb5601e6fff464d679736",
"id": "7",
"lights": [
"14"
],
"name": "TRADFRI open/close remote ",
"scenes": [],
"state": {
"all_on": false,
"any_on": false
},
"type": "LightGroup",
"uniqueid": "ec:1b:bd:ff:fe:df:cc:f9"
}

lights/14:
{
"etag": "c4a7cb040196416adc156e0e729a816d",
"hascolor": false,
"lastseen": "2020-05-31T08:30:03.790",
"manufacturername": "IKEA of Sweden",
"modelid": "FYRTUR block-out roller blind",
"name": "Hovedsov rullegardin høyre",
"state": {
"alert": "none",
"bri": 254,
"lift": 100,
"on": true,
"open": false,
"reachable": true
},
"swversion": "2.2.009",
"type": "Window covering device",
"uniqueid": "68:0a:e2:ff:fe:43:f5:9c-01"
}

Hm, the remote's lastseen is current, but state.lastupdated is from the day before yesterday. That would indicate it hasn't sent any commands recently (or at least that deCONZ didn't receive any).

Hm, the remote's lastseen is current, but state.lastupdated is from the day before yesterday. That would indicate it hasn't sent any commands recently (or at least that deCONZ didn't receive any).

Yeah, I fetched from the REST API before testing the switch.
Now the state.lastupdated also is updated:
"state": {
"buttonevent": 2002,
"lastupdated": "2020-05-31T08:54:24.695"
},

But still no reaction of the blind...

I'm not sure when the API verifies (and where needed fixes) the group membership. It might wait for a sign of life from the Blind before sending the command (as the Blind might be asleep). Have you opened or closed the blind after adding it to the group? Does it still respond to API commands?

You might want to double-check in the deCONZ GUI that the group has been added to the blind. Open the _Cluster Info_ panel, select the blind's _Groups_ cluster, and try the _View Group_ command. It should (briefly) show _SUCCESS_ in the _Status_. If it (briefly) shows _NOT FOUND_, the group hasn't been added. You might try and add it using the _Add Group_ command.

Have you opened or closed the blind after adding it to the group? Does it still respond to API commands?

Yes and yes.

You might want to double-check in the deCONZ GUI that the group has been added to the blind. Open the _Cluster Info_ panel, select the blind's _Groups_ cluster, and try the _View Group_ command. It should (briefly) show _SUCCESS_ in the _Status_. If it (briefly) shows _NOT FOUND_, the group hasn't been added. You might try and add it using the _Add Group_ command.

Yeah, it shows “not found”.
The “add group” asks for a Group ID on the format 0x0000 and/or(?) Group name. What should I enter here? 0x0007? Do I need both ID and name?

7 in hex is 0x0007, indeed. I've yet to see a device that actually supports group names. OK to leave _Group Name_ empty.

The group has been added now, but still no reaction when pressing the switch. Controlling the blind from deCONZ is working fine. The timestamp for the remote is updated when pressing it. Strange...

Odd. As a hail-Mary: reboot the blind (remove the battery for 5 seconds) and double-check that it's still a member of the group. I want to add /groups support for window covering devices, so we can send the group commands from the API.

@ebaauw

I am confused here. You said

PUT {"lift": "stop"},

So I assumed (cannot find any documentation of it) it is a string value. But when I send "lift":"10" to the rest api, an error is returned. How do I need to use this attribute for setting the blinds height?

{"lift": 10}. Not happy about the "stop" value, but copied this behaviour from "bri". I see no better alternative at the moment. For API v2 we should distinguish between commands and attributes (also e.g. to support _Toggle_).

I am working with more strict definitions on the attributes, either int or string , and this "lift" attribute accepts string values, but throws errors when a value is string and numeric... will have to find out how I can get this to work now....

I’m open to suggestions for a more consistent API. Maybe a write-only stop attribute? The {"bri_inc": 0} makes no sense semantically, but at least it’s syntactically consistent.

I do like the option of the write only stop attribute, after all it is only a command, it has nothing to do with the state that is returned. lift would be set then at the actual percentage right?
If you think the bri_inc is easier, I am fine with it also, but indeed that is not a logical one, but at least the integer is not changing.

And in the above JSON sample of Sven-Ove, there is also an "open":false attribute in the state object. What is the meaning of this?
Sorry about all the questions, been unable to catch up here for two months, now getting up, and seem to have missed a few things here. Is there a current document that describes all the newer attributes?

My latest PR implements {"stop": true}.

Eric,

Thanks! Will prepare for it here

I also have the FYRTUR blinds and having trouble with them (grayed out not working up button), with Home Assistant Add-On 5.3.5 (deconz 2.05.75).
Any suggestions how to fix this?

I also have the FYRTUR blinds and having trouble with them (grayed out not working up button), with Home Assistant Add-On 5.3.5 (deconz 2.05.75).
Any suggestions how to fix this?

Have you tried this?
How to manually bind and enable attribute reporting on the example of the current position for windows covering devices

1. Manually bind a cluster
In deconz GUI, select Panels and then Bind dropbox.
For your device as well as the coordinator (blue node), press the most right bullet to expand the available clusters.
For the coordinator: Drag&drop 01 Home Automation Endpoint as destination.
For the device: Select the windows covering cluster as source, also drag&drop it. Take note that this must be a server cluster (colored blue).
Press bind.

2. Manually set up attribute reporting
Then you need to set up attribute reporting. In most cases, there are default settings already defined and should be placed into action either after a deconz restart or power-cycling the device. However, if values do not get updated upon the taken action or not at all, attributes reporting has presumably not been set up properly.

Select windows covering cluster of your device, double click on 0x0008 (current position).
On the lower end of the dialog, enter the values

Min. report interval: 1
Max. report interval: 300
Reportable change: 1

then press write config.

Just my 2 cents. I have setup the same parameters as you suggest @hwikene, but I'm also experiencing the same issue as @mdcobra is reporting. Also with the latest DeCONZ version. It seems that attribute reporting is still not working properly for both of my FYRTUR covers.

After doing a manual read from VNC, the attributes are retrieved correctly. But I really don't want to do that multiple times a day 😉.

Quick edit: Maybe we could open a new issue regarding attribute reporting?

As far as I'm aware, there's two issues related to attribute reporting:

• Sometimes deCONZ doesn't seem to set this up properly. This is a very tough nut to crack; ultimately we need to address this in API v2, when refactoring the whole pairing logic. As a workaround, you can setup the binding and reporting configuration manually in the GUI;
• Sometimes the blind doesn't send reports, even though attribute reporting seems to have been setup properly. The only remedy I've seen for this case is to power-cycle the blind (remove the battery for like 10 seconds).

In either case, deleting, resetting and re-pairing the blind isn't needed. I would even advise against that, as you need to re-set the open limit, and re-join it to the remote's group.

• Sometimes the blind doesn't send reports, even though attribute reporting seems to have been setup properly. The only remedy I've seen for this case is to power-cycle the blind (remove the battery for like 10 seconds).

Great suggestion. Just tried that and that seemed to work on both of my blinds. Hopefully it will keep working.

@ebaauw thanks for the power cycle tip! This has solved it for now, lets see for how long...

Hi guys, after several false starts I have finally got my blind and remote showing up in Deconz and in Home Assistant.

The blind shows as a cover and responds to the up, down, stop buttons and the slider. Seems to be reporting position correctly too. EDIT: I just noticed the blind is also reporting batter status in HA

The remote is also showing battery % in HA, but currently doesn't operate the blind, so presumably isn't paired directly to the blind. However, if I press the buttons I can see deconz_events being generated for each press. Next job, automate the button presses to move the blinds...

The steps I took to get it working involved several attempts, but basically are using the Deconz GUI:

1. Set Deconz to search for new lights.
2. Reset the Ikea Repeater (paperclip in the small hole on the front) and wait until Deconz finds the Repeater
3. Stop Deconz searching for more lights
4. Go to Switches and start Deconz looking for new switches (EDIT: I chose OTHER as the remote isn't in the IKEA set)
5. Reset the Remote (4 rapid clicks on the reset button until the red light comes on)
6. Wait until Deconz finds the switch.
7. Go back to set Deconz to search for new lights
8. Press and hold both buttons on the blind for > 5 seconds until it resets (led flashes)
9. wait until Deconz finds the blind

If any of the above steps fail to find the device, retry from the respective reset step until you finally get it working properly. Once the devices are all found in Deconz, restart HA to ensure it's got the updates, then check the devices are showing up and working as expected. If you find either the remote or blind isn't reporting right in HA, remove it from Deconz and repeat the steps to reset the device and add to Deconz.

It took be several goes to get all the devices working as they are now, so keep trying and don't give up.

Good luck

so presumably isn't paired directly to the blind

You pair both the blind and the controller to deCONZ, not to each other. The API Plugin should bind the remote to a group (check config.group in the ZHASwitch /sensors resource for the remote). You need to add the blind to that group. After that, the remote controls the blind, even when deCONZ is down.

Next job, automate the button presses to move the blinds...

Better use the group to control the blind from the button. The API plugin current cannot send group commands to end devices, and sending unicast commands is bound to run into routing issue.

Note that you don't need to use the repeater, provided the blind and controller are in range of another Zigbee router (or the coordinator).

I'm using the Phoscon GUI through the HA Add-in and using VNC I can see both devices, but can't see how to link them in a group.

In the API, do a PUT of the /groups resource adding the blind’s /lights resource to the lights array. See the API documenration.

Alternative, in the GUI issue an _Add Group_ command from the _Cluster Info_ panel, while selecting the server (blue) _Groups_ cluster of the blind’s node. See the GUI User Manual (under _Help_).

I don’t use Phoscon and wouldn’t know how the web UI works.

@ebaauw I'm hoping you can dumb this one down a bit for me. I'm trying to do the same thing as @Geoff571
First attempt ever at using Deconz. Have about 30mins experience here.

I've got the blind added and the on/off button added. I've got the blind reporting proper status from your post in April about the reporting config. That's done.

Now I want the button to control the blind (will soon be blinds, I've got a dozen of these).
In Home Assistant it gives the Phoscon GUI which has group settings but won't allow me to put the button (switch) into a group.
I can access the Deconz GUI via VNC.

If I select the blind, and select 0004 Groups (1) I can see under "add a group to the device" Group ID 0x0000 and Group Name Blinds. I click exec and it comes back success. Great!

If I select the button, 0004 Groups (0) is greyed out. I assume the (0) means it is not part of a group. With this one I don't have an "Add a group to the device" option. So how do I add the button to the same group as the blind?

@ebaauw, after a bit of persistance and learning how to get the REST API up and running, I've now spent the evening following what you suggested and adding the devices to the group that was created when the remote was added. The remote still isn't working the blind as per the experience of @svenove back in May/June and I'm still at the status I was yesterday, except the remote is no longer generating a deconz_event to HA since I added the light to the group.

So to recap, HA can see both devices and their sensor data, the remote generates. The both show up in Phoscon GUI (via HA Deconz Add-on). I've tried adding the remote to deconz first then the blind and the other way around, all with the same result.

Here is the deconz info as it currently stands:

Sensors/46

    "46": {
        "config": {
            "alert": "none",
            "battery": null,
            "group": "47",
            "on": true,
            "reachable": true
        },
        "ep": 1,
        "etag": "ef34257694f525580286b96f6ad76a50",
        "lastseen": "2020-07-27T22:03:56.671",
        "manufacturername": "IKEA of Sweden",
        "mode": 1,
        "modelid": "TRADFRI open/close remote",
        "name": "TRÅDFRI open/close switch",
        "state": {
            "buttonevent": 1002,
            "lastupdated": "2020-07-27T22:03:56.672"
        },
        "type": "ZHASwitch",
        "uniqueid": "00:0d:6f:ff:fe:b1:c6:80-01-1000"
    },

Lights/12

    "12": {
        "etag": "3a154d9c285b4d7d40685ac3ff2451a6",
        "hascolor": false,
        "lastannounced": null,
        "lastseen": "2020-07-27T20:57:43Z",
        "manufacturername": "IKEA of Sweden",
        "modelid": "KADRILJ roller blind",
        "name": "Window covering device 12",
        "state": {
            "bri": 0,
            "lift": 0,
            "on": false,
            "open": false,
            "reachable": true
        },
        "swversion": "20190311",
        "type": "Window covering device",
        "uniqueid": "d0:cf:5e:ff:fe:d9:92:e1-01"
    },

Grroups/47

    "47": {
        "action": {
            "alert": "none",
            "bri": 127,
            "colormode": "hs",
            "ct": 0,
            "effect": "none",
            "hue": 0,
            "on": false,
            "sat": 127,
            "scene": null,
            "xy": [
                0,
                0
            ]
        },
        "devicemembership": [
            "46"
        ],
        "etag": "57cab4195d7d8a054e477635a742bb66",
        "id": "47",
        "lights": [
            "12"
        ],
        "name": "TRADFRI open/close remote ",
        "scenes": [],
        "state": {
            "all_on": false,
            "any_on": false
        },
        "type": "LightGroup",
        "uniqueid": "00:0d:6f:ff:fe:b1:c6:80"
    }

Can you (or anyone else) advise what else to try?

Here's a late night update for you.

I noticed that the repeater that came with th eblind had dropped off the mesh in Phoscon. Without removing the repeate device, I simple did a reset on it and set Phoscon to search for new lights. The repeater started to appear as active again.

I tried a hunch based on the sequence of how you pair the remote, blind and repeater in the Ikea instructions, and held the reset button on the remote for >10secs, at which point it went into pairing mode again.

The actions of pairing created a new group with a new number, 61506. When I then added the light to that group a miracle occurred and the remote now works the blinds.

New group data below (after adding the light):

{
    "action": {
        "alert": "none",
        "bri": 127,
        "colormode": "hs",
        "ct": 0,
        "effect": "none",
        "hue": 0,
        "on": false,
        "sat": 127,
        "scene": null,
        "xy": [
            0,
            0
        ]
    },
    "devicemembership": [
        "46"
    ],
    "etag": "a1cf8537b8ed6b52334d4b3711a957c2",
    "id": "61506",
    "lights": [
        "12"
    ],
    "name": "TRADFRI open/close remote 47",
    "scenes": [],
    "state": {
        "all_on": true,
        "any_on": true
    },
    "type": "LightGroup",
    "uniqueid": "00:0d:6f:ff:fe:b1:c6:80"
}

I've no idea why those actions got it working and it's late, and I'm in no mood to break it again to try and repeat the steps.

Comparing the two versions of the group, the difference appears to only be the ID, 61506 / 47

@MRobi1 You cannot add a remote to a group. You create a binding from the remote to the group address. The blue cluster on the blind is a server cluster; the grey one on the remote is a client cluster. Also, you cannot use group address 0x0000, that’s a special address.

@Geoff571 Likely the high group was created by the remote on reset whereas the lower was created by the REST API plugin. Are you on the latest firmware for the blind, remote, and repeater? I find sometimes the blind is half lost: it still sends reports, but doesn’t receive commands. Power cycling the blind (remove the battery for 10s) usually remedies that.

@ebaauw ok great, so that tells me I have a problem but it doesn't give me any direction on fixing the issue. How do I create binding from the remote to the group address when it doesn't appear to be creating the group I need?

Press a button on the remote and check the /sensors resource for the remote. If it contains a value for config.group, it’s already bound. The REST API plugin should have created the corresponding /groups resource. Note that Phoscon, for reasons beyond me, no longer shows empty groups.

ok with a fresh pair of eyes this morning, I notice there is another difference between the Group/47 and Group/61506 details (Group #47 has gone btw, presumably overwritten by #61506 as both uniqueid values are the same).

Group#47:

        "name": "TRADFRI open/close remote ",
        "scenes": [],
        "state": {
            **"all_on": false,
            "any_on": false**
        },
        "type": "LightGroup",
        "uniqueid": "00:0d:6f:ff:fe:b1:c6:80"

Group#61506:

    "name": "TRADFRI open/close remote **47**",
    "scenes": [],
    "state": {
        **"all_on": true,
        "any_on": true**
    },
    "type": "LightGroup",
    "uniqueid": "00:0d:6f:ff:fe:b1:c6:80"

Now that is all fully working as expected, I'm not going to touch it as I'm running short of Pixie dust and might not get it working again.

Many thanks for your suggestions and help @ebaauw and good look @MRobi1 and anyone else struggling to get their blinds working. I hope the few bits of experimental info I've added to the subject help someone along.

After saying I was going to leave it alone, I had to unplug the Ikea repeater as it was just attached via an extension lead to my PC while I was testing. Lo and behold, while it's unplugged, the remote doesn't work (and yes, my office is full of other mains powered devices acting as routers). Plug it back in and the remote works again.

I'm now convinced that the Ikea repeater that came with the blind is a significant factor in the remote functionality.

presumably overwritten by #61506 as both uniqueid values are the same

uniqueid isn't, despite it's name. It should only be exposed for resources related to Zigbee devices, best ignore it for other resources, like /groups. Note that it's the mac address of the open/close remote, indicating that the REST API created these /groups resources for the remote.

Lo and behold, while it's unplugged, the remote doesn't work (and yes, my office is full of other mains powered devices acting as routers). Plug it back in and the remote works again.

Probably the remote does work (you should see button event changes in the API), but the commands don't reach the FYRTUR.

If you power down the parent router of an end device, the end device won't notice that at first. Only after waking up, realising that it's parent has gone, and finding a new parent, the end device can once again receive messages. I don't know the exact behaviour for this of the IKEA devices; devices from different vendors react very differently to this. Best power cycle the end device after powering down the parent router.

I'm now convinced that the Ikea repeater that came with the blind is a significant factor in the remote functionality.

I'm not. I've been using my FYRTUR and open/close remote without the repeater ever since I got them.

I do suspect some routers might be incompatible with the IKEA blinds and don't hold on to the group broadcast messages sent by the open/close remote. Sometimes my FYRTUR no longer seems to receive any messages (but still is happily sending out reports), and power cycling the FYRTUR doesn't remedy that. If I power down the lumi.curtain and then power cycle the FYRTUR, it comes back every time. Using the repeater didn't make any difference: the blind seems to roam parents even when previously using the repeater.

OK, I'm getting somewhere. With a whole lot of what I'll call "button smashing" I finally got a group created for the button. It took 3 different buttons, pairing and resetting about 10 times, but finally a group was created with a group ID of 3 for Tradfri open/close remote.

Using the GUI I added all 3 blinds to group 3. The button fully controls 2 of the 3 blinds with the 3rd doing nothing from the button. Manual control of the blind using the 2 buttons on the blind works fine. Control of the blind through home assistant and node red work fine. But the button doesn't control this one.

I can see the "light" as part of the group through rest api as well.
"id":"3","lights":["2","3","4"],"name":"TRADFRI open/close remote "

Any thoughts there?

EDIT: I just saw your note above about power cycling the blind. Pulled the batter for ~10s and now it's responding to the remote commands. Honestly, I'm not sure how I've gotten here but it's working the way I need it to which is all I care about. Now I've got to cut and install 9 more and do this 9 more times! lol

@MRobi1 I'm so glad you got there too. It sounds like your experience was very similar to my trial and error efforts. :-)

Hey all,

after struggling with coupling a few Fyrtur blinds with HomeAssistant I can add the following info.

To be able to control blinds via the wireless remote control after coupling the repeater, the button and the blind to the Conbee network you can navigate to the old deconz web interface (called 'light control' available at http://<your_ip> when Phoscon is at http://<your_ip>/pwa) and add the blind to the group of the switch like this:

After this is done, the button and the blind are coupled and work together without any further need for automation rules in your home automation software. The Zigbee network of course needs to be up and running and available to both the blind and the button.

I also have a question: the reason I was struggling with adding the blinds to the Zigbee network is because I had the 'great' idea to upgrade to the latest deconz docker container and updating the stick firmware before adding the blind. After a long evening of trying and re-trying to get both blind and button coupled I decided to downgrade both Phoscon and the Conbee firmware. I had to revert to Phoscon 2.05.76 and firmware 26580700 to get the blinds and the remotes coupled and working.

What versions of Phoscon and firmware are you using?

@hollie As far as i know, the fyrtur works fine with the latest versions.

However: This question is ideal for Discord :) Please find the link in the readme file.

Deconz: 2.05.79 (as HA addon)
Firmware 26580700

Is the KADRILJ / FYRTUR working by now, I can't figure out what I'm doing wrong, I have the button paired, and the range extender, and when I ask it to pair the blind it does the 'dimming-wave' thing, and then it gives a sharp flash, and turns off. That usually means it's paired, but I don't see it in the list of lights? So what am I doing wrong?

@fribse have you looked to see if the device is shown in the VNC view? If it is then it's probably just the Phoscon App not updating correctly. Try pairing it again, you may need to delete it again in the VNC view first, but give it a go without. I found that I had to repeat the process several times before it finally made it into Phoscon.

Hi @Geoff571, thank you, I don't see anything called cover in vnc, does it show like something else ?

Hi @fribse , when it shows up initially it will have a name that is just a hexadecimal tag until you rename it or until Phoscon finds it and adds the device type as the name.

One way to spot a new device when you first add it is to open VNC and get familiar with the layout of your existing devices then play spot the difference when you add the new one.

Ha ha, 'spot the difference', I've attempted the blind before, so it might already be in the vnc, I can see this one:

Which don't recognize, so I'm going to remove that and see what happens.

That one looks like the open/close switch

Here's my blind to give you an idea what you're looking for:

Good luck

Ok, I found it:

But it seems I can't delete it from VNC, if I delete it, and restart the deconz software it just pops up again without I add it.
So that way I can't get it to get into the phoscon app.

Hello, just for your reference: I've been struggling with getting both remote and blind getting linked to Phoscon at the same time with more recent versions of the firmware and Phoscon. I also saw the wave-flash-turn off behavior when I tried to couple the blinds, and then onze I got it coupled it did not allow me to control it 'upwards' in home assistant.

Please see my remark higher in this thread:

I had to revert to Phoscon 2.05.76 and firmware 26580700 to get the blinds and the remotes coupled and working.

I am still running that version and 3 blinds and remotes are running fine and working as expected for about a month now.

Might be a solution to test to downgrade Phoscon and the firmware on the stick to see if this helps?

Kind regards,
Hollie.

I'm running Phoscon 2.05.79 and so far only had the blind go AWOL once and stop responding. I think it goes to sleep after not being used for a number of days as it still showed up in Phoscon and VNC but stopped responding to either Home assistant or the remote. This was easily was fixed be removing and replacing the battery as has been mentioned previously.

You could try resetting the blind and then removing from VNC, then trying to re-add via Phoscon as a switch, obviously having put the blind into pairing mode. It took me a few goes to get it to show up in Phoscon, though it almost always appeared in VNC.

Hey @Geoff571 thanks for sharing your experience. A question: did you add the blinds to your Zigbee network before upgrading the Phoscon version to 2.05.79?

The reason I ask: I had 1 Fyrtur working as expected on 2.05.76 before I bought 2 additional blinds. Then when I wanted to install the 2 new ones I first updated to 2.05.79. I could not get them working as expected, although I attempted to couple them quite a few times.

The first blind that was already coupled before the upgrade continued to work as expected with 2.05.79.

Then I reverted both Phoscon version and stick firmware as described above and I could bind both new blinds and buttons to the Zigbee network at the first attempt.

I'm just trying to understand if this could be impacting the issue that @fribse is seeing.

All the best,
Hollie.

Hi @hollie

Unfortunately I can't be sure when I upgraded my stick. The release date for .79 was 22/05/2020, which is before I added my blind. Knowing me, when I first encountered issues adding it, the first port of call I'd have made would have been to check for latest firmware, so chances are I did upgrade it either before or while adding my blind about a month or so back. Sorry, that's probably not much help.

When I added mine, I did have to manually link the button and blind to the same group using REST API in order to get direct button control

@Geoff571

OK, then it is maybe time for me to re-attempt the upgrade and to see if everything remains working. Thanks for sharing your experiences with the new Phoscon.

I agree with you that you need to take the additional steps to couple the blind and the button. As I described above, I did this via the 'light control' web interface, also known as the 'old web interface'. The screenshot of that is available higher in this thread.

hi.

Tried to configure 3 new blinds today, and it dont update the state. (nor does it find the battery).

i do have 2 blinds that I got before 2.05.76, and had similar problems as i have now, 2.05.76, fixed those issues and now they are working rock solid, even with the current version.

at the moment, i run 2.05.81, and as stated, I dont get the state, or battery level

since im using Home Assistant I am able for force them going up and down ( with a call service), so communication works.

I remember that it would sometimes help to remove the battery and reinsert it, while search for devices in deCONZ is active. Did you try that? Otherwise I would not know other options

@Nimmsis like @wvuyk suggested indeed works. Like @ebaauw suggested in https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1121#issuecomment-649410495 restarting the node by removing the battery makes reporting work correctly.