Cover position changes made from the wall switch are never reflected in HA

[romain38]

Describe the bug

Cover position changes made from the wall switch are never reflected in Home-Assistant.
If I run mobile app Tahoma, or run stop command from Home-Assistant, right position are updated.
I've try to call service homeassistant.update_entity on my cover sensor without effect.

To Reproduce

Force refresh with stop sensor command:

• Cover opened at 100% (physically and in Home-Assistant)
• Close cover via wall switch (Somfy IO remote control: SMOOVE RS100 iO)
• Cover physically closed but Home-Assistant keep opened status at 100%
• Wait some minutes, Home-Assistant keep opened status still at 100%
• Call cover.stop_cover command on cover sensor in Home-Assistant
• Home-Assistant update cover status to closed

Force refresh with Tahoma android app:

• Cover opened at 100% (physically and in Home-Assistant)
• Close cover via wall switch (Somfy IO remote control: SMOOVE RS100 iO)
• Cover physically closed but Home-Assistant keep opened status at 100%
• Wait some minutes, Home-Assistant keep opened status still at 100%
• Run Tahoma android app, cover is displayed as closed in Tahoma mobile app
• Home-Assistant update cover status to closed

Expected behavior

Cover status must automatically reflect the right cover position (with an acceptable refresh delay) without call manually stop command or use Tahoma AndroidApp.

Environment (please complete the following information):

• ha-tahoma version: 2.0.1
• Home Assistant version: 0.112.4
• Platform: cover
• Firmware: io:RollerShutterWithLowSpeedManagementIOComponent

Devices:

Somfy IO cover
Wall switch SMOOVE RS100 IO
Tahoma Box

[iMicknl]

I am afraid this is due to #167 as well. Did you not have the same behavior with the old version in Home Assistant core?

Could you share some more details about your device? Settings -> Integrations -> Devices -> (click your cover device. Could you share the firmware?

Example:

[romain38]

Hi, thank you for this quick response!

This issue was present in the "old" TaHoma integration (home-assistant/core#20188) and also in Somfy integration (home-assistant/core#25051).

Here is the missing firmware information: io:RollerShutterWithLowSpeedManagementIOComponent.

[iMicknl]

{
	"commands": [{
		"commandName": "close",
		"nparams": 0
	}, {
		"commandName": "delayedStopIdentify",
		"nparams": 1
	}, {
		"commandName": "down",
		"nparams": 0
	}, {
		"commandName": "getName",
		"nparams": 0
	}, {
		"commandName": "identify",
		"nparams": 0
	}, {
		"commandName": "my",
		"nparams": 0
	}, {
		"commandName": "open",
		"nparams": 0
	}, {
		"commandName": "refreshMemorized1Position",
		"nparams": 0
	}, {
		"commandName": "setClosureAndLinearSpeed",
		"nparams": 2
	}, {
		"commandName": "setClosure",
		"nparams": 1
	}, {
		"commandName": "setDeployment",
		"nparams": 1
	}, {
		"commandName": "setMemorized1Position",
		"nparams": 1
	}, {
		"commandName": "setName",
		"nparams": 1
	}, {
		"commandName": "setPositionAndLinearSpeed",
		"nparams": 2
	}, {
		"commandName": "setPosition",
		"nparams": 1
	}, {
		"commandName": "setSecuredPosition",
		"nparams": 1
	}, {
		"commandName": "startIdentify",
		"nparams": 0
	}, {
		"commandName": "stop",
		"nparams": 0
	}, {
		"commandName": "stopIdentify",
		"nparams": 0
	}, {
		"commandName": "up",
		"nparams": 0
	}, {
		"commandName": "wink",
		"nparams": 1
	}, {
		"commandName": "pairOneWayController",
		"nparams": 2
	}, {
		"commandName": "unpairAllOneWayControllers",
		"nparams": 0
	}, {
		"commandName": "unpairOneWayController",
		"nparams": 2
	}],
	"states": [{
		"type": "ContinuousState",
		"qualifiedName": "core:ClosureState"
	}, {
		"values": ["good", "low", "normal", "verylow"],
		"type": "DiscreteState",
		"qualifiedName": "core:DiscreteRSSILevelState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:Memorized1PositionState"
	}, {
		"type": "DataState",
		"qualifiedName": "core:NameState"
	}, {
		"values": ["closed", "open"],
		"type": "DiscreteState",
		"qualifiedName": "core:OpenClosedState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:PriorityLockTimerState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:RSSILevelState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:SecuredPositionState"
	}, {
		"values": ["available", "unavailable"],
		"type": "DiscreteState",
		"qualifiedName": "core:StatusState"
	}, {
		"values": ["comfortLevel1", "comfortLevel2", "comfortLevel3", "comfortLevel4", "environmentProtection", "humanProtection", "userLevel1", "userLevel2"],
		"type": "DiscreteState",
		"qualifiedName": "io:PriorityLockLevelState"
	}, {
		"values": ["LSC", "SAAC", "SFC", "UPS", "externalGateway", "localUser", "myself", "rain", "security", "temperature", "timer", "user", "wind"],
		"type": "DiscreteState",
		"qualifiedName": "io:PriorityLockOriginatorState"
	}],
	"dataProperties": [{
		"value": "500",
		"qualifiedName": "core:identifyInterval"
	}],
	"widgetName": "PositionableRollerShutterWithLowSpeedManagement",
	"uiClass": "RollerShutter",
	"qualifiedName": "io:RollerShutterWithLowSpeedManagementIOComponent",
	"type": "ACTUATOR"
}

[vlebourl]

Same problem as for the velux, @tetienne can confirm.

[tetienne]

I can confirm indeed. And even the tahomalink website does not make the update when you use the wall switches. You have to log in to refresh the state. So I'm affraid there is no easy solution.

[iMicknl]

We could call /setup/gateways/{gatewayId}/devices/states/refresh, which is the same behaviour as tahomalink.com does on login I assume...

However not sure how often we can call this and when to call. We could integrate it as a service like tahoma.refresh_states, offering a workaround for some users.

[vlebourl]

If that service does refresh the state, it would be a nice addition.

[romain38]

We could call /setup/gateways/{gatewayId}/devices/states/refresh, which is the same behaviour as tahomalink.com does on login I assume...

However not sure how often we can call this and when to call. We could integrate it as a service like tahoma.refresh_states, offering a workaround for some users.

This solution seems good to me: this would be a major update for my use case!

[iMicknl]

@romain38 could you give https://github.com/iMicknl/ha-tahoma/archive/feature/add_refresh_states_service.zip a try? You can unzip this file and place the tahoma folder in your custom_components folder. Best is to first remove the old one, to make sure you don't have any conflicts.

This will add a new service call named tahoma.refresh_states. Calling this service should trigger an update within 30 seconds (or less, based on your configured update interval). Could you give it a try? We will investigate better solutions in the future in #167.

[romain38]

Hi @iMicknl ,

It works fine (with https://github.com/iMicknl/ha-tahoma/archive/feature/add_refresh_states_service.zip version) !
My test steps:

• modify manually (with wall switch) several cover
• call tahoma.refresh_states
• wait (between 2 and 15 seconds)
• right states are displayed in HA!

If I understand correctly, on a next version, this service will be called automatically depending on the integration config?

Many thanks for this improvement!

[iMicknl]

@romain38 great to hear! Indeed, we are looking to add a way to define a refresh period in the future. For now, you can create your own automation that will periodically call tahoma.refresh_states! Just make sure your polling interval is in the same frequency at least, since that is needed to refresh the updates.

[iMicknl]

@romain38 I will close this issue for now, since we will track this feature in #167. If you subscribe to that issue, you will get notifications of updates and when it is ready :-).