Improving the Table of Hardware (TOH)?

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.
  • 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)"
  • 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.

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.

  1. Import to Pandas (ansi)
  2. Export to CSV
  3. Import to DBBrowser for SQLite
select * from
case when supported != "FALSE" then TRUE
else FALSE
end as simple_supported,
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
end as supported,
substr(supportedcurrentrel, 2) as major,
* from o
where simple_supported is TRUE
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)

Hi @RollingStar.

I think that an improvement to TOH could help users in the moment of buying a new router.

That is exactly what I do every time I buy a new one.

I never buy an router that isn't compatible with OpenWRT, even though I have no immediate intention of using OpenWRT on it. For me compatibility is important for future uses or as a lab.

As I read, you make several suggestions that at the moment I don't have time to analyze in more detail as the subject deserves.

I created an own application that I use when I'm looking for an new router, that is why I import the TOH CSV. In my interface I can filter MINIMUM Flash, MINIMUM memory, if I need Gigabit, if I need USB ports, for example.

But since you opened this case, I just want to write what I've noticed but I didn't get to write:

  • the current interface is very bad to be consulted (I personally only use the full version of TOH)
  • The filter fields have a very bad behavior, when filling a field and after seeing the result, decide to change the content of the field and add another filter field. Apparently it only takes into account the last changed field
  • The side scroll is terrible because the header that identifies the fields disappears when there are too many results
  • A price range field is also lacking. I suggest a price class field, such as Low (<$50), Medium ($50-$100), High ($100-$200), Very High (>$200)

Best regards

1 Like

All valid points, but a volunteer is needed to implement those suggestions. The team currently maintaining the wiki and ToH does not have the capacity to do significant development work.

Right now, a Dokuwiki datatable plugin is used to realize the ToH and a lot of peculiarities are inherited from it. What would be needed for a truly good user experience would be a dedicated database CRUD application to maintain the ToH data, ideally with some integration into the wiki.

Someone would have to implement that.


Is the code for Dokuwiki/datatable as used by OpenWrt available?

For Plugin creation, see

You mean the export

Brand names are shown as best fit ascii representation of the brand, including capitalisation. Normalizing is no option.

Already done: CSV Hardware Download Version field uncomplete - #11 by tmomas


There is no SQL available for any of the toh views. The data plugin handles all the SQL. Out of this datatable definition

---- datatable ----
cols       : Device Type, Availability, Brand, Model, Versions, Supported Current Rel_releasepage, Device Page_page, OWrt Forum Topic URL_url, Device Techdata_pageid
headers    : Device Type, Availability, Brand, Model, Versions, Current Release, Device Page, OpenWrt Forum, Device Techdata
align      : l,l,l,l,l,l,l,l,l,c
dynfilters : 1
rownumbers : 1
filter     : Model!=@@Model@@
sort       : Brand

the data plugin creates
No user editable SQL involved (except for the csv export, which is not part of the data plugin).

See for available datatypes. Numeric is not available.


USB2.0 is something different than USB3.0, therefore just counting 1+1 together is wrong. How does a user find devices with USB3.0, if he has only "2x USB" information available? Same for Ethernet ports.

  • Stable: a stable release is listed in the dataentry
  • dev: snapshot is listed in the dataentry
  • false: device is not in the ToH. We still have some unsupported and / or WIP devices though, but much less than when we started the ToH in its current form. If there is useful information about a device and it is actively being worked on, we show it in the ToH (e.g. "PR pending").

Apart from that: Your expectations on stable and dev are not matching reality. A device with "stable" support might have serious issues (thinking of WiFi on WRT3200 etc.), while a device with "snapshot" (=dev) support might work perfectly.

If you are searching for a device to buy, use the right ToH view with appropriate filters already set, e.g., instead of the "show me all" view which shows the status of each and every device.

PR pending = A PR has been created, but has not been merged yet.
snapshot = dev
external image = someone has created an image (external to OpenWrt), but that's it. No PR has been created yet, no official image exists.

That's not a range, that are two distinct values 4 and 8, not 4,5,6,7,8.
In the data plugin, separate values are separated by comma.

Some explanations or "legend" could be easily implemented.

¿ was the first thing that came to my mind when I realized that ? does not work with the data plugin.

Can you please elaborate on this?

The Availability field allows you to filter out devices which are discontinued and possibly not easily available any more. I agree, it is in poor shape (I blame it on the community which only want to have, but doesn't want to give back), but removing it would be the wrong choice.

That would be an additional information, but would not replace the availability field.

See this as a confirmation that someone has actively checked commercial availability, rather than an extensive and complete listing of purchasing sites.
If someone sets "Availability" to "Available 2022" without providing "Where available", I immediately question this entry. This attitude comes from yearlong experience where I have seen many dataentries being created with "I whish it was supported, and creating a dataentry and putting bogus information in there certainly helps to get this device supported!!!11" in mind.

I think this could be easily implemented. What's the ebay query syntax for e.g. "WRT3200"?

Users do want to get an up-to-date device, click a button and receive their device 5min later, at least that's my impression. Searching to buy specifically "v5" while "v12" is already available might be difficult and time consuming. You have to ask yourself: Does it really need to be that special device that has been discontinued by the manufacturer 8 years ago and which takes weeks or months to source via ebay or other channels?

Select the view which matches your usecase, and you will get a table with a subset of columns (more or less).

Apart from that, I agree to jow's reply: It needs someone who does it (it = integration into the wiki).

Be aware that there are quite a few devices without FCC numbers, it's only mandatory for the US market, but there are quite a few vendors which don't intend to sell there and have no need to go through the FCC procedures (in addition to following the certifications of their intended target markets). Just to name a few examples, AVM (very big in Germany and to a much lesser extent neighbouring European markets and Australia), lots of ISP branded devices (e.g. the bthub5 comes to mind), many aliexpress 'brands', which are still popular (cheap) worldwide, ….

1 Like

In EU you pretty much only need the CE marking, and no one makes quality check since it is up to the manufacturer themself to decide if their thing is CE qualified.
And a EMC mark looks pretty cool also.

And the biggest prio one mark of them all! RoHS! Never forget that stamp!

It seems like technical limitations are preventing substantial changes to the table. So a high priority would be:

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.

This would be the strangler design pattern. Slowly replace the functionality of the old wiki table until it is no longer needed. I don't understand enough about the TOH data pipeline to be able to design a replacement. I might be able to revisit this in a few months. It could be easier if more specific requirements are made for the TOH. Does it need to be a page generated by live Dokuwiki software or can the "legacy" version be a Google sheet, static page, R Shiny interactive table, etc.

Another question: How common are changes to the TOH? On the daily(?) SQL export is there always changed data?

Really easy:

Another neat trick is sold listings (see the market rate):

This data is user contributed, as new devices appear and are being worked on (at least wished to be worked on), so expect it to change often, maybe not every day, but more than weekly (if you count changes to existing devices even more often).

1 Like

Tryout with ASIN + ebay (with GL-B2200 though):

Hi again,
i updated my DB now from file downloaded here, and noted that 2 columns are all filled with NULL:

  1. ethernetgbitports
  2. lede_forum_topic_url

But on column ethernetgbitports has data and lede_forum_topic_url do not exists on screen.

I noted that now there are columns for Ethernet 2,5, 5 and 10 GBit that are not on the csv file.