It’s a bit difficult to respond to this meaningfully without knowing which hardware you’re using, and what isn’t working at the moment (is your code compiling? does it run? are you getting errors? are the readings incorrect?)
I’m not sure what the logic is here. What risks are you concerned about?
It would likely be beneficial to refer to the Blue Robotics TSYS01 arduino library. You’ll also want to make sure you have appropriate pull-up resistors on your SDA and SCL lines (which might already be integrated into your board, or level converter if you’re using one).
Compilers check for consistency, not correct English, so since the same spelling is used throughout that shouldn’t cause any compilation issues. Now that you mention it though, I’ve just noticed that the ReadK function takes in char Adress and then doesn’t actually use it (but does use a hardcoded TSY01_K0 which is likely where that variable is supposed to go).
In the Blue Robotics Arduino library the reading process gets all the calibration values in a loop, into an array, with just one delay beforehand instead of one per value. That’s a more robust way of obtaining the relevant data, and avoids having to hardcode a read call and corresponding output variable for each calibration value.
Now, I found a new problem: temperature is OK but become wrong some hours after (22 degres to 49 degrees !). On a second system, temperature -same environment- is always good.
I was thinking it was a cable problem so sensor has been changed by a new one.
I did a soft reset and saw temperature came back to good value.
So this is my new question: there is a temperature request every 10mn, is it better to do a “reset” before each reading request (reset reading K0 to K4) ?
There doesn’t seem to be any mention of a maximum delay time in the sensor datasheet, so it’s unexpected that the sensor would be playing up like this.
It’s perhaps worth noting that the code in your initial post seems to be missing a few stop calls - you start I2C, write some things, wait a bit, and then start again without stopping. It’s possible this (or some other part(s) of your program) are causing the sensor to misbehave.
I don’t believe this should be necessary, but it’s at least good to know that it’s working for you
It was to dangerous to have a wrong measures so I prefered to be sure it made a reset in case of big variation (my product can be used for more than 20 days and there is no possibility to make a manual correction during this time). Now I didn’t saw wrong temperature in real situation (6 days long).