hm… this might be an issue with the device type?
I don’t have any of these - so I am not sure, but I guess, the device type “screen scull…” is type curtain while the others seem to be device type “cover” or “blind”.
My guess is that this is not Home Assistant related, but rather how the device was added to Tahoma in the first place. Home Assistant takes its cue from that. Is it listed exactly the same there, or different from the others?
Hi, @CChris , thx for this tip! (I’ve never been here before…) This solved part of the issue . Changed it to Blind and assigned appr. icon.
However, the state is still reversed. (I can assure that all blinds are opened)
What I meant is, are they exactly the same in Tahoma/Connexoon too? Or do they show different there, or act reversed too? Both the type of device and orientation of the motor should be deternined in Tahoma.
the main issue here is, that the device is reporting the current state (open or closed) as well as the position (number value)…
in this case, the device open position is mapped with the “current position” → 0 while the other devices are using the 100 for the open state.
This information comes from the integration or better, how the device is reporting to the integration - and it will be difficult to change that information in HomeAssistant.
BUT:
Since the entity is already providing the state information “open” - I think, this COULD be an issue with the card itself.
It seems, that the card relies on the current position information rather than the state.
But from my understanding, if the state is open → then the arrow down should be enabled (to close the blind)…
As you can see, all shutters/screesn are Opened. Also the “trouble one” (Scullery).
Thus, “Open” status is the same status as shown in HA cover.screen_scullery
As @CChris mentioned, the curent_position is what’s deviated from the others (0 instead of 100)
However, looking at the device “Screen Scullery”, it shows the opposite (position 100 instead 0):
Did you group the devices in the Somfy app, or did Somfy do that based on its type? It still looks to me like Somfy too sees this as a different type of device. But then again, if Somfy and HA disagree on what is open and what is closed, that is either a bad config or a bug. So if there’s no “reverse operation” property in HA, you should report it as a bug I think.
On the other hand, if it is a different device type, the percentages may need to be interpreted differently. You did override the device class manually, so it is not a staight situation. I’d still try to remove it from Somfy and add it again to see if you can pick the type of device and have it truely the same as the others.
Best is to create an issue on core GitHub with your diagnostics information. We need to overhaul the cover entities to make sure we have less inverted covers.
We have had many issues with awnings especially, and not be able to figure out the best way. It seems there are a few exceptions and we need to map these…
Thx all @Edwin_D to exclude possibilities I’ll try your suggestion and update the result.
@imick I’ll be happy to help and add it to the ja core git. Since this is new to me, could you please provide me a link or directions how to find this repository?
Hi Edwin,
As promised. Today I deleted it from the somfy installation and added it again. Unfortunately, with the same (inverted) result in HA.
Called the Somfy support desk and they recognize the issue “some devices are recognised differently by the app than others” . In my case (having 5 screens), 1 of them is listed in the Somfy app as a “different device”. (as seen in one of the screenshots)
In the somfy app and the remote are working as expected (up =up and down = down).
From the integration perspective;
All devices are listed from same Manufacturer but with different Models (postionableScreen and AwningValance).
When looking at the HA entities is where 2 issues arise.
(easy to solve) , change from Awning to Blind. This will resolve the corresponding icons to be same as the rest.
current position value is 0 where as all others have a value of 100 (all fully opened)
according to the linked issue, it seems to be something on the somfy side.
If I get this comment right:
As you said, the behavior was ok during few days, then it was incorrect. On HA side, I’ve checked the history, we didn’t check the logic. But, looking at what Somfy returns, there is something weird:
ClosureState and DeploymentState sum must be 100. When one is 75, other one is 25 for instance.
DeploymentState set to 100 means fully deploy, and ClosureState set to 100 means fully unoffuscated.
So it seems there was an update on Somfy server side.
then the cloud service is reporting something wrong.
Neverless - I would do the following:
I would create a new issue on Git - and link both issues… (mention the old one in the new ticket)
EDIT:
But… it is still possible, that the sensor is another device type:
So, as your device is of type Awning, open with HA means fully deployed, and close fully undeployed. If it’s well the case, and you want the opposite, you will have to create a cover template to change the logic.
I do think thats a Somfy issue (some devices just are reported “wrong”, even if its pysical same device but electronically different)
So from HA persprective / overkiz integration its alright (diff device, so diff reporting).
Indeed, the quickest way to fix this in HA is to create a cover template to reverse the logic. I’ll start a new topic since its off topic here.
While it has some relation I’ll update the link here for others looking for something similar.
Hi, I have landed on HA. I have had the same problem integrating tahoma through overkiz. Then, I just erased tahoma hub from homekit and it appears automatically on HA without the problem o inverted blinds.
Hope it helps.