mosquitto
mosquitto copied to clipboard
Bridge connection state doesn't update locally when `notifications_local_only` is set to true
I'm trying to use an LED on a device to indicate the bridge broker status using mosquitto V1.6.7. I found an issue, where the bridge connection status is not getting updated under certain circumstances.
I have set notifications
and notifications_local_only
to true
(I don't want the status notification to be sent to the bridged broker).
When mosquitto starts up with a broken bridge connection, the state 0
is published in $SYS/broker/connection/*id*/state
and as soon as the connection is restored, state 1
is published in the same topic, as expected.
However, if the connection breaks again, status 0
is no longer published in the above topic. When mosquitto starts up and establishes the connection straight away but the connection is broken later, status 0
is not published into the status topic.
I tried re-subscribing but the retained message received at subscribe has the payload 1
.
This doesn't seem to be an issue at all, when notifications_local_only
is commented out from the configuration, in which case the status of the bridge connection is updated as expected, every time when there is a change in the bridge connection status.
I think this is what I commented on when it was initially added, that only the 1 is published: https://github.com/eclipse/mosquitto/issues/233#issuecomment-371149796
I just fought with this problem, it's frustrating to know that this is a known issue. Confirmed on v1.5.8 (Rpi3, Yocto Warrior)
I've just retested this on 1.6.12. As before, the "1" is published locally when the connection is made, but the "0" is never published locally when the connection goes down.
I've just retested this on 1.6.12. As before, the "1" is published locally when the connection is made, but the "0" is never published locally when the connection goes down.
Yes, I met this problem this days. It should publish state 0 locally, and here is my patch for that.
diff --git a/src/bridge.c b/src/bridge.c
index c951c8c..54936bd 100644
--- a/src/bridge.c
+++ b/src/bridge.c
@@ -355,13 +355,11 @@ int bridge__connect(struct mosquitto_db *db, struct mosquitto *context)
context->bridge->initial_notification_done = true;
}
- if (!context->bridge->notifications_local_only) {
- notification_payload = '0';
- rc = will__set(context, context->bridge->notification_topic, 1, ¬ification_payload, 1, true, NULL);
- if(rc != MOSQ_ERR_SUCCESS){
- return rc;
- }
- }
+ notification_payload = '0';
+ rc = will__set(context, context->bridge->notification_topic, 1, ¬ification_payload, 1, true, NULL);
+ if(rc != MOSQ_ERR_SUCCESS){
+ return rc;
+ }
}else{
notification_topic_len = strlen(context->bridge->remote_clientid)+strlen("$SYS/broker/connection//state");
notification_topic = mosquitto__malloc(sizeof(char)*(notification_topic_len+1));
@@ -375,14 +373,12 @@ int bridge__connect(struct mosquitto_db *db, struct mosquitto *context)
context->bridge->initial_notification_done = true;
}
- if (!context->bridge->notifications_local_only) {
- notification_payload = '0';
- rc = will__set(context, notification_topic, 1, ¬ification_payload, 1, true, NULL);
- mosquitto__free(notification_topic);
- if(rc != MOSQ_ERR_SUCCESS){
- return rc;
- }
- }
+ notification_payload = '0';
+ rc = will__set(context, notification_topic, 1, ¬ification_payload, 1, true, NULL);
+ mosquitto__free(notification_topic);
+ if(rc != MOSQ_ERR_SUCCESS){
+ return rc;
+ }
}
}
The above patch is not correct, the 'state = 0' is still published remotely after bridge disconnected.
The above patch is not correct, the 'state = 0' is still published remotely after bridge disconnected.
No, Above patch is not well tested for you situation, More see #1902, it should work fine!
The above patch is not correct, the 'state = 0' is still published remotely after bridge disconnected.
No, Above patch is not well tested for you situation, More see #1902, it should work fine!
I see, I was not aware of the change in send_connect.c.
As a side comment I would like to add that the notification_topic is not mapped by the bridge according to the topic mapping rules, when set as LW&T topic by the bridge. So to avoid problems it is best to keep it the same on the local and remote brokers.
Please give the develop
branch a try if you are able.