Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of WikiWatershed, an initiative of Stroud Water Research Center designed to help people advance knowledge and stewardship of fresh water.
New to EnviroDIY? Start here

DigiXBeeWifi class mqtt codeflow example

Home Forums Mayfly Data Logger DigiXBeeWifi class mqtt codeflow example

Viewing 4 reply threads
  • Author
    Posts
    • #19620
      Sabin
      Participant

        I am trying to make mayfly work as publisher, send data to broker running on raspberry pi. I am using Xbee s6b wifi modem.
        While using this class to create client that I could pass into pubsub or arduinomqtt as constructor variable. But, DigiXbeeWifi class would always reset my DL to 0.0.0.0 which I set using xctu to correct broker address and therefore couldn’t be connected.
        Are there any good working example of this?

      • #19621
        Sara Damiano
        Moderator

          Ooooh.. yup, there’s a bug in DigiXBeeWifi.cpp.  I’ll look into it.

          Exactly which version of the library are you using (release, master branch, develop branch)?

          For now, you may be able to get it working by commenting out lines ~303-310 in src/modems/DigiXBeeWifi.cpp, the section starting with “set the destination IP to 0”

        • #19622
          Sabin
          Participant

            Thank you for your response.
            I think it’s the master branch.

            Also, this is what I am trying to do.

            DigiXBeeWifi modemXBWF(&Serial1, powerPin, statusPin, false,
            modemResetPin, modemSleepRqPin,
            ssid, pwd, false);

            Client* netClient = nullptr;
            MqttClient* mqttClient = nullptr;

            void setup() {
            Serial.begin(9600);
            Serial1.begin(9600);
            delay(2000);

            if (!modemXBWF.connectInternet(60000L)) {
            Serial.println(“WiFi failed!”);
            return;
            }
            Serial.println(“WiFi connected!”);

            delay(1200);

            netClient = modemXBWF.createClient();
            mqttClient = new MqttClient(*netClient);

            <div>Somehow this code is called. bool DigiXBeeWifi::extraModemSetup(void). I don’t know which line does this. So the broker connection fails.
            I have used this workaround by implementing the Client with just a fake abstract wrapper and preconnect xbee s6b with xctu…
            class XBeeTransparentClient : public Client {
            public:
            XBeeTransparentClient(Stream& s) : _stream(s) {}int connect(IPAddress ip, uint16_t port) override { return 1; }
            int connect(const char* host, uint16_t port) override { return 1; }
            void stop() override {}
            uint8_t connected() override { return 1; }
            operator bool() override { return true; }

            size_t write(uint8_t b) override { return _stream.write(b); }
            size_t write(const uint8_t* buf, size_t size) override { return _stream.write(buf, size); }
            int available() override { return _stream.available(); }
            int read() override { return _stream.read(); }
            int read(uint8_t* buf, size_t size) override { return _stream.readBytes(buf, size); }
            int peek() override { return _stream.peek(); }
            void flush() override {}

            private:
            Stream& _stream;
            };

            </div>

          • #19623
            Sara Damiano
            Moderator

              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.

            • #19624
              Sabin
              Participant

                Thank you for your response.
                I used TinyGSM directly and got into this problem. I was deploying broker locally,, the code on the inside check for dns lookup.. Currently I commented this code out and tinygsm works.
                https://github.com/issues/created?issue=vshymanskyy%7CTinyGSM%7C854

                This is what my full code looks without tinygsm:

                This is how I am implementing tinygsm

                Tinygsm implementation will result in flaky broker connection like this:
                1773954855: New client connected from 144.39.141.49:49164 as ArduinoTempSensor (p4, c1, k15). 1773954865: Client ArduinoTempSensor [144.39.141.49:49164] disconnected: connection closed by client. 1773954865: New connection from 144.39.141.49:49165 on port 1883. 1773954865: Protocol error from 144.39.141.49:49165: First packet not CONNECT (30). 1773954865: Client 144.39.141.49 [144.39.141.49:49165] disconnected: protocol error.

            Viewing 4 reply threads
            • You must be logged in to reply to this topic.