Overkiz API and Somfy API

[imick (Mick)]

@Mariusthvdb

anyone else seeing this issue in more-info:

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.

[Mariusthvdb (Marius)]

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?

[imick (Mick)]

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.

[Mariusthvdb (Marius)]

@imick

Can you link the issue

I did, in my post above

@imick

if there is an interesting state that you would like to keep as a sensor or binary sensor.

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…)

[imick (Mick)]

@Mariusthvdb

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.

[Mariusthvdb (Marius)]

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?

[tetienne]

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).

[Mariusthvdb (Marius)]

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

[imick (Mick)]

@Mariusthvdb

sure I would, but before I do so, please let me know which sensors you plan on creating already, next to the currently available?

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?

[Mariusthvdb (Marius)]

@imick

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.

[tetienne]

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.

[Mariusthvdb (Marius)]

@tetienne

About the Moving State I will contact their support. Perhaps you spotted an issue. We found another one few weeks ago.

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

@tetienne

planned to add PriorityLockOriginatorState.

thanks!

@tetienne

For the wind sensor Eolis, the main advantage is the device is directly connected to the awning.

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.

[Mariusthvdb (Marius)]

Might I repeat my question here Somfy Tahoma Official API - #1526 by Mariusthvdb

Maybe it got buried under the other issues…

[tetienne]

No idea on this. That’s the value returned by Somfy.

[Mariusthvdb (Marius)]

Ok, thanks.

Can’t we check when Somfy returns which value then ? I am not sure if I have all possible values (good, normal, weak) and when somfy decides they are ( good, normal or weak)…

Surely that must be listed in their Api?

[tetienne]

Here the values that Somfy can return.

 {
      "type": "DiscreteState",
      "values": [
        "good",
        "low",
        "normal",
        "verylow"
      ],
      "qualifiedName": "core:DiscreteRSSILevelState"
    },

You can join us on Discord: https://discord.gg/HDVSYqvh

[Mariusthvdb (Marius)]

hope this is allowed, but I have a Tahoma app question, which I can not find the answer to on the Tahoma or Somfy web pages…

Trying to guard the Garage door with a pincode, or some other way of securing opening the door, there doesnt seem to be a way I the official Tahoma app at all? I would think to be the most basic form of home security, and right now, anyone with access to an opened phone can enter the premises…

I did include the garage door via Nabu casa, requiring a security code, so in the HA environment it is just that bit safer, but doesn’t Tahoma provide this basic security requirement? This can not be true can it?

what am I missing…

thanks for allowing an having a look

[flopepe74]

Hello,

I have a problem with an error when integrating the tahoma.

I have for my personal use the tahoma v2 and everything works perfectly when adding.

However, I installed a home assistant at my parents’ house with the new Somfy connectivity kit that was recently released.

I’ve been using it for a while now and it works perfectly.

error_code: policies.ratelimit.QuotaViolation, fault_string: Rate limit quota violation. Quota limit exceeded.

I followed the same tutorial as for my tahoma v2 at home and with my parents’ always the same problem.

I thank you in advance for your help

Good Sunday

[imick (Mick)]

You could give https://github.com/imicknl/ha-tahoma a try, have a look at the specific instructions for the TaHoma Switch. (and perhaps this will resolve your issues with the official Somfy API as well).

[Mariusthvdb (Marius)]

anyone on securing the Tahoma App itself on the Phone (pincode/touch-id/face-id), and securing a Garage door in the App with a security code? seems a horrible security issue if that isnt possible…