I have a scpi-sensor daemon that experiences a comm snafu with a frequency of ~1 per week. The issue I observe is, after some time, all of my measurement key-value pairs become shifted by one:
>>> # normal
>>> client.get_measured()
>>> {"power": 4.34, "temperature": 21.12, "shutter": 1.0, "measurement_id": x}
>>> # after comm issue
>>> client.get_measured()
>>> {"power": 21.12, "temperature": 1.0, "shutter": 4.34, "measurement_id": y}
I have not yet identified exactly what happens that makes the write/read calls get unsynchronized, but the measurements keep coming without issue, just with the wrong channel map.
Client side restarts do not fix the issue; the daemon needs to be hard stopped and restarted.
Hoping to have a solution that (a) prevents key value errors from persisting after the bad measurement, and/or (b) fixes the issue through a client restart command.
Presumably the other scpi daemons would also benefit from whatever fix we come up with here.
I have a scpi-sensor daemon that experiences a comm snafu with a frequency of ~1 per week. The issue I observe is, after some time, all of my measurement key-value pairs become shifted by one:
I have not yet identified exactly what happens that makes the write/read calls get unsynchronized, but the measurements keep coming without issue, just with the wrong channel map.
Client side restarts do not fix the issue; the daemon needs to be hard stopped and restarted.
Hoping to have a solution that (a) prevents key value errors from persisting after the bad measurement, and/or (b) fixes the issue through a client restart command.
Presumably the other scpi daemons would also benefit from whatever fix we come up with here.