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.
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.
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]
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. Thanks for pointing it out!
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.
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.
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?
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 ). But "MIMO" is shorter and sweeter. Again, more input from someone who is not me please.
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)