Add a unique device ID to Messages list

[becorey]

Subject of the issue

With an RTK EVK sending messages using TCP Client, there is currently no unique device ID available to identify the device.
With a unique ID, it would enable the possibility of deploying a fleet of RTK EVK devices which all report data back to a central server, and keeping track of which device is associated with which incoming data.
The ID could be the UBX-SEC-UNIQID, the ESP32 MAC address, or some combination of those.
Reference to forum post Unique device ID in RTK EVK messages?

Your workbench

• What version of RTK firmware are you running?
• • Beta d1.4
• What radios are you using: Bluetooth, WiFi, and/or ESP-Now? What app are you using to connect over Bluetooth? Are you transmitting NTRIP back to the device?
• • Wifi, using TCP Client. Yes NTRIP to the device from PointPerfect.
• Are there any additional details that may help us help you?
• • The RTK EVK is installed with a vehicle and powered by the vehicle's 12V battery. A 4G modem/router provides Wifi to the EVK. The EVK sends messages using TCP Client to a server which logs the messages to files. Data is collected for several hours each day to track the movements of the vehicle.

Steps to reproduce

Tell us how to reproduce this issue. Please post any log files from serial output that may have been generated.
Put RTK EVK into Wifi Config mode, visit the config screen with a browser. Open the list of Messages available to send. There are many available but as far as I can tell none of them include a unique ID to identify the device that is sending messages.

Expected behavior

Tell us what should happen
It could implement a similar approach as SparkFun_RTK_Firmware #476, adding a $GNTXT message which sends the GNSS unique chip ID and the last four digits of the ESP32 MAC address.
It could be sent periodically like any other message and likely would be set to a low frequency such as once every 20 fixes.

Thank you!

[nseidle]

This is a great feature to add but will require a considerable amount of work to implement. We'll need to add a custom message generator which has no precedence. Please give us some time to consider how it might be added. In the mean time, if you have any ability to contribute to the codebase, we welcome PRs.