[BUG] Device value not updated in realtime because of wrong value_id in html code

[SuksAE]

Describe the bug
When opening the devices pane, all values are updated according to the configured Interval time. This is not the case for Input shift register P129 and Output shift register P126 (and maybe a bunch of ohers...).
After some debugging, I maybe found that there is a wrong value_id in the html code for these devices - see attached screenshot below. Other devices use value_0_0 and value_1_0 as IDs for these values. This plugins use value_0_4 and value_1_4 which prevents the periodic update of the values.
When changing the IDs in the html code (using web_develop_tools of Edge or html Inspector tool of Firefox) to value_0_0 and value_1_0, the values are updated as intended.

PS: verified the correct reception of the incomming data of the input shift register using the serial console - this is OK, so I guess the wrong id is the main culprit here...

To Reproduce
Steps to reproduce the behavior:

1. add input shift register peripheral
2. return to devices pane
3. look at html code
4. compare with other peripherals

Expected behavior
value id shall be set correctly in html code for all peripherals so that the values are updated periodically according to the configured Interval

Screenshots

Used platform (please complete the following information):

• ESP type: ESP32
• Build version: ESP_Easy_mega_20260121_collection_E_ESP32_4M316k Jan 21 2026

Platform Specifics (when applicable, please complete the following information):

• Flash size: 4M
• Brand/Model: ESP32-MINI-1-N4
• Browser + OS: Windows 10 / Edge / Firefox

[tonhuisman]

Ah, this is most likely related to the way the data uses an alternative presentation via the PLUGIN_FORMAT_USERVAR plugin function for both these plugins.
I'll see if that can be fixed.

[SuksAE]

looking good - thanks for the fast fix...

[SuksAE]

Just one more thing - and I am not sure if this is the right place or if this needs another bug report:

Before this fix and now at initial load, the values at shift register input and shift register output are grouped in 8bit (or 2digits in hex mode) groups separated with dots.
After the fix, there is only one long line of numbers with a decimal number in front and no dots when the values are automatically updated...

[TD-er]

Very likely a result of the fix.
And it might not be the only one showing this discrepancy...

[SuksAE]

should I make a second bug report, or do you want to use this one?

[SuksAE]

Following plugins implement PLUGIN_FORMAT_USERVAR:

P081
P111
P126
P129
P140

and following implement PLUGIN_WEBFORM_SHOW_VALUES:

P023
P036
P077
P082
P087
P094
P098
P124
P126
P129

The overlap are P126 (shift out) and P129 (shift in).

So lets assume these are the only plugins affected by this discrepancy...

[TD-er]

So lets assume these are the only plugins affected by this discrepancy...

I think so too.
And while discussing it yesterday with Ton, we both kinda predicted this would/could happen as we really shouldn't have multiple places to implement this.
It is actually the same concept, with only a "display format" or "Verbose formatted" flag as difference.

In the (not so distant) future, but just not now, we should implement these using the recently introduced key-value-writer concept.
This is a writer which does take care of formatting in its base class. So you can either have a JSON writer, or a HTML writer (for now, new types can be added later) which can be configured using various parameters. One of these is whether it is intended for 'display' use (e.g. to be read by a human).

So the idea is to completely strip the function that now populates those tables like the Devices/Controllers/Networks/Notifications and just output some basic structure with empty elements and only HTML id's. Then just fetch a JSON like we do now for the taskvalues and let JavaScript fill in the table.
This way everything can be made dynamically updated and to make sure the ESP doesn't get flooded with generating the same data over and over again, we can also add some flags to see which 'consumer' already has had those updates since they last changed.

The same concept (including the kvwriter) is now already used in the log handling.
There is just one queue of log elements and each log-consumer can request the oldest items not yet consumed by that consumer.
It is a very simple and (IMHO) elegant way of serving data and I think it can make the code quite a bit smaller and faster and easier to maintain. Especially that last part is exactly what we're seeing now, when things are implemented in several places and you need to keep track of those specifics on the side of the caller.
We just need to keep info as local as can be as that's where the knowledge is about what it represents and also it makes it much easier to not include it when for example a plugin is not part of the build.

[tonhuisman]

For now I've added optional value formatting for display by setting event->ParN[idx] to 1 for the desired value. Expecting a better solution in the future.