Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of 
@srgdamiano
Active 2 weeks, 4 days agoForum Replies Created
-
AuthorPosts
-
Yes, those are because of the old firmware. If you’ve got it working, it may not be worth updating, but it should eliminate those work-around.
If you want to use custom SSL certificates, upgrade. The only way to push custom certificates with the old firmware (or with an ESP8266) is to use a python script to write the memory blocks with the new certificate data. And getting that working is much harder than upgrading the firmware. AWS IoT core requires custom certificates.
Are you using the original TinyGSM or the EnviroDIY fork? The EnviroDIY fork is far ahead of the original right now. (It’s on my to-do list to have a proper PR.)
I’d (strongly) recommend updating your AT firmware. The current version of TinyGSM on the EnivroDIY fork expects firmware >= 3.2.0.0. Because of changes in the memory mapping for SSL certificates (and other stuff) around version 3.2, you’ll need to completely re-flash the board with esptools/ESP flash download tools instead of using the AT+CIUPDATE function.
Were you able to connect to your MQTT broker?
It looks like you’re working from the modem component within Modular Sensors. That component wraps TinyGSM and adds physical pin support for power management. But the wrapping makes it a bit confusing because you have to access objects with pointers and creator functions. And if you’re trying to use the ModularSensors master branch as of 8/4/26, it’s broken. (The last release is fine, just not the current master branch.) Until you have your communication set, I would work directly from the TinyGSM example set which is more direct. After you’ve got your communication set, figure out power.
Ah. That example is written for the current “master” branch of the library, not the latest polished release. I’m way overdue for a new release, but there are some bugs I still need to fix.
Try starting from this example instead, which is matched to library release 0.37.0: https://github.com/EnviroDIY/ModularSensors/blob/v0.37.0/examples/DRWI_Mayfly1/DRWI_Mayfly1.ino
**DO NOT** use the current master branch as of 8/4/2026. There’s definitely a bug in for the SIM7080/EnviroDIY LTE module. Usually I keep the master branch functional and try to keep not-actually-working stuff in other branches, but as of today master is broken.
The ESP32 does. It’s also a currently supported product and very widely available. You can get very cheap ESP32 breakout boards in a variety of shapes and sizes. There are several flavors depending on how much power you need, but they can all do a basic secure post request. You could even use the older, even cheaper ESP8266.
If you’re using something else as the “brain” and only want to use the ESP32 (or ESP8266) as a blind modem, flash it with AT firmware and use TinyGSM. Check out the Web Client example for a hand-made post request. This is probably similar to what you were doing with the S6B. If all you need is sever certificate verification, that example should be all you need. If you need client certificate or mutual verification, I wrote up an example here of uploading new certificates to the module. You only need to upload the certificates once.
You can get a lovely ESP32 in Bee format with AT firmware pre-flashed here: https://www.envirodiy.org/product/envirodiy-esp32-bee-wifi-bluetooth/
If you don’t want to use a second board as the brain, there are zillions of examples on the web of people using ESP32’s to do all kinds of cool things. They’re very heavily used in home automation and are quite powerful. Buy any breakout format you want.
No. The S6B (wifi) does not support secure clients.
From your error messages, it looked like you have mismatched versions of libraries. I’m not sure how permissions are set up on your PC, but typically the Arduino libraries would be stored in a personal user folder that you could change at will.
How and when did you download all of your libraries?
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 bymodemXBWF.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.
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”
-
AuthorPosts
