Overkiz integration - Local API [Development / Testers topic]

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?

it a template binary helper (on off), not a normal helper.

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 :slight_smile:

image

2 Likes

@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!! :slight_smile:

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. :wink:

1 Like

That sounds absolutely doable :grimacing: 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.