client.py report_mode may yield empty object #42

Closed
opened 2 years ago by topquark12 · 4 comments
Owner

In pytec/pytec/client.py, def report_mode(self) may yield empty object once every few seconds when polled continously.

pytec/autotune.py shows a temporary workaround and shows where the issue can arise.

In `pytec/pytec/client.py`, `def report_mode(self)` may yield empty object once every few seconds when polled continously. `pytec/autotune.py` shows a temporary workaround and shows where the issue can arise.
topquark12 was assigned by sb10q 2 years ago
Poster
Owner

Just logging what I've discovered so far.
The phrasing of this issue might not be very accurate. The issue is actually a second set of {} sent after the pwm x i_set y command.
As you can see in the Wireshark screen capture, the client side was a bit slow to ack the {} sent after pwm x i_set y, so the thermostat just decided to send it again, which ends up in the pytec client input buffer, which is interpreted as an "empty" object in the next cycle.
Not sure if the workaround in autotune.py is good enough, or should pytec/client.py be fixed, or should something be done in thermostat firmware.

Just logging what I've discovered so far. The phrasing of this issue might not be very accurate. The issue is actually a second set of ```{}``` sent after the ```pwm x i_set y``` command. As you can see in the Wireshark screen capture, the client side was a bit slow to ack the ```{}``` sent after ```pwm x i_set y```, so the thermostat just decided to send it again, which ends up in the pytec client input buffer, which is interpreted as an "empty" object in the next cycle. Not sure if the workaround in autotune.py is good enough, or should pytec/client.py be fixed, or should something be done in thermostat firmware.
Owner

That's definitely a bug and the workaround is not acceptable. A TCP connection should never duplicate any data.
But I'm not sure if it's a TCP-level retransmission - normally Wireshark flags TCP retransmission packets as such, no? Isn't the TCP sequence number incremented between the two packets?

That's definitely a bug and the workaround is not acceptable. A TCP connection should never duplicate any data. But I'm not sure if it's a TCP-level retransmission - normally Wireshark flags TCP retransmission packets as such, no? Isn't the TCP sequence number incremented between the two packets?
Owner

So likely it's a bug in the way the firmware passes TCP TX buffers to smoltcp.

So likely it's a bug in the way the firmware passes TCP TX buffers to smoltcp.
Poster
Owner

Well I've done a bit of digging, so the send_line function is actually called twice in the main loop to send the {}, so TX buffer is working as expected.

However, I started to count the frequency of receiving double {} at the client, and it happens every 146 or 147 or 293 pwm 0 i_set 1 sent, which is 14 characters long including newline.

14 * 146 = 2044, 14* 147 = 2058, 14 * (293 / 2) = 2051 which are all suspiciously close to the socket RX buffer size of 2048.

I think something funny is happening at the Rx side of things.

Well I've done a bit of digging, so the send_line function is actually called twice in the main loop to send the {}, so TX buffer is working as expected. However, I started to count the frequency of receiving double {} at the client, and it happens every 146 or 147 or 293 ```pwm 0 i_set 1``` sent, which is 14 characters long including newline. 14 * 146 = 2044, 14* 147 = 2058, 14 * (293 / 2) = 2051 which are all suspiciously close to the socket RX buffer size of 2048. I think something funny is happening at the Rx side of things.
sb10q closed this issue 2 years ago
Sign in to join this conversation.
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.