Once installed through HACS, you have to enable it like a classic integration like you did with the original Somfy.
@SeBsZ @martinst OK I will have a look this week to add this service. It should not be over complicated.
@tetienne That should be great when it is implemented. Thanks!
But the problem which I mentioned this saturday about the false triggers:
- This is occurred today a few times, the same error ==>
Logger: homeassistant.components.somfy
Source: helpers/update_coordinator.py:153
Integration: Somfy (documentation, issues)
First occurred: 12:47:54 (4 occurrences)
Last logged: 13:49:06
Error requesting somfy device update data: 502 Server Error: Bad Gateway for url: …
So in the history the state is presented as NOT AVAILABLE for all my roller shutters. I think it is really a problem of the false triggered automations.
Imagine starting a 2000 watt device on the trigger. Then you don’t want to have false triggers.
I’m quite new to Home Assistant maybe I do something wrong. But is it possible to execute the trigger of shutter is OPENED only by the correct ones and not when the status was not available at the moments before. So do I need some exclusion on my trigger?
Hi tetienne,
Thanks, I thought that installing the somfy integration through Configuration panel would install the official one 
So, that didn’t work as expected. Here are the logs, but it just seem to give up after 5 tries. Ideally, I would need an exponential backoff strategy I guess.
I’ve seen there’s an other somfy addon in HACS which you seem to be one of the authors : https://github.com/iMicknl/ha-tahoma
What’s the difference with this one ?
edit: I’ve tested with the non official Somfy TaHoma - Home Assistant from HACS and therefore I get access to all my scenes defined in Tahoma !! So now, it works perfectly because it calls a scene from tahoma. Does this custom component rely on a deprecated API ?
@SeBsZ @martinst I added 3 services related to the slow mode (only available if at least one cover support this mode):
- somfy.open_cover_slowly
- somfy.close_cover_slowly
- somfy.set_cover_position_slowly
Can you please install you too uninstall your Somfy integration and replace it by this one: > lease uninstall the Somfy integration, and reinstall it using this custom component (through HACS for instance): https://github.com/tetienne/somfy-custom-component
You can play with them within the dev tool panels.
Once you will confirm it works fine, I will add them to the main repository.
The Tahoma component uses the unofficial Somfy API. tahomalink.com uses this API. This component supports almost all devices. The Official API is really limited. For instance, the scenarii are not exposed as discovered. Not because I’m lazy, but because of Somfy… I’m also involved in this component. See the related topic: Tahoma Integration Refactored
Anyway, I will still try to fix the “official” component to handle your case. You are the 2nd user that apparently lives in a castle (20 covers!!!) with this issue. You can also try to contact their support.
Hahaha, I wish I’d live in a castle. It’s just an old house with a “Veranda” of 8 covers, so it goes up to twenty covers.
I’ll stick to the unofficial addon, hoping it won’t get deprecated by somfy anytime soon. I wish they could add the scenario feature to their official API, it would fix my problems.
I’ve tried to register an app on their developpers portal but I can’t even get an OAuth token, I get a 404 error. I’ve reached their support, and here’s their answer (french) :
Bonjour,
Merci de nous avoir contacté.
Le problème se trouve chez nous. Certaines apps créées de puis notre portail API ne se synchronisent pas correctement.
Je vois que vous essayez de lier à home-assistant. Sachez que vous n'êtes pas obligez de créer d'app si vous utilisez le composant officiel (https://www.home-assistant.io/integrations/somfy)/ Celui-ci intègre un service d'account linking natif d'Home Assistant.
Cordialement
Thanks for your help tetienne
Yes their app system is a shame. It’s why I suggest to use the native HA account already setup and tweak by Somfy.
But IMO, the fact they cannot handle 20 requests is not something normal. I will contact them. But I don’t know if they will do anything, they clearly told me several times that they haven’t any resources allocated to their official API.
If only we could get rid of the tahoma box and send directly the radio signal ourselves through an RF emitter.
I don’t get the point of setting up an officlal API that is buggy and way much behind in terms of feature to the unofficial one used in ahomalink.com.
Hopefully it will remain usable for as long as the official one gets all the features from the unofficial.
Hey Martin,
Just a comment: you could always set the trigger with “from:” state and “to:” state. So you could only trigger an automation, if a shutter state changes “from: closed” -> “to: open” and ignore the trigger, if “from:” is something else, i. e. unavailable.
1 Like
That’s exactly what I do for most of my automation today avoid surprise.
Oh nice! In one shot 
I will see to add it in the Core project.
@tetienne : Oh…I see some errors in the log:
Logger: homeassistant
Source: custom_components/somfy/init.py:163
First occurred: 8:55:38 (17 occurrences)
Last logged: 10:12:15
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py”, line 119, in _handle_refresh_interval
await self.async_refresh()
File “/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py”, line 193, in async_refresh
update_callback()
File “/config/custom_components/somfy/init.py”, line 203, in _handle_coordinator_update
self._create_device()
File “/config/custom_components/somfy/cover.py”, line 94, in _create_device
self.cover = Blind(self.device, self.api)
File “/config/custom_components/somfy/init.py”, line 163, in device
return self.coordinator.data[self._id]
KeyError: ‘64a30328-6be429be-bce09b3c-7783c0b9’
I saw it too. I will try to fix this.
Okay thanks
The issue is due to Somfy not returning the devices from time to time:
2020-12-15 13:28:21 DEBUG (MainThread) [custom_components.somfy] Number of devices: 8
2020-12-15 13:28:21 DEBUG (MainThread) [custom_components.somfy] Finished fetching somfy device update data in 0.795 seconds
2020-12-15 13:29:21 DEBUG (MainThread) [custom_components.somfy] Number of devices: 8
2020-12-15 13:29:21 DEBUG (MainThread) [custom_components.somfy] Finished fetching somfy device update data in 0.741 seconds
2020-12-15 13:30:21 DEBUG (MainThread) [custom_components.somfy] Number of devices: 8
2020-12-15 13:30:21 DEBUG (MainThread) [custom_components.somfy] Finished fetching somfy device update data in 0.630 seconds
2020-12-15 13:31:53 DEBUG (MainThread) [custom_components.somfy] Number of devices: 0
2020-12-15 13:31:53 DEBUG (MainThread) [custom_components.somfy] Finished fetching somfy device update data in 32.193 seconds
2020-12-15 13:31:53 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Oh really…damn the official Somfy CLOUD API is very very very bad.
It’s time to buy soon the Velux KLF200 and run everything locally…
The somfy cloud is totally unreliable.
Does the Velux KLF200 work fine with the somfy covers ? No issue whatsoever ?
What I read in this topic is that there are users that are working with the Velux KLF 200 and that everything is working correctly.
But maybe those persons could tell us there real experience with us.
The box is € 160,-. But if with this box everything is working reliable, it is worth the price. Also it should then be possible (I think) to poll locally every x seconds. So much more then now, i believe 60 seconds with the offical plugin and 30 seconds with the unofficial?