#define MQTTMODE 0 in settings.h still generating error

[JureqB]

... Documents\Arduino\3D-LED-Clock-1.01\clock_main\clock_main.ino: In function 'boolean reconnect()': clock_main:106:1: error: no return statement in function returning non-void [-Werror=return-type] 106 | }

[Resinchem]

I'm not able to duplicate this issue as the code compiles fine for me whether the MQTT mode in settings is set to either 1 or 0. However, you can try adding an #else statement in the reconnect function to see if it solves your issue:

boolean reconnect() {
#if (WIFIMODE == 1 || WIFIMODE == 2) && (MQTTMODE == 1)
  if (client.connect("ClockClient", mqttUser, mqttPW)) {
    // Once connected, publish an announcement...
    client.publish("stat/ledclock/status", "connected");
    // ... and resubscribe
    client.subscribe("cmnd/ledclock/#");
  }
  return client.connected();
#else
  return true;
#endif
}

You can try adding the #else and return true lines to your version and see if it resolves the issue. But it shouldn't be required as I am not getting any compilation errors without it. As an FYI, I am using the Arduino IDE v1.8.16.

[JureqB]

I am using 1.18.19 (Windows Store 1.8.57.0)

When I have MQTT enabled, I can compile oryginal a sketch and only this message appears:

In file included from C:\Users\xyz\Documents\Arduino\libraries\FastLED\src/FastLED.h:79, from C:\Users\xyz\Documents\Arduino\3D-LED-Clock-main\clock_main\clock_main.ino:13: C:\Users\xyz\Documents\Arduino\libraries\FastLED\src/fastspi.h:157:23: note: '#pragma message: No hardware SPI pins defined. All SPI access will default to bitbanged output' 157 | # pragma message "No hardware SPI pins defined. All SPI access will default to bitbanged output" | ^~~~~~~~~~~~~~~~~~~~ Unfortunately, the uploaded program compiled this way does not work properly, I only see CLOCK_AP, I can connect to this network but the page 192.168.4.1 does not work

[JureqB]

Serial monitor at 74880 baud received this:

15:55:26.108 -> ets Jan 8 2013,rst cause:2, boot mode:(3,6) 15:55:26.108 -> 15:55:26.108 -> load 0x4010f000, len 3424, room 16 15:55:26.155 -> tail 0 15:55:26.155 -> chksum 0x2e 15:55:26.155 -> load 0x3fff20b8, len 40, room 8 15:55:26.155 -> tail 0 15:55:26.155 -> chksum 0x2b 15:55:26.155 -> csum 0x2b 15:55:26.155 -> v000618e0 15:55:26.155 -> ~ld 15:55:26.202 -> rf cal sector: 1020 15:55:26.202 -> freq trace enable 0 15:55:26.202 -> rf[112] : 0⸮

[JureqB]

After making the suggested change and turning off MQTT, the program was compiled, only the above message about SPI appeared and after programming, I can connect to the AP but the board is still not visible in the local network. I'm testing it on a bare board without a clock, sensor and LED, but it probably shouldn't affect the lack of network connectivity.

[Resinchem]

From the serial monitor, the rst cause:2, boot mode(3,6) is usually due to a watchdog reset. This means something is hanging in your program. It could be the real time clock, connection to wifi taking longer than expected, or some other peripheral that isn't wired correctly and is not reporting back as expected. I'd recommend verifying all your wiring, and if necessary, add some Serial.println() statements to various sections of the setup code to see where the application is hanging up.

Also the fact that you are seeing the clock AP being broadcast means that it isn't connecting to your wifi. Verify your WiFi settings in Credentials.h. You can also try setting WIFIMODE to 1 in the Settings.h, meaning that it will only connect to your wifi and not broadcast a local AP hotspot.

Unfortunately, I cannot duplicate the issue. Mine compiles and runs just fine, with or without MQTT. The 3D printed clock has been in operation for nearly 3 years now and I haven't seen or noticed any watchdog resets like you are reporting, so I don't believe this is a firmware issue but something likely due to your particular build.

[Resinchem]

OK... our messages crossed paths. First, the SPI message you are seeing is normal and isn't an error. Next, the watchdog resets are likely a result of the missing RTC clock module. The clock calls this module to get the current time... and I'm guessing that since you don't have the clock module connected, this is what is causing the reboots.

If the clock is constantly rebooting due to this watchdog error, it probably also explains why you cannot bring up the web page... the ESP is constantly rebooting and is unable to start the web server and respond to the web request.

For this particular code and the way it is written, the RTC module is required.

[JureqB]

I don't currently have the RTC module, once I put it all together I will let you know if there is any improvement, thank you for your help :)

[Resinchem]

No problem. Glad to help. This is one of my earliest Arduino projects and there is a ton of room for improvement. It's one of many projects I'd like to revisit and clean up the code... if I can ever find time to do it.

I'm going to go ahead and close this issue for now. If you have problems or errors after connecting the RTC module, feel free to open a new issue.

[JureqB]

I managed to assemble everything and run it, but I have a problem with the clock. The points should blink every second, but in my case they do it randomly - they blink for a few seconds and then there is a long pause or they stay lit for a few seconds. The time is displayed correctly. I changed the power supplies but it didn't improve anything. In the case of the timer, the dots blink perfectly, and other functions also work rather flawlessly. When externally powered, it synchronizes after going green on 2-3 segments of the first digit. Powered by USB, it turns green sometimes even for 3 digits, but when it starts, the dots still behave randomly. I have the following reading on the port monitor after the reset:

13:38:35.923 -> ets Jan 8 2013,rst cause:2, boot mode:(3,6) 13:38:35.923 -> 13:38:35.923 -> load 0x4010f000, len 3424, room 16 13:38:35.923 -> tail 0 13:38:35.923 -> chksum 0x2e 13:38:35.923 -> load 0x3fff20b8, len 40, room 8 13:38:35.923 -> tail 0 13:38:35.971 -> chksum 0x2b 13:38:35.971 -> csum 0x2b 13:38:35.971 -> v0005f530 13:38:35.971 -> ~ld 13:38:36.016 -> rf cal sector: 1020 13:38:36.016 -> freq trace enable 0 13:38:36.016 -> rf[112] : 0⸮

[Resinchem]

First off, you should not be trying to power everything via USB. The LEDs can pull over 4A depending upon color/brightness. It is recommended that no more than about 500 mA be pulled on he 5V pin on the D1 Mini/ESP8266. Trying to run everything via USB will likely damage or destroy the ESP board at some point. I think my build recommended a 5V 8A power supply and the board, as built, supplies power to the LEDs and controller in parallel so that the total current isn't running through the ESP board.

That being said, the error you are getting is a watchdog reset. This is generally due to something hanging or taking too long to complete, which results in a reboot of the board. The fact that the 'points' are delayed at times and that they work fine when in other modes (such as timer), points to something hanging up or delaying in the updateClock process. And the one thing that is different about that process is the real time clock module (RTC). It is highly likely that it is this module that is causing a delay when it is called (Rtc.GetDateTime). This would explain both the delay in the dots updating and the reboot if the delay is too long.

So you probably need to focus on the RTC module... assure it is properly wired, has a fresh battery, etc. It could also be causing issues if underpowered (e.g when powering via USB or an underpowered power supply). You should also verify that it is one of the supported chip sets for the RTC library being used. You can get that info here: RTC Library Wiki.

But the fact that other modes work fine and only the clock is having these issues points to either a problem with the RTC module and/or the system being underpowered. I'd recommend using a power supply that can supply at least 5A, preferably 8-10A.

[JureqB]

I have used various 3-10A power supplies and it does not matter. Current consumption during operation does not exceed 1.5A. Only when I turned off Wi-Fi+AP mode and left Wi-Fi anly (#define WIFIMODE 1) did the dots blink as they should. So it's a program problem, not an external one.

[Resinchem]

Do you have MQTT configured and enabled (MQTTMODE = 1)? There are really only two things in the main loop that could cause a significant delay (which would impact the blinking dots) or even a watchdog reset... waiting on the RTC module to return a valid value, or trying to connect/reconnect to the MQTT broker. The Wifi or Wifi+AP mode really shouldn't make a difference. The only difference between these two settings is whether the ESP continues to broadcast its hotspot after connecting to wifi (mode 2) or turns it off (mode 1).

It is entirely possible that I missed something, especially if MQTT is not configured or off... or I missed a combination check of both Wifi and MQTT modes to determine whether to use MQTT or not. But I have successfully been running this code for multiple years on this 3D clock. I also have 3 matrix clocks, and while the output to LEDs are different, the rest of the application logic is basically the same. But I do have MQTT enabled for all of these.

If you do have MQTT enabled, how long does it take for MQTT to connect when the system boots up? You should see green LEDs light when connecting to Wifi (although this could happen so fast that no green LEDs light up). When attempting to connect to MQTT, blue LEDs will light up. But note that a continuous connection is not maintained to the broker. So after a certain amount of time, a reconnection is necessary. So it if is taking significant time to connect/reconnect to your broker, that could potentially be an issue. Again... the other issue is communication with the RTC.

I'm happy to try to help, but I can't seem to replicate the issue on my clocks so it is a little tough for me to try to troubleshoot what might be occurring in the code.

[JureqB]

I don't have MQTT (MQTTMODE 0 MQTTSERVER "0.0.0.0" MQTTPORT 1883) , but my first problem, as you remember, was that I couldn't compile the program after turning off MQTT in settings.h

[Resinchem]

OK... thanks. Even though I fixed the compile errors, I most likely I missed something somewhere where it is still trying to connect to your non-existent MQTT broker. Since I'm using MQTT, I didn't actually install and test the last fix... just the fact that it compiled.

Give me a little time and as soon as I get a chance, I'll circle back to the code and go over it again and assure that it is not making any calls to MQTT if the option is disabled.

[Resinchem]

OK... I've reviewed the code and I don't see anything related to MQTT. If you set MQTTMODE = 0, most of MQTT functions and processes don't even get compiled into the firmware. But I was looking back through what we discussed above and something caught my eye. You said that the dots function normally for things like the timer, but are only acting unusual and delaying when in clock mode. In the main loop, every 1 second it calls the method to update the display (either via updateClock, updateCountdown, updateScoreboard, etc.).

Well, in the updateClock function is this call that isn't present in any of the other update methods:

RtcDateTime now = Rtc.GetDateTime();

So this points back to a potential issue with the clock module and/or its communication with the D1 Mini. The clock would appear to keep the correct time, as it only updates once per minute... and that timer is kept within the main loop. But the dot update (toggling the dots on/off) is occurring within the individual updates (clock, timer, etc.). So, if the clock update is taking too long to communicate with the RTC module, the dots will be delayed in turning off/on, but the master loop keeps counting, so the minute will roll forward at the 60 second mark (unless it is delayed in the loop right at that moment). That would also explain why the dots work normally in the timer mode, as it isn't calling the RTC module. Here's a test you can try that might confirm the problem:

Start a stopwatch right when a new minute is displayed. Watch it for 5 or 10 minutes. The clock should update to the next minute right at 60 seconds. If you are seeing a one or two second difference (or even greater), then the updateClock procedure is causing a delay. But since the 60 second counter continues to run in the main loop, you may not see this right away. So if you don't see a difference in the first 5-10 minutes, let both the stopwatch and clock run and come back every so often (maybe every hour or two) and see if the clock is still in sync with the stopwatch... updating the time at the top of minute on the stopwatch. If the update has drifted over time, this also indicates that the clockUpdate is taking too long and causing a drift over time. Unless you are pressing a bunch of the pushbuttons (these actually consume a couple hundred milliseconds), then the clock time should not drift by more than a couple of seconds MAX over a 24-hour period.

I don't think MQTT is the issue any longer. But it does appear to be something limited to the clock mode and the only real difference between that mode and the other modes is the call made to the RTC library/module. Please let me know what you find based on the above and we can take it from there.