Deploying embedControl webserver to ESP32 and/or programatically accessing tcmenu item data on the ESP32 via wifi.

[AtmosphEng]

Hi Dave et al, I'm currently looking at deploying a embedControl webserver to an ESP32 and/or programatically accessing tcmenu item data on the ESP32 via wifi. On your tcc webpage https://www.thecoderscorner.com/products/apps/embed-control/control-embedded-device-browser/ it says "By default, the designer UI can take the most recently built version and auto deploy it to certain larger boards including ESP32 and Raspberry PI". I'm an experienced embedded engineer with C and some C++, but I've not done much network coding so I'm not sure about how to start doing this. Could you please elaborate on the feasibility of what I'm attempting here and/or provide some pointers on how to begin. Thanks.

[davetcc]

Unfortunately that page needs updating, the react app was too heavy to serve from lwip and ran into issues. I have a plan to try and serve most of the app from a CDN but it will take more time to prepare that.

As much as anything it needs time to do it and for me at the moment it is not a priority. if anyone else needs it they could look at how to serve the static parts of the app from a CDN, the rest would be trivial.

[davetcc]

In terms of the web based application onto ESP32 and STM32, that's a rather unfortunate situation really with me losing several months of effort trying to get it working. I even wrote a webserver that integrated with task manager to try and slow down the requests so that it did not overwhelm LwIP's memory stack, but even with that embedded boards do not like serving up a 100K React.JS app.. This is why I implemented the embedded Java on Raspberry PI option, it works really in my own testing but as I said earlier there are not many users of it yet.

Coming back to ESP/STM,. The LwIP stack tends to run out memory, and let's be honest, the purpose of an embedded board is to do its main job, be that an amplifier, greenhouse control or whatever else, we don't want to allocate over half of the memory to LwIP just so it can serve that app and risk missing an event while it is busy serving up a 100K app.

I think the answer here is to move to a much lighter framework, there are ones out there that focus on being light. They can serve up at around 15K, which including the API and logic may come in at about 30K compressed, which is probably more doable. But again the issue is time, I need to get 4.0 out before I can even think about anything else, and I've got a few projects of my own that have been on the back burner for too long.

[vzahradnik]

My plan is to build an Android/iOS multiplatform app to interact with TcMenu. This app won't be open-source as it's tailored for our specific product but I'd like to open-source whatever makes sense.

Android is easy. We already have Java implementation so if @davetcc makes an issue for this, I can over time create an example project to customize by others.

iOS is a problem. It doesn't work with Java. Originally I considered using Flutter but currently I'm more inclined to using Kotlin Multiplatform. Once I finish the Python version of the library, I'd like to implement the same in Kotlin and use that for the iOS app as well. Then, having an iOS example project could be possible as well. I'd say the library holds most of the business logic. Developers just need to build some UI around it for their needs.

I personally don't like the idea of running a webserver on the embedded device unless there is no way how to avoid it. With PCs and Android phones supporting the existing library, we already have covered perhaps over 80-percent devices (my ball-park estimation). Anyone can pick up embedControl app or integrate into their solutions with the libraries where some are yet to be written.

[davetcc]

I personally don't like the idea of running a webserver on the embedded device unless there is no way how to avoid it.

Agreed, I tried it, it really didn't work and in fact caused major problems. I have really gone off the idea since.

[davetcc]

I'd like to implement the same in Kotlin and use that for the iOS app as well. Then, having an iOS example project could be possible as well.

This should be quite straightforward as Kotlin should accept Java code, so hopefully we could just get the API working that way, and support both platforms. But as you said earlier, I also don't want to get into deploying a general purpose app either, it is just a world of pain for little gain. In my opinion the best offering would be if designer could output some kind of starter project with a few blanks filled in.

[vzahradnik]

We can further discuss this idea once I start actually building the app. I'm sure we can figure something out.

As for Kotlin, there is one caveat. In order for it to work on iOS, the library can use only the Kotlin code which is actually supported on multiple platforms. Luckily, there is enough for me to start. I just need to do some research.

Kotlin does operate with Java but it is not multiplatform. You can read more about it here:
https://kotlinlang.org/docs/multiplatform.html

[davetcc]

I mean maybe the answer here is, for people who just want a really simple Android and iOS UI without doing any build-out, that we provide an integration plugin with an IoT solution such as Blynk. Many tcMenu users already integrate with Blynk, and on the old forum, the one mentioning it was in the hottest topics list. I would imagine the integration would be relatively simple and if there were any sticking points, help would probably be available to better integrate the two.

EDIT - that way it would become:
I want a simple ready made UI -> use Blynk (or other ready built IoT solution)
I want to write a custom UI using components -> use the APIs we provide and build a UI.

[davetcc]

So this morning I've updated the documentation to remove any mention of running the webserver-based solution on anything other than a Raspberry PI. It is well supported on the PI and works pretty well for light use cases, tested with each release too.

I also created the repo for the Xamarin mobile UI prototype as discussed yesterday https://github.com/davetcc/tcMenuController which would provide the components to quickly build any UI. It does have the just-in-time UI in there but it is not advanced enough to put on the store as is. This effort was from a prototype a few years ago that I decided to open source.

With the resources available I think components for quick start are the best offering right now. If some more developers stepped up maybe we could look at a more general-purpose app, but for now, it is some way off.

[davetcc]

OK so a bit of an "all change please moment", we had an internal discussion today between developers, and I think there's room to have some kind of App Store app for Android and iOS and it is likely to go ahead soon, we already have the required developer license for Apple and Microsoft. Obtaining for Play Store shouldn't be too much trouble.

What exactly would be included in there is yet to be decided but at least some kind of basic control and monitoring would be possible without having to build anything out. Much still to be worked out.

[AtmosphEng]

I realise you replied above that the ESP32 was not a good choice of embedControl server. But I have a follow-up question please. If the tcmenu comms were to be over Serial UART at 115200 baud instead of Wifi, does that allow the ESP32 to be used as a reliable embedControl server? I ask because that would suit my current use case. Thanks.

[davetcc]

Oh yes, it is very good at either using a direct socket over WiFi or Serial of any type. Part of every test cycle is to test the Socket server and Serial server support, and they work flawlessly on ESP32.

As you've probably seen, after a long discussion, I came to the conclusion that we will deploy a basic app to the Play Store, Apple Store, and Microsoft Store. This will probably happen after 4.0 is released (and a subsequent patch release).

But right now there are two options for ESP32:

• Enable WiFi or Serial endpoint and use Desktop embedCONTROL works really well on macOS, Windows and Linux and tested in every release.
• Use a RaspberryPI, the menu-in-menu support and serve the web version from there.

[davetcc]

Just to be very clear, the only thing that I am saying doesn't work is using the web server plugin which is not even any longer available to install anyway.

Both "ESP Wifi control of your menu for ESP boards" and "ESP Serial remote control (Rs232 / USB / Bluetooth)" work perfectly. All the ones you can install from designer generally work properly.

[AtmosphEng]

Thanks. I personally have about 5 old Android phones ready to try an embedControl Android app on, and I'm sure there would be many more enthusiasts in the hobby-end of the market ready to do the same.
I saw you wrote previously that embedControl would run on any RPI 3 or over. As luck would (not) have it , RPI prices are bad just now but I do have an old RPI 2b. Do you think its worth trying embedControl on an RPI 2b via its wired ethernet?

[davetcc]

using the Bellsoft 32bit Raspberry PI JDK it may well work, but I don't have anything older than a PI3 to try it on.

[AtmosphEng]

Thanks. I've got time to try it next week and report back.

[AtmosphEng]

Sorry I gave up on this. My Raspberry Pi 2b had Raspbian stretch (Debian 9) and I could not get the Bellsoft 32bit Raspberry PI JDK to load. Its been years since I used any Linux tbh.

[davetcc]

Yep, I've not tried going back beyond very recent devices, I suspect the first couple of hardware revisions may not run it that well, even if it did run. I doubt that anyone is targeting getting Java 17 onward to those devices.

I heard that there's finally some availability of PI4's so maybe we'll all be able to actually buy them again at some point soon.