K3:
The point of this is to make it easy. To do this you need to be able to communicate your desires to the program. This means a user interface. I've looked at a number of different programs that are intended to do this, but they tend to require a lot of hard coding because of memory constraints of an embedded processor. They also tend to all mirror the same action/response methods.
The UI requirement has been done to death by many different groups. It may be backwards but I am implementing the 'IX UI environment from 20+ years ago because it is solid code and does what I want.
,do you think at the end it is makeable ,buildable for others with less knowledge ,and custumizeable
How I envision it working is that the code is the code. It can be distributed just like a bios update, so download a file, plug in a blank ESP32 device, and run the program. After that, there are many tools in the Espressif toolbox that allow the device to update itself.
I'll be honest you do need some knowledge to build something. solid electrical knowledge so you know how to implement an electrically complete circuit. You need to understand what a pullup resistor does, why you need a chip select line, and how a device bus is implemented. (Tie all the same lines together of all the devices.)
What I am glossing over is that the code already knows about all the devices you can connect to the ESP32 (at least what I have programmed it to understand). The internal guts of OpenStill are just a global variable array, and there are "programs" or built in logic that uses those global variables to accomplish it's task. Likewise all the pin configurations and the operations are saved on the flash so it can restart properly after a reset. You can implement a flash card as you want, when you add one as a module, it adds functionality like reading in pin configurations, and all customizable screen widgets. That way the display can be whatever language you wish to translate to.
So the job for the implementer is make sure that all the mandatory devices are implemented for the "program" you want to run by assigning devices to the ESP32 pins.
You then use a terminal program to connect to the ESP32 through the usb/com port and it is plugged into a breadboard or a something more finished. Since it is blank device, it will also broadcast itself as a open access point called "OpenController(n)" the n part is if for some reason there is an AP already named OpenController. Connect to this wireless network and telnet to the default gateway will give you the exact same screen as the console port.
Since we are configuring a brand new device, if there are available AP's to connect to it will prompt you to authenticate to one.
Assuming it can connect, it will try to get a .240 address from the AP. This is to make things easy since the most technical thing you need to do on an ongoing basis is establishing a telnet session to its ip address.
I'm waiting on a microsd card socket so I can test some flash capabilities. I want to try and reuse the existing flash data pins and use GPIO15 as chip select output. Then it will be able to read files that you can edit/put on from a pc. This makes it easy to do for example a temperature sensor has many "windows". A DS sensor has many variables, rom code bus gpio, resolution, read cycle timing, calibration offset, number of errors in addition to the current and historically trended temperature readings. So that window 1 is just the 78.04 the reading in float while window 5 can be 87.5% ABV. windows 10 can be a ascii character blob that changes colour based on the reading.
You can overlay windows so that would allow you to simulate boiler heatup and alarm conditions. Think of it like when they film animation. There is a background then you add little images on top of each other to get the whole picture.
Hopefully it is not going to blow up.
