Prepend system hostname to discovery_device_name

[Ziris85]

Description:

Hi there! This is mainly just a proposal for a quality-of-life adjustment stemming from my very-short-lived bug report #306 . Now that a client_id composed from the discovery_device_name is being passed along with the MQTT connection per #299 , this can cause connection conflict when more than one gateway is connecting to the same MQTT broker if one is lazy like myself and leaves the default configuration. So, this proposal is simply to change the default for that config and prepend the systems hostname to the configuration, making it by default <hostname>-TheengsGateway. This way, the name is less likely to cause conflict with multiple gateways!

An alternative idea I had was maybe to generate a short random string/UID to prepend instead of the hostname, but I thought the hostname might be more meaningful to ID the system it's running on.

Thoughts?

Checklist:

• I have created the pull request against the latest development branch
• I have added only one feature/fix per PR and the code change compiles without warnings
• I accept the Developer Certificate of Origin (DCO).

[DigiH]

Thanks for this proposal. As I'm away all this week I won't really be able to look at and test anything properly until next week.

My idea however is to possibly also use this opportunity to derive the three MQTT topics by concatenation with the defined discovery_device_name. As they are currently all statically defined in the config a name change for an individual gateway requires four changes to be nicely fully applicable, e. g.

"discovery_device_name": "TheengsGatewayKitchen",
…
"lwt_topic": "home/TheengsGatewayKitchen/LWT",
…
"presence_topic": "home/TheengsGatewayKitchen/presence",
…
"publish_topic": "home/TheengsGatewayKitchen/BTtoMQTT",

Instead of the hostname or any other random UUID, I would also propose to append the last octets of the MAC address of the gateway, similar to the sister app OpenMQTTGateeway.

Talking about OpenMQTTGateway, are you aware that one instance of Theengs Gateway on a more powerful machine, even if it's only a Raspberry Pi, should be sufficient, and that you can extend device reception with one or more smaller, cheaper and more energy efficient ESP32s with OpenMQTTGateway BLE installed on them?

I hope you don't mind keeping this PR open for the time being, until a full resolution to the above has been decided upon, as you now know how to rename one of your gateways to remedy the issue you were originally seeing.

[Ziris85]

Talking about OpenMQTTGateway, are you aware that one instance of Theengs Gateway on a more powerful machine, even if it's only a Raspberry Pi, should be sufficient, and that you can extend device reception with one or more smaller, cheaper and more energy efficient ESP32s with OpenMQTTGateway BLE installed on them?

Heh, well tbh I hadn't looked into that, though the two things I'm using are x86-64 Linux laptops, so it seems like Theengs is the way to go for those.

The MAC address would work too! Especially if it's in alignment with the other project, though that could be trickier to implement, especially on a system with multiple NIC's. Multi-NIC scenarios probably aren't a factor for OMG since that's just dealing with tiny developer boards with just a single connection. Open to ideas on what that might look like!

[DigiH]

The MAC address would work too! Especially if it's in alignment with the other project, though that could be trickier to implement, especially on a system with multiple NIC's.

Just have a look in your theengsgw.conf files. Which MAC address is being assigned to gateway_id there for your two Theengs Gateway gateways? This MAC address gateway_id is currently being used to identify individual gateways for the internal tracker syncing, but in line with the OpenMQTTGateway default gateway naming it would be along the lines of TheengsGateway-DDEEFF for the MQTt Broker connection.