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.
sure I would, but before I do so, please let me know which sensors you plan on creating already, next to the currently available?
btw, I dont have any battery sensors, what devices are those? Hope I am not missing out on any remotes, or wall switches, because I really would love those in HA.
currently I see these attributes:
**core:FirmwareRevision: 5128570B00?**
**core:Manufacturer: Somfy**
core:NameState: Rolluik Logeerka
core:PriorityLockTimerState: 0
**core:StatusState: available**
**core:DiscreteRSSILevelState: normal**
**core:RSSILevelState: 54**
**core:MovingState: true**
**core:ClosureState: 100**
**core:OpenClosedState: closed**
**core:Memorized1PositionState: 85**
**core:TargetClosureState: 100**
core:ManufacturerSettingsState: null
io:PriorityLockOriginatorState: null
io:PriorityLockLevelState: null
obviously I dont use the ‘null’ attributes, but that might be device dependent? Apparently mine don’t use that. the others I would love to have available, if only to check for errors.
MovingState: true I dont understand the meaning of. It always shows that, even when the screens/covers are not moving. So either that is a bug, or it reports something unexpected.
I’d love to see the starred attributes, one way or another.
Name is evident, so no need for that, and the PriorityLockTimerState is unclear to me to. Id expect that on my garage door for example, which I have secured with a code, but this isnt that?
core:PriorityLockTimerState is linked to io:PriorityLockOriginatorState. The latest can have several values: LSC, SAAC, SFC, UPS, externalGateway, localUser, myself, rain, security, temperature, timer, user, wind
When there is too much wind, my awning is automatically undeploy, io:PriorityLockOriginatorState is set to wind and core:PriorityLockTimerState is set to 30. Meaning my awning is locked for 30s because there is too much wind. Within the tahoma website I can see this:
I don’t know when the other values are returned. They also need I guess an external sensor, or a specific device.
I plan to add this state as sensor as it can be useful to trigger a notification when its value change.
About core:MovingState, for a cover, like you guess it means the cover is moving. We already use it. That’s weird Somfy always returned true for your device. This state is set to false by default for my cover.
Can you please give me the firmware displayed in the device page? It look like this:
btw, I dont have any battery sensors, what devices are those? Hope I am not missing out on any remotes, or wall switches, because I really would love those in HA.
A lightsensor for instance is battery device. Remote are not supported. We (should) support all the devices you can control through your official application (like tahomalink).