Value change of "Device.MQTT.{i}.ConnectRetryTime" can't be applied to mqtt #109
Comments
|
Currently an updated ConnectRetryTime is only applied if OBUSPA is restarted or if there is a Controller initiated reconnect. We've noted this as a bug which is most likely to be an issue when first onboarding a device, changing ConnectRetryTime from it's default. It could result in any subsequent reconnects being at a different frequency than anticipated, until OBUSPA is restarted. It would be unusual to change ConnectRetryTime at any time other than first onboarding a device. Typically this parameter is set up once, then forgotten about. |
|
thanks for your reply! |
|
Yes, to fix this issue, we will probably need to write a function called something like MQTT_UpdateRetryParams (which does not exist in the codebase currently) |
Fixed
- MQTT keep alive can now be completely disabled (if required) when
linking with libmosquitto v2.0.x
- OBUSPA should subscribe to all topics indicated by the subscribe-topic
user properties in the CONNACK [R-MQTT.15]
- OBUSPA should delete pending USP notifications (on MQTT MTP) if
notification has expired whilst waiting to be sent
- MQTT connection blocks for too long if server is unresponsive. To
workaround the underlying issue in libmosquitto, OBUSPA tests for server
responsiveness by transiently connecting, before proceeding with the
libmosquitto connect (if responsive).
- OBUSPA should disconnect if unable to subscribe to anything
[R-MQTT.17]
- Device.MQTT.Client.{i}.Name should be auto-assigned by the agent, if
not given at creation time, and immutable thereafter
- Device.MQTT.Client.{i}.RequestResponseInfo should control whether
response information is requested in the CONNECT frame. Previously it
was always requested, regardless of the value of the parameter
- Removed unimplemented parameter:
Device.MQTT.Client.{i}.RequestProblemInfo
- Modifying MQTT KeepAliveTime should not force a reconnect
- MQTTv5 Assigned Client Identifier is not being saved in
Device.MQTT.Client.{i}.ClientID
- MQTT ConnectRetryTime parameter modifications should apply at the next
retry [GH #109]
- MQTT CleanSession and CleanStart parameter modifications should apply
at the next retry
- STOMP ServerRetryMaxInterval parameter modifications should apply at
the next retry
Added
- Device.LocalAgent.X_VANTIVA-COM_PreConnectTimeout controls how long to
wait for the can_mtp_connect vendor hook to allow connection, before
connecting anyway
- USP_REGISTER_Object_UniqueKey() validates that the unique key
parameters have not already been registered
|
Closing as fixed in OBUSPA v8.0.5 |
Hi,
We just found that changing value of the MQTT.{i}.ConnectRetryTime doesn't work for the mqtt connect retry time, has to restart the obuspa to make it effective.
what i found in the code is that the function "NotifyChange_MQTTConnectRetryTime" maybe should call the MQTT_UpdateRetryParams(which was not implemented) to sync the new values to the mqtt.c ?
is this a bug or something TODO in the plan?
thanks!
Xiaofeng Meng
The text was updated successfully, but these errors were encountered: