hu values

[kalleick]

I implemented option 2 (with original KM271) and ESP32.
I get the setting values in the dashboard (e.g. automatic operating mode, burner on/off), but all temperature values are marked with "hu".
So the communication seems to work in principle.

But why am I not getting any readings?

Does it take a long time to see values or is there a defect?

[dewenni]

Hi,

that is interesting. I had a similar behavior in the past.
I am pretty sure that this is related to the printf format strings that I am using.

Are you using the latest version?

the related code is this:

the function is located in basic.cpp:

const char* uint8ToString(uint8_t value){
  static char ret_str[4];
  snprintf(ret_str, sizeof(ret_str), "%hhu", value);
  return ret_str;
}   

In your setup there must be some difference regarding the data types and the formatting of the printf.
But I honestly don't know what that depends on.

I think I must find a different solution for that conversions from number to string that is more robust.

[dewenni]

@kalleick
I did some research and I would like to ask you to try this code change:

add #include <inttypes.h> to the basic.h file

change the code of the convert functions in basic.cpp like below - using PRIi8, PRIu8, PRIu16, PRIu64

const char* int8ToString(int8_t value){
  static char ret_str[4];
  snprintf(ret_str, sizeof(ret_str), "%" PRIi8 "", value);
  return ret_str;
}

const char* uint8ToString(uint8_t value){
  static char ret_str[4];
  snprintf(ret_str, sizeof(ret_str), "%" PRIu8 "", value);
  return ret_str;
}

const char* uint16ToString(uint16_t value){static char ret_str[10];
  snprintf(ret_str, sizeof(ret_str), "%" PRIu16 "", value);
  return ret_str;
}

const char* uint64ToString(uint64_t value){
  static char ret_str[64];
  snprintf(ret_str, sizeof(ret_str), "%" PRIu64 "", value);
  return ret_str;
}

please give me feedback if this works for you. If yes, I will change the code and build a new release version.

Thanks!

[kalleick]

Hello Sven,

great, thanks for the quick help, that's really great!

yes i have had the newest version. my project started today

I have now done the following steps:

1. basics.h supplemented by the #include <inttypes.h>
2. Code changed
3. Build successful
4. OTA firmware upload from new file "firmware.bin"
5. Reboot
   But no change, still "hu" where the values should be.
   Maybe I have a too old Logamatic version (3.18)?

One more note: via MQTT I get these values:

2023-05-06_21:29:41 MQTT2_ESP_Buderus_KM271 ww_temp: 58
2023-05-06_21:29:41 MQTT2_ESP_Buderus_KM271 boiler_temp: 44
the others are also "hu", see attachment.

Best regards
Patrick
[fhem_mqtt.txt](https://github.com/dewenni/ESP_Buderus_KM271/files/11413

225/fhem_mqtt.txt)

[dewenni]

a pity...

but I still think that it is related to this format specifiers and your esp board.
here has someone else reported the same problem: HelTecAutomation/CubeCell-Arduino#117

It seems that in some cases the length specifier hh or ll is not supported.

then please try this one

const char* uint8ToString(uint8_t value){
  static char ret_str[4];
  snprintf(ret_str, sizeof(ret_str), "%u", value);
  return ret_str;
}

or maybe it is even better to also cast the value to unsigned int

const char* uint8ToString(uint8_t value){
  static char ret_str[4];
  snprintf(ret_str, sizeof(ret_str), "%u", (unsigned int)value);
  return ret_str;
}

can you please try and give me feedback?

[kalleick]

thank you, very much, this one worked:

const char* uint8ToString(uint8_t value){
static char ret_str[4];
snprintf(ret_str, sizeof(ret_str), "%u", value);
return ret_str;
}

info: i have this board:
https://amzn.eu/d/9RxEe0u

[dewenni]

ok, than I should change it that way.

but two more questions.

is this shown correctly?

and also this one?

[kalleick]

hi Sven, thank you so much, yes, some values are declared with "hi", see my screenshots.
MQTT Port ist OK.

[dewenni]

ok, its pretty clear that in your setup the 3-sign format specifier (hhi, hhu, llu) are not supported, even if this should be the right ones.
A format specifier %hhi result in printing hi, %hhu result in printing hu and %llu result in printing lu
Also if you use the combination with <inttypes.h> and the generic format specifier it seems that they are replaced with (hhi, hhu, llu) by the compiler that do not work.

I will change the functions to the "basic" format specifier (%u and %i) and hope that this will work for everyone else as well.
For the 64bit value, I will implement a manual way.