FR5 polling wrapper is displaying a failed request as a reading

LeoCarter0971 · 5 May 2026, 22:02 UTC

Reply to discussion
LE
LeoCarter0971
Changed SDK in our bench setup. Old wrapper expected one status value; the replacement gives a container with extra information. A failed request now reaches the display as a plausible reading. I've stopped using that screen for the trial. Need to untangle the parsing before restoring it.

10 replies

JA
JasperChan1073
Replying to LeoCarter0971

Capture successful and failed returns from that exact installed version, with the documented return contract beside them. Check success before extracting the reading. Don't select the first numeric field simply because it resembles the value your old wrapper used.

15 points
LE
LeoCarter0971
Replying to JasperChan1073

Saved both. The wrapper's fallback takes a numeric field after the old extraction fails. That explains the plausible number. Removing it and testing the parser offline first.

16 points
WI
WillCarter1009
Replying to LeoCarter0971

What happens to the previous successful reading when the next request fails? Leaving it unchanged can make the screen look current even after you remove the bad fallback.

16 points
IM
ImranAdams0131
Replying to LeoCarter0971

Had a test substitute hide a version mismatch on our teaching setup. Use the recorded returns here, not a fake response invented to suit the new parser

7 points
JA
JasperChan1073
Replying to ImranAdams0131

Include malformed and missing data too. A successful request with no usable reading still shouldn't paint a current status. Or rather, request success and a valid reading need separate checks.

6 points
LE
LeoCarter0971
Replying to JasperChan1073

Will, it currently keeps the old value with no stale indication. Added that to the offline cases. Jasper, missing data now has its own expected unavailable state rather than falling through to a number.

6 points
WI
WillCarter1009
Replying to LeoCarter0971

Show the time of the last valid observation if you retain it for reference. Make its age and the failed update visible; don't require the operator to infer them from a stationary number.

11 points
IM
ImranAdams0131
Replying to LeoCarter0971

And don't catch every exception as an ordinary polling failure. You'll hide the next programming error that way

4 points
LE
LeoCarter0971
Replying to ImranAdams0131

Parser tests now separate valid readings, reported request failures and invalid responses. Unexpected parser errors stay visible in diagnostics. The proposed screen marks retained data as old, but the operator review hasn't happened yet. Still offline.

6 points
JA
JasperChan1073
Replying to LeoCarter0971

When you review that screen, include startup before any valid reading exists. There isn't an old value to label in that case (and zero shouldn't quietly stand in for one).

19 points

Add to the discussion

Welcome to Application Robot

Everyone can read the forum. Sign in or create an account to start a discussion, reply, or upload photos.

Forgot your password?

By creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.