New method to automatically detect phoenixcontact_modbus UPS model

[RikyPlaza]

Implemented a new method to detect the UPS model connected since firmware version register is not consistent.
2 fixes of probelms mentioned in #2710.

[RikyPlaza]

No idea on this error, the CodeQL is failing with the following error:

phoenixcontact_modbus.c: In function ‘upsdrv_initinfo’: phoenixcontact_modbus.c:174:66: error: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Werror=format=] 174 | fatalx(EXIT_FAILURE, "Uknown UPS part number: %llu", PartNumber); | ~~~^ ~~~~~~~~~~ | | | | | uint64_t {aka long unsigned int} | long long unsigned int | %lu

The ci-nut-org build is failing with:

Making all in drivers �[1mphoenixcontact_modbus.c:174:55: �[0m�[0;1;31merror: �[0m�[1mformat specifies type 'long' but the argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat]�[0m fatalx(EXIT_FAILURE, "Uknown UPS part number: %ld", PartNumber); �[0;1;32m ~~~ ^~~~~~~~~~ �[0m�[0;32m %llu

[jimklimov]

@RikyPlaza : Cheers, I've updated this PR with a few typo fixes. Hopefully can merge after CI is done with it.

[AppVeyorBot]

✅ Build nut 2.8.2.2526-master completed (commit 124accff17 by @jimklimov)

[RikyPlaza]

@jimklimov Hi, thanks for the tips. Just a quick question: was the issue related to different machine-architecture of the CodeQL and CI builds? As i was telling i'm not a very C/C++ developer but i guess the issue was related to the fact that format specifiers "%ld" - "%lld" are not expecting same bit-long variables on the two builds.

Regards

[jimklimov]

Yes, there are many different int-like types that are macro'ed/typedef'ed as size_t on different platforms, and then different format string tokens to name them (e.g. %zu and %ju are "recent" additions in terms of where NUT can be built).