I am using a Connexoon RTS. I do not own a Tahoma device.
When I try to login I get
Invalid authentication
I do have a Somfy Account, but yet I get denied. I am able to login the Somfy website with my credentials.
Ok, so you are trying to use the Somfy integration from core? I have the feeling that this doesn’t work with Connexoon RTS.
You could give GitHub - iMicknl/ha-tahoma: Custom component for Home Assistant to interact with smart devices via Somfy TaHoma or other OverKiz based API's. a try, since it works with Connexoon RTS. Currently we show the wrong names during set up, thus it is possible that you need to select Somfy TaHoma instead of Connexoon RTS.
I am actually using the ha-tahoma.
That’s where I get the problem of not being able to login.
Edit: I tried to select al different options. did not work.
Running into issues with the Somfy Integration getting this error “400, message=‘Bad Request’, url=URL(‘https://account-link.nabucasa.com/refresh_token/somfy’”. I have a Connexion IO Box and i’m able to login to the Dev Portal and execute Calls against the APIs using the Credentials (ClientID and Secret) as issued. Any Ideas?
My Somfy integration is not working anymore. I get the message: Bad credentials.
The credentials at my site are NOT changed. When I re-enter the credentials the message bad credentials stay.
Are there more people who has those problems at the moment?
(Somfy…give us a local api!)
Update: in the meantime the problem is solved (I think by Somfy)
1 Like
Are you taking about the Tahoma integration installed through HACS? If so, a fix has been pushed on 2.6.2. Which version are you using?
@vlebourl asked if you use this component (the custom one) The legacy Tahoma component (built-in HA) does not work anymore.
OK upgraded to 21.8 core and it works again
I am trying to reinstall it from the link in the readme file but getting a “FLow cannot be loaded” error
I am using https by means of duckdns
Please described the steps you did. Did you install the component through HACS ? If not, give a try.
OK. Deleted everything and restarted from scratch.
Seems all right now.
Thanks a lot for your help
1 Like
customizing the icon color for the rssi levels, I was trying to find the specific % for the levels to change from low-normal-good (have all 3 of these, maybe there’s another level yet?)
sensor.*_rssi_level:
templates:
icon_color: >
if (state > 80) return 'green';
if (state > 40) return 'gold';
if (state > 20) return 'orange';
return 'red';
works for me now, but please correct the numbers? All I could find is the device_class SIGNAL_STRENGTH_DECIBELS, but I didn’t yet see the actual thresholds.
thanks for having a look, or pointing me to the code
anyone else seeing this issue in more-info:
while the attributes are:
issue: Somfy SupportedManufactu
This is not really an issue in ha-tahoma, but an issue in the front-end. However, please know that all these attributes will be removed in a future version. We kept them for now to have an easier overview on which states are present per device, however eventually all states/attributes that an user would use will be presented as a seperate sensor or binary sensor.
The front-end is not build to show many values, like the supported manufacturersettings. This is something that Somfy added recently by the way.
Ludeeus just replied in the issue it is an issue with the integration… now where do we solve this… 
or, you’re saying this will be solved by taking out the attributes soon?
Can you link the issue? But ludeeus is right, attributes are not made for such lists thus they cannot display this correctly in the front-end.
However, as far as I know, this is currently not blocking anything in the interface. It is just less pretty. All available states and attributes will be removed soon, at least before the core PR, thus it will be resolved soon.
In the mean-time, have a look at your devices and states to see if there is an interesting state that you would like to keep as a sensor or binary sensor.
I did, in my post above
tbh, any of these core attributes is of use. I was very happy to see them in the attributes list, and would be sorry if they were to be taken out again. except for the core:MovingState: true (which I don’t understand, because the cover isnt moving…)
Could you perhaps create a GitHub issue where you share your thoughts / worries? It would be good to understand which ones you would like to keep and for which use-case.
Currently RSSI and battery are already moved to a separate sensor, thus you won’t lose that state.