Table of hardware: add new fields for 2.5 GBit ports and outdoor devices


I like to propose adding two more fields to the table of hardware to make it easier to search for specific hardware:

  1. a field for 2.5 GBit ethernet ports as seen in newer devices (e.g. WAX206 -
  2. a field to mark outdoor devices (e.g. ZyXEL NWA55AXE, TP-Link CPE210/CPE510/...)

For the outdoor devices it might also be nice to have a field to specify the IP rating. In addition it might be useful to add fileds to specify the PoE standard supported by the device, which is also useful for a lot of indoor APs.

@tmomas can we add those fields?



Yeah, the whole network port stuff needs to be changed to reflect current hardware possibilities, i.e. multi-Gig ethernet and SFP.

I had a discussion with @Borromini quite some time ago (sorry, didn't have time to attack this in depth), during which I had created a mockup:

Please take a look and report back any issues, concerns, or change proposals.

Outdoor devices

Some prior discussion about outdoor devices in the ToH: Techdata: add new dropdown value: "Routerboard" - #2 by tmomas

From the implementation point of view, the solution via devicetype is really the easiest to implement.

Current devicetypes: WiFi AP, WiFi Router, Router, Travel Router, Travel Router - Battery powered, Range Extender, Powerline Adapter, Single Board Computer, SFP module, Switch, Modem, NAS, Camera, Emulator, unknown, other

Which of those would need to be outdoor? Do outdoor travel routers exist?-)

IP Rating

Why is the IP rating important, if you already know that it is specified for outdoor use? Does it really matter if it is IPX5/IPX6?


PoE is already specified in the Power supply datafield, see



I had a look at the proposal and I like the compactness, but fear errors when data is entered. Unless you can validate input, I would personally go for separate fields for different port speeds to reduce errors and to keep is well-structured. Compact fields could then be computed/filled from the structured data to generate better views for users.

Outdoor devices

From looking at your device type list I think you would need to add an outdoor suffix to multiple categories: WiFi AP, Camera, Switch, Powerline Adapter

Outdoor often means that they are rated for harsh conditions e.g. sub-zero temperatures, some outdoor components still need to be put in an outdoor enclosure.

However, while there are specialized outdoor devices in those categories available, it does not mean that OpenWRT would ever support them.

I think it would be best to just add it via a separate data field “Outdoor” [yes|no]

IP Rating

Some devices can withstand water, others are just sealed off against dust. So depending on the location of the device you would require different ratings. The list of outdoor devices might however not be that long, so probably an IP rating field is not that important.


I just missed that one. :wink: Thanks for pointing it out!

I am in agreement with Noki that a separate Outdoor Y/N would be preferable. The IP Rating would be a bonus, but perhaps we should determine how many actual outdoor devices are supported first.

1 Like

@tmomas can you add the outdoor field so we can flag devices? shows 44 devices

Done, "Outdoor" datafield added.


Like this? -> Updated dataentry mock up

  • Red = additional fields, replacing the blue field; can be implemented quickly (just like I did today with the Outdoor field)
  • Yellow = SFP field needs to be added anyways; can be implemented quickly (just like I did today with the Outdoor field)


I like the compactness of the blue one: One column, easily searchable for e.g. 1G, 2.5G etc.
Needs more time to implement though (script needed to fill the field with the existing 100m + Gbit ports).

I'd be inclined to go the quick and dirty route for now and implement red and yellow, just to get thing going.
("Lieber mit Fehlern gestartet als perfekt gewartet.")


1 Like

From a human-parseable standpoint: yes. But if you want to programmatically parse it into a device matrix/selector, it's very much the worst case.

Over the last few weeks, I've been (off and on) working on an easy-to-handle multi-dimensional filter matrix (akin to what geizhals does), and it's making good progress, possibly towards a christmas holiday release. But I'm still pulling my hair on how to parse the ant hill that is currently the "power supply" field without going insane:

I'd really hate the network interface field to become the same unordered, unsorted, unmaintainable freeform mess. I'd very much prefer lots of distinct fields with well-defined data, they can easily be consolidated for output later, the opposite is a lot of work at best, impossible at worst.


You are my very hero! :slight_smile:

I guess what I'm saying is: If you have half a dozen fields for different port speeds, who cares really? They don't weigh down the database that much and one can make it into a human-readable string later. I would even advocate having "SFP ports" and "SFP+ ports" two separate fields, with purely numeric data. Basically avoid freeform entries where the data is quantifiable.


The new mock with fields for each port speed for ethernet and different SPF ports is perfect. Let's go with that one and try to autofill the compact format from that data.

btw.: I started filling the outdoor field:[Outdoor*~]=yes

Ancillary thought: Earlier this year I was looking for a supported 3x3 or 4x4 device, and it would have been damn handy to have it as a selection criterium. Should we/could we/do we want to have a field for the antenna configuration (i.e., 2x2, 3x3, 4x4) and if so, would we need a single one, or two, one for each of the Wifi bands?

I'm of same opinion. Have separate fields for the values. Once its in a table you can pull it and display it anyway you want. However if you have to pull a table and parse it, its harder to manage.

1 Like
  • What would be the name of this new datafield? Antenna Confinguration? MIMO?
  • What values are needed? 2x2 or 2T2R or ...?

That's just semantics, they are equivalent. But there's also an "extended" format, "TxR:S" (because apparantly there's devices out there that do "3x3:2", i.e. 3 antennas but only 2 streams, or such nonsense). And I'm pretty sure we would be entering bikeshedding territory if we enumerate all possible TxR:S variants, especially since TxR can already go up to 8x8.

(Edit) It would probably make sense to have separate "2.4GHz MIMO" and "5GHz MIMO" fields, even if they usually do not differ. The Unifi AC LR for example does 3x3 MIMO on 2.4GHz, but 2x2 MIMO on 5GHz.

As for the name of the field, I don't really care. "Antenna configuration" sounds sensible since "MIMO" implies, well, MIMO (and "1x1" is not MIMO :wink: ). But "MIMO" is shorter and sweeter. Again, more input from someone who is not me please.


Thanks to a reminder I revisited this topic today and found scripts I had prepared before my holidays, (almost) ready to be applied. :slight_smile:

I have now updated the dataentries to include multi-Gbit and SFP ports.


sorry for bumping this, but could also get the > 1gbit ports listed ?

Done, multi Gbit ports added.

1 Like

I'm inclined to simply follow what's out there on wikidevi and techinfodepot.

  • Name of datafield: MIMO (even if 1x1 technically isn't)
  • Options for datafield type -> to be decided
    a) textbox (free text, TxR:S notation possible; easy copy&paste from wikidevi)
    Downside: We will get mixed results, i.e. 2T2R, 2x2, 2x2:2
    b) select (dropdown, predefined values, TxR notation)





1 Like