Can’t expose covers via HomeKit about home_assistant_neosmartblinds HOT 15 CLOSED

Have been happy with the performance but it got me wanting more ... with positioning support in place, the desire to press "stop" is there and also attempting to drag the position slider around and set positions one after the other confuses things dramatically. I have started to play with maintaining state for the cover (so it shows as opening / closing / open / closed) and I think this means using asyncio. As a starter for 10, I got the basics working and refactored cover.py and neo_smart_blind.py so that entity related logic is in cover.py and talking to the hub is done in the other module. Next I'll try to get this async ...

For reference, my playground is on a separate branch on the fork: https://github.com/gee-jay-bee/Home_Assistant_NeoSmartBlinds/tree/state-tracking. Master remains as it was.

from home_assistant_neosmartblinds.

Can you try the latest version in the master branch. That one has been updated to add HomeKit support. I have that build running and HomeKit is working for me.

An updated release hasn't yet been published with that change yet, but you can test it out and let us know if it is working for you.

from home_assistant_neosmartblinds.

New released based on the most current code in the repository is now available. (1.4)

Please give this one a shot.

from home_assistant_neosmartblinds.

The covers are now exposed via Homekit and basic open / close via Siri or Home app works. The home app isn't always giving positive feedback at the point that the blind is either opened or closed (the status says either "opening" or "closing" indefinitely). Things seem to get a little crazy if you attempt to set a position using the slider in the Home app and the blind repeatedly starts and stops moving up and down. I'm not expecting it to work particularly well given that the motor doesn't support percentage positioning (I have not set it to 1 in the config) but wonder if there's anything that can be done to improve it. At a guess, the home app seems to send commands as you drag the slider (this is certainly the case for lights) so I wonder if the back-to-back positioning commands confuse the timers used to estimate position. I couldn't do much testing last night without disturbing others so I will try to play around with it a little more during the day today and report back later.

from home_assistant_neosmartblinds.

A bit more playing confirms what I saw last night. The behaviour seems to be similar when dragging the position slider within HA or using position in Home app.

I wondered whether the paths through the code without percentage positioning support (e.g.

from home_assistant_neosmartblinds.

FYI, I pushed what I did to my fork:

https://github.com/gee-jay-bee/Home_Assistant_NeoSmartBlinds

from home_assistant_neosmartblinds.

How well is this change working on your fork? looking at it, it seems like a good change to include in this repo.

from home_assistant_neosmartblinds.

It got some use today and it's generally OK. I think the favourite/intermediate position logic is a problem though. In general, I think the use of Homekit / percent positioning in HA is not compatible with using the intermediate positions built into the motor. Reason being, as soon as using tilt up/down to set a favourite, this integration has no idea at all where the blind will stop so cannot be in sync from then on. As an aside, the tilt slider isn't particularly intuitive in either way but -- before I started playing with Homekit -- having the services available to tilt up / down to use intermediate position or open / close to ignore the intermediate position was really useful so I wouldn't want to lose them!

My suggestion: add config option to indicate whether to allow favourite positioning or not via set_cover_tilt. If not enabled, do not advertise tilt positioning through supported_features(). I think this will avoid the original Homekit discovery issue. I also get the sense that there's a legacy positioning logic that used 50/51 to get the intermediate positioning so maybe the _percent_support option needs to be an enum of: legacy (use 50/51), implicit (as I have implemented on the fork), explicit (as implemented already when self._percent_support is non-zero). Separating favourite control from position control then gives the user the choice. Does that make sense?

from home_assistant_neosmartblinds.

On second thoughts, perhaps the overload is just going to make things harder to maintain in the long run. With percentage based positioning in play, perhaps the breaking change here is to define new services to move up / down to favourite positions (e.g. neosmartblinds.cover_micro_open and neosmartblinds.cover_micro_close)? That way, access to these functions is independent of the positioning strategy (and perhaps it's more obvious that using those services will not play nicely with positioning!).

I'm happy to mock this up on my fork but I might not get around to it for a day or two.

from home_assistant_neosmartblinds.

The change to move the favourite selection from 50/51 on the position slider and instead to use tile 50/51 was done since with percent support that caused a conflict with being able to select those values. I left the legacy 50/51 for position there as to not break any peoples existing automation. But that could be removed and they could then be required to move to using the tilt.

As you mentioned, the favourite settings still set the potion to 50/51 as there is no feedback from the blinds to know where they actually are, so for now I had just left it like that. I was actually thinking of allowing the user to define the favourite position in the config so that way I could accurately set the position.

Sorry, not really sure what you mean by this "As an aside, the tilt slider isn't particularly intuitive in either way but -- before I started playing with Homekit -- having the services available to tilt up / down to use intermediate position or open / close to ignore the intermediate position was really useful so I wouldn't want to lose them!"

from home_assistant_neosmartblinds.

Sorry I wasn't very clear. I meant that I saw the value of exposing the micro-tilt option by overloading the tilt up / down options. I had these on custom buttons in the UI before I started playing with Homekit. However, I think the non-obvious behaviour is simply the explicit setting of the tilt position because the slider exposed via either Home Assistant or the Home application for the tilt control doesn't really work in a "slider-like" way.

From what you say above, I think the simplest solution to the problem I have on my fork is to make _percent_support an enum as I described and re-use the logic you put in place to move the favourite behaviour to the tilt controls. Then, only "legacy" mode allows 50 / 51 with the cover position control.

I'm still wondering whether it's clearer to define a dedicated service for those intermediate positions and avoid the overload altogether. I suppose you could either set the favourite position through config or as an input argument to those services but doesn't that anyway mean that HA knows the favourite position so there's no need for the micro-tilt? It's all just position logic in HA (could be scenes / multiple favourites)?

from home_assistant_neosmartblinds.

The simple solution seems to have worked, I pushed what I have running locally to my fork

from home_assistant_neosmartblinds.

You beat me to working on getting the Async started. been wanting to get that going for a while, just haven't had time.

from home_assistant_neosmartblinds.

@Carla-J @gee-jay-bee

Can I convince you two to join the Discord I have linked at the bottom of the readme? Would love to be able to discuss the addon more there.

from home_assistant_neosmartblinds.

I'm going to go ahead and close this issue as gee-jay-bee's changes have been merged into master and seem to be working. I am working with Antonio at Netosmartblinds to get the last piece ironed out with the API on their side of things.

from home_assistant_neosmartblinds.