First off, thanks to all the devs and maintainers for keeping the ToH as useful as it is right now. This post comes from a desire to make the page more useful to more people, which is subjective but hopefully can be gauged through some kind of feedback. And keep in mind not everyone who is curious about OpenWrt is an OpenWrt developer.
A lot of the device info in the wiki is not super maintained. It's also confusing if you're using it for shopping advice.
Discussion points:
- export as UTF-8. most parsers and programs prefer it, and it reduces ambiguity. Pandas doesn't autodetect the ANSI format and complains about it.
- normalize brand names to all start with a capital. this will fix sorting (A-Z). alternatively, have two fields - as-is and normalized.
- replace the max with group_concat CSV Hardware Download Version field uncomplete - #8 by carliedu
- share the latest SQL in somewhere easily accessible (wiki?) CSV Hardware Download Version field uncomplete - #8 by carliedu
- Many fields should be converted from text to numeric. With this being so common, is there a technical reason preventing this? (GPIOs , OpenVPN perf, Wireguard perf, buttons)
- if there is a technical problem with this, make a master table which has all the fields nice and pretty, and generate the backwards-compatible table for the wiki software. and provide another export/interface to the pretty table.
- underlying fields should be split apart, and rolled up alongside the underlying fields (USB3 + USB2 = total USB; Gig + 100Mbit = total ethernet)
- a simple "supported" field. Either true/false or with like 3 values: "stable", "dev", "false". As an end user I am keenly interested in buying a new OpenWrt device that works, not browsing something which hasn't been supported since 15.x.
- The default sort should only display supported/dev devices. I'm not sure what 'PR pending', 'snapshot', and 'external image' mean, but those can be fit in somewhere.
- where a range of fields is possible, store the range. This may run into technical limitations of the filter functionality. See the 4, 8 MB ram here. https://openwrt.org/toh/hwdata/7links/7links_px-4885
- explain the use of
¿on the main TOH page. the conventions link explains some: "¿: unknown (ALT+168; used for filtering reasons. Please avoid '?' and use '¿' instead)" https://openwrt.org/toh/hwdata/3com/3com_3crwer100-75 - Why not, for example, NULL?
-is already reserved for NA/not applicable. importing this into many data science and SQL tools would be seamless, while¿is not a standard. - Firmware links should be computed rather than hardcoded where possible (use the version, device name, target etc. to generate the URL)
Situations which need more discussion:
Availability field is useless due to lack of maintenance. Hot take: replace this with an automated system that uses FCC data. That would lose some fidelity on the date available - FCC approval happens before commercial availability. But the ease of maintenance should make it superior.
Sites to purchase (Amazon, etc.). I can't think of a case where this is useful.
- General electronics (new) -> Amazon etc.
- Used -> eBay
- Chinese -> Aliexpress
- Specialty -> vendor direct
I would, however, find an ebay link quite useful. That would let me quickly find the going price of the item.
Similarly, I don't quite understand the use case for knowing whether a device is still being made. It's supported by OpenWrt, isn't it? Something still being made probably has better vendor support to fall back on if Owrt has issues.
Sort the columns by use case. The first set should be for general users, the next set should be for slightly techy users (cores, Mhz, port speed), the next should be more info (URLs to wiki, forum search, wikidevi), then "devs" with stuff like Gluon support, and finally should be "data" which is listed not so much for quick browsing, but just because it happens to be stored for use on the device page. Nobody is browsing by GPIOs.
If there is a problem with rendering speed, this would help - only a subset of columns would need to be shown at once.
See also: RFC: rendering Table of Hardware via yaml files - #12 by aparcar
Re: the page renders too slow. There's also the Yaml proof of concept, as well as a million static site generators. https://github.com/bucherfa/lineageos-devices https://lineageosdevices.com/
If this helps anyone else, here is the SQL I used to browse the table. Some lines are commented out but may be useful to future Googlers who don't have a lot of SQL knowledge.
- Import to Pandas (ansi)
- Export to CSV
- Import to DBBrowser for SQLite
select * from
(
select
case when supported != "FALSE" then TRUE
else FALSE
end as simple_supported,
*
FROM
(
select
case when supportedcurrentrel in ('PR pending', 'snapshot') then 'future'
when supportedcurrentrel = 'external image' then 'external image'
when supportedcurrentrel = '22.03.0' then 'stable'
when major = '21' then 'old?'
-- WHEN supportedcurrentrel = '¿' then FALSE
-- WHEN supportedcurrentrel = 'EOL' then FALSE
ELSE 'FALSE'
end as supported,
*
FROM
(
select
substr(supportedcurrentrel, 2) as major,
* from o
)
)
)
where simple_supported is TRUE
AND
lower(wlan50ghz) like('%ac%')
and lower(devicetype) = 'wifi ap'
-- and lower(brand) in ('d-link', 'mikrotik', 'netgear', 'tp-link', 'ubiquiti', 'zyxel')
-- order by devicetype
order by --target,
lower(brand), lower(devicetype)
