Allow local UI mapping (content and layout) from external data

[hb020]

Right now, HA or any other external systems need to know the screen layout when they send data or want to change colors etc.
Wouldn't it be better if the data sources just provide the sensor data, and leave the UI mapping and layout to the device? It would be much more scalable and easier to maintain.
Right now, whenever I change a screen layout, and have to renumber the page elements, I also have to adapt the data source. That's rather messy.
The following would be better:

• the data source sends "/plane01/data/roomtemp 19.5"
• with a device mapping being something like:
  • p1b3.text = roomtemp%3.1f
  • p1b3.text_color = if roomtemp < 17 then blue else black

[smcgann99]

I cannot see how this offers any benefit, you are just going to offload more of the processing to the less capable device ?

When you change a screen layout you do not need to renumber elements, the id is a reference just the same as roomtemp would be.
The ids do not need to be sequential, so if b3 is used for roomtemp then no need to change it if you add or remove other elements.

[hb020]

cannot see how this offers any benefit, you are just going to offload more of the processing to the less capable device ?

Yes, that is absolutely the goal.

I compare this to how most UI works nowadays, in web browsers or mobile apps or embedded devices.
What is happening now in openHASP is what I would call "partial prerendering".
It is not prerendered like the old web server days where the server would push a full html page, nor like how prerendering frameworks like nuxt work.
Nor is it fully client side rendered, where the client just consumes data, and the rendering is handled by the client device.

Right now, both the client device and the data provider must know (at least partially) how the layout is done.
I see that the numbering can be free (I was indeed under the impression that they needed to be consecutive, like the pages), so that gives somewhat more freedom, and makes the element "name"/number more of a logical name. But it's still a far cry from total independence. Hence my classification of "partial prerendering".

The device is not powerful enough for fully prerendering, as it is not powerful enough for neither a nice enough browser, nor a complete enough javascript engine. So that is out.
It is my assessment that the device is powerful enough for a data driven, client side rendering approach.

I am looking for the data driven, client side rendering approach. It will have limitations, but it can be made more friendly and more versatile than it is now.

It is not purely about "place of maintenance". All of the methods will allow the UI source code/config to be maintained in 1 location. It is just harder with openHASP, as that would require the device to get the jsonl files from the server.

It is mainly about these 2 advantages:

1. more friendly to maintain: re-ordering screens would no longer impact the data source, and no need to go via rather arbitrary and unfriendly numbers; one could simply use names.
2. it can be made compatible with a full mesh situation: the UI device could intercept the sensor data directly, and not rely on some central hub to distribute it out again. The future is in meshing.

[fvanroie]

the UI device could intercept the sensor data directly, and not rely on some central hub to distribute it out again.

The design of openHASP is to offload the scripting/templating/computing to the HomeAutomation controller.
If you want scripting/templating/computing on the device, there are other solutions like HASPmota.

The future is in meshing.

openHASP doesn't support meshing, but you can always fork and adapt the project to your specific requirements.