Fixes and features for tile structure

[peuter]

Features:

• add possibility to mark a widget as "outdated", the backend needs to provide the date of the last value update for that
• adding fixed horizontal lines for charts that are either for a fixed value or on the calucated average value
• add POST, PUT and DELETE requests to the proxy api
• add support for the MQTT specific address attributes, to add MQTT support to tile structure
• add dynamic manifest generation to improve the PWA support

WIP feature:

• Add a base class to inherit from if a user wants to implement a custom backend client locally which works like a plugin that is not part of the CV-source code. During development I found out that the API of my reolink ip-cam does not provide useful information for the cometvisu, so I stopped the development. Another reason to pause this topic (but keep the beginnings) is that in future qooxdoo versions it might be much easier to have a pure JS-Class that inherits from a qooxdoo class, and this feature would benefit from that, because the locally developed client must be a pure JS-Class to avoid the need for compiling it.

The rest if this PR are minor bugfixes that I have found during testing

[ChristianMayer]

add possibility to mark a widget as "outdated", the backend needs to provide the date of the last value update for that

This is a great idea. What does the backend need to provide to make it work?
(And how can I test it?)

add dynamic manifest generation to improve the PWA support

What does this fix / what exactly wasn't working before?

[peuter]

add possibility to mark a widget as "outdated", the backend needs to provide the date of the last value update for that

This is a great idea. What does the backend need to provide to make it work? (And how can I test it?)

The backend needs to send a value that the cometvisu converts to a date object. And the you have to add an cv-address to a widget like this <cv-address slot="tileAddress" transform="OH:datetime" mode="read" target="last-update:120">Meter_Energy_Grid_Import_Timestamp</cv-address>.

Important is the transform to a date and the target value "last-update:120" which means if the date is older that 120 seconds the widget is marked as outdated (little red triangle in the upper left corner with an exclamation mark in it).

Full example:

<cv-info format="%d" style="color: #f2495c">
      <cv-address slot="address" transform="OH:number" mode="read">Meter_Energy_Grid_Import</cv-address>
      <cv-address slot="tileAddress" transform="OH:datetime" mode="read" target="last-update:120">Meter_Energy_Grid_Import_Timestamp</cv-address>
      <span slot="title">Z&#228;hlerstand Strom</span>
      <span slot="unit">kWh</span>
</cv-info>

I know that I have to provide documentation for this feature and also an example in the demo config but that has to wait until the next free time slot.

add dynamic manifest generation to improve the PWA support

What does this fix / what exactly wasn't working before?

This makes the CometVisu pass the lighthouse test in the chrome developer tools. Benefit from that is that you see a icon the browsers address field that says "Cometvisu installieren". Also on mobile phones the system bars change their background color. You have be in a "save environment" (localhost or https) to test this, because a running serviceworker is a requirement. If you test this in source-build you have enable it with the url-parameter &worker=true

[ChristianMayer]

I think we should add window.location.hash as well, so that you can start the installed visu on a sub page, when desired

[peuter]

I left that one out on purpose. I think most of the users will want to start with the first page. In addition to that I think that it will lead to lots of "support cases" where users that hit the install button while being on a subpage, will be confused because the "app" will not start on the start page.

[ChristianMayer]

Although Lighthouse is (mostly) happy about the PWA now, the "Application" doesn't find the manifest anymore:

(Actually, I hoped to be able to check there whether the icons are already "maskable" ready)

[peuter]

Although Lighthouse is (mostly) happy about the PWA now, the "Application" doesn't find the manifest anymore: (Actually, I hoped to be able to check there whether the icons are already "maskable" ready)

I think thats only a visual problem. When I install the cometvisu on my mobile all things that are defined in the generated manifest are used. So its working. Maybe Chrome checks for the manifest directly after loading and does not check that its been added later.