With our work on the thermostat software, one of the issues that persists for us is that the button press tracking is fairly slow to reset so that when a button is pressed, there is between 500ms and 1.4 seconds before I2C reads to the IO expander STM chip return a response that the button as no longer being pressed. Since a button press can be debounced in 20-50ms, this time frame is very long which makes interactions with the buttons awkward for users.
We have played with the time between reads to the IO expender and they have no effect indicating that the issue is on the STM chip programming.
Could you clarify, are you working in your own C program running on the ESP32. And you are saying the the code running on the IO expander chip needs some changes? I am pretty sure that Lijun posted source for both CPUs on github.
Hi Maurice,
We are using our modified version of the TStat10 software on the ESP32, but the original software on the IO expander chip as we have not set ourselves for compilation on that microcontroller. The issue would seem to be a common one that would affect all thermostats in that even when we have a very simple program on the ESP32 that just polls the IO expander, the time frame of a button press on the IO expander is very long.
The following is some sample output from the simple program where we are just polling the IO expander and printing the time in milliseconds at which the button is pressed and for which the button is seen as still pressed on every subsequent poll. The “Button duplicate” output is where the reading from the IO expander is still seen as the value originally printed in the “Button press” output.
In each case, the IO expander shows the button as pressed for at least a second when it is just being pressed normally which would be less than half a second in any case.
2024/08/08 23:18:16 UTC - Button press 2
Button duplicate 2049083
2024/08/08 23:18:16 UTC - Button change detected
Button duplicate 2049136
Button duplicate 2049189
Button duplicate 2049242
Button duplicate 2049296
Button duplicate 2049349
Button duplicate 2049402
Button duplicate 2049455
Button duplicate 2049508
Button duplicate 2049561
Button duplicate 2049614
Button duplicate 2049668
Button duplicate 2049721
2024/08/08 23:18:16 UTC - Button action performed
Button duplicate 2049774
Button duplicate 2049827
Button duplicate 2049881
Button duplicate 2049935
Button duplicate 2049989
Button duplicate 2050043
Button duplicate 2050097
Button duplicate 2050151
Button duplicate 2050205
Another example:
2024/08/08 23:22:59 UTC - Button press 4
2024/08/08 23:22:59 UTC - Button change detected
Button duplicate 2332575
Button duplicate 2332681
Button duplicate 2332787
Button duplicate 2332893
Button duplicate 2333000
Button duplicate 2333107
2024/08/08 23:23:00 UTC - Button action performed
Button duplicate 2333213
Button duplicate 2333321
Button duplicate 2333428
Button duplicate 2333534
Button duplicate 2333640
Button duplicate 2333747
Button duplicate 2333853
Button duplicate 2333960
Button duplicate 2334073
Button duplicate 2334181
Button duplicate 2334288
Button duplicate 2334396
Button duplicate 2334504
Button duplicate 2334612
Button duplicate 2334718
Button duplicate 2334824
What is the end result of this change you are after. You need to respond on the display some messages and user interactions?
Can you show us the symptoms with the standard Tstat10 firmware like sluggish keypad /UI interactions or… just trying to understand so I can write this up for our team to work on it.
Hi Maurice,
A sluggish/non-responsive keypad is what is observed in certain cases when the same button is pressed more than once in succession. Conversely, pressing up then down will respond more closely with what is expected because the first (up) button state is quickly overwritten in the IO expander when the second (down) button is pressed.
The simplest example is when someone is attempting to change the temperature manually. Once they hit the up button, they basically have to count 1-1000, 2-1000 before they can hit the up button again to ensure that the new button press is detected. Otherwise, the button is seen as having been held down and no new button press detection can take place for the same button. The button state should only be retained by the IO expander for a few hundred milliseconds at most.
I hope this makes the issue clearer.
Thank you,
Chelsea will have a look at speeding it up.
Thanks for your feedback, I’ve improved the keystroke response speed in the new firmware. However, the processing of the button is done by a small chip, which is not very convenient to update and requires a small dongle.
Hi Chelsea,
Can you please clarify that you made changes to the STM chip firmware? If so, that is what we were expecting.
Is the STM firmware upgrade process and firmware documented somewhere? We can see the jumpers on the TStat10 board for selecting between the ESP32 and STM chip.
Will these changes automatically be present in future purchased units of the ESP32 based TStat10?
Thanks,
Jason
The changes require an update to the STM chip, correct. Not many folks will need to do this unless you are doing development work on the source code like you are doing. You will need to round up an STM programming dongle. Chelsea can give you instructions on how to do the update if you need help.
All new production will have this new ST firmware loaded, users might notice a little more responsive keypad is all but thanks for pushing us, in a good way.
Hi Maurice, Chelsea,
I am curious how much of an improvement was made in the button responsiveness? The repeated press of the same button was slow enough previously so that it seemed as if the button was stuck or not working. I can send the test program we wrote to test the timing of the button if that helps.
Please let me know once these changes have been pushed into the new products as we would like to install in more customer sites once we know that the button use will not confuse the users.
Thanks,
Jason
At present, I can only say that it is better than before, but it is not very good because of hardware limitations. I am still testing and hope to improve it as much as possible. You can send me your test program, thank you very much.
My email is chelsea at temcocontrols dot com