LEDE Table of Hardware: Review of dataentry fields

The first step before importing any dataentries is to update our dataentry template.

-> Go to https://wiki.lede-project.org/templates:template_dataentry
-> Click the LEFT edit button below the dataentry box

Please review the template for

  • datafields to be added (Is any useful information currently missing?)
  • datafields to be changed/updated
  • datafields to be deleted (Not needed any more for LEDE)
  • available dropdown values for certain datafields (Is any useful value currently missing?)

I started to collect todo's here https://wiki.lede-project.org/talk:templates:template_dataentry

Discussion should take place here in the forum. The outcome of the discussion should then be placed on the talk page https://wiki.lede-project.org/talk:templates:template_dataentry.

@tmomas - I'm glad to see a start on the Table of Hardware (ToH). You have added two sets of pages:

This gives us a basis for making judgements about the fields to include/exclude for these templates as requested in the original post. Here are some thoughts:

  • This looks really good. It's comfortable for those of us who worked on the OpenWrt ToH, and gives us a chance to do it even better.

  • If I remember correctly, it's (relatively) straightforward to make systematic changes to these templates. We have scripts that can add a new fields with known/static data. Similarly, the scripts can automatically remove a given field from each template.

  • It would be a lot of (manual?) work to add new fields that have unique data for each device's template.

  • Should the top-level start page be within the "hwdata_lede" folder? (Maybe not, since it might get in the way of the script processing)

  • I had thought about including FCC ID & date as fields since these are valuable for determining the age and identity of a router. But it would (pretty likely) duplicate Wikidevi info. Perhaps we could have a "FCC ID & Date" field, but populate it with a link to Wikidevi (or just "See Wikidevi page")

  • [Side note: it was pretty scary when wikidevi went off the air about 6 months ago, and no one could raise its maintainers. Do we know if there's a (public) backup? How might we find out?]

  • If we include any instructive text on the dataentry pages, I think we should tell readers to use the "edit" button at the "lower left" of the page. (OpenWrt pages say on the "left" - and I scan in vain to find it.)

I'll say more as I look harder at it. But Great Work!

see also:

These are the minimum/maximum columns tables, just to give you an impression of the look with the raw bootstrap wiki-template. I will see if I can change this to a better (i.e. show hor/vert lines in the tables) via CSS.

Be careful: You are mixing up template and dataentry.
template_dataentry != dataentry of device_xyz
template_dataentry = the mother of all dataentries
The template itself doesn't contain any device specific information, but the dataentry does.

Changes to the template_dataentry are easy, since it is a normal wiki page.
Whatever we want to be in the dataentries, we better decide now and implement that now (=@time of import), instead of later.

The LEDE ToH dataentries are created via a script that contains the template (not the template page out of the wiki, but hardcoded in the script; changes to the wiki page must be transfered into the script manually. That's why I currently work with the script, rather than the wiki page; wiki will get updated later).

Changes @creation time of the dataentries are easy to do and result in nice and clean dataentries from the beginning, without any spamming of the wiki logs. There are more than 1100 devices in the ToH, and a change that affects all would result in more than 1100 changes that the wiki would have to handle. I would like to avoid that.

On top of that: If the dataentries are created correctly right from the beginning, you can later rely on that all dataentries have the same fields. This is important for the usage of the data in the datatables: If fields are added oder changed or deleted later on, you might have to adjust all datatables that make use of those fields. Tedious work that really needs to be avoided.

Changes that come later, when the LEDE ToH is fully implemented, can be done via wiki internal batch edit (not preferred for changes of more than 50 devices; you have to click a checkbox for each of them, which get's annying with increasing numbers), or alternatively via a shellscript (once again ssh access proves useful, thanks Ted! :slight_smile:

The current folder is a little dirty remainder of the conversion. I forgot to change it to hwdata only. will be updated in the next update.

Regarding FCC: Linking to wikidevi would not make much sense. A link to https://fcc.io/yourFCCid is nice and short and easy to create for the user.

Regarding wikidevi: I havn't yet contacted them, since I wanted to have full access to the ToH data first. If I want to offer something to wikidevi, I need to be able to export data from the sqlite db and send it over to wikidevi. This ability is not given in the OpenWrt wiki (at least not for me), but now in the LEDE wiki.

A wikidevi backup is not a bad idea, indeed. This big pool of data must be available at all times.

Regarding LEFT edit button: Take a look at the dataentries: The 'includes' are already there, but the source of the includes not yet. Will be done later...
BTW: This is a nice example for modularity: Change one include-source, and you changed >1100 dataentries, without even touching them.

OK, enough for this reply. Keep on looking, let me know if there's something to improve.

re: First-cut ToH pages.

  • The pages are much too wide. Perhaps the default text/search field widths could be made smaller?
  • CSS has the ability to make alternating rows different background colors (some kind of odd/even selector. See, for example, http://www.w3schools.com/cssref/sel_nth-child.asp)

Yes, I wasn't quite clear. It's all about "creation time". If we want to apply changes to every template, we really need to decide about those changes right now.

It's one thing to run a script across the 1100 dataentry pages to add/modify/remove fields. If we screw up and want to make changes after other people have started to enter their own info, it's a much harder process.

I was only suggesting that I would prefer to call this the "bottom-left button". I was initially perplexed at the instructions stating to use the "left edit button" because my eyes looked to the left and didn't see one... at least until I scrolled all the way down to the bottom. "bottom-left Edit button" would completely satisfy my concern.


depending on what you think about my idea here about templating the flashing guides too, we might need more fields to accomodate the info required by that to work
(flash offsets (min/max) for manual flashing, an identifier field to link the right tutorial depending on web interface as newer devices might have a different web interface even if they have the same brand ,console settings, something else maybe)

The file downloads have been reorganized and most of the packages are now at a folder at the same hierarchy level as targets. Under this "packages" folder are now a flat set of 39 instruction sets (I just checked all the subfolders) so I do not the the "Sub Instruction Set" field will be needed.

Can we mirror the exact names in this page https://downloads.lede-project.org/snapshots/packages/ for the Instruction Set values. Can the drop-downs link to the appropriate sub page?

I for one have not a clue as to how to map from targets to instruction sets, and do not think it's safe to have the user guess.

Not sure how to do the cleanup on this.

I find it confusing to have the fw images sorted into folders by target, and the packages sorted into folders by instruction set. Why is this so?

Updating instruction set in the dataentries: Sure, can be done.
Please complete the table I created here: https://wiki.lede-project.org/toh/instructionset_conversion

I don't understand... what dropdowns and sub page do you mean?

Images are grouped by target and packages by instruction set because multiple targets share the same packages.

Will provide a list of mappings here once I'm ner my PC again

I am referring to the drop down in the Data Entry view while in edit mode which contains the instruction set values.

I am suggesting, if possible, this display as a hyper-link in the data entry view mode and point to the same value on this page: https://downloads.lede-project.org/snapshots/packages/ .

So the LEDE Instructions Set value "i386_geode" would land here: https://downloads.lede-project.org/snapshots/packages/i386_geode/

I have gone into more detail here: Packages for instruction sets I have no idea how to map the values in this table, and suspect most users will also not.

OK, now I get it!
I'm afraid, AFAIK this is not possible. That's our old problem, that we want to show a short link in the datatables, e.g. "Installation Image" or "Upgrade Image" instead of the current full url.

Found a workaround:

  • datafield "LEDE instructionset" is now of type "page" -> internal wiki link
  • datafield "Packages download" is now of type "title" -> internal wiki link
  • on the page that both of the above datafields currently link to, I placed an external link to https://downloads.lede-project.org/snapshots/packages/
  • I created a namespace template for /instructionset/, which automatically fills in the instructionset in the pagetitle and the packages URL.

Good enough?

1 Like

Great solution!

I realize that I should mention something that has always bothered me about the "Device Page" entries shown on the OpenWrt ToH.

The names are lower-cased, but I think they would be far better ("more official" appearing) if they were the same case as the "Model" column.

We were talking about modularity. Several devices share the same installation methods.
Introducing the "Installation method" field was an attempt to create shortcuts to the always same installation instructions, that do not need to be repeated over and over again.

Richb wrote in Toward a good "Flashing LEDE Instructions" page - #22 by richb-hanover

I am not sure of the value of this "Installation method" field.

First off, I don't know how we would populate it. It wouldn't make
sense for us to review all the Device Pages from OpenWrt: despite the
fact that it would be a lot of work, we'd simply propagate any
(mis)information contained there (because we don't have personal
experience with all devices).

Second, what will the reader do differently based on the setting of this field? Would they choose not to use the device?

  1. I'm not afraid of a lot of work.
  2. Why should we review the OpenWrt devicepages, when this is about LEDE devicepages (which have yet to be created)?
  3. You don't want to propagate (mis)information -> you don't want to copy the OpenWrt devicepages, but instead create new LEDE devicepages. If the devicepages are created new anyways, why not add a new way to include installation instructions?
  4. Why should the reader do anything differently?
    What you might think: The "Installation method" shows up in the ToH, and the $user wants to sort and select by this criteria. That's not necessarily so, but thinking about it, it could be a usecase (I want a device that can be flashed via GUI, since I'm too noob to even think about using CLI. Everything different than GUI will not do.) But that's only thinking aloud...
    What I was thinking of: Show this field only on the devicepages and make them more modular by doing so.

Look at the packages download: Packages are now downloadable by instruction set, not by target, because several targets share the same instructionset and therefore also the same packages.

Same same in this case: Several devices / targets share the same installation instructions.
You could show this field on the devicepage in the "Installation" datatable, right next to the firmware download urls https://wiki.openwrt.org/meta/template_device#installation

Since LEDE is targets not only routers anymore, but to a wider category of embedded devices with hardware that may be much different than routers:
Would it be useful to have a field "GPIOs" in the dataentries?

The number of readily accessible GPIOs could be a useful search criteria.

What do you think?

Definitely, I think GPIO info is useful for custom hardware projects

+1 for GPIO field, for devboards/single board computers it is crucial info.

It may make sense to list also screen ports (either embedded like LVDS or external like HDMI) and audio ports.

Gentle reminder :slight_smile:

The conversion table I posted above moved to a new location and is waiting for filling. Once I have the relation OWrt vs. LEDE Instructionset, I will update the dataentries.


he posted them here

If what you need in that wiki page is mostly monkey businness (jow not strictly required), I can do that tomorrow.

Nice! Thanks for pointing me to that posting!