(Better and faster) Table of Hardware

[wxop]

While the TOH (Table of Hardware) is a fantastic resource, I often find myself wrestling with frustration as I use it. The loading times are painfully slow, and the columns displayed rarely match what I’m actually looking for.

So, I've created a new TOH that pulls data directly from the OpenWRT site. This revamped version promises to be much faster and more user-friendly... At least, that’s the goal!

Try it (live) at:
Enhanced OpenWrt Table Of Hardware

Your feedback would be appreciated! If enough of you find it useful, I’d love to propose it for inclusion on the official OpenWRT site. After all, who doesn’t want a TOH that actually works?

[frollic]

@wxop

Your feedback would be appreciated!

replace the "At least 8MB Flash and 64MB RAM" buttons with 16/128MB.
8MB devices will be dropped after 23.05.

the "available" filter is kind of pointless, since availability could vary with location.

[wxop]

Hi @frollic , thank you for your feedback

I will implement your suggestions ASAP!

Regarding Filter presets & features, I've tried to mimic some of the current TOH filters (listed here).

As stated in this GH issue, we have to first implements most current filters, then add some addtionals interesting ones.

If you've have a GH account, and some basic JS syntax skill, this can easely added by just creating the filter definition here:

soif/OpenWrtTOH/blob/master/src/www/static/js/toh_conf.js#L462

[frollic]

@wxop

If you've have a GH account, and some basic JS syntax skill,

got an account, but no skills

[flygarn12]

@frollic

the "available" filter is kind of pointless, since availability could vary with location.

The idea with that was to have some kind of feedback if anyone have seen a specific device for many many years. And in the second stage after that, is anyone using it or can it be dropped from the supported device.

[wxop]

I've just release version v1.1.

It adds most (if not all) of the features filters currently listed in the (official) TOH

Enjoy it live there:
My Enhanced OpenWrt Table Of Hardware

[richb-hanover-priv]

Wow! This is pretty compelling.

I'm curious about your statement "... pulls data directly from the OpenWrt site." Are you pulling from the "data entry" pages (for example, https://openwrt.org/toh/hwdata/gl.inet/gl.inet_gl-mt6000)? Or is there some other source?

It would be terrific if you improved the Github's README to give more info about the process for collecting the data that supports this new ToH. Thanks, and congratulations!

Update: Holy moly! I had no idea that https://openwrt.org/toh.json existed! Is this already produced automatically by the existing site's machinery? That's a huge help. (You still need to update the README to document this...

[ed8]

@wxop

This revamped version promises to be much faster and more user-friendly

Blazingly fast it is indeed!

One sort of cosmetic remark: could you put the sort arrows at the right side of the input-columns? (this improves the alignment)

[wxop]

This JSON is the one that the original TOH currently uses.

I guess it is automatically (daily?) build (by parsing the Wiki?) fom some cron script....

Regarding the Readme, and as my english writing skill is very very limited (as U C), I would appreciate if anyone (with a GH account) could do it.
I think it can be done online at GH, without any GIT knowledge, by simply clicking the 'pencil' icon, and then sutmit the commit as a PullRequest..

[wxop]

Blazingly fast it is indeed!

I cant understand how the original TOH is often that SLOW.
Either a design error, or heavy load on the server(s). Anyway, despite the huge JSON (4M) used, my version is usually really faster.

One sort of cosmetic remark: could you put the sort arrows at the right side of the input-columns? (this improves the alignment)

Will do, but please note, that i've fixed (as default) a lot of columns to a very small width (to keep space), and in these cases, the header's seach input is very small. So to fix this, I auto expand the search input to a larger one, when you click on it.. With the sort icon at right, it would be hidden until you 'blur' the Input field. Would that still be OK?

[ed8]

Thanks, I am not sure how this is going to look like in reality but I guess it's ok.

ps: some ideas for (OpenWrt 24.x compatible) Presets based on Device Type:

• Access Point (Device Type = Wifi AP, minimal 16MB Flash, minimal 128MB RAM)
• All-in-one Router (Device Type = WiFi Router, minimal 16MB Flash, minimal 128MB RAM
• Core Router (Device Type = Single Board Computer, minimal 128MB RAM)
• LTE Router (Modem Type = LTE, minimal 16MB Flash, minimal 128MB RAM))
• Travel Router (Device Type = Travel Router, minimal 16MB Flash, minimal 128MB RAM)
• Switch (Device Type = Switch)

[wxop]

I've just release version v1.2

• allows to link filters to columns view (you should like it)
• move sort icon to the right ( @ed8 suggestion)

Enjoy it live there:
My better & faster Table Of Hardware

BTW: MANY thanks for your feedback and suggestions.

You would help me a lot by:

• posting your suggestions in an issue at GH (rather than here), so that I can automatically link my commit to your issue
• I'm not english native (as U can C), and with a GH account, and without any code skill, you can edit any file at GH to fix/improve my words... Please do it!
• obvioulsy, any code Pull-Requests are VERY welcome!

[richb-hanover-priv]

@wxop

Regarding the Readme, and as my english writing skill is very very limited (as U C), I would appreciate if anyone (with a GH account) could do it.

I just forked your github repo and will take a stab at updating the README. Thanks!

Update: Done. see the PR

[ed8]

@wxop

move sort icon to the right

Thanks, this looks good!

[wxop]

THANK YOU!

Dont hesitate to fix as many english words/sentences as you feel.

and BTW, if you wish to add presest/features filters, or anything... please do (as separete PR, of course).

[richb-hanover-priv]

@wxop

I cant understand how the original TOH is often that SLOW.
Either a design error, or heavy load on the server(s). Anyway, despite the huge JSON (4M) used, my version is usually really faster.

There's a third choice - the algorithm chosen for the Dokuwiki tables never expected to see 70+ columns by 2,600 rows...

Your solution will need some tricky integration into the Dokuwiki pages, but I believe it will be worth it once it has more of a shakedown. Thanks.

[wxop]

I've just merged your PR into v1.22 !

THANK YOU VERY VERY MUCH!

you rock!

[wxop]

Guys, I need your help/advices.

I want to fix the bug on the "Flash MB" column. The problem is that each cell is in fact an array of values made of number and letters : a very bad Database practice, but i have to deal with it

Here are some examples (taken from the first default page):

- [ "32" ]
- [ "16" ]
- [ "8", "128NAND" ]
- [ "16", "128NAND" ]
- [ "4096", "eMMC" ]
- [ "32", "1024NAND", "microSD" ]
- [ "16", "32", "64" ]

How should it be sorted (and also filtered)?
I mean the value used to sort/filter, while the cell will still display the details.

• Should i always take the array member with the higher number, ie [ "16", "128NAND" ] becomes 128 ?
• Should I add the numbers (ie [ "16", "32", "64" ] becomes 16+32+64=102)
• What means an "eMMC" member (without number)?
• Should I consider "microSD" to be on top priority, and means, for example 128G (128x1024MB) ?

[ed8]

Flash RAM seems like a mess indeed - I have been thinking about this for an hour but could not find a proper solution...

[wxop]

Yep a mess

Is there any Documentation in the Wiki about how this field is supposed to be filled? What are the rules?

Maybe a Wiki official editor may help?