Add manufacturer/vendor handling

[ishotjr]

addresses part of #1236

[Eirenliel]

There is no SOMATICVR_ORION board type in firmware and shouldn't be. The whole idea of sending string as manufacturer was to get rid of the need to hardcode it and argue who should and shouldn't be added to board types.

Also translations should not be committed here, they're done via Pontoon.

[loucass003]

yeah only en translations keys should be sent

[ishotjr]

Thanks for the insight; I'm still learning! 💗 These changes correspond to the addition of SOMATICVR_ORION to BoardType in SolarXR:

SlimeVR/SolarXR-Protocol@283641d#diff-b05f90ae5bff957780c6d30ffa6cbfe47efb633444ac13b3f32104bb33ff33aeR31

[env:BOARD_SOMATICVR_ORION] exists in this fork:

https://github.com/SomaticVR/SomaticVR-Tracker-ESP/blob/main/platformio.ini#L254

and the hope was to be able to have both the manufacturer and main board correctly populated in the server UI. If BoardType is set in stone now, should other boards use CUSTOM rather than their own types, or ? 💭📛

Would it be helpful if I stripped the translation and SOMATICVR_ORION references and resubmitted the PR as just the manufacturer/vendor functionality? 🥺

Will investigate Pontoon for translations -- thank you! 💗

[Eirenliel]

The SolarXR PR is rejected for the mentioned reason. The text fields in protocol were added specifically for manufacturers to put anything they want in there, please use them. There is Vendor Name, URL and product name. It's not yet implemented in the GUI, but since you started on it would be cool if you could add that too :)

[ishotjr]

Understood; I spent quite a lot of time digging around in all of this to try to figure out why the fields we added didn't seem to be doing anything, trying to understand how it worked or what the intent was -- and reached out as such here; is there any documentation around this stuff that I'm missing? 💗

There is Vendor Name, URL and product name. It's not yet implemented in the GUI, but since you started on it would be cool if you could add that too :)

I would love to! Can you confirm that I got it right with my existing vendor === manufacturer implementation? and then I'm guessing product name replaces the current board type/name in the GUI? how should the URL be used? 🤔💭🔗

I'm guessing UPDATE_ADDRESS/UPDATE_NAME are best saved for another day, since they'll require extensive changes in order to function? 😅💾

[Eirenliel]

It was added for future compatibility, we haven't implemented it ourselves. There is no documentation, but yes you're using it correct. Vendor is manufacturer. You can add URL as a separate line to the GUI that can be clickable by the user to open the manufacturer's site.

[ishotjr]

Excellent! Will do!! Thank you so much for your quick and helpful responses!!! 💗✨

[ishotjr]

@Eirenliel I'm trying to figure how things line up across the codebases and there seems not be a direct relationship between SolarXR and the firmware (unlike the server, which uses it directly), and beyond that, I'm not sure there are any accommodations in SolarXR for these new fields? I see model in SolarXR -- is that intended to be used for the value in PRODUCT_NAME in the firmware? and does VENDOR_URL exist at all, or should I add something for it in HardwareInfo in hardware_info.fbs? thanks for your patience as I try to understand how everything works together or is intended to! 💗

[ishotjr]

@Eirenliel just wanted to check and see if you had any insight on this? 💗

[loucass003]

our interfacing with solarxr is very rough for all the manufacturer stuff. honestly i wouldnt mind a proposal to clean it up.

nobody use it outside of gui so we can prob deprecate whatever fields do not make sense and make new ones. ideally we would remove all the hardcoded ids and enums ouside of supported mcus and imus. then boards would become more abstract.
pure strings

[ishotjr]

@loucass003 thanks for the quick response! will take a look at this...

[unlogisch04]

I want to remind, That we have a problem with the current handshake packet that is still not solved.
When on the same network are older or not patched ESP32 SlimeVR Compatible Tracker, They might crash, when a other tracker send all Manufacture Data,..
This is still not fixed in SlimeVR-Tracker-ESP/main

[ishotjr]

@unlogisch04 I've applied @gorbit99's patch from kounocom/SlimeVR-Tracker-ESP@6e21ba0#diff-f9c2c74e084edc8f3bda0c3f9eb75959d82ef5da197cabed835b90c0e92f6524L547 to a fork of the firmware and testing suggests it fixes it; is there anything I can do to help with this?