Hi,
I’m trying to solve an inverted blind from the Tahoma integration.
Apparently, one blind is from a different make.
I can change the icon in the frontend of course.
How can I change the state icons or make the device look like all others?
My attempts to solve it in the frontend, resulted in Invalid yaml code.
thx in advance.
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”.
You can change the device class this way:
open the entity settings:
then, go to the “show as”
and select the device type you want.
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)
@Edwin_D the status from the integration shows that the blind is open.
I’m puzzled that these statuses are not the same, as I would expect.
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)… 
Thx again for the replies!
This is what is shown in the Somfy App
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):
This is starting to “smell” like a bug in the card as @CChris is thinking too?
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?
Thx
here you go
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.
Hi Chris,
Seems that there are already issues created for this. Somfy Overkiz Inversion opening closing of the awning · Issue #66857 · home-assistant/core · GitHub and are closed due to inactivity. Should I open a new again? or reopen an existing in order to get attention to it?
thx
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:
{ "name": "core:ClosureState", "type": 1, "value": 100 }, { "name": "core:OpenClosedState", "type": 3, "value": "closed" }, { "name": "core:DeploymentState", "type": 1, "value": 100 }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:
OK, so about the returned states, according to Somfy, they are correct. See Somfy-Developer/Somfy-TaHoma-Developer-Mode#22 (comment)
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.
If you connect to the tahoma somfy device with homekit in HA it shows correctly in the homekit entities.
