Hello,
I have paired some roller shutters from fibaro and they are dimable. I was also able to control the shutters with the slider in the homey app, i.e. setting to~ 40%.
But if i want to group the roller shutter in the “group” app, then these devices arenot offered for selection under “dim level”. the device only appears for selection under “window coverings set”.
I tried all combination of the setting changes for the devices and still not working.
Does anyone know why it doesn’t appear under dim level in the group app? Any ideas?
Hints:
group App version v2.4.304
Fibaro app version v3.0.14
Homey version 6.1.0
I saw your post already in the group thread. The reason why I didn’t answered was that I don’t understand the problem correctly.
Because I don’t have no problems to group 2 Fibaro RS2, and the dim slider is available:
The previously paired roller shutter switches look like in the picture from you.
The newly paired roller shutters, the settings, the configurations and the functionalities are the same:
Hint: the difference (toggle switch/double m. switch) has no influence.
The previously paired roller shutter switches can be grouped under “dim level” in the app “group”.
The newly inserted roller shutter not. The ne ones appear only by selecting “window coverings set”:
Since the device “EZ_3” is visible in homey and i can control it in “on/off mode” and “dim level mode”, the question is: Why it doesn’t appear in the app “group” under “dim level”?
Background:
I grouped the shutters and i use the groups in my flows.
Now, if I have some shutters in one group und one or two devices not, then i need to add the missing manually in each flow
From my point of view it is an issue in the “group” App!
I compared the device classes on the developer page and i saw this difference:
Devices, which can be grouped under “Dim Level” in the “group” APP, have the class “windowcoverings”:
Devices, which cannot be inserted, have the class “windowcoverings (Virtual: blinds)”:
is it possible to change the device class from “windowcoverings (Virtual: blinds)” into only"windowcoverings"?
@Jamie
I have contacted homey support and they suspect that the “group” app has a problem. Since the app does not come from homey, they cannot offer any support
It is very helpful, if you can take a short look on this issue and give me/us a hint how it can be solved. Thank you in advance
There is a different between EZ_1 (old) roller shutter and EZ_3 (new).
EZ_1 uses Z-Wave Command Class for the Blind position reports type in the advanced device settings, EZ_3 uses Fibar Command Class.
I remember, that I changed the report type from Z-Wave to Fibar for test purposes. With the report type Fibar the roller blinds didn’t report the dimmlevel state. So please try to change the EZ_3 from Fibar to Z-Wave and try it again.
This is the post where I changed the command class (sorry, only in German language). And Caseda explains something regarding the differences (in English):
The code for the group app does not check against the capability type in anyway sorry. It simply asks homey for all devices and then uses the methods provided _ list of capabilities provided by Athom/honey then to check which devices have {the capability you clicked on} then displays it.
If there is a problem with the capability not showing for you, I suspect that it’s driver of the device you are adding.
When was the device added to homey? Was it before they had window covering capabilities?
the devices were added ~2years ago and due to a recovery issues (some weeks ago) some of them lost the connection to homey and I was forced to re-pair them…With this action i got this problem!
Deleting the old devices and adding them again is not a solution for me. It costs a lot of time and affects the configuration of the flows.
The devices are from Fibaro.
Can the Fibaro app update negatively affects this capability-list? which criteria must be fulfilled so that the group app shows the devices under the category “dim level” or “window covering set”?
What is the difference between these 2 categories? From the function point of view I’m not seeing a difference.
Yes and no.
If the device is included and the app will be updated afterwards does not affect the capability list/type of the device.
If the app is updated and the device is included afterwards, the device uses the new capability list/types.
Afaik the capability list was changed with an update. I don’t know when and why, but you could ask Athom.
Info: All my RS2 were included approx. 2 years ago.
///////////start ///////////
For several years, window coverings (roller shutters, blinds, etc.) used a dim-level capability, which was technically incorrect, as dim-level should only be used for lights of any kind. We introduced the window coverings capability, which has some unique properties, and allowed us to further improve our software.
Unfortunately in your case this means that previously added devices still have the dim-level capability (as the capabilities are set during pairing, and cannot be changed without a re-pair), and the newly added devices have a window covering capability, due to the new settings.
If you want to control all devices with a single group, you’ll have to remove the older devices, and re-pair them to Homey, so the window covering capability is used. Alternatively, you can create 2 groups, and use a flowcard for each respective group in the flows you want to create.
///////////End ///////////
That’s incredible! changing things without regard to the users nor offering an intermediate solution is not OK at all!!! I can’t believe that such a serious change is simply made according to “sink or swim”.
For me it shows that the maturity level of this sw product still low and unstable!
Now I can spend again a toned of hours to re-pair all the devices to be able to group them like before! otherwise, I can go away from the group app and this is sad , because I like the idea behind it makes the flows clear and simple.
That Athom is trying to improve their system is good. Perhaps this change was necessary so that the blades for blinds can finally be adjusted reasonably, who knows. That devices have to be re-paired and flows have to be adjusted I don’t find bad either.
What is definitely not okay, is the communication of Athom what must be considered in case of changes and innovations, what consequences this may have for users. I agree with you there.
, because I like the idea behind it makes the flows clear and simple.