1.0.0

[aaronbeckmann]

The intial release for ESP-DashboardPlus.

If you find any bugs start a Issue or Pull Request.

---

This discussion was created from the release 1.0.0.

[Crudelis98]

I forked it and am very interested. It's exactly what I need for my project. However, I have a few questions:
Is it maintained?
Why use strings?
Why unmaintained async libs?
Console logs very buggy, sometimes works some times it doesn't, I will expand on this, of course.
BUT
Last commit was 1m ago, so It gets me worried, if you are stilll working on this? If yes, nice job keep it going and forget the questions.

[aaronbeckmann]

Thank you for your interest in my project! I am actively working on ESP-DashboardPlus as a hobby project. It is and will be maintained in the future. Any reported bugs or issues found by me or someone else will be fixed as soon as possible.

• Regarding the question about strings: please elaborate.
• The async libs used where chosen because I had weird issues with random crashes of the esp32. If you find compatible versions or alternatives which can be used with some adjustments I am happy to exchange them.
• Console logging is indeed not buggy. A console log element can only be transmitted if dashboard.loop() runs. If you place a delay() after a console log on the same core as the dashboard.loop() call then the logged element will not be transmitted in the timeframe you thought it would. If you combine this for example with a countdown until the device is restarted with delay()'s inbetween, this might cause the messages to be lost at all as dashboard.loop() is not called until after the restart.

[Crudelis98]

Regarding the question about strings: please elaborate. + Console logging is indeed not buggy.
The problem with using String is that it can fragment the available memory to the point where there are no longer large blocks of free space. In my app I store last 30 logs. When I try to send them at once via ESP-DashboardPlus, it breaks.
In apps like this I use global buffer, char buff[512]; and write to it in every function. With that I have 512 bytes reserved in same place in memory + its not in heap.
The async libs used where chosen because I had weird issues with random crashes of the esp32. If you find compatible versions or alternatives which can be used with some adjustments I am happy to exchange them.
I repleced with:
bblanchon/ArduinoJson
ESP32Async/AsyncTCP
ESP32Async/ESPAsyncWebServer
Didn't ecnounter any problems, except warnings of:
StaticJsonDocument<64> doc; is deprecated, use JsonDocument.

[aaronbeckmann]

When sending 30 logs, do you use the broadcastLog() function with any logX() functions with all logs in one message, or individual calls for each log item? - there is a size limit in the JSON doc of 512 bytes sent over the websocket.
When logging 30 logs in quick succession the string output in line 1932 is allocated (I would estimate roughly 350 bytes per message) this would lead to ~10KB of heap being possibly fragmented (~12KB with the serialization overhead). Which is quite low compared to the heap available (~300KB).
While I think assigning a global buffer for usecases such as writing data to console for example for later plotting is a great idea, i must ask are you sustaining the log burst over sustained periods? how does your partition table look like?

If your usecase is exporting csv like data would you wish for an osciloscope feature which can be attached to a pin or input stream?

Regarding the global buffer for logging: Please create a PR of your fork. I would like to have you in the list of contributors for the hint and for future reviews. Thanks!

[Crudelis98]

Don't worry, I'm so interested that I won't disappear. I have a lot of work right now and I'm working on my project after work too. But I will definitely contribute to this project.