Add keepalive_interval as a persistent configuration option for c8y_bridge.conf

[jmoo900]

Is your feature improvement request related to a problem? Please describe.
Working with a customer that is utilizing cellular devices. They have strict bandwidth requirements where even the frequency of keep-alive messages can impact the negotiated contract with their cellular provider. The proposed option would allow them to limit the number of MQTT keep alive messages being sent by their device and ultimately the amount of bandwidth that passes through the cellular connection. This could impact any device that is utilizing a cellular connection.

Describe the solution you'd like
Would like the option to either be set through the tedge cli and saved as a tedge configuration option. Could also be a persistent entry in the c8y_bridge.conf file. I have found that when I manually add it to the configuration file and restart Mosquitto service through sysctl, I can see the behavior I want. The problem with this is that the configuration file gets recreated when a tedge reconnect c8y command is run and the change needs to be reapplied.

Describe alternatives you've considered
The workaround that we are investigating in the short term is scripting the modification of the bridge configuration file and then restarting the Mosquitto service. This is a bit cumbersome and technically may not be feasible given the additional start up latency that it will introduce. We have also considered creating a new configuration file and storing it in the /etc/mosquitto/conf.d directory (this is already referenced in the mosquitto.conf file, similar to /etc/tedge/mosquitto_conf) . I think this fails because the bridge seems to be created by some logic in thin-edge where it builds out the connection and the keepalive_interval needs to be in the context of that connection. Because it is outside of that in this config file we have created, it prevents Thin-Edge from starting.

Additional context
I don't think there are any screenshots that are needed. I'm happy to jump on a call and show any of things I mentioned above if that is helpful.

[reubenmiller]

@jmoo900 It makes sense to have the mqtt keep alive interval configurable, however playing nicely with the cellular network is only half of the picture, the keep alive interval would have also be compatible with the Cumulocity IoT MQTT broker, as I believe there is an upper limit here before the platform thinks the connection is dead (but maybe I'm wrong here).

Have you already experimented with the some ping intervals against Cumulocity IoT and have any idea of what upper limit would be sustainable?

[jmoo900]

Hey @reubenmiller,
You bring up a good point. I have really only been focused on the device side of the equation. The configurations that I have been trying have been in the 5 minute range and based on some wireshark outputs, it appears to be working as expected. I haven't noticed any MQTT connection issues with my thin-edge. If I remember correctly, the customer that I am working with was looking at around 15 minute interval for the MQTT keep alive. On the Cumulocity side, there is the concept of a "required interval" that allows you to set the expected communication frequency of a device, but I think that just drives the availability/online status of the device. I will have to do some digging on the actual connection to see if there are any timing limitations for the MQTT broker.

[reubenmiller]

On the Cumulocity side, there is the concept of a "required interval" that allows you to set the expected communication frequency of a device, but I think that just drives the availability/online status of the device.

Yes, you are correct. The "required interval" has no influence on the MQTT level (as the feature works for any kind of device, not just MQTT devices).

I will have to do some digging on the actual connection to see if there are any timing limitations for the MQTT broker.

That would be a great contribution 👍 But we can also help if you need some guidance with anything.