This, unfortunately, is a feature. The official Somfy API only supports a few devices, thus there are no options to add these devices.
The Somfy Tahoma integration uses their internal API, which means that all devices are supported. We are in the progress of adding this integration to core, but in the meantime you would need to use the custom component.
ok thanks Mick, good to now. CC is working just nicely!
Any idea when this will be merged into core?
Second big diffenrence I notice, is the updating of the CC is much more responsive than the current core integration? Taking a long time for the position to be updated using core, while the CC is quite swift. Though only for 0% and 100%, it doesnât update while opening/closing?
now that I have you here: what does the alarm_control_panel.alarm do in the CC config? I dont have a Somfy alarm, and yet this device and entity was created.
Unfortunately, I wasnât able to pair the TaHoma Box with homeassistant via homekit controller. Even after the latest Somfy Update, it still doesnât work.
This still could take months, since there is a huge backlog of contributions on core. For now I would just use the custom component and watch the changelogs 
.
This is correct, their official API is very limited, thus the experience with their internal API could be significant better.
This is disabled by default, since many users donât use a Somfy alarm panel. However, there is no way for us to understand if Somfy Protect is enabled or disabled unfortunately. This is the reason why it is included, but not activated.
I am afraid that this wonât work soon. We are not sure if this is a limitation in the homekit_controller implementation in Home Assistant or if this problem is on the Somfy implementation.
Cool, thanks! Any chance of the CC being able to update âliveâ while opening/closing? Ive made an automation and template sensor for my Ikea cover doing so, and would have hoped the Somfy integration to have that built-inâŚ
cover_stookhok_position:
friendly_name: Stookhok position
value_template: >
{% set position = state_attr('cover.raamverduistering_stookhok','current_position') %}
{% set state = states('input_select.raamverduistering_stookhok') %}
{% if state == 'Stationary' %} {{state}} at {{position|int}} %
{% else %} {{state}}
{% endif %}
automation:
alias: Cover stookhok
trigger:
platform: state
entity_id: cover.raamverduistering_stookhok
condition:
>
{{trigger.to_state.attributes.current_position !=
trigger.from_state.attributes.current_position}}
mode: restart
max: 35
action:
service: script.raamverduistering_stookhok
data:
old: '{{trigger.from_state.attributes.current_position}}'
new: '{{trigger.to_state.attributes.current_position}}'
I have a question to @imick and @tetienne: What about combining the official Somfy API and the Somfy WebAPI into one component and providing the superset of features to the user. Whenever possible, you use the official API; if it fails or if the feature is not avialable, you fall back to the WebAPI. On one hand, that would make it more stable; on the other hand you would only have one set of Somfy components in HA instead of two sets of covers/shutters etc.
What do you think?
Feel free to create a feature request on GitHub (GitHub - iMicknl/ha-tahoma: Custom component for Home Assistant to interact with smart devices via Somfy TaHoma or other OverKiz based API's.). I am not sure how feasible this is though, we probably only receive the new position when the execution has been successfully executed.
Current behavior is that we show a different icon in the front-end, when a cover is in moving state.
I like the idea, but it isnât feasible unfortunately. And even if it technically would be possible, it would make it a very complex integration and also hard to pinpoint where the issues are. For now, the official Somfy API is less stable and has less devices supported.
Their internal API based on the Overkiz platform is also used by other platforms (CozyTouch, Rexel, Hi-Kumo), thus a more logical next step would be to rebrand tahoma integration to the overkiz integration.
You could easily use both integrations next to each other, where you can disable duplicate entities.
Ok I will, but Iâll check first if the position is being updated while opening closing. The current core integration doesnât do that as I have just been able to establish with the above automation and template sensor.
@imick sorry if this is the wrong thread, but after dlâing the CC in the correct folder and restarting HA, I still cant see the integration and set it upâŚ
Did a fine install on another system, so am confused now.
Do we need to reboot the host, or restart Home assistant (or restart coreâŚ)
the link is somewhat multi-interpretable:GitHub - iMicknl/ha-tahoma: Custom component for Home Assistant to interact with smart devices via Somfy TaHoma or other OverKiz based API's.
reboot Home Assistant
hmmm, even a host reboot doesnt reveal the Somfy TaHoma integration. Now what./âŚ
update
a 3d restart made it happen⌠Tahoma integration loaded.
This is mainly due to front-end caching probably, only one restart of Home Assistant should be enough.
is there a still lag time like 30 seconds to update percentage of opened window?
The minimum polling interval is set to 30s so yes.
yes that feels really inadequate, eg compared to the ikea roller shutters that report in real time.
Is this a matter of the Tahoma api being pulled by the integration (in which case that could be done more often) or is Tahoma simply pushing each 30 seconds (in which case there probably isnât much to do about it)?
I mean, most of my roller shutters, even the big ones, close within 17 seconds, so a thing like the shutter-card is quite useless for witnessing them slide up and down unfortunately
It would be good to understand more about the use-case and which integration you are using. (Somfy vs Somfy TaHoma). When you use Somfy TaHoma, it will listen to events every 30 seconds. This means it can take up to 30 seconds for a state to change, if you execute an action outside Home Assistant.
If you take an action inside Home Assistant, it will poll for new updates every second. However, if I am not mistaken, TaHoma only shares the new position after the execution of a command is done. However, if you use the default entity cards, you should see a different icon when a cover is opening or closing. (is_opening and is_closing have been implemented).
Which devices do you own and can you see them in the Somfy TaHoma integration? Not all devices are supported via the official Somfy API unfortunately.
using Tahoma Somfy here, mainly because I believed it to be more real time then the core Somfy integration (which I now doubt to be honestâŚ)
the use case is nothing fancy, simply open/close the shutters, or set them at a specified percentage. the action is taken in different ways:
either by talking to Google Home, which has a direct link with Somfy, or by using the devices and entities in HA pushing either the up down arrows, or an automated script.
I do see the icons, real time, (not when talking to google) but not the realm time position. Can this be âforcedâ in any way? Maybe a setting in Somfyâs app/api?
Also, is this identical for the core integration and the Tahoma Somfy integration?
Btw, if I would add the shutters to HA Cloud, would I see the icons when commanding via HA Cloud 's Google Home integration?
The Somfy integration uses an interval of 1 minute, where the Somfy TaHoma integration uses an interval of 30 seconds (and 1 second, when you are executing a command). You do the math 
.
Previously it was set to one second all the time, but Somfy didnât allow this. Thus we settled on 30 seconds (which should be more than low enough!) and 1 second when we executed an action.
The real-time position can not be retrieved unfortunately. Somfy TaHoma api will only share the new position, when the command is fully executed. This is how we show the moving icons as well, we just look if there is still an up/down command running.
Yes, it should be. It just wonât show the is_moving and is_closing when you execute a command directly via tahoma app or google integration. As long as you are routing the command via Home Assistant, it will show.
Hi guys,
I red partially the thread but Iâm not getting if there is a solution for using âSomfy TaHoma via HomeKit Accessory Protocolâ instead âSomfyâ integration standard or from HACS.
I would prefer the first option because I think it works only locally instead through the cloud.
thx
Unfortunately we havenât been able to get this working. In the Somfy TaHoma integration we print the HomeKit code when you have debug mode turned on, but the HomeKit controller in Home Assistant doesnât support the TaHoma bridge. I donât know why.
Hey guys
I am trying to get my Somfy Tahoma components (other than the covers that are already working through the standard Somfy integration, e.g. Izymo on-off receiver) working. Looking through this thread I found the link to the beta version of a custom component for Tahoma https://github.com/imicknl/ha-tahoma#readme and was now trying to get this up and running. I thought I followed the steps in the manual but I canât find the component in the integrations.
Looking through the log I see an error message âSyntaxError: invalid character in identifierâ but I donât see what the issue is. Any ideas? Apologies if it is a dump question, Iâm fairly new to Home Assistant.
