Closed neuhausf closed 2 years ago
@neuhausf can you change the value of your remote and generate your diagnostics again? It would be good to have a diff to easily spot what changed.
There is a RemoteController present in your config, thus perhaps this is the right one. The limitation will be that it takes up to 30 seconds until your update is in anyway, thus real-time scenarios are not interesting.
{
"creationTime": 1620383790000,
"lastUpdateTime": 1620383790000,
"label": "**",
"deviceURL": "rtds://****-****-1997/176943",
"shortcut": false,
"controllableName": "rtds:RTDSRemoteControllerComponent",
"definition": {
"commands": [],
"states": [{
"type": "ContinuousState",
"qualifiedName": "rtds:ControllerBatteryState"
},
{
"type": "ContinuousState",
"qualifiedName": "rtds:ControllerBipState"
},
{
"type": "ContinuousState",
"qualifiedName": "rtds:ControllerOrderTypeState"
},
{
"type": "ContinuousState",
"qualifiedName": "rtds:ControllerOriginatorState"
},
{
"type": "ContinuousState",
"qualifiedName": "rtds:ControllerSensingState"
},
{
"type": "ContinuousState",
"qualifiedName": "rtds:ControllerSirenState"
}
],
"dataProperties": [],
"widgetName": "AlarmRemoteController",
"uiProfiles": [
"Specific"
],
"uiClass": "RemoteController",
"qualifiedName": "rtds:RTDSRemoteControllerComponent",
"type": "REMOTE_CONTROLLER"
},
"states": [{
"name": "rtds:ControllerOriginatorState",
"type": 1,
"value": 2
},
{
"name": "rtds:ControllerSensingState",
"type": 3,
"value": "KO"
},
{
"name": "rtds:ControllerBatteryState",
"type": 3,
"value": "OK"
},
{
"name": "rtds:ControllerOrderTypeState",
"type": 3,
"value": "onZ2"
}
],
"available": true,
"enabled": true,
"placeOID": "ebd524eb-5f73-435c-bb7c-60ed8cf2ed9b",
"widget": "AlarmRemoteController",
"type": 4,
"oid": "437d55db-6467-41c1-9292-2d6108cb8abb",
"uiClass": "RemoteController"
}
(2): remote on "auto" -> switch auto to manual (3): remote on "manual" config_entry-overkiz-91796d4b3b8434e80fa9ccd21a2481e9.json (2).txt config_entry-overkiz-91796d4b3b8434e80fa9ccd21a2481e9.json (3).txt
I don't see any difference... All registered blinds on the remote move a little bit (same as identify). Not only the blind on the selected channel.
@iMicknl as for the remote I guess it's the basic TaHoma Remote, which came with the box: https://elektro-zollinger.ch/Shop/Somfy/RF-Handsender-Somfy-TaHoma-Serenity-2-RTS-ws-gu-204012039?sort=rating&order=ASC&page=9 I'm interested in the state of the Somfy Situo 5 Variation A/M remote: https://www.somfy.ch/de-ch/produkte/1811636/situo-5-variation-a-m-io-pure-ii Shouldn't the remote store the auto/manual state on the blind or on the box?
What does the remote do? But it doesn't seem like this is exposed unfortunately. If you cannot see it on tahomalink.com or in the official app, it is probably not available.
The Situo remote closes/opens the blind. It has 5 channels to control 5 blinds. The auto/manual switch is to enable/disable automations running on the TaHoma box. The switch state is reflected in Tahomalink: So it should be retrievable by the API I guess?
I guess I found it. It's the priority lock originator sensor, which is disabled by default. "Benutzer" (user) means in this case, that the manual control is activated. "Unbekannt" means it's on "auto".
Only issue: The value doesn't update itself. Only if I open the TaHoma App on the phone or refresh Tahomalink. @iMicknl can you poll this sensor from time to time? Or expose a service to do so. I don't need "realtime" data - every 5 to 10 minutes would be enough.
@neuhausf we won't fix this on short term. We already poll every 30 seconds for updates on the event listener, but apparently this state is not broadcasted. Opening the TaHoma app (or tahomalink.com) will call an endpoint to refresh all states, which we should not call every 5 minutes.
We looked into this in the past: https://github.com/iMicknl/ha-tahoma/pull/271, however we couldn't settle yet on a good decision. Somfy's infrastructure is just not built for this...
@iMicknl I see. It's a pitty that I can't use this switch without polling. Probably you can reconsider #271 in a different approach: Expose a service which refreshes the state of (one) device. Implement some rate limiting: Only x requests per hour/day. Something like HACS does with the github API.
In my case I just need about three updates a day: Auto opening/closing blinds in the morning/during the day/evening. So the update will occur before making a decision in terms of automation (in my case with AppDaemon, hass-blinds).
@neuhausf Within the Tahoma website, when you switch the mode, do you see an instant update of UI? If yes it means there is an event we don't read.
@tetienne No and yes...
The following happens in the web interface after opening the iPhone app:
Thx for clear debug session :) So indeed even Somfy cannot trigger a live update within calling this RefreshAllDevicesStatesCompletedEvent
.
@tetienne Just another detail: I activated manual mode on 20:30 -> state was not reflected in HA until 7:00 the next day. At this time, a Somfy automation ran. So I guess that the Tahoma box must refresh all device states before running an automation.
Hopefully we can refresh the states more often with https://github.com/iMicknl/ha-tahoma/issues/796 So I'm closing this for now, so we (meaning you 😜 ) can all focus on implementing the local API (which will be awesome 😉 )!
Did you read the instructions?
The request
I’m trying to use the little A/M switch on the somfy remote as a sensor in my automations. But I can’t figure how (or if) the switch is represented by this integration. See also https://community.home-assistant.io/t/overkiz-api-and-somfy-api/61448/1769?u=neuhausf
Which gateway / hub do you use?
Somfy TaHoma V2, Firmware: 2021.6.4
Device model (optional)
PositionableExteriorVenetianBlind (or probably TaHoma Short Channel)
Device type (optional)
io:ExteriorVenetianBlindIOComponent
Additional information
diagnostics of TaHoma V2 from HA config_entry-overkiz-91796d4b3b8434e80fa9ccd21a2481e9-tahoma.json.txt