Looks great, one question about it
why is the binary_sensor needed? (Andys Shade Helper)?
to store the state of the somfy shade.
- trigger:
- platform: state
entity_id:
- cover.media_room_somfy_window_shade
id: "on"
from: opening
to: unknown
- platform: state
entity_id:
- cover.media_room_somfy_window_shade
id: "off"
from: closing
to: unknown
binary_sensor:
- name: Media Room Shade Helper
unique_id: a5c19860-c74d-4b25-8893-982e8b135bcd
state: "{{ trigger.id }}"
What kind of helper is it?
I have done it a bit different from your example, thanks to get me in the right direction.
- cover.keuken_gordijn_rts is the ID I have given the entity provided by Overkiz
- cover.keuken_gordijn is the new cover and sensor.keuken_gordijn is the status helper for the state changes.
template:
- trigger:
- platform: state
entity_id: cover.keuken_gordijn_rts
id: opening
to: opening
- platform: state
entity_id: cover.keuken_gordijn_rts
id: open
from: opening
to: unknown
- platform: state
entity_id: cover.keuken_gordijn_rts
id: closing
to: closing
- platform: state
entity_id: cover.keuken_gordijn_rts
id: closed
from: closing
to: unknown
sensor:
- name: Keuken Gordijn
state: "{{ trigger.id }}"
unique_id: keuken_gordijn
cover:
- platform: template
covers:
keuken_gordijn:
device_class: shade
friendly_name: "Keuken Gordijn"
unique_id: keuken_gordijn
close_cover:
service: cover.close_cover
target:
entity_id: cover.keuken_gordijn_rts
open_cover:
service: cover.open_cover
target:
entity_id: cover.keuken_gordijn_rts
stop_cover:
service: cover.stop_cover
target:
entity_id: cover.keuken_gordijn_rts
value_template: "{{states('sensor.keuken_gordijn')}}"
Now for my next challenge. I want to add āpercentageā state so 0% = closed, 50% = my button, 100% is open and that only these three steps can be chosen when dragging the slider.
I have tried, but with RTS the somfy hub does not know the %, I am not even sure you could hack it, but with my button in my example it does show as āopenā as somfy seems to fully close the shade then re-open it to the my_position when activated.
RTS itself does not have any state or percentage.
But this should be possible as I had it working like that with the TaHoma HomeBridge plugin. With HomeBridge linked to Home Assistant.
The HomeBridge plugin kept the state between 0-50-100% but you could select any percentage between 0-100%.
But as Overkiz now has Local API I really want to do this ānativeā in just Home Assistant.
btw, you can clean up your code a little bit
using your template code you can change
this:
value_template: >
{% if states('sensor.keuken_gordijn') == 'opening' %}
opening
{% elif states('sensor.keuken_gordijn') == 'open' %}
open
{% elif states('sensor.keuken_gordijn') == 'closing' %}
closing
{% elif states('sensor.keuken_gordijn') == 'closed' %}
closed
{% else %}
unknown
{% endif %}
to this:
value_template: "{{states('sensor.keuken_gordijn')}}"
i would like to know if you manage it, as atm if you close the shade a little, with my code it thinks the shade is fully closed, thats only downside.
Thanks, I cleaned up my code and post with that change.
To all devs and coders. The ESPSomfyRTS project offers a handy method to caculate a state in %.
https://github.com/rstrouse/ESPSomfy-RTS
Once ESPSomfyRTS setup is finished there is an option for each cover to set start and end time a cover needs for open and close. Then based on the time the percentage state is calculated.
I would be really cool to get such an option for Overkiz motors. Would that be possible?
This is not allowed in the integration itself. As the policy within the HA development is that the state needs to be real which is not possible with RTS.
With a Template Cover it should be possible to recreate this.
The HomeBridge Tahoma plugin has this implemented by the way, where you can set the time of opening/closing and it gives an estimated percentage. It was never accurate enough for me though, so only used 0% (close) - 50% (my) - 100% (open) which I want to recreate in HA now.
Unfortunately, this wonāt be implemented for the Overkiz integration in core. The HA policies donāt accept this, as mentioned by @danieldeni. The core focus of the Overkiz integration is the control of your Overkiz devices.
It would be possible to use a custom component (or advanced template) to have a āstatefulā RTS cover, controlled by the Overkiz integration. But I donāt have time to build this and/or support this.
There it isā¦the announcement of the announcements
@imick I have installed the new HA with the integrated local api. It works.
Thanks for all the effort and time. I have sent you a donation.
Thanks Martin, appreciated!
From now on, if you face any issues you can create an issue on HA core repository. No need for this topic anymore.
I was waiting for this awesome work for ages. Thank you so much @imick!!
Currently, I have connected Overkiz via Cloud (but Iām not using it) and also, I have added my Somfy devices via Homekit-API
Quick question, what is the migration process for someone on the cloud-API? Is it just removing the current Overkiz-Cloud connection/integration, then re-adding Overkiz and chose to go local? Also, is it correct this will not touch the existing Homekit Controller connection of Somfy devices in any way?
Thanks heaps, so much looking forward to this!
Yes!
I aim to have a better process in the future where the integration will ask to upgrade, after you set up the local API with an existing cloud API entry. Due to time constraints this wasnāt possible for the initial release, and I really wanted to ship this after a year!
So for the people with renamed entities, the current way is not great, but some pain for a local API is perhaps a good tradeoff.
That sounds absolutely doable what do you mean with ārenamed entitiesā? When I remove the cloud API, the entities will be gone and I will get new entities as soon as I add the local API or am I missing something?
Some users have renamed all their entities, and they use the new entity names in their automations and dashboards. This is something you will have to do again if you remove and re-add the integration.