Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bridge connection state doesn't update locally when notifications_local_only is set to true #1488

Closed
matesh opened this issue Nov 4, 2019 · 8 comments

Comments

@matesh
Copy link

matesh commented Nov 4, 2019

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.

@karlp
Copy link
Contributor

karlp commented Nov 4, 2019

I think this is what I commented on when it was initially added, that only the 1 is published: #233 (comment)

@timothyfroehlich
Copy link

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)

@karlp
Copy link
Contributor

karlp commented Sep 2, 2020

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.

@jason416
Copy link

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, &notification_payload, 1, true, NULL);
-                               if(rc != MOSQ_ERR_SUCCESS){
-                                       return rc;
-                               }
-                       }
+                       notification_payload = '0';
+                       rc = will__set(context, context->bridge->notification_topic, 1, &notification_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, &notification_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, &notification_payload, 1, true, NULL);
+                       mosquitto__free(notification_topic);
+                       if(rc != MOSQ_ERR_SUCCESS){
+                               return rc;
+                       }
                }
        }

@cimplart
Copy link

cimplart commented Sep 1, 2021

The above patch is not correct, the 'state = 0' is still published remotely after bridge disconnected.

@jason416
Copy link

jason416 commented Sep 1, 2021

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!

@cimplart
Copy link

cimplart commented Sep 2, 2021

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.

@ralight
Copy link
Contributor

ralight commented May 25, 2022

Please give the develop branch a try if you are able.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 20, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants