For test purposes I can see that via the API it can see my Connexxoon device, but as you mentioned it doesn’t make a difference for Home Assistant integration. Still somehow we must do something different, as for some it is working one would say.
Odd, this sounds like my initial setup, minus the NGINX proxy: callback to local HA ip, over http, not https and trying to activate when on my own local network.
Then I figured the Somfy integration needed remote access, so I set that up via the DuckDNS add-on (including the LetsEncrypt SSL cert) but again ran into the same issue.
I wonder if your NGINX proxy does something magical that it works for you… Maybe @tetienne has an idea?
Hum, you don’t need remote access to confirm the integration. If your instance is only available on your local network, you have to use a local ip for the callback url like http://192.168.1.123:8123/auth/somfy/callback. For sure, during the initial setup, you have to use a computer on your local network.
You can double check the url in your browser when your are redirected to the Somfy portal to see if the callback url my component build is correct.
Is there any way to check the callback url works ok? If I visit the page now I 500 error, which can be ‘correct’ if the page assumes that certain parameters are provided, but it can be some misconfiguration on my side as well.
What do you see once you confirm the connexion with Somfy? Can you show me the URL you see when your on this page?
If their was an issue on the component, you would have seen an error in the HA logs sections.
There is some weirdness going on with the building of the callback URL (though it might be expected behaviour). As @CrazyChaos mentioned, base_url might have something to do with it.
I created a new Somfy app on the Developer site with the local ip in the callback url and put the new key in my HA config. After restart the callback URL that was build showed the new key but had the (remote accessible) base_url in the url instead of the local ip address… When I removed the base_url from the config, after a HA restart the callback url was build with the correct local ip.
Not sure if this is related to the issue though…
@ge2rt That seems logical to me, if you don’t fill the base_url variable Home Assistant can only assume it is reachable on the local IP address. Once you have set base_url it will always use that to create callback/external url’s. But it might influence the behaviour of the integration, but it the end you would assume that if the url you define in ‘My apps’ and the url you see given in the callback match it should work.
I replied to tetienne in private as the url contains a publicly accessible IP.
BTW I am new to both Home Assistant and Somfy, so sometimes I might overlook obvious things.
From the logs:
2019-09-13 16:43:29 ERROR (MainThread) [aiohttp.server] Error handling request
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/aiohttp/web_protocol.py", line 418, in start
resp = await task
File "/usr/local/lib/python3.7/site-packages/aiohttp/web_app.py", line 458, in _handle
resp = await handler(request)
File "/usr/local/lib/python3.7/site-packages/aiohttp/web_middlewares.py", line 119, in impl
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/real_ip.py", line 40, in real_ip_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 73, in ban_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 231, in auth_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/view.py", line 128, in handle
result = await result
File "/usr/src/homeassistant/homeassistant/components/somfy/config_flow.py", line 128, in get
text="Missing code or state parameter in " + request.url
TypeError: can only concatenate str (not "URL") to str
I reproduced it and this is what happens when you visit the callback url directly without parameters. So:
http://[hass]:8123/auth/somfy/callback.
Now when I visit the callback url with parameter I retrieve from the Somfy page, then I get presented a 404 without any further information in the Home Assistant log:
https://[hass]:8123/auth/somfy/callback&response_type=code&state=3db9d16ea6864349b32c9915aa165423
So something seems to wrong there in the parameters or the callback itself.
A 404 would mean that /auth/somfy/callback does not exist.
That’s weird, as it appears correctly in the python code (at least on github).
Does the 404 also generate a log entry on HA?
The 404 doesn’t generate a log entry, only the 500 error does 
I tried contacting a local/regional distributor of blinds using the Somfy automation, and they were clueless and no help whatsoever. I told them I would not / could not buy something this unreliable, and they simply had no answer. They had no influence on the blinds manufacturer or the automation supplier. Despite being primed and ready to replace/automate many of the blinds in my home, Somfy has made this a VERY simple decision: NO.
I hear ya. I even contacted Somfy locally, and they basically said the only option was to wait for the developers to fix it. I won’t even bother with the sales people. Oh well, at least I got the hub for “free” (now works pretty OK with the tahoma integration).
Hey, this worked for me now, atleast I got the oauth process completed.
Glad to know! Can you see your covers now?
I can confirm it works too! Yes!
It finds the roller shutters and a roller blind. The garage door is missing, but via the app I get an error too, so that’s a different Somfy problem…
I just tested it briefly, as it was late, but no, it only saw one cover, but i forgot to disable the Tahoma component, so I’m thinking there might have been a problem with duplicates or something…have to test it further. The Tahoma component is also working well for me now, but I’d rather use the open API (if it stays stable).
Somfy support just contact me.
They finally find why their was so many issue with the authentication. They have released the fix yesterday. So it can explain why now you are able to use the component normally. That’s a great news! They are really sorry for the delay and apologies for this.
About, coming feature, sadly they don’t have anything planned.
This is good news! I’m a bit disappointed that they don’t support much from their products. But I guess the API is quite new, and now that it’s actually connecting, maybe they’ll continue developing it. In the meanwhile, kudos for the good work @tetienne!
I confirm it is now working ! I can’t see my awning though 
Same here. Integration now works in HA but my awnings don’t show up. Likely they are considered not as a ‘blinds’ type but as something different…
In the API test site on the Somfy dev site my Connexoon does show up but also no devices there…
This API seems to only pick up my screen, but not my awning (although they are both shown as awnings in the tahoma integration, at least).