add new vendormodel for broken devices

[maurerle]

this relates to #148
we now have a separate vendormodel for broken devices.

This fixes the issue, that broken devices were currently shown as recommended.
Users can decide wether they want to have broken devices shown in the firmware selector, through the recommended toggle.

Maintainers can add "broken" in the config to enabled_device_categories and add their own builds for untested devices

[belzebub40k]

I agree that we should remove the broken devices from the recommended group but I think categorizing the devices by the level they are broken might be more helpful instead of one devices_broken group. Like we already did with the devices_ath10k_lowmem. For example devices_no_11s for devices which aren't able to mesh, devices_no_reset for devices without a reset button and so on. This way communities can much better select which devices they want to show.

[belzebub40k]

Maybe we could also rewrite the device_info code to be more flexible and show the problems the device has in the WebUI. This way the user directly knows what limitations the device has and if he/she is fine with the them.

[maurerle]

I fully agree with you, but what about devices which aren't able to mesh and have no_reset? listing them in both does not work easily.

So this would be a much bigger feature.
Also adding a comment on why it is broken - and also the device_info_link is currently mostly used for 4/32 deprecation while it could make sense to show something different for other groups.

But I think thats a different issue and would still like to have this merged, as it improves the current situation (showing broken devices as recommended)

[belzebub40k]

Right I did not think about devices broken in different ways. Maybe then use the category which is more critical (no_mesh > no_reset) or introduce an additional group. But the later might be a bit cluttering.

Sorry I did not meant the device_info change should be implemented in this PR. It was just an idea I had and could easily be a separate PR.

[Djfe]

Which Gluon version shall be used as reference for how broken a device is? (major vs minor release)
Devices can be broken in different ways depending on the Gluon version.
It could be broken in the newest version only: regression or a feature was removed

• for example raspberries could mesh till Gluon 19, then IBSS meshing was removed and BCM never supported 802.11s (of course raspberries were always broken as they are untested, this is meant to serve as an example)

or the newest version could bring an improvement that removes it from being broken.
Also: some communities might not update to the newest Gluon immediately. :/ (so the firmware could be of status broken while the firmware-selector doesn't mark them as such if it doesn't compare version tags which it will likely never be able to)

[belzebub40k]

As we don't have a way to distinguish the broken state for different versions I would always base it on the latest status in the gluon master branch. As we currently list a lot of the broken devices in the recommended category this would already improve the situation. And even if your community does not provide up to date builds it is always possible to build the firmware yourself.

[herbetom]

A much more advanced (and complicated) way of handling this could be to generate some sort of data strucutre from within Gluon for Gluon builds (a bit like the manifest).

One part of this could be a caveats list. Broken devices then wouldn't just get broken=true but instead some attributes like broken={'no_reset_button','no_802.11s}' (a humand readable comment is often already present for broken devices).

Having those would allow quite an improved firmware selector. Devices could be only displayed if the Community allowed that tag for the device in question:

{
  "allow-broken":{
    "*":[
      "no_leds"
    ],
    "zyxel-nwa55axe":[
      "no_reset_button"
    ]
  }
}

These settings could be customizable for different branches. In a "nightly" branch other things might be acceptable in comparison to a "stable" branch.

[Djfe]

ok, then it's clear what the stance is. nice to know :)

I'm thinking about adding a sidebar to the firmware selector in another pr.
Hamburger Button on the top-right where the links are currently. Then it slides in a sidebar on top of the devices (main page) where you can select with checkboxes which types of devices you want to be visible.
The state of these could be remembered via cookies in addition to GET.
The community could set defaults which types of broken should be enabled by default. (like a broken led, it could also be labeled as minor or non-severe) (@herbetom just mentioned the same idea above)

We could also add other checkboxes/links/select buttons to this sidebar in the future to filter for devices that the community recommends, or for offloaders or for outdoors devices, switches etc. (and hiding development boards or very rare devices from the default view)

Also I would add these broken filters to the get parameters in order to have devices show up, when you send a link to someone.

edit:
What are your thoughts on this? :)
Maybe you are against a sidebar
I don't want to start working on such a PR when it's clear beforehand that it won't be merged 😅

I chose a sidebar to avoid adding even more stuff above the table of device icons.
An alternative would be showing tags in one line above the table of devices and adding/removing them.

overall broken state could be a list of tags per device. so a device can have more than one way of being broken. low flash/ram could also be converted to tags, I'm not sure whether I want to touch devices.js for this though.

[Djfe]

The data structure @herbetom mentioned could also be used to improve handling of manifest aliases and allow us to remove stuff like this override
https://github.com/freifunk-darmstadt/gluon-firmware-selector/blob/master/app.js#L452-L489