Triggering some blinds manually (ie. not from Flexom/HomeKit) result in a forever loading state in the Home app

[Valerian Saliou]

Hello,

First of all, thanks a ton for this integration to Homebridge! Never liked the official Flexom app to be honest, I'm really happy to have finally found an alternative to it :)

Describe The Bug:

Just having a slight issue with the blinds, where in some not-so-rare cases a blind would stay in loading state in the Home app, that until I reboot my Homebridge server, which would I assume re-poll the blinds states from the Flexom API and thus update HomeKit accessories. Note that this does not seem to not happen to the lights.

To Reproduce:

To reproduce, it looks like to me that the blind would need to be partially closed (eg. 97%), and the action would need to be taken using the physical wall-mounted control, ie. not Flexom nor this integration. In my case, the blinds are a kind of BSO (sun-blocking, can be fully closed yet each flap has an aperture of ~45 deg letting the light pass in, but blocking the sun rays producing heat), so those are not traditional blinds we typically see in most homes.

In case I need to have them in that fully closed state, yet sun-blocking and light-passing, I'd fully close them with the physical control button, and then make them go upwards again and then block them with a control button (all that from the physical button, ie. not from the Flexom app or this integration). In certain cases, Flexom's "buggy" systems understand that the blinds are like 97%-98% closed, while they are in reality 100% closed.

I assume that this non-100% factor is what could make your Homebridge integration to believe that the "closing" or "opening" action is still ongoing, forever, thus resulting in a forever-loading spinner in the Home app.

Image of a similar blinds: https://www.bimobject.com/en/content/showproductimage/aaa5ad73-b452-4ee6-8458-ef03ce4e4f60/371623/default?ver=20200803072245

Expected behavior:

I would expect the loading state to disappear once the blinds are not moving anymore.

Fix pathway:

I have no knowledge of how this Homebridge integration works, but I would assume that it's expecting the window covering accessory value polled from Flexom API to reach some target number in order to consider the action as fulfilled. In such cases, I'd add a ~10% margin for error tolerance in order to consider the action as complete, which would effectively fix the aforementioned issue for BSO-type blinds.

Logs:

Manually 100% closed (full light-blocking BSO) then re-opened the blinds ~15 minutes later to their closed yet light-passing BSO state (so, closed to 100% position but aperture at 45deg).

[27/07/2021, 18:42:13] [Flexom:Office:WindowCovering] changed from 0 to 50
[27/07/2021, 18:59:16] [Flexom:Office:WindowCovering] changed from 50 to 7.000000000000001

After this 18:59 time on 27th, the forever loading state started appearing in the Home app, and is still there right now.

Plugin Config:

        {
            "name": "Flexom",
            "email": "xxxx
            "password": "xxxxx",
            "zones": true,
            "excludeZones": false,
            "excludedZones": [
                {
                    "light": true,
                    "window": true
                }
            ],
            "things": false,
            "platform": "Flexom"
        }

Screenshots:

Environment:

• Plugin Version: v2.2.4
• Homebridge Version: v1.3.4
• Node.js Version: v14.17.1
• NPM Version: v7.17.0
• Operating System: Raspbian GNU/Linux Buster (10)

[Raphaël Sauget]

Hi,
Thanks for your feedback!
I'm currently redeveloping the plugin thanks to Ubiant who provided me with API docs.
I integrated a "tolerance" in the current beta v3.0.0-beta1 which defaults to 0.05 (5%) and that you can override in plugin config.
Can you give it a try?

[Valerian Saliou]

Hey there! Sorry I didn't get notified by GitHub. I saw the repository and package disappear suddently, I thought you got a take-down notice, super happy its back online, with the API docs you had been given!

Oh, just before I update to v3.0.0-beta1, as a quick note, I had to patch the code I was running on my Homebridge as I was being 429-ed on all my requests due to this plugin fetching Ubiant's APIs too frequently. Possibly because I have many IoT accessories to poll for their states (lights + blinds). Would also be super cool to have the poll interval configurable, as I do not need in my case to poll that frequently. This would definitely help alleviate 429s.

Edit: sorry, didn't see #8 ; trying this out rn!

Other than that, didn't get any other issues, using this daily!

[Valerian Saliou]

Update after using v3.0.0-beta3 over the weekend: everything went smooth, I am not seeing the blinds forever-loading issue now. Note that I have set the factor to 0.15, as when I leave the blinds closed at a 45deg angle to let light in, they are usually reported as 10%-something open by Flexom APIs.

Just seeing this error that occured today at the exact same time:

[12/12/2021, 11:23:55] [Flexom] Logout failed {"err":{}}
[12/12/2021, 11:23:55] [Flexom] Logout failed {"err":{}}
[12/12/2021, 11:23:55] [Flexom] Logout failed {"err":{}}
[12/12/2021, 11:23:55] [Flexom] Logout failed {"err":{}}
[12/12/2021, 11:23:55] [Flexom] Logout failed {"err":{}}
[12/12/2021, 11:23:55] [Flexom] Logout failed {"err":{}}
[12/12/2021, 11:23:55] [Flexom] Logout failed {"err":{}}
[12/12/2021, 11:23:55] [Flexom] Logout failed {"err":{}}
[12/12/2021, 11:23:55] [Flexom] Logout failed {"err":{}}
[12/12/2021, 11:23:55] [Flexom] Logout failed {"err":{}}

I'd tend to think there was a WebSocket connection termination by the server or some network error. I don't have further logs about this. But controls are still working at the moment, without requiring any Homebridge restart, so everything is fine.