Issues after updating libraries

[mczakk]

Hi Matthias, tried to update my esp32 today , simply to change one line of text on the OLED display, but now it appears that the code will not compile at all. I have installed all the latest for weathersensorreciever and weathersensor, but once i click upload the ide hangs at this point: I have tried selectin both TTGO LoRA32 v2 and TTGO LoRa32 V2 (1.61) (the correct one) in the board revision, both with the same result! I did managed some sucess earlier, but the screen wasn't working, nor was the board sending to TTN. this screenshot shows the serial output from such an attempt:

Any Advice would be greatly appreciated

[matthias-bs]

Hi, I'm pretty sure that the offending line with global_tbuf is part of your customization. Could you please upload it to your github? I'll have a look when time permits. Did you also update the IDE/compiler? Cheers Matthias

[mczakk]

Your'e right, i hadnt declared global_tbuf , but have now. I've uploaded my BresserWeatherSensorTTN3.ino and ...TTNCcfg3.h files to github for you to look at. thye code compiles and uploads, but gives the guru meditation errors as shown in the previous post My arduino ide is fully up to date, running version 2.1.1

[matthias-bs]

Currently global_tbuf is never written to, but read in displayWeatherData(int ws). It seems you are lucky - global variables are initialized to zero (if I'm correct), so the string functions will find a terminating \0 immediately. But I would not rely on that and this is probably not what you intended to do.

I just got an uplink and a full execution cycle with your code. The code seems to be o.k. Maybe a glitch with a stale library, i.e. a library has not been compiled after updating?

You also modified your sketch to adopt the change in the rain counter - that's good!

Update: I ran the sketch on a TTGO LoRa32-OLED V2.1 (compiled with Core Debug Level: Verbose) for more than an hour. I checked the communications on TTN console and the log messages - nothing wrong there. Only the OLED display was not showing anything useful, only "noise" it seems. I did not check the I2C wiring, though.

[matthias-bs]

Maybe a primer about the Adafruit_SSD1306 class helps.

Adafruit_SSD1306 inherits from Adafruit_GFX (see Arduino/libraries/Adafruit_SSD1306/Adafruit_SSD1306.h and Arduino/libraries\Adafruit_GFX_Library\Adafruit_GFX.h)

Adafruit_GFX inherits from Print (an Arduino class) (see https://github.com/espressif/arduino-esp32/blob/master/cores/esp32/Print.h)

That means, your display.print() method has the same interface as the Arduino print() method.

From Print.h:

    size_t print(const __FlashStringHelper *ifsh) { return print(reinterpret_cast<const char *>(ifsh)); }
    size_t print(const String &);
    size_t print(const char[]);
    size_t print(char);
    size_t print(unsigned char, int = DEC);
    size_t print(int, int = DEC);
    size_t print(unsigned int, int = DEC);
    size_t print(long, int = DEC);
    size_t print(unsigned long, int = DEC);
    size_t print(long long, int = DEC);
    size_t print(unsigned long long, int = DEC);
    size_t print(double, int = 2);
    size_t print(const Printable&);
    size_t print(struct tm * timeinfo, const char * format = NULL);

• The first parameter shows which datatypes are supported - Arduino F("") strings, Arduino String class, C strings aka. character arrays, character, ...
• The integer types of different width - signed and unsigned - have a second parameter with default value DEC. This means without specifying anything else, the value will be printed as decimal. Other options are HEX, OCT and BIN.
• The double type has a second parameter with default value 2. This is the number of fractional digits. I.e. display.print(3.1416, 1); will just print 3.1.

Now you only have to make sure that

• Anything you want to print has a supported data type (or a typecast is possible, either automatically or explicitly)
• The variable you want to access is within the scope of the function, i.e. is visible where the display.print() function is located

The compiler will help you if all warnings are enabled. (Please make sure they are!)

The display.print() statements in displayWeatherData() look fine to me.

In the beginning of the sketch, you have //display.print("%s",tbuf); - this won't work, because formats strings are not supported by the Arduino Print class! Only the printf() function (and its siblings) support this.

Finally, when dealing with character arrays like char global_tbuf[24]; you make sure that enough space is provided for the desired contents AND the terminating \0 character! I.e. if you write to it with sprintf(), only 23 characters are permitted! If you write past the array boundaries and the compiler did not detect this (which is quite possible), the CPU happily write into anything which happens to be located in the adjacent memory location - which leads to disaster in most cases and is often hard to track down.

The Arduino String type (https://www.arduino.cc/reference/de/language/variables/data-types/stringobject/) handles the size dynamically, this is much safer (but less efficient). If a function can't handle it, you can still convert it to an ordinary C string: printf("%s", String("This is an Arduino String object").c_str());

Hope this helps!

BR Matthias

[matthias-bs]

Another advice: If you save you code on GitHub, just overwrite your previous version with an update instead of using Sketch2.ino, Sketch3.ino etc. This allows to compare the different versions quite easily.

[mczakk]

Thanks for all that Matthias, i guess what is confusing me is that the only thing i changed in the code was line 1756 from "White Lodge Weather" to "Cwm Hir Weather". Yes i updated the Libraries and had to comment out the lines about defining Bresser 7 in 1 and lightning , but other than that i changed nothing! to me, the only things that have changed are the BresserweathersensorReciever libraries I may have found one issue, the wire hardwired to pin DIO1 on the board may have been contacting the metal cover as shown by the green line in the picture: Is it possible that i have fried the board?

[matthias-bs]

Maybe. I don't remember the signal direction this wire is used for. If it is an output of the ESP32 and the port driver is affected, you could switch to another port.

[matthias-bs]

BTW: Can you imagine any other heading for this issue? It seems the current one does not really fit any more.

[mczakk]

I've ordered a new board, will try that and see if its a hardware issue :) The board i have is not working with even basic code examples. However it does seem to work somewhat with the weather sensor code, as it reports the correct weather values just before giving the guru meditation error! I would argue that the heading does fit, after all the issues arose after i used the same code after updating the libraries? If the new board works properly i will close the issue :)

[mczakk]

Got the new board, but now I'm having issues with the complier https://forum.arduino.cc/t/issue-when-compiling/1151233/15 and here https://forum.arduino.cc/t/resolvelibray-arduinojson-h/1152357 Also, I keep getting errors causing the complier to crash that are just plain weird, as in they were not causing errors previously, but are now. It just doesn't make sense!!

[matthias-bs]

Well, I can only say that the latest CI run (compilation of the latest source code with the library versions defined in CI.yml using the current version of the Arduino command line tools) was just fine: https://github.com/matthias-bs/BresserWeatherSensorTTN/actions/runs/5678578038. CI is done for several boards (currently 8), including esp32:esp32:ttgo-lora32:Revision=TTGO_LoRa32_v21new.

Besides, I compiled your code with Arduino IDE 2.1.1 two days ago. It still works today (takes ~1 minute).

[mczakk]

well i'm just about done with this. All I wanted to do was upfdate one line in the display and it has cost me over a weeks worth of data. I have uploaded a folder to my github page which has the TTN .ino and Cfg.h files in, the ones from my windows machine, and those from my ubuntu. neither will compile. the compiler takes over 30 minutes on 'resolvelibrary and then the compiler either hangs forever (windows) or fails to compile with a variety of reasons (ubuntu) I have included screenshots of each machine at the end point of the compile process. Both machines are running fresh installs of Arduino IDE, with all libraries as up to date as possible. Niether the old board, or a brand new one (also with wirre from dpio2 to GPIO12) work on either machine. I am really srtuggling to see where the issue is!!

[matthias-bs]

Sorry about that! Never change a running system... If the data is precious, keep at least one last known good device. Did you try to compile an ArduinoJson library example? If you provide a compile log with all warnings enabled (text file, no screenshot!!!) I might have another look!

[matthias-bs]

I never experienced any problems like those with the Arduino IDE. It's really strange that both the Linux and Windows installations fail. You might consider to use the Arduino CLI tools. Or even set up the toolchain on GitHub. I could change my CI workflow to keep the binary. You could copy the setup and just flash the binary from your local setup.

[matthias-bs]

Don't know if this is related: https://github.com/G6EJD/ESP32-e-Paper-Weather-Display/issues/222#issuecomment-1656693415

[mczakk]

Interesting, I was going to try rolling back the arduinojson library to see when these compiler errors started

[matthias-bs]

Hi, any news on that?

[matthias-bs]

Closed due to inactivity.