简体中文界面。帖子、指南及政策正文保留原文；未对原文作自动翻译。
VeraCarr · 2026年7月2日 08:34 UTC
Save one successful and one failed response with the exact installed SDK version. Then compare them with its documentation before selecting any numeric field. The fact your existing labels can display a number isn't evidence that the number is a mode.
8分Does a failed request produce a new number, or leave the previous mode on screen? Those are different places to investigate.
5分Rachel, a new number: our helper catches an extraction error and returns zero, which the screen labels as a mode; Nora, the saved failed container has no valid mode value according to the matching guide.
17分Would an explicit unavailable result avoid inventing that zero? I would still retain the failed response for diagnosis, rather than make the adapter quietly discard why it could not obtain a mode.
0分Yes, Bruno, but do not reject every zero either. Vera needs the documented success condition and payload validation, not a blacklist of values that looked embarrassing in the failed case.
8分And how are you selecting the old or new interpretation? Guessing from the container length will become another plausible-looking answer when a third shape turns up.
15分Rebecca, the helper tries the new extraction and falls back to the old path on any exception; I'm removing that guess and making the configured environment select its documented adapter.
22分What happens if the configured adapter does not match the imported SDK? Configuration can be wrong too.
10分Rachel's point belongs at startup. Verify the loaded package identity against the supported adapter and fail visibly on a mismatch. Don't make the first failed poll your version detector. Keep unexpected response forms distinguishable from ordinary documented read failures.
11分Does the display need the detailed failure reason, or only an unavailable state with somewhere to inspect the diagnostic record? I would avoid teaching operators to decode raw SDK containers.
4分Bruno, unavailable with a readable reason and a link to the diagnostic record; package mismatch is a startup error, while a documented unsuccessful poll is shown as a read failure, and neither supplies a numeric mode.
19分Nora, I agree on unexpected forms being distinct, but I'd also test one after a good reading; otherwise the parser can complain correctly while the display keeps the previous mode looking current.
9分And a documented successful mode of zero. Otherwise this particular fault could produce a fix that rejects a real state.
16分Both cases are in the tests: successful zero remains a valid mode, failure supplies no current mode, and an unexpected container after success clears the current-state display while keeping any previous read explicitly historical.
15分Does historical identify the time of the successful read and its connection context? A screen refresh timestamp beside an old value can still make it look newly observed.
25分That's the last-user problem for me too. People should not need to open the diagnostic record just to discover the large mode label is old.
18分Would the same explanation be available before any good reading exists? A previous-value panel with a default entry would reintroduce the invention at startup.
10分Nora and Rebecca, historical values show their successful-read time and connection identity in a separate labelled area; Bruno, before the first success it says no successful reading, with no default mode. The maintainer has reproduced those screen checks from the saved cases.
6分Normal documented reads now pass in both supported environments, along with controlled failed reads, recovery and reopen checks; adapter mismatch and unexpected-form tests remain explicit errors, and the maintainer has accepted the mode-reporting fix with the version-linked examples retained.
8分Good, keep the regression that proves the old zero fallback is wrong alongside the valid-zero case. They explain why the fix checks the response contract instead of merely refusing an inconvenient number.
11分