ffh-support-status: add README

[AiyionPrime]

@grische @lemoer
This polls the api-server (what is currently that dirty python hack) in semi-regular intervals.

The meshviewer will later not have a list of deprecated-devices anymore, but show the warning depending on what yanic sends it.

edit
view the readme properly:

https://github.com/freifunkh/ffh-packages/tree/ffh-support-status/ffh-support-status

[lemoer]

Why not have something like this?

Or maybe something like this?

The scheme that you proposed above, seems to be complicated in my opinion.

[AiyionPrime]

Meshviewer n'acked similar requests with the valid argument, that the meshviewer would only be a data viewer, and not a datasource.

Not sure how @genofire feels about this, but the same argument could be valid for yanic as well, if yanics intends to "just" aggregate data from respondd and not other sources.

The API will be a clean interface to a hopefully not too dirty codebase, as gluons device definitions in lua make it hard and errorprone to parse them without the languages interpreter.

The first approach you drafted would mean yanic would do this job which I hope @genofire would outright refuse. And I would not want to implement in go.

Having the deprecation status available on the node would allow for other packages to use it as well and allow e.g. proper EOL-SSIDs on affected devices, without having to compile an explicit EOL image.

Anyway, I'm leaving the lua package for now, until we agree on where it would be useful to have the deprecation data, and focus on the exam; and if some time is left, I'll hack the API together.

[genofire]

why not create an meshviewer with has an list inside or query an json api - to show deprecated.

the way over respondd on router and yanic on collector is really "complicated" and not necessary out of my opinion.

[AiyionPrime]

@genofire I think @xf- made it clear in the past, that he does not want the meshviewer to aggregate data, but only for it to show what's in meshviewer.json.

But maybe I got him wrong there.

[genofire]

you still could modify the config.js like you prefer ...

https://github.com/ffrgb/meshviewer/blob/5475b4994fb344ca15f1ef34df88d70a8d8fbbb7/config.default.js#L30-L46

[xf-]

Yeah, you got the right impression. I want good performance in larger instances on slower client devices. Running a task on a server is benchmark able and can be done with a timer and the client gets the latest output. But doing a lot of work on a client will slow down and decreases the usability massively.

Also add Stuff on the map (c&p from the docs example)

*Dynamic/Ajax objects*

This example adds temperature sensors with colored dots on the map.

geo: [
      {
        json: function () {
          var linkScale = require('d3-interpolate').interpolateHslLong('darkblue', 'darkred');

          return require('helper').getJSON('https://opendata.ffggrz.de/').then(function (result) {
            result.features.forEach(function (item) {
              var temp = ((item.properties.temperature ? item.properties.temperature.toString() : 0) + 20) / 55;
              item.color = linkScale(temp);
            });

            return result.features ? result.features : false;
          }, function () {
            return false;
          });
        },

        option: {
          pointToLayer: function (feature, latlng) {
            return L.circleMarker(latlng, {
              radius: 8,
              fillColor: feature.color,
              color: '#000',
              weight: 1,
              opacity: 1,
              fillOpacity: 0.8
            }).bindTooltip(feature.properties.temperature ? 'Temperatur: ' + feature.properties.temperature.toString() + 'C' : '');
          },
          pane: 'markerPane'
        }
      }
    ]

https://github.com/d3/d3-interpolate#color-spaces - Info about colors

Also, genofire is right, you can modify data in config.js and there are ways to output additional data.

[maurerle]

So from the demand side of this feature the information about the support-status/deprecation-warning is needed in

• meshviewer to show support status on map
• gluon node to show support status on status page or change ssid (like FFMUC did)?
• gluon-firmware-selector to show support status for downloaded firmware

the simplified proposal by @lemoer would not handle the second bullet.

Information about supported devices is currently available in the devices.json from gluon-firmware-selector - so one could change this to a json and depend on the state if its model is listed in "recommended".
As discussed here freifunk-darmstadt/gluon-firmware-selector#149 (comment) it might be interesting to not only show "supported yes/no" but also more information.

I could not find the current hacky python script, but would be interested (https://github.com/freifunkh/gluon-support-state seems to be private for now).

So I would like to have additional access to a simple devices.json (which can be (re)generated from a gluon source - probably like already existing as the state of the api).
This would make it easier to use the information also in the firmware-selector in the future?
Other than that i think that aiyion's approach very useful.