New Community Tools/Bug Fixes

[rcl27]

Just testing the waters. I went down the AI coding rabbit hole and ended up designing a full suite of tools/library for Virtuino. It was originally going to be just a collection of helper functions, but yea... I completely rewrote the backend lol. It is private now on GitHub, but if there are some other people that are willing to try it out and make their own additions, I am totally willing to release it as a new way to use Virtuino.

Current features:
1. No more Strings - everything has been converted to char arrays to lessen the risk of memory fragmentation. The user experience is more difficult using buffers with dtostrf and snprintf, however larger, more complex programs are now more robust.
2. WebSocket Disconnects - I have a literal army of watchdogs and backup measures in place that make disconnects incredibly rare. The ones that do happen will cause a weakened state that can last for about 10 minutes, but actual downtime is limited to about 1 minute. I wanted to actually solve the issue, but it is within the Virtuino code. If people are interested, I can explain this further.
3. WebSerial integration to allow for remote monitoring/commands.
4. A vast debugging catalog that can be edited on the fly through Virtuino. I have both a sketch version and a library version.
5. Batched variable uploading with scripts to use in Virtuino. I got it fully working with sensor data. A quirk of the language scripts, they don't realize where the variables are coming from even if the inputTag is linked to an ESP. Any variables received in the parsed message from the ESP will immediately be echoed back to the ESP (not just copied to Virtuino's local version of the ESP variable). Only work around is using an untagged "local" variable. They can be stored on the ESP's variable list, just no tags.
6. Import Variables & Widgets - Separate from the library, but I am in the process of finishing some python scripts that import csv data and convert directly to new/edited variables and widgets. I mentioned this in a previous post, but have refined it since then.
7. Minor Options - Most of the options in the library can be set in the sketch, so you can enable/disable automatic resets, watchdogs, timers, debugging categories, see which debugging categories/output are currently enables, etc.

So yea, it's been a wild month and it's nice to see sunlight again lol. If anyone is interested, hit me up. I would love to get some input from humans instead of just Copilot's Claude and Gemini!

[krzycho]

could you give me the address of githyb?
I'm not very good at programming, so the ability to use String variables to exchange ESP <> application information is incredibly beneficial to me. I prefer to reset ESP from time to time to clear RAM than to make my life difficult with array variables.Your other changes seem interesting and I'd be happy to check them out.

The problem of disconnecting WebSocket communication is easily solved by enabling the full heartbeats mechanism on the ESP side. If you detect a lack of communication with the client, you should restart the WebSocket protocol. This solves 99% of disconnection cases. The remaining 1% requires a software ESP restart (in my case only for ESP32C3)
I have not had the need to restart the application to resume communication with the ESP

[rcl27]

Hey! You are actually the reason I implemented a softer WebSockets restart as a first line of defense vs the hard reset I had before. I still have subsequent hard resets programmed in if it needs it, but you were right that WebSockets alone is fine for 99% of the problems.

The loop I kept hitting:
Client[0] is connected... X time passes... Client[1] connects! Activate sendPinStatus! It would make it about half way through before one failed. Then it would just be 10 second timeouts until... Client[2] connects! sendPinStatus! Except the WebSockets/Async buffers would all be filled up now without receiving the ACK back. Then Client[3] connects!

Eventually in the mix, clients will drop off. Sometimes Client[0] disconnected within the first seconds of Client[1] connecting, other times I lost it.

Once we got some solid (I say we as in me and Gemini 2.5 Pro) debugging things in place with some client management. It seems Virtuino tries to aggressively reconnect back to the client. I am still not 100% sure if the original client[1] connection is tied to a Client[0] disconnect or if the spurious Client[1] causes the disconnect.

I will PM you the GitHub address in just a bit. I still would prefer a few eyes on it before I make it public. Especially because the library is still a bit of a mess. I have been more in "Debug mode" vs "refine it and make it a cohesive body of code mode". We basically would just shotgun debug messages any and everywhere we could. I am sure there are doubled in there too from different sessions lol.

I don't have a readme or any instructions yet, but there are A LOT of comments all through out. I will try and write you up some basic X does Y notes though!

[krzycho]

Thanks for github
You are right - the application is quite aggressive in trying to connect to ESP. In the WS connection settings, there is only the option to set a timeout without the option to set the number of unconfirmed control frames. 
I think this generates more clients.
For important ESPs I set very short delay times for confirming the control frame in the ESP and a small number of repetitions, obtaining disconnection times of max 5-10 s. This generates slightly more traffic in the WiFi network, but it is irrelevant considering the current WiFi protocols.