Yeah, so that and all the following lines of code are basically redundant, repetitive, annoying to maintain and overall not really necessary. It's not wrong, per se, but it's kind of the caveman-with-a-club approach to it.
Here's the server-side JavaScript I use:
<script type="text/javascript">
function append() {
const form = document.getElementById('input-form');
var url = "/get?val=";
for (const element of form.elements) {
var parsed = parseInt(element.value, 16);
if (!isNaN(parsed) && parsed >= 0 && parsed <= 255) {
if (parsed < 0x10) {
url = url + '0';
}
url = url + parsed.toString(16);
}
else {
url = url + '00';
}
}
console.log(url);
window.location.href = url;
return false;
}
</script>
It's part of the HTML served by the ESP. The form (with id "input-form") consists of all the data fields in a fixed order. You could of course give the fields unique ID's as well if you want.
I did write a routine on the server side that uses a lookup table that records in which order the variables occur in the passed array. This routine then uses that lookup table to parse the received array back into separate values in the light program arrays.
@davidmarli
you haven't answered my question.
So for the time beeing I assume you are not getting any JSON from your browser.
And therefore no need to handle any JSON.
Stick to the data in structure like already mentioned.
Store it to the fileystem (like show cased by @J-M-L ) or in the Preferences.
Indeed, my browser did not send a json file.
I make it.
But, I think the structure will change, because, (but I don't know how to do it) :
All users don't have the need for 5 range timer per day.
So I would like that there is only one range per day and the user could click on a "+" button which could make appear a new range with a max of 5 per day.
But I don't know to do it with html.
For now, it works with my json horrible job (max json size is 5300bytes, and it is ok).
doable, but do you really want to go down in that rabbit hole?
you would need something to validate if to show the row or not.
you would need something to find a "free slot" (time "99:99" or your bool?!?)
probably you would need "a button - " to invalidate a row.
and finally you will work on your css because you will get 7 different sized groups on the screen.
I would do that after having all configuration in a nice structure only.
Your "up to 5 programs a day" made me think.
In the end you have 5 programs x 7 days x 2 outputs = 70 programs.
Implicit you limit the user to a maximum of 5 programs per day. He can't use 6 or more for one day even if he doesn't use a lot of programs on another weekday.
so why not assign the weekday (and the output) dynamically?
struct Program {
bool active; // active or inactive (reusable)
bool weekdays[7]; // weekday(s) to be used *)
uint16_t start; // start time in HHMM
uint16_t end; // end time in HHMM
uint8_t channel; // channel A or channel B to be effected
}
This would give the user the possibility for example to
define 24 programs on Mondays,
define 24 other programs on Tuesdays
define 6 other programs on Wednesdays
define 6 other programs on Fridays
and 10 program on weekends (SA & SO)
so it wouldn't matter for what relay, for what weekday a program slot is used. You take full advantage of all available slots.
foot note
*) if really every byte counts, you could use a single byte variable instead of the array also ... 0b0000001 Sunday
... 0b0000010 Monday
... 0b0000101 Tuesday and Sunday
I think you get the point.
yes but more code to access a given bool... you do have more RAM on an ESP32 than on a UNO — so this might be an OK tradeoff to keep attributes as full bytes