There are still many things that need to be polished for the local API, however it would be good to already run some user tests. Best way to deliver feedback is on our Discord.
I have the connectivity kit with RTS covers. However, I’m unable to move them to ‘my position’. After reading through this thread, I’m a little bit unsure, if this is actually supported by the overkiz API or not!?
I dl the linked repo (so the whole HA fork by Imick) by clicking the Green Code button (select zip) and selected the Overkiz component in that. Copy that as complete folder into your custom_components folder. Then add a “version” key in the manifest file and restart HA.
(I did not do that correctly above, so that is still a cloud install You can see it in the Connected to: field., where it should list your local device id key )
Next screen wil bring you to your credentials I which your enter your own key replacing the xxx’s, user and pw.
what I marked “3” in above picture is my cover.seitenmarkise below.
The state seems reversed. So in below screenshot it is actually NOT deployed which would be “closed” to me? At least the others ( 1 and 2 from above) do show CLOSED when NOT deployed.
However despite it seems inverted! The default UI card does correctly show me the arrows for down and up ! In this example it is again NOT deployed … so the arrow DOWN is just fine! But the state is despite that Closed / current position 100.
I can live with it but thought it might be interesting as it is not the same experience for the 3 different types.
From Somfy recommandation, we map open to deploy and close to undeploy for Awning devices. It’s the case for your Absenkmarkise and Hauptmarkise. But your Seitenmarkise is not reported as an Awning, it’s why you see a reverse state. FYI the same kind of motor can be used for a classic cover where this state is logic.
thank you for the explanation and I understand the logic of the non awning is coming from core then.
Template Covers are also problematic as the issue here is that value_template and position_template cannot been set concurrently in a template cover, so HA assumed the cover is open, when position is 100 and cover is closed when position is 0.
So I would need to use the orignal and template entity both to have a full working solution.
Edit: btw … I understand and support the Somfy logic. I think also for “other” covers many people would like to have 0 = closed = undeployed and 100 = open = deployed …
unfortunately core has no option to actually invert this.
Can you post your diagnostics information here? (or on GitHub gist and link it here). It would be interesting to see the device types, since we are revamping the cover entity.
hey and when revamping the cover entity … maybe also consider that many actuators actually report 1-3 % off … means when they fully open or close the motor itself might stop the motor a moment earlier than the actuator was calibrated which result in something like this:
Just the Somfy ones, there is a download diagnostics button in Home Assistant.
Do you have this issue with the Somfy covers? We will only rewrite the Somfy cover implementation. And even there, I am not in favor of this change. If this is an issue with a certain vendor / platform, they either need to fix this or the Home Assistant integration needs to handle this margin / offset.
Had the same issue. Got it working by patching the api.py file from PR Custom Component: on line 330, there’s a call to timeout(). I just removed the loop=asyncio.get_event_loop() parameter (and the comma of course), so that it reads:
async with async_timeout.timeout(TIMEOUT):
I don’t know if this is really a proper fix, but (after a restart of HA) I was able to install this native Somfy API component - and it has been working like dream (for now): response is like instantaneous!