Skip to content

Fall back to the web portal when a socket SET is never acknowledged - #95

Open
justinmaiuto wants to merge 1 commit into
jnimmo:masterfrom
justinmaiuto:portal-fallback-on-ack-timeout
Open

justinmaiuto wants to merge 1 commit into
jnimmo:masterfrom
justinmaiuto:portal-fallback-on-ack-timeout

Conversation

@justinmaiuto

Copy link
Copy Markdown

What happens

Since early October 2026 the command server at 212.92.41.143:5210 accepts TCP connections again, but it never acknowledges SETs. On 2.4.0/2.5.0:

pyintesishome: SET uid=1 value=1 seqNo=N not acknowledged within 5.0s

Every command fails and the unit doesn't respond, even though the web portal still delivers commands. The fallback added in #90 only applies when _ensure_socket() fails. A socket that opens but stays silent never reaches it.

Change

  • _set_value: after the ack times out, try _portal_set_value() before returning False. The same portal path, lock and session from Add web portal command fallback when the socket cannot be opened #90 are reused.
  • use_socket=False is unchanged. That path returns before the ack wait, so it never reaches the portal.
  • Repeating a SET is safe. Portal SETs are absolute uid/value writes, so if the socket SET did arrive and the ack was simply lost, sending it again through the portal applies the same value.
  • I know the docstring says a missing ack is treated as a controller problem rather than a broken socket. If the controller really is offline, the portal SET fails too and the result is still False. The only cost is one extra portal round trip on a command that was going to fail anyway.

Tests

  • test_unacknowledged_set_falls_back_to_portal: the socket opens, no ack comes back, and the portal delivers. Returns True. This test fails without the change.
  • test_unacknowledged_set_fails_when_portal_also_fails: returns False and doesn't raise.
  • test_acknowledged_set_does_not_touch_the_portal
  • test_set_opens_the_socket_on_demand now stubs the portal so it stays offline.

The full suite passes: 107 tests. ruff check and ruff format --check are clean.

Field use

I've been running this as a local patch on Home Assistant 2026.10.x with hass-intesishome 2.4.0 since 11 Oct 2026. Commands that previously failed now go through via the portal, and the log shows the warning added here.

🤖 Generated with Claude Code

The command server at 212.92.41.143:5210 has been reachable again since
early October 2026, but in a half-alive state: TCP connects, the SET is
written, and no set_ack ever comes back. The portal fallback from jnimmo#90
only covers a socket that cannot be opened, so in this state every
command fails ("not acknowledged within 5.0s") while the portal would
still have delivered it.

Use the same portal fallback after an ack timeout. Portal SETs carry
absolute values, so repeating a SET that did arrive is harmless.
use_socket=False is unaffected: it never reaches the ack wait.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant