After switchting to plugin still seeing "connecting" or "reconnecting" messages even with no MQTT anymore

[marcelser]

Hi Bill,

I’m not sure if this intended behaviour or results from previously having MQTT devices in the project. I deleted all of them and I’m still seeing “connecting” or “re-connecting” messages when app wakes up from background or from stopped state. Actually the plugin is connecting in a fraction of seconds and those messages are not needed nor helpful but blocking the area where they appear for this time.

Are those messages left-overs from my MQTT devices or just linked to the “connect” method of the plugin? Can I disable them somehow? And one more thing, is it able to print some error from the plugin like “error: result was http 503 Access Denied” or something similar? actually just like the “connecting” messages as a toast?

Thanks for any insight on this questions.

Best

Marc

[bill (Bill Venhaus)]

Those messages have nothing to do with the plugin or MQTT devices. They appear when the status of your network adapters change. Every time the network state changes it will reconnect & show those toasts. You can disable those toasts & all others by checking the “Hide Toasts” advanced setting in the Designer. I generally discourage doing this because you could miss some helpful error messages.

You can print custom messages to the console window in the Designer using “console.log”. Those log messages however are not available in the actual app. What you could do is something like @hotelfoxtrotnovember did in his Advanced Plugin Logging post.

Advanced Plugin Logging

This topic idea came out of a discussion I had with Bill and he suggested I put it in its own topic. For those developing plugins (whether starting from scratch or just making some “minor” modifications for your specific system), it is often help to have debugging output. This allows you to trace when plugin callbacks are invoked and to access the internal state of the plugin (values of variables, functions being invoked, etc). One easy way to get debugging output is by using the builtin cons…

[bill (Bill Venhaus)]

Another thing you could do is handle the error yourself by wrapping the code in a “try-catch”. Then execute some alternate code in “catch” block that could, for example, try to connect to a different host.

try {
  //Try to connect locally.
}
catch(err) {
  //Try to connect remotely.
}

[marcelser]

Thank you Bill for your insights but of course I know about the console.log, I used that a lot in debugging the plugin. I’ve also seen that “Advanced Plugin Logging” thread, but to be honest it just fills a variable with the console.log messages to be displayed somewhere in a custom field.

The only use of something like this that comes to my mind is that I could maybe mimic some kind of toast with a custom hidden element and not pass the full log but just one line of logging and then display it for 1-2 seconds and then hide it again. But it requires adding this field on all pages and it’s kind of an very ugly hack.

So I think 2 feature requests would make sense here.
1.) disable “info” level toasts like those (re)connecting and other purely informational stuff in desiger apart from all toats (maybe as a radio button or second checkbox)…
2.) have a “toast” function for the plugin api available which could then be wrapped in a try/catch to improve plugin errors which usually just result no action but also no error.