Marc Billow
ba089dbb5c
Two releases landed since the 0.1.6 pin, both confirmed by upstream (QuiteYellow, in issue #361) as additive/opt-in with no interface changes on our side: - 0.1.7: server-certificate profiles (SamsungServerProfile), a bounded DTLS handshake deadline (connect() now defaults to a 12s bound instead of none), and a cancellable connect() via ConnectCancellation. Our connect() call sites in coordinator.py and config_flow.py pass no args, so they pick up the bounded handshake for free; the cert-profile and cancellation pieces are opt-in and unused here. - 0.1.8: fixes blockwise OBSERVE notification reassembly (QuiteYellow/SmartThings-Local#39) -- a notification carrying only the first Block2 block was previously handed straight to on_notification instead of being reassembled, and separately, the Block2 loop could append a retransmitted/late block as if it were the next one, or miscompute the next block offset after a mid- transfer size downshift. Both corrupt a multi-block observed resource without necessarily truncating it -- the "premature end of stream" / "error decoding unicode string" CBOR failures reported in issue #361 on /mode/vs/0. All error types stay within the existing compatible-built-in table (ConnectionError/TimeoutError subclasses), so no exception handling changes. `>=0.1.6` already permitted pip to resolve 0.1.8 on a fresh install, but an environment that already has 0.1.6 or 0.1.7 satisfying that floor won't be upgraded by Home Assistant's requirement check -- which is what #361's reporter is very likely still hitting on 0.22.0. Raising the floor to >=0.1.8 forces that upgrade on the next release. Verified against smartthings-local 0.1.8 from PyPI: full suite (1573 tests), ruff, and ty all pass. No source changes needed beyond the three version pins (manifest.json, requirements-dev.txt, Dockerfile).
10 lines
511 B
Docker
10 lines
511 B
Docker
FROM ghcr.io/home-assistant/home-assistant:stable
|
|
|
|
# Home Assistant normally installs a custom integration's manifest.json
|
|
# requirements itself at integration setup, but that depends on the
|
|
# container having outbound network access at exactly that moment and
|
|
# repeats the install attempt on every container recreate. Baking
|
|
# smartthings-local into the image keeps the dev container usable
|
|
# offline and avoids relying on that runtime install path.
|
|
RUN pip3 install --no-cache-dir "smartthings-local>=0.1.8"
|