As far as I understand MQTT is only currently possible via wifi to an internet connected AP, is that correct?
If so, would it be possible to run it via Bluetooth to a mobile with the meshtastic app running? I imagine there would be some power savings and secondly the RAK4631 I am using doesn’t have WIFI.
The plan is to connect one of my solar powered RAK4631 nodes to the internet this way from a mountaintop where there is cellular service.
Any other suggestions on how to achieve this would be very welcome. I’ve made a raspberry pi based MQTT broker so far but am a bit stuck as to how to connect the RAK4631 to the internet right now.
From what I can tell, MQTT is currently tied to the TCP/IP stack of the underlying platform (so on TTGO, which uses the ESP32, this is the TCP/IP over Wi-Fi stack in the ESP-IDF.)
Since TCP/IP isn’t supported out-of-the box for the NRF52xxx which the RAK4631 is based on, there’s quite a bit of design work required for your specific use case, along with the additional implementation work. (Neither will be simple, I’m afraid.)
Here are some sketches of ways to accomplish what you’re looking for:
The most direct translation of your request here: add some networking stubs for accessing MQTT via Bluetooth as a transport for a cell phone’s data connection, tunneled through the Meshtastic phone app.
This has a pretty big disadvantage in that there’s going to be a fair amount of custom stuff for marshalling MQTT over the Meshtastic Bluetooth protocol. Both the device and the phone app would require a fair amount of code to support something custom like this.
Advantage: Resources required on the NRF52 would likely be minimal.
The advantage of this is that it seems that there’s a fair amount of (NRF52 community) interest in doing that. This means there might already be an implementation for it, and almost zero code will be required on the phone! I didn’t look, though.
Disadvantage: if nobody has done it, it’s a fair amount of work. Also, I’m not sure how much it’ll consume of the space on the NRF52.
Just spent some time reading about this. Not an option. BLE does not support PAN; that’s only available for Bluetooth classic, not BLE, and the NRF52 family only supports BLE. Unfortunate. For anyone looking, BLE has a profile called IPSP; however, current Android and iOS implementations don’t appear to support it for tethering (unsure).
Run a more powerful node, like a Raspberry Pi 3, to interface with NRF52 over USB or BLE. You’ll run the Meshtastic API over the serial port (or BLE) to talk to your node, and then have the Raspberry Pi 3 deal with connecting to the internet (cell modem hat?) and handling MQTT.
Disadvantages: more parts, more cost, higher power consumption. You’ll need to write some code to interface with the Python API and an MQTT client.
Advantages: Quite possible as you’re no longer constrained to the NRF52xxx / ESP32 microcontroller’s limited resources. Agnostic of what platform (ESP32/NRF52) you’re using for Meshtastic.
Add a Wi-Fi module to your deployment, and add support for the MQTT client to interface with it.
There’s a lot of reasons this sucks, and you can probably figure most of them out. Among them includes power consumption, additional code required on the device, space required on the device (maybe offload the TCP/IP stack?)
Power consumption was my main concern, hence why I would like to avoid WiFi.
There is an LTE module available for the RAK 4631 which would provide internet connectivity without BLE or WIFI. RAK 5860 WisBlock LTE module
Would that circumvent the problem? I’ve ordered one already but not sure I’ve got the skills to get it to work within meshtastic. I previously built a sms controlled relay with a module that used AT commands and an arduino but meshtastic is somewhat more complex than that.
In any case, I think a RAK4631 with a RAK5860 and solar charging could make a great base station for connecting a remote network to the internet.
From what I recall, LTE can also be very power hungry, although it depends greatly on the quality of the link to the LTE base station – sometimes with better power efficiency than Wi-Fi.
The RAK5860 would be similar to the last option in some ways. Optimizing for power, the RAK5860 would probably be your best option, as its product description indicates that it has support for an “Quectel AT” command set and a little bit of searching hints that Quectel modules like BG96 sometimes support offloading the entire TCP/IP stack. If the RAK5860 is similar to the BG96, for your purposes, this is a very good thing as it would put the burden of networking on the LTE modem module, the power consumption would be pretty close to the minimum possible for your goal, and the code required for Meshtastic should only be moderately difficult. Your task would then be to interface the MQTT connection to the RAK5860’s AT interface for TCP/IP. That’s a little bit tougher than something like a Raspberry Pi 3 where all the drivers handle networking, and you can take your pick for MQTT clients, but not infeasibly difficult – just a matter of setting up the RAK5860, and having it relay TCP data to/from the Meshtastic nRF52 module.
From what I understood these NB-IOT LTE modules are optimised for low power consumption, and this should be even better than having a mobile attached with all the overhead that a modern mobile brings with it. In my case I have good connection from the top of a mountain, but absolutely no signal in the valleys below.
Starting up the LTE module once every 20 min or so to just send messages stored in the interval might be used to further conserve energy.
RAK has some example code here RAK5860 TCP code to send GPS data from the module to a hologram TCP server. Could this serve as a starting point?
Agreed. A cellphone will likely consume much more power than this NB-IOT LTE module.
Yes, I think the WisBlock 5860 TCP example code is a good place to start.
I’m making some guesses here; it appears that theMQTTcode in Meshtastic depends on PubSubClient. If this is the right one, then you’ll need to implement a few functions for accessing TCP/IP via Arduino.
Lines 91 and 180 are the meat-and-bones you’d need for offloading TCP/IP to the module. Most of setup() will probably be needed, and you’d likely need to bring in most of the “AT commands” up to line 91, to be sent from the Meshtastic device to the LTE module via the serial port, and the LTE module would be attached to that. Line 91 would need to be issued on Client::connect(). Something similar to line 180 would need to be issued on send()/Client::write() (links are to the usages of those symbols in the PubSubClient code). The modifications you’d need to make will need to be an implementation of Arduino’s Client library.
A little bit more reading suggests UIPEthernet might be useful. It’s an example of how to implement TCP/IP communications for a ENC28J60 and linking it to Arduino. The linkage happens via #define EthernetClient UIPClient in ethernet_comp.h; you’d want something similar, likely changing it to #define EthernetClient LTEClient, and ripping out a lot of the code of UIPClient and implementing your own LTEClient containing all the AT commands to send to the RAK 5860 module.
The RAK 4631 appears to have two UART ports. You should check how the WisBlock Base connects the RAK 5860 LTE module to the RAK 4631, and use the appropriate UART port on the RAK 4631 when writing your UIPEthernet-derived driver.
