Configuration Options

[mediatech15]

So I was looking to start on a simplified configuration option inline with new features to facilitate easier testing and also given the current way is in code.

The options I see

1. Desktop/Mobile App
2. Web configuration
3. File based config

There are pros and cons to each. Some are:

• File Based is fastest and minimal changes down the road other than adding keys.
• Web Config
  • Can be simplistic
  • Can be a battery hog
  • Most would have to be client side
  • Page size could become an issue
• Desktop/Mobile App
  • Can basically do anything
  • Could still be wireless upload
  • Could be wired upload
  • Allows for most options
  • Can be Cross platform immediately

Thoughts.

[mediatech15]

I personally was leaning towards desktop/mobile app as it's the most flexible. I can easily whip up a POC or a fully fledged version with the changes needed for firmware also

[mediatech15]

I can also make a POC and show demo it

[MatthewColvin]

I am not sure what its best but I wonder if we could start with a file based config and then if we get to the point where we want a full drag desktop app we can support that by generating a config file with that desktop app?
Or is there a benefit to just going straight desktop?

[mediatech15]

I feel they can go hand in hand. AKA config file rule and the config file is generated from the app. So ultimate flexibility

[MatthewColvin]

Yeah I think to start working on what the config looks like we can use some mockups to determine what will be customizable.

Like take the use case of a light bulb controlled via MQTT.

We need to customize the topic to send the message out on and maybe that's it? Idk?

So if we have some mockups to talk about what data is needed to drive that layout we can minimize the needed config options.

If not I'm afraid we will end up throwing the kitchen sink into the config and it will basically become a mark up language.

[mediatech15]

If this becomes a markup language something is wrong but also if done right there should be no issue adding support.

To be honest this may be a case of ill poc it and then we can tweak as needed

[mcurtiss1992]

Has any progress been made in this area? If not, I've got a surprise for you guys and could use a bit of help cleaning up and debugging.

[Wraithers]

Hey there, this sounds intriguing! 👋 Is there a prerequisite of having the PCB/hardware to test your solution? Or is just software side usage and compilation testing enough? I'm not experienced in ESP32 dev, but I could maybe help debugging if it's just configuration testing etc. without hardware 😊

I took a quick peek, and I'm assuming it's on https://github.com/mcurtiss1992/omote-config?

[KlausMu]

@mcurtiss1992 Looks nice. I wonder how to use it.
How is loading, saving and processing of the json files done in the OMOTE?
I see calls to http://omote/getJson?... in the html files. Where is the counterpart to it? Did you extend the ESP32 firmware?

[mcurtiss1992]

Yup! I customized the firmware to run an extremely light web server and render the json files pseudo dynamically (you have to hit an endpoint on the web server or reboot the omote. Since SPIFFS is persistent, it honestly rocks! I just needs the level of polish that I cannot provide on the embedded side. My C/C++ is a bit rusty. I'll make a public branch of my dynamic firmware in the next couple of days for you all to check out.

[mcurtiss1992]

Oh I should also mention I've only got this implemented on the hardware. If you guys like the direction I'm going, I could use help porting that over to the emulator.

[mcurtiss1992]

Okay I've created a branch for my configurable firmware. Please be kind when looking through it. My C is rusty. It still needs quite a bit of work in terms of stability and sometimes requires manual editing of the json when something gets out of sync or a file is missing, but I don't want to do a bunch more work on it unless it seems like the correct path forward.

Anyways this is the branch:

https://github.com/mcurtiss1992/OMOTE/tree/configurableFirmware

[KlausMu]

Thanks, I had a look at it. The firmware is based on rev4 from December 24, and unfortunately I don't have a rev4 board anymore. It is on the way to China because of the tft ghost touch problem.

You could try to merge your branch with https://github.com/CoretechR/OMOTE/tree/main/ , but there will be most likely some merge conflicts.

Sorry, maybe someone else is able to test it.

What I wanted to see is what you already can do with the omote-config application

• how can you define the scenes, devices and so on
• what is already possible and what not yet
• how is it in terms of features compared to the code based approach
• ...

But I can't test it because the browser app first wants to have a connection to an OMOTE.

As far as I see it is pure html and JS. Is there no framework used like Angular or something like this?

I am not an expert in browser applications, nor have I ever written a big one, but my colleagues at the company write browser applications, and I am quite sure, for big applications they would never go without a framework.

[CoretechR]

@mcurtiss1992 Thank you, this looks really cool! I just had a quick look at the config branch. There is a bunch of stuff not working for me but this is a very promising first step towards a web configurator.

@KlausMu : Just to show you the UI:

[mcurtiss1992]

@KlausMu Oh yes. Sorry I wasn't super clear on this, but it's basically a proof of concept. I wasn't really sure how much trouble the omote would give me as a mini webserver. Turns out a lot. But I was able to work through the big problems. One big problem was serving large json files. It didn't take much to burn up the available memory, but I was able to compensate for that by splitting up the files into smaller files and transmitting the files as blobs rather than entire packages. The frontend would be implemented inside a framework in any kind of "production" version. This is just me proving it can be done.

As far as functionality, I've currently got all of this implemented in the gui POC along with rendering on omote side:

• device config
• command config (IR, BLE, and MQTT)
• scene config (I still need to write the omote side code to handle the scene start and scene end commands)
• basic gui config (this was very difficult and could probably be made better). Supports buttons, sliders, switches, and text as is
• global config (haven't used this much, but would be simple to add basic config like mqtt ip)
• raw json editing with syntax highlighter (This is what I started this project with and it's still really useful for fixing problems)

@CoretechR Thank you :) If you'd like, I could create a video walking through what's currently possible. I'd also be available to walk through how the omote side works. I had to make quite a few changes to the firmware, but it is built using all the same principles from the original project. The core methods and functionality have all remained the same. You can still hardcode config if you want as well.

Oh. You can also turn the webserver on and off. That's in settings (setup mode).

[KlausMu]

One big problem was serving large json files. It didn't take much to burn up the available memory, but I was able to compensate for that by splitting up the files into smaller files and transmitting the files as blobs rather than entire packages.

I am suprised it works at all in rev4. Do you have WiFi and BLE turned on? With both on, there is approx. 20-25k RAM left, with big screens even less, with peaks down to 10k while swiping.

In rev5 of course things are completely different.

The frontend would be implemented inside a framework in any kind of "production" version. This is just me proving it can be done.

Ok, great.

• basic gui config (this was very difficult and could probably be made better). Supports buttons, sliders, switches, and text as is

I totally believe that this was the hardest part. There have been several approaches for a GUI designer for LVGL, one by the maintainers of lvgl themselves. Of course they have to support much more widgets.
Very interesting part are the callbacks. Would like to see how you define what should happens in the callbacks.

Would even be conceivable to have some kind of scripting language you could use in the callbacks. Maybe, sometimes in the future ...

• global config (haven't used this much, but would be simple to add basic config like mqtt ip)

For inital setup, an access point provided by the OMOTE to setup WiFi would be helfull anyway.

If you'd like, I could create a video walking through what's currently possible. I'd also be available to walk through how the omote side works.

I would be interested in it.

I had to make quite a few changes to the firmware, but it is built using all the same principles from the original project. The core methods and functionality have all remained the same. You can still hardcode config if you want as well.

That would be really great. I could be that not all configuration options are available in the beginning of the web app. But if we could have a combined approach, where people are able to do configuration via browser and add via code everything which could not be done with the browser, would be awesome.

Oh. You can also turn the webserver on and off. That's in settings (setup mode).

How do you store the jsons on the OMOTE?

Other people already talked about a better integration with Home Assistant. I do not yet fully understand what exactly they want to achieve. My impression was that some think the whole configuration of the OMOTE could be done with Home Assistant. But I don't see this. But I would like to understand this better and how this would fit to a web application like yours.

[Wraithers]

I love seeing the progress! 🌟 I'm following along as best as I can without the hardware to test, and a video would be great to get a sense of how it works, as others already mentioned 🙌

Side-note: I would like to see the Home Assistant integration be optional, since many people use openHAB, Node Red or other services instead, including myself. It wouldn't be great to have an OMOTE UI configurator get locked to needing a Home Assistant instance running just to use it. Just my 2¢ ☺️

[SIR-Inc]

I only found out about this project a few days ago so I can't say I know the whole story and all the details but speaking to the comment made by Wraithers I hope the project has made a firm decision regarding their overall design philosophy. Unless you are designing a bespoke device for a single application you really have to be careful. Based on what I've seen so far I can only hope one of two integration routes is being taken, 1) design a dumb device that relies on server-side implementation or 2) design a smart, self contained device and then expose the functionality with an API or at least something open and standards based like MQTT. With this approach you can then use the device with openHAB, Home Assistant or any device or platform. I strongly agree with the comment about forcing vendor or platform dependencies, it will only hurt the project. With some careful thought and planning it is possible to have the OMOTE hardware play nicely with almost everything and this coming from a staunch Home Assistant fan and advocator.

[KlausMu]

Maybe you want to join this discussion: https://discord.com/channels/1138116475559882852/1354429864559513724
If not yet on discord, please follow this invitation https://discord.gg/5PnYFAsKsG

[SIR-Inc]

Thanks, I'll take a look if I have the time. I'm starting a new contract and I don't know how busy I'm going to be. I certainly hope I have spare time to work on personal projects.

[mcurtiss1992]

Hey all. Sorry I started the config tool and disappeared. My mother passed away on 4/1, so it has been a very difficult time for me and my family. I intend to pick the config tool back up at some point, but currently just trying to focus on my day job and stability.

If you guys would like to progress further on this, I’d be open to meeting with someone that would like to take point on it.

[Wraithers]

Sorry to hear that 😢 Our condolences to you and your family 🙏 Just focus on what you need to, health first 👍