| 
Hi Abilio,   This is promising actually…   We are already using the notification_topic for up/down state; we have a separate requirement for recording why the connection failed. I’ve done a quick test here and I can see logging on the $SYS/broker/log/#
 topic – our system should be able to parse these, as long as there is a recognisable pattern for bridge errors.   Regards   Rebecca Gellman   
From: mosquitto-dev <mosquitto-dev-bounces@xxxxxxxxxxx>
On Behalf Of Abilio MarquesSent: 04 October 2022 17:25
 To: General development discussions for the mosquitto project <mosquitto-dev@xxxxxxxxxxx>
 Subject: Re: [mosquitto-dev] Reading bridge errors over MQTT ? [EXTERNAL]
   
WARNING: This message came from an external source. Please exercise caution and proper judgment when opening any attachments, clicking links or responding to this message. 
 
   
Probably you already discovered it, but you can get the state of the bridge (1 or 0) on a special topic (see "notification_topic"). This is not exactly what you want, but at least helps
 to detect when a connection fails. 
For the why, you could ask Mosquitto to emit the logs over MQTT, setting "log_dest". Of course, you will still need to filter the messages by payload. You can also set the "log_type" to
 reduce the number of messages. Not sure if this is viable in your product though.   
Hi,   At this stage, I’d welcome pointers – if only to pass onto my superiors as to “why we’re not doing this like you wanted”
😉   Regards   Rebecca Gellman       
WARNING: This message came from an external source. Please exercise caution and proper judgment when opening any attachments,
 clicking links or responding to this message. 
 
   
I'm afraid that's not possible at the moment. I could advise where to look if you wanted to see about implementing something yourself?   
Hi,   Is there a way to read (over MQTT, or some other well-defined mechanism, e.g. UNIX domain socket protocol) connection errors related to a bridge connection?   We are using Mosquitto as a bridge from our device to a cloud provider, and have a requirement to detect (and log) when a connection fails with the reason why it failed (e.g. DNS
 resolution failure, SSL failure, authentication failure, etc.)   I’d rather not be parsing log files…. Not least because in release configuration our device doesn’t have any
😐   Regards   Rebecca Gellman   
 
 This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have reason to believe
 that you have received this e-mail in error, please notify the sender and destroy this e-mail and any attached files. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the
 Curtiss-Wright Corporation or any of its subsidiaries. Documents attached hereto may contain technology subject to government export regulations. Recipient is solely responsible for ensuring that any re-export, transfer or disclosure of this information is
 in accordance with applicable government export regulations. The recipient should check this e-mail and any attachments for the presence of viruses. Curtiss-Wright Corporation and its subsidiaries accept no liability for any damage caused by any virus transmitted
 by this e-mail. _______________________________________________mosquitto-dev mailing list
 mosquitto-dev@xxxxxxxxxxx
 To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/mosquitto-dev
 
 
 This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have reason to believe that you have received this e-mail in error, please notify
 the sender and destroy this e-mail and any attached files. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the Curtiss-Wright Corporation or any of its subsidiaries. Documents
 attached hereto may contain technology subject to government export regulations. Recipient is solely responsible for ensuring that any re-export, transfer or disclosure of this information is in accordance with applicable government export regulations. The
 recipient should check this e-mail and any attachments for the presence of viruses. Curtiss-Wright Corporation and its subsidiaries accept no liability for any damage caused by any virus transmitted by this e-mail. _______________________________________________mosquitto-dev mailing list
 mosquitto-dev@xxxxxxxxxxx
 To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/mosquitto-dev
 This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have reason to believe that you have received this e-mail in error, please notify the sender and destroy this e-mail and any attached files. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the Curtiss-Wright Corporation or any of its subsidiaries. Documents attached hereto may contain technology subject to government export regulations. Recipient is solely responsible for ensuring that any re-export, transfer or disclosure of this information is in accordance with applicable government export regulations. The recipient should check this e-mail and any attachments for the presence of viruses. Curtiss-Wright Corporation and its subsidiaries accept no liability for any damage caused by any virus transmitted by this e-mail.
 
 |