Local API returns `available: false` for io devices despite devices being fully functional and controllable

[Cinecom]

Summary

The local API on my TaHoma Switch returns "available": false for some io-homecontrol devices, even though:

• Commands execute successfully on these devices
• The devices respond and move correctly
• The core:StatusState shows "available"
• The devices work perfectly in the TaHoma app and via Google Home (cloud API)

This causes Home Assistant (via the Overkiz integration) to mark these devices as "unavailable", making them unusable despite being fully functional.

Environment

• Gateway: TaHoma Switch
• Firmware Version: 2025.6.4-4
• Protocol Version: 2025.6.4-4
• Affected devices: io-homecontrol roller shutters and exterior screens

Detailed Problem Description

API Response showing the bug

When querying /enduser-mobile-web/1/enduserAPI/setup/devices, some devices return "available": false at the device level, while their internal states show they are actually available:

Example - Affected device (Roller Shutter):

{
  "deviceURL": "io://<gateway-id>/<device-id-1>",
  "label": "Shutter Side",
  "available": false,
  "enabled": true,
  "synced": true,
  "controllableName": "io:RollerShutterGenericIOComponent",
  "states": [
    {"name": "core:StatusState", "value": "available"},
    {"name": "core:DiscreteRSSILevelState", "value": "normal"},
    {"name": "core:RSSILevelState", "value": 74},
    {"name": "core:ClosureState", "value": 0},
    {"name": "core:MovingState", "value": false}
  ]
}

Example - Working device (same type) for comparison:

{
  "deviceURL": "io://<gateway-id>/<device-id-2>",
  "label": "Shutter Front",
  "available": true,
  "enabled": true,
  "synced": true,
  "controllableName": "io:RollerShutterGenericIOComponent",
  "states": [
    {"name": "core:StatusState", "value": "available"},
    {"name": "core:DiscreteRSSILevelState", "value": "good"},
    {"name": "core:RSSILevelState", "value": 90},
    {"name": "core:ClosureState", "value": 0}
  ]
}

Both devices:

• Are the same type (io:RollerShutterGenericIOComponent)
• Have enabled: true and synced: true
• Have core:StatusState: "available"
• Have good RSSI signal strength (74-90)
• Accept and execute commands successfully

Proof that commands work on "unavailable" devices

I can successfully send commands to devices marked as available: false:

Request:

curl -k -X POST "https://<gateway-ip>:8443/enduser-mobile-web/1/enduserAPI/exec/apply" \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"label":"Test","actions":[{"deviceURL":"io://<gateway-id>/<device-id>","commands":[{"name":"setClosure","parameters":[50]}]}]}'

Response:

{"execId":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"}

The shutter physically moves to 50% position. The device is clearly functional.

What I have tried (nothing fixes it)

Action	Result
Rebooted the TaHoma Switch via API	available flag remains false after reboot
Regenerated Developer Mode token	available flag remains false
Sent refreshState commands to devices	States update but available stays false
Set device names via setName command	Names update but available stays false
Set memorized positions via setMemorized1Position	Positions save but available stays false
Waited extended periods	The flag never self-corrects

Affected Devices

Device Type	controllableName	available	Actually works?
Roller Shutter 1	io:RollerShutterGenericIOComponent	false	YES
Exterior Screen 1	io:VerticalExteriorAwningIOComponent	false	YES
Exterior Screen 2	io:VerticalExteriorAwningIOComponent	false	YES
Roller Shutter 2	io:RollerShutterGenericIOComponent	true	YES

All devices are io-homecontrol protocol, have good signal strength, and respond to commands.

Impact

This bug makes the local API unusable for home automation systems like Home Assistant, openHAB, ioBroker, and others that rely on the available field to determine if a device can be controlled.

Users are forced to use the cloud API, which defeats the purpose of local control and introduces dependency on internet connectivity.

Expected Behavior

The available field should be true for all devices that:

• Have core:StatusState: "available"
• Are responding to commands
• Have good radio signal (RSSI)
• Are enabled: true and synced: true

Request

Please investigate why the available flag becomes stuck at false for some devices despite all evidence showing they are available and functional.

A fix in the gateway firmware would resolve this issue for all users of the local API.

Additional Information

• The TaHoma app and Google Home can control all devices perfectly (they use the cloud API)
• This issue appeared without any configuration changes
• All affected devices are io-homecontrol protocol (not RTS)
• Developer Mode is enabled and the token is valid
• The issue persists across token regeneration and gateway reboots

[BernoldNL]

I'm not on that version yet, but this feels quite similar to #182

[iMicknl]

This is affecting multiple Home Assistant users. Is this a bug that is on the radar? Or do we need to make changes to our logic?

[fberu-somfy]

Hello @Cinecom and @iMicknl ,

Issue has been created on the 12th January, which is few days after having deploying this new 2025.6.4-4 release. Were you facing this issue before this release ?

What are the status of your devices on the TaHoma app ? Are they also unavailable or are they well available ?

We just deployed a new 2026.1.3-3 firmware release last week. Do you have still the issue ?

Thanks

[iMicknl]

@fberu-somfy in the TaHoma app (which uses cloud API, right?) they are available. This is only an issue on the Local API.
I didn't face this issue myself, but other users reported this.

[iMicknl]

@fberu-somfy one user reported the updated solved the issue, thanks!

[BernoldNL]

Is this related?

When I send a (setPosition) command to one of my roller shutters it does not respond. Then when I read /setup it indicates it is unavailable. Meanwhile RSSI level is stable at 44 (Normal). I can get status back to available by using it's Smoove RS100io. But then when I try again, it becomes unavailable again. Other roller shutters seem to work without issue.

I am on firmware version 2026.1.3-3 now (latest).

Edit: Seems to be working again with 2026.1.3-4.

[viriemailing-byte]

LocalAPI not working as intended for me:

Home Assistant Log:
" "2026-04-14 18:49:26.849 ERROR (MainThread) [pyoverkiz.client] Giving up fetch_events(...) after 5 tries (aiohttp.client_exceptions.ClientConnectorDNSError: Cannot connect to host gateway-2310-xxxx-xxxx.local:8443 ssl:False [MDNS lookup failed, DNS server returned answer with no data])

2026-04-14 18:49:36.147 ERROR (MainThread) [homeassistant] Error doing job: OSError exception in shielded future (task: None)

Traceback (most recent call last):

File "/usr/local/lib/python3.14/site-packages/aiohttp/connector.py", line 1574, in _create_direct_connection

hosts = await self._resolve_host(host, port, traces=traces)

        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

File "/usr/local/lib/python3.14/site-packages/aiohttp/connector.py", line 1165, in _resolve_host

await future

File "/usr/local/lib/python3.14/site-packages/aiohttp/connector.py", line 1221, in _resolve_host_with_throttle

addrs = await self._resolver.resolve(host, port, family=self._family)

        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

File "/usr/local/lib/python3.14/site-packages/aiohttp_asyncmdnsresolver/_impl.py", line 197, in resolve

raise OSError(None, exception_strings)

OSError: [Errno None] MDNS lookup failed, DNS server returned answer with no data

" "

[iMicknl]

@viriemailing-byte this isn't related to this issue; please open a new one. At a glance, it's hard to tell whether this is a networking issue on your device/Home Assistant side or something specific to the Somfy TaHoma Developer mode.

[slennie12]

Since yesterday I'm also facing this issue, the strange part is is that I was already running 2026.1.3-4, the local api did work for me for at least two months. (despite that when the Tahoma was cutoff from the internet, I needed to reboot the Tahoma Switch from time to time, but that seems to me another issue). It are also not all devices, I still get information from some Amy remotes for instance via the local API. (in this case the temperature. Unfortunately, all my shutters are available:false, according to the diagnostics). The cloud api does work correctly.

I've tried to "re-add" (deleting and searching for io devices) all devices to the Tahoma Switch after initially losing all shutters, and after generating new io keys for all devices, it did again work in Home Assistant via the local api. After around 8 hours of being connected, most devices did lose again their availability status, despite that the cloud api does work correctly. A reboot of the Tahoma, generating a new API key and re-adding the the gateway to Home Assistant did not work. A JSON of one shutter in the diagnostics of Home Assistant;

          "controllableName": "io:DynamicRollerShutterIOComponent",
          "deviceURL": "io://****-****-3056/11098332#1",
          "synced": true,
          "label": "** *(**#**)*",
          "type": 1
        },
        {
          "states": [
            {
              "value": "available",
              "type": 3,
              "name": "core:StatusState"
            },
            {
              "value": 2200,
              "type": 1,
              "name": "core:LuminanceState"
            },
            {
              "value": 20,
              "type": 1,
              "name": "core:SunEnergyState"
            }
          ],
          "attributes": [],
          "available": false,
          "subsystemId": 2,
          "enabled": true,
          "definition": {
            "states": [
              {
                "name": "core:LuminanceState"
              },
              {
                "name": "core:SunEnergyState"
              },
              {
                "name": "core:StatusState"
              }
            ],
            "attributes": [],
            "commands": [],
            "widgetName": "LuminanceSensor",
            "uiClass": "LightSensor",
            "type": "SENSOR"
          }

[slennie12]

@slennie12 could you report the bug to Somfy? You can add your problem description and diagnostics to the Somfy issue (#217), so that they can investigate.

@iMicknl; That is already this issue, right? :)