"stuck" temperature reading

[corsac-s]

Hi, I noticed I sometime get the same temperature reading for multiple hours using TEMPER2 external sensor:

I'm unsure if it's something in the firmware or in the way it's queried with Python. It looks a bit like that “old” issue in a different project: https://github.com/padelt/temper-python/issues/61

Not sure there's anything which can be done at the software level but in case some other people experience that and/or have a workaround, I'd be interested.

[eode]

I've sent a message to the manufacturer, but am doubtful of getting a response.

[corsac-s]

I've sent a message to the manufacturer, but am doubtful of getting a response.

Thanks! I'm not holding my breath indeed.

Considering the following quote from #9 applies to this issue:

I haven't run into this issue -- how frequent is it? Do you have a repeatable case we can use for testing?

Honestly I don't know. I run temper.py on various boxes during munin runs, in order to graph temperature over time. So I don't really have a repeatable case besides just running it every 5 minutes and check if the graphs look correct or not.

Over the last week there really was an example of the external sensor beeing stuck around 11°C here:

In the mean time, I've created the branch stuck_temp_fix that you can check out.

Please let me know if it helps. If it does, I'll optimize it and include it (at least as a configurable option). It will probably be disabled by default, because it does incur a +50% overhead in run time for each device -- or, if optimized, would still incur a lot of irregularity in the call time.

Yes I'll report back. I don't think I'm too bothered by the overhead but I can understand it's an issue.

[eode]

@corsac-s Thanks, it getting stuck like that is pretty weird, and ~has to be~ is probably a hardware issue (considering it shows up in other projects as well). Looks like it's happening often enough that it should be confirmable in a week or two.

That branch automatically uses the reset, so you don't need any particular cli or function arguments.

Oh, BTW, just confirming relative to the PR and README -- the temper-hum 3.9 doesn't support temperature, just humidity, right?

[corsac-s]

@corsac-s Thanks, it getting stuck like that is pretty weird, and ~has to be~ is probably a hardware issue (considering it shows up in other projects as well). Looks like it's happening often enough that it should be confirmable in a week or two.

Yes, I'll report back

Oh, BTW, just confirming relative to the PR and README -- the temper-hum 3.9 doesn't support temperature, just humidity, right?

I don't know, I only have Temper2 and TemperGold so no humidity sensor.

[eode]

Ah. Was adding another one, I think it's my typo then.

[corsac-s]

@corsac-s Thanks, it getting stuck like that is pretty weird, and ~has to be~ is probably a hardware issue (considering it shows up in other projects as well). Looks like it's happening often enough that it should be confirmable in a week or two.

Yes, I'll report back

I'll let it run a bit more but unfortunately it doesn't seem fixed:

[eode]

I'd have to agree - that means a USB reset doesn't have an effect on the issue. I'd be happy to see a few more days of data to satisfy the completionist in me, but realistically that's probably enough data to call that potential resolution a no-go.

That's too bad, and it makes me concerned about my own device - I'm going to need to start graphing that data for my own system to check for this issue.

On Fri, Nov 25, 2022, 9:32 AM Yves-Alexis Perez @.***> wrote:

@corsac-s https://github.com/corsac-s Thanks, it getting stuck like that is pretty weird, and has to be is probably a hardware issue (considering it shows up in other projects as well). Looks like it's happening often enough that it should be confirmable in a week or two.

Yes, I'll report back

I'll let it run a bit more but unfortunately it doesn't seem fixed: [image: image] https://user-images.githubusercontent.com/18496906/204016805-a0351923-fa51-4b01-a705-9cc6a9b0692c.png

— Reply to this email directly, view it on GitHub https://github.com/ccwienk/temper/issues/13#issuecomment-1327632002, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAS4PT77H3QNJXSDD6YIHELWKDL2JANCNFSM6AAAAAAQYOVPR4 . You are receiving this because you commented.Message ID: @.***>

[eode]

Still, since it's consistently the same incorrect temperature, we might be able to at least increase the accuracy by making it really work hard if it wants to return that value.

This would be a significant lag spike, so it would need to be optional, but if we get that specific value, we could poll it N times and see if it only returns that value or if it occasionally returns another one. Then, if it occasionally returns another one, use that value instead.

Of course, this depends on the behavior of the device, and I don't really know if it would vary, or if it's solidly out of commission during those times.

[corsac-s]

So after a few days:

If you have ideas on how to debug or poke the device and you can't really reproduce on yours don't hesitate to ask, I can definitely run experimental code here.

[eode]

Still on my radar, but I haven't had time recently to work on it.

I haven't heard back from PCSensor.

The only thing I can think of that might work (and I doubt it) is we can poll it multiple times if the result we get is 11c, and see if it gets anything else. But by the graphs, I'm not too hopeful about that.

[corsac-s]

The only thing I can think of that might work (and I doubt it) is we can poll it multiple times if the result we get is 11c, and see if it gets anything else. But by the graphs, I'm not too hopeful about that.

Yeah I don't think it'll work, it get stucks at multiple temperatures: 11C but also around 19C (not the same device):

I'm not sure what makes the thing “unstuck”.