In general, I am in favor of adding a banner for 8/64 devices - or adding them to deprecated devices.
As there currently is no removal date/timeline for these devices stated in gluon, I don't know if it is already time to add this second banner. Another solution by time would be to just wait and then use #75 :D
Personally, I do not think, that there is such a big difference, as the call to action "this old, pls replace" is the same.

To the PR itself:
There is no option to disable only one of the banners, which might be wanted by communities who do not want to disturb users with that for the next 2 years.

There is no option to filter for EOL devices instead of deprecated devices - and by changing the definition of deprecated to eol and introducing a new eol group, the filter #16 does not work correctly anymore (e.g. does not include 4/32 anymore).
I think, that the filter should include all deprecated/EOL devices.

Actually, even OpenWRT does not state a timeline or that they will be "out of support soon":
https://openwrt.org/supported_devices/864_warning
Just, that the functionality might be limited and one should not buy such devices new anymore.
Which is a very different situation..? Or am I missing something?

In general, I am in favor of adding a banner for 8/64 devices - or adding them to deprecated devices.

This was not meant as a 8/64 banner, but generally a second banner to warn for removal of devices in the future. Unlike the current warning that the devices already have lost their support.
If you look at the example devices added, those have no support anymore in Gluon v2023.2+ but are still supported in Gluon v2023.1.

• freifunk-gluon/gluon@66a33a3
• freifunk-gluon/gluon@61fc55f

There is no option to disable only one of the banners, which might be wanted by communities who do not want to disturb users with that for the next 2 years.

You can simply define an empty list and then there is nothing warned about.

Actually, even OpenWRT does not state a timeline or that they will be "out of support soon":

This is just a sample text, don't focus too much on the 8/64 here.

There is no option to filter for EOL devices instead of deprecated devices - and by changing the definition of deprecated to eol and introducing a new eol group, the filter #16 does not work correctly anymore (e.g. does not include 4/32 anymore).

I don't understand what you mean here. All filters work fine for me:

Thanks - I did just deploy this in FFAC - with a small fix:
The deprecation feature has to match the name on the Map which is for the RE355:
TP-LINK RE355
https://map.aachen.freifunk.net/#!/en/map/ec086b3a33d2

For devices you don't have on your map, you can check the model drop down of this grafana dashboard:
https://stats.darmstadt.freifunk.net/d/CA5PRFmMz/gluon-census3a-dashboard

Other than that, I like it! :)

For devices you don't have on your map, you can check the model drop down of this grafana dashboard:

I have a tool that gets a list of all devices of the major communities. If you want, I can share this with you, remind me :)
I probably just did a wrong copy&paste somewhere.

EDIT: It seems there are both variants with "v1" and lower-case TP-Link and some without and an upper-case TP-LINK, but I didn't find a 305 so assume it's the same. I added both variants now for each model.

@skorpy2009 @MyIgel can you review and merge this please? :)

@Djfe this problem is unrelated to this PR here and should probably be addressed outside of this PR?

In that case sorry for the noise 😅

Which problem are you referring to?
#81 (review)
or
#81 (comment)

I couldn't find any issues in the code during my review :)

Issues we faced in Aachen were issues caused by browser caches.
The translation was updated prior to the javascript code. Resulting in 4/32 devices (old deprecated) being presented with the red warning label but the text for the 8/64 warning.

i guess you can fix this issue with updating also the cacheBreaker value in the config.json
when using an updated Language file

Freifunk Donau-Ries would like to use this feature too.

the i guess the CI would pass if: #110 was merged

this pr is currently running fine on or PR (freifunkMUC@5d45efa)
and live on our map https://map.ffmuc.net/

@maurerle do you know when this could be merged? Some Dependabot PRs are waiting to be merged as well.

Nvm. @skorpy2009 @MyIgel can you have a look at it?

@grische can you rebase this PR please?

The changes to the language files suggested by @Djfe should also be implemented before merging: #81 (review).

Is the effort worth it? We haven't gotten any feedback from upstream here.

rebasing is at least useful if other communities would like to apply this patch on top of the latest change.
Independent from if it gets merged..? :)

I am happy to Rebase if this gets merged, but I don't want to maintain this code twice. Can you maybe base it off of our fork?
https://github.com/freifunkMUC/meshviewer

Or we just make a more proper fork without customisations if this repo and base our customisation on top of it

our fork https://github.com/freifunkMUC/meshviewer is also not uptodate, we need to update our fork also so we got all changes from upstream :/

Rebased to latest version again

Please run npm run lint:fix and add the changes

@grische there's also a review with some comments by @Djfe in january - it would be nice to not ignore it, if you don't agree with the suggested changes simply write that as a response to his remarks.

interesting, I didn't get an email notification about:

review comments are unrelated to the changes this PR wants to make

(just to let you know about this in-case you use Github's dismissal feature again)

and indeed, yes they are :)
Glad that this got merged and that the Meshviewer is being actively improved again.