@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).
the alert is what I am looking for too!, check this, apparently an obstacle has been detected:
and clicking that displays:
while there is no attribute displaying that?
current_position: 99
rssi_level: 56
core:Manufacturer: Somfy
core:SupportedManufacturerSettingsCommands:
- dead_man_up
- dead_man_down
- dead_man_stop
- dead_man_impulse_up
- dead_man_impulse_down
- enter_settings_mode
- save_upper_end_limit
- save_lower_end_limit
- stop_after_save_limit
- set_auto_end_limits
- set_auto_upper_end_limit
- set_auto_lower_end_limit
- save_settings
- invert_rotation
- save_my_position
- delete_my_position
- set_smart_protect
- set_open_level
- set_security_level
- set_discreet_mode_speed
- set_nominal_mode_speed
- set_soft_start
- set_soft_stop
- reset_actuator
- double_power_cut
- eject_from_setting_mode
core:FirmwareRevision: 5128570B00?
core:NameState: Rolluik Studente
core:PriorityLockTimerState: 0
core:StatusState: available
core:DiscreteRSSILevelState: normal
core:RSSILevelState: 56
core:MovingState: true
core:ClosureState: 1
core:OpenClosedState: open
core:Memorized1PositionState: 85
core:TargetClosureState: 0
core:ManufacturerSettingsState: null
io:PriorityLockOriginatorState: null
io:PriorityLockLevelState: null
friendly_name: Rolluik Studenten
supported_features: 1551
device_class: shutter
you can see the firmware version here too, as you asked for. and yes the MovingState is true on all my covers so something is not right there.
the windsensor is the tahoma device? Somfy Eolis Wirefree io: Draadloze Windsensor ? if like that though I have more than a few weather intergrations with windspeed, I guess nothing beats a factual sensor at location
We didn’t plan to add any others yet, all the ones that we are aware of are already added in the latest version.
Looking at the attributes/states you marked with an attribute, most of them are already visible in a sensor entity OR in the cover entity. For example we map core:StatusState to the native Home Assistant status, core:OpenClosedState, core:ClosureState to the cover entity.
The only one from your list that we don’t map yet is core:Memorized1PositionState, why would that one be useful for you?
I was under the impression that was the ‘My’ position, and as such, it would be very nice to have.
Must confess my rts covers don’t have that attribute, while they do have a My position… So maybe it is another value?
I now also see: core:Memorized1PositionState: 105 on my ‘Blind’. Considering that, could this be the value the screen programs itself to, when adjusting the height of the device? If yes, this is truly a useful value, because it is an indication to the factory set programming is adapted to the factual positioning.
Speaking in general, I would think it to be useful to report everything the Tahoma Api returns, if only for administrative purposes, and maybe even more importantly, so we can check the Tahoma install.
My supplier was very surprised I had more info on the devices than the Tahoma App itself returned. Coming to think of that, it is quite odd the official app doesn’t even report the position % of the covers.
Therefor, I would strongly advocate to return all information in HA the api offers.
about the MovingState:
upon restart, I see all screens/covers/blinds to be false. after a single action, this value turns to true, and remains like that. there’s definitely something not correct there.
About the Moving State I will contact their support. Perhaps you spotted an issue. We found another one few weeks ago.
About the sensor, I’ve planned to add PriorityLockOriginatorState.
For the wind sensor Eolis, the main advantage is the device is directly connected to the awning.
thanks, fyi, some more detail on that:
core:MovingState: true
core:ClosureState: 83
core:OpenClosedState: open
core:Memorized1PositionState: 85
core:TargetClosureState: 83
target has been reached hours ago, and still MovingState: true
thanks!
I feared that, as I don’t really want it to control beyond the Tahoma box, or user set rules. Would have hoped the Eolis was a sensor only, and the User could set logic , ( and because of that we could trigger an automation in HA).
Don’t think Somfy provides sensors that do only that, measure the windspeed.
Might I repeat my question here Somfy Tahoma Official API - #1526 by Mariusthvdb
Maybe it got buried under the other issues…