Last one for today: In "USB" we have '-' (27) and 'No' (345) in parallel.

We should be more consistent here.
According to the general rules it should be

 -         : not applicable / hardware not present

but we have several other fields where we also have 'No' in use today, instead of '-'.

Too late now for me to think about this.
Just come up with a proposal, you'll do the right thing ;-)

Please check on the GL.iNet router.  It has a page indicating it is good to go, but is not in any of the 4 TOH related pages.  http://wiki.openwrt.org/toh/gl-inet/gl-inet

Some or all of this may be covered in the prior pages

I think the page frame needs to be enlarged so that the scroll bars will disappear on wide monitors.  I also think the TOC is problematic on the right.  It is too long to be seen on one screen so it's "ease of access" is diminished, and it reduces space for the vendors to the left of it.  It might work better as a table at the top of the page  so all can be seen with out scrolling.  In addition a search box with a GO button would allow entering a few chrs for quick vendor access.

I would prefer to see the same content for all devices, but understand that this is difficult, and/or will result in a very wide page.  I recently tried to extract data from the table, but had issues as the format was different between devices.  In general I come here more for validation.  Does my device work, in which case I can get details from the device page.  (Another story where standardization - catalog management tools - would be helpful)

Some fields I think would be helpful to the shopper
Date introduced
Date discontinued
Battery Powered

Fields not needed
HDD
Detachable antennas

Other ideas
filters for reducing the displayed content
Export data to CSV, TXT or XLS.
Query driven table

Thank you for your efforts in this very difficult task.  I do not require specific answers to my thoughts.

@tmo: USB, I can replace NO with '-', or the other way around. No prob.
About scraping the bootloader You know, I have once ran a script to check the device pages for existance. Never scraped anything on/from them. So that would be quite some work. We'll see, maybe I can come up with something smart.

@RangerZ: thank you for your interest.

There is a new proposed solution that will improve the situation much. Quite much like you suggest. Filtering and sorting on any column will work. And there will be a wide table with everything, and more narrow tables with fewer details, and they will all show the same underlying data. Editing will be improved (form based, with dropdowns and stuff). Export to CSV will be possible.

About your suggested fields... we have just introduced an "Availability Field" (dropdown with values like: Available, Discontinued, Discontinued 2014). Battery Power is a new idea, not being discussed before. It makes sense. Other people find the Detachable Antennas field useful so I think it will stay. When it comes to things like HDD/SATA/eSATA it is tricky with those things that are relatively rare.

We are in the phase of polishing the data for the final (at least release candidate) import into the new improved "table". We are also waiting for a few server side fixes to enable the new functionality.

Take time, this is not critical. I just stumbled over that field and the availability of that information on the devicepages. It's a nice to have and I have no clue how many pages have that info included.

Apart from us two improving minor details... what is stopping us from saying this is good enough for RC1 on the real site?

I was thinking the same yesterday evening.
- Regarding data quality, we're pretty good.
- Fieldnames are defined correctly now.
- Example tohs + templates for data+device are available
- Bureaucracy forms for creation of new data + devicepages are available
- Typa aliases are defined and available (needed for dropdowns)

Regarding data plugin and it's functionality (dataentry + datatable): We're good to go.
-> Tryout can start now (we need an admin to import the datapages into the wiki)

Regarding creation of new data/devicepages: Bureaucracy plugin + folded plugin need to be installed
-> we need an admin to install bureaucracy + folded. Once that's done, we can also test creation of new data/devicepages.

-> Get admin support and then let's go!

Edit: For the wiki admins: http://wiki.openwrt.org/toh/installatio … ctionality

(Last edited by tmo26 on 14 Jul 2015, 17:55)

Small mistake: hz vs. Hz

Please change:
WLAN 2.4Ghz -> WLAN 2.4GHz
WLAN 5.0Ghz -> WLAN 5.0GHz

Updated USB No->'-'

Tonight I installed an Edimax EW-7811Un USB Wireless Adapter.  Info was scarce.  Maybe another related opportunity.

MFG                  EdiMax
Device              EW-7811Un
Technology      rtl8192
Multi SSID        No
Speed              150
Wireless Type  b/g/n
Ext Antenna     no
Driver               kmod--rtl8192cu

USB thumb drives are probably not worth including, but there may be some other device "types" that are.

While the actual tool is probably low priority, planning for the feature may be more relevant.

Updated (Ghz->GHz).

LOL, I forgot one: CPU MHZ -> CPU MHz
Sorry for the many incremental changes...

BTW: You didn't update the wikitxt.tgz, did you?

I think I did update wikitxt.tgz.
Anyway, I updated again. It is very quick.
Sorry for not checking the quality of my work properly...

Don't worry, shit happens
Thanks for the update!

Demowiki updated this morning.

Use case: Imagine you want to know, whether your $device is supported by openwrt or not.
-> demowiki -> Table of hardware - even shorter
-> Enter e.g. 'dir-' in the Model column
-> Several devices come up with a OpenWrt release number (=supported), others are simply blank.

What do the blank fields tell the user?

blank = ¿ = We don't know the status
blank = - = We know the status, and it is 'not supported'
blank = something completely different

That IS a relevant use case. I started checking the four "ADB" router in this state.

Two of them are on the "supported page", the device page show OpenWrt boot logs and indicate how you can install, but not mentioning any stable versions.

One of them says it is never going to be supported (and is on Possible page).
One of them is on Possible page and says it could be supported because original firmware is based on Kamikaze (!).

As I see it, all these have very questionable support, and very unclear if BB or CC actually works. It would be great if people with more information (an actual piece of hardware) could update the information.

Supported = Unknown.

I will look at more.

Airlink, 4 devices.

One supported 14.07 - ok.
One supported 15.05rc1. My Data Entry says so, but it has not made it into your Data Entry.
One listed as WIP, very little information available. My Data Entry says WIP, but not in Wiki Table.
One listed as unsupportable, and does not even have a device page. My Data Entry says unsupportable, but not in Wiki Table.

So, apart from 15.05rc1, the lack of information just means "not supported". But The WIP/unsupportable distinction has not made it into the Data Entry at all. (I have a feeling this is by design, and that I was the reason)

Davolink, 2 devices.

One supported.

One listed on "WIP" page and supported="trunk". But the device page says "version supported: no, compile your own". Device page updated 2 years ago. I guess supported=unknown. Someone needs to try BB/CC with their actual device (if there is an image) and feedback status.

Linksprite, pcDuino (3 versions).

Listed supported. Seems supported. But no "version" is given, just "supported".
Again, this information is in my exported Data Entry, but it is lost while importing.

Mikrotik RB532: Listed as supported for 7.06-10.03.1.
Not very clear if this support really ceased after 10.03.1, or if it is just not updated.
Again, information is in my exported Data Entry, but lost while importing.

And again, not possible to figure out if it is supported or not, unless trying on real hardware and reporting back.

I think we should have a new field called "Unsupported reason:" where we can:
1) export the current "unclear" data that does not fit in the strict Currently Supported Version.
2) write something clever when we learn something (like: never supported, too little RAM)

Seems some issues with the demowiki and the dataplugin.
I'm now running the update again, but with corrected type definitions (admin area, not on the datapages). In fact, the WIP and 10.03 were missing in the type definitions, and hence were not displayed.
However, even after manually setting the 10.03 and WIP in the dataentries, they didn't show up in the datatable.

Maybe some caching issue. I will check and report back.

Yes, reimport solves the problem. 10.03, WIP and CC trunk do show up now.

But we need to get cleaner in the "Status" column. Example:
10.03 / Trunk
10.03 no adsl
10.03, trunk

If we want to restrict the valid values via dropdowns, we need to reduce the above (and other entries) to a pure release, if possible.

Edit:

Explanation: Definition of type aliases for release

"release           ¿, -, 0.9, 7.09, 8.09.2, 10.03, 10.03.1, 12.09, 14.07, 15.05, CC trunk, WIP"

Everything that doesn't fit in there, will not be displayed in datatables or the editor. Those values are only visible in the wikisource. We have to balance between adding to the above, and keeping it somehow clean for future entries.

(Last edited by tmo26 on 16 Jul 2015, 20:21)

@zook: Did some minor changes to vlan, usb, and some other stuff, mainly for pushing the available data in the dropdown scheme. Could you update, please?

How many reasons for unsupported do we have?
unsupportable - too little Flash
unsupportable - too little RAM
unsupportable - no/wrong target
other reasons... ?

We currently have "unsupportable" in the valid values, which could easily be changed to the values shown above -> no separate field neccessary.

However, I might not have captured your intention with adding a new field.
What unclear data are you thinking about?