johanstokking
commented
4 years ago 1 Operating temperature we're not copy-pasting datasheets 2 RelativeHumidity we're not copy-pasting datasheets 3 Compliancy we're not copy-pasting datasheets
I think we should keep them for three reasons:
- They are optional
- They are useful to feed a device catalog / marketplace
- They will not be copy-pasted by us, but by device makers. It is in their best interest to provide as much information as possible in a structured way
1 Not everyone will install the validation tools Lot of hassle to install
This is literally one command: npm install, with Node installed. Also, it is the most popular language. This is not going to be easier.
Also, this is optional. Everything will get validated by GitHub for pull requests.
2 yaml thing doesn't work well it barely gives input (or I didn't install correctly). Either way, it needs improvements
What do you mean with "barely"?
The instructions for VS Code is already there.
Sure, it would be great if we can have an interactive web interface, but that's a project in itself.
3 Not clear what to enter list all options clearly as descriptions
See above; your editor will show that.
Just create a template with all fields, options, examples and comments.
4 HW version not clear 5 SF version not clear
What is not clear about this?
See for example: https://www.bosch-connectivity.com/products/connected-mobility/parking-lot-sensor/downloads/
It is very common to have multiple versions of hardware and software, which are or are not certified and work or do not work in certain regions. As you see with the parking sensor, the payload format changed, so the profile changed. We don't want to show these iterations as different devices.
6 firmwareVersions version or numeric choose 1, chis confuses ppl
We need a numeric field for the LoRaWAN TS006 (Firmware Management) specification. It's an optional field anyway.
7 Firmware Version profiles are most of the times similar EU863-870 & AS923 may refer to the same file (might not be an issue)
You can use the same profile for multiple versions and for multiple regions indeed, if they are the same.
8 vendorProfileID what is it and how to get it
It's issued by the vendor itself, and it's used on the QR code, LoRaWAN TR005 specification.
The vendorID is assigned by the LoRa Alliance. The list is now public, will paste it in a comment.
9 pen & oui what is it, where to find it. Why is it necessary?
They are not necessary.
See field descriptions what they are. For example:
They are useful for linking to vendor information. The OUI is also typically used to issue DevEUIs, so we can recognize device vendors this way.
What is missing? What do you want to see?
- [ ] Improve CONTRIBUTING.md
- [ ] Clear example with all options people can fill out
- [ ] Clarify required and optional fields
I agree
- [ ] Not an option to have HW & SF version as we have it now. Reconsider this part
What is the proposal?
laurensslats
Summary
As of now, its too complicated and error-prone.
What is missing? What do you want to see?
How do you propose to implement this?
I will work on documentation. Johan to provide feedback
Can you do this yourself and submit a Pull Request?
Yes, with input from @johanstokking