Reply To: DigiXBeeWifi class mqtt codeflow example

Are you using anything else from the Modular Sensors library? Post your entire sketch as code (use the <> button to post as code)?  Are you setting the host and port for the mqttClient? (mqttClient.setServer(ip, port)) Use your local IP there.  If you do that, I don’t see why you’re not getting a connection even with the bad DL setting in the extraModemSetup function. The correct DL should be set by PubSubClient when it connects because it will call client.connect(ip, port) on the client created by modemXBWF.createClient(); That client is a TinyGSM object which should properly set DL using XBee command mode.

If you don’t need the power on/power off via pins that are in the DigiXBeeWifi class, use a TinyGSMModem/TinyGSMClient object directly.  There’s no need for that fake client thing. TinyGSM does all the work of converting the xBee into a client and provides you with the functions to connect to the network and a host so you don’t need XCTU.

The reason the extraModemSetup forces DL to 0.0.0.0 is to force the Bee to grab a new IP address each time. Doing that means that you *can’t* use XCTU – which is the “bug.” But the reason that’s done is that the WiFi bee tends to get stuck thinking it has an open socket to an IP address if it has one in memory – even if the module isn’t connected to the internet.  Sorry, it took me a bit of thinking to remember why that was done.  This is not a bug that should be fixed.

If you’re going to leave your Mayfly and XBee fully powered the whole time you program is running and you’re confident that your never going to lose the internet or socket connection and you’re comfortable with XCTU, then you may be fine with your faked client.