How to control gpio pins of Arduino with internet

Hardware
1

i want to connect to internet with Sim800L and control gpio pins of Arduino.
i searched a lot and found there is a way by using serial connection using Firmata and Arduino Nodes palette, but this way doesn't work when your Node-RED server runs on a IP-Valid server.

my idea is this :
make a switch-node in flows and a http in[get] then with sim800L send a Get request every 10 second to server to check if switch-node is on or off and by reading switch value , control gpio pins of Arduino .

am i right? is this a good way?

2

For GSM you will need a lightweight protocol with some queue and resend features... sounds like mqtt is the best way.
Write or find a firmware for this microcontroller, use a public mqtt service accepting insecure connections (most likely the microcontroller is not able to encrypt mqtt sufficient) and the Node-RED part is trivial.
Nice project ... interesting what you like to switch from far away ... :thinking:

1 Like
3

thanks for your answer , so with quene and resend feature , i don't need to send httpget every several second to check the status of switch-nod? and i have a permanent connectionŘź
my friend has a aviculture and i want to control lights and fans with a 5v relay , so i have to control gpio of Arduino from far away.

4

i searched about mqtt protocol and you are right .
HTTP request opens and closes the connection at each request, while MQTT stays online to make the channel always open between the broker server and clients.

is it good if i use Mosquitto broker next to the Node-RED server? i can set a user/pass for the broker and connect my gsm with this user/pass to broker , is this a secure way ?

5

When you leave your LAN it is tricky. Perhaps take a look at LoRa wan instead ip overt the internet

Long range especially in the field and not automatically exposed to the word.
There was even a open source satellite launched a couple of months ago.

6

I find the more reliable way to do this using GSM, 3G, 4G, etc is to use a mobile phone as a hotspot and connect your device via WIFI (this often means using an ESP device like the ESP32 or the ESP8266).

FWIW, I have tested LoRa and NB-IoT (building a custom tracker) in my area. I found that LoRa and NB-IoT was "spotty" at best. Both were like "ham radio experiments" and were fun to test, but did not provide a reliable connection. If you want to "play with LoRa" that is a different story, but if you want the most reliable service, then using a robust carrier's 3/4/5G network is really the better option.

Eventually, I moved to ESP devices with WIFI and just let them connect to my mobile as a hotspot (for example, in my car or on my motorcycle out in the country side).

The reason for this reliability (at least in my area) is that the big telcos have invested a huge amount of money in 4G since nearly everyone has a mobile phone and uses 4G. Very few people user LoRa or NB-IoT and the service is so "cheap" (NB-IoT and LoRa) at a "hobbyist price", that of course these services will not be a robust as 4/5G.

Hence, if you want a reliable service (at least in my area) the #1 was to go is to use a mobile hotspot connected to the very reliable GSM/3/4G services (soon to be 5G) and use ESP32 modules. I am building a new GPS tracker using ESP32, waiting on some new GPS modules from AliExpress.

In addition, I have tested (extensively) ESP32 v ESP8266 and due to some firmware changes for the ESP32, it is more reliable than the 8266 (which makes sense, because the 32 is an upgrade over the 8266); however, the 8266 works OK.

The different is that with the ESP32 there is a better reset function available and so when your connection is lost, sometimes these ESP devices will not reconnect robustly (the same is also true for LoRa and NB-IoT btw).

One way around this issue is to detect when the connection is lost (with a timer) and then reboot the device in software. The ESP32 has better hooks to do this compared to the ESP8266. I tested this extensively for nearly two weeks in different failure / recovery scenarios.

Hope this helps.

7

Interesting project indeed! The esp32 is a fantastic little piece of device. I have used them for a while and you realize how powerful they are, amazing. There are maybe many possibilities for fw but I have found ESPHome having a lot of great examples for various use so that's where I currently "go digging" when I look for various applications. Just recently I built a GW to control my awnings/shutters where the GW communicates with NR via.....MQTT, works just perfect

I think the idea of using a (cheap) mobile as hotspot and a public mqtt service is great. The ESPHome has ready-made examples of how to configure it for MQTT as well as how to control GPIO's, it is so easy to both work with and upload. Another benefit using the esp32 wifi connected is that you can upload sw changes over the air. As @Christian-Me pointed out, the support for MQTT encryption is still lacking but it supports user and password for authentication

But hey, if we have reached this far, the step to use a (older & cheap) Raspberry Pi and it's GPIO is not too far away. Unless the price is critical

8

ESP32s and ESP8266s costs around $2 to $6 USD (depending on the package), much cheaper than PIs, and of course consume much less power.

Of course, it always depends on the application, but for most GSM/3/4/5G tracking and other apps, we only need an ESP device; and of course they consume so little power, some makers report they work for many months on a single set of batteries (this I have not tested yet).

This picture shows one of my ESP8266 devices in a full dev kit. I paid less than $4 for the entire kit, directly from China and this kit is " relatively expensive" LOL because it is in a developer's package. Barebones ESP devices for production are very small and consume little power:

IMG_9207
IMG_92073888Ă—2916 2.73 MB

MQTT runs great on these devices and if you need encryption, then you can run it over SSL or if that is too much work (to set up all the certs and keys) you can just use symmetric AES (128 or 256 bit) shared secret encryption (that is what i use, BTW).

I have already have working MQTT apps running on ESP devices which encrypt using AES and are decrypted on the server using PHP.

Encryption is not an issue at all with data over MQTT. It's easy to encrypt / decrypt on all devices with AES libs (before and after pub/sub over MQTT). I have working code for this (Arduino, ESP and PHP) and it works flawlessly.

And or course, it is easy to use WIFI on the PI and attach to a hotspot. All of this, it's too easy. I don't recommend LoRA or NB-IoT for apps which are "moving" and need to have reliable connectivity.

When we see "the guy with the swiss accent" on YT doing a LoRa test for 100s of KM in a single "line of site" test, while that make a cool YT video, is it very different (in robust, practical day-to-day use case terms) than a tracking app in car or motorcycle moving along in the country side. I've tested all these, and while it was fun to test, the reliability comes from using the robust 4G/5G networks and connecting to small devices WIFI to our own mobile "hotspots". I've tested them all different configuration and scenarios.

9

Regarding encryption, mentioned above.

Here is a quick write up on this topic, by chance (I forgot about this when replying before sorry. I have a lot of Node-RED running, doing plenty of stuff I already forgotten about, LOL):

10

Hi,

a lot of beautiful insights an thoughts. A few things kept some question marks in my brain .

Why you like to add another hop (node - Wifi - phone - GSM - network) in the communication. The Sim800l is a serial to GSM converter (like the first ESPs where designed as serial to WiFi converters. There origin are GPS car / dog and what not trackes. I agree that in the western world GSM has a good coverage (and in Germany recently they decided before switching off GSM all others (UMTS, 2G ...) will be ditched first to have always a basic phone and small data network)

In a stable design you hopefully don`t need a watchdog (often). And the watchdog sits in your micro (or perhaps even better outside in a dedicated chip. So the quality of the watchdog design has nothing to do with if you are using WiFi or LoRa for your WAN design.

Don't get me wrong I love my ESPs. But to keep an eye on them I desigend my remote-device-table. Especially the nodes in the garden are getting into trouble too often. If there are only sensor nodes it is not a big deal but for actuators or "important sensors" it is. Before you ask I`m using Ubiquiti UniFi APs at home. Depending on the weather (rain = bad) the connection quality results in low uptime rates (as my firmware resets after a certain amount of failed connections). But none of my nodes is able to run longer than around 10 days without a reset.

When it comes to RF communication a often ignored point is antenna design. The ESP (Especially the AIThinker designed modules) comes with a very good designed PCB antenna (I found them better than many china dedicated antennas). If you place the module good in your design of your device you get fantastic reach.

When it comes to encryption I mentioned the (OTA) link between your device (ESP / Arduion / STM32 ...) and your AP ... I only wanted to say that if it is difficult (not impossible) for the ESP32 to do proper encryption I think it is nearly impossible for a small Atmel (Arduino). Perhaps again LoRo is an option because it brings their own encryption

Chris

11

I very happy with how this works, Chris. If you are happy with your ideas, that is fine with me :). I have explained the reasons for my rock solid implementation in detail. LoRa is like a toy. It's not reliable when traveling 100s of km along the roads where I am. NB-IoT is better, but not by much.

Adding a reliable hop is not a problem at all. The networking engineering world is not defined by "hops" it is defined by reliability. If you prefer unstable, spotty LoRa to save a hop, that is your design choice. There is no reason to question my tested, working approach because it differs from yours.

From my testing, my config is much more reliable and stable than a much less reliable connection which breaks "most of the time when moving" with LoRa and NB-IoT. LoRa and NB-IoT are very unstable and not reliable, from my testing in my area. I thought I made this clear. My technique is rock solid, because I have tested all of these (LoRa, LoRaWAN, NB-IoT, and ESP/WIFI/5G) and I know, because I have tested all of the configurations extensively. YMMV.

Regarding encryption and AES-256 message encryption MQTT. It works flawlessly.

I have it working on all devices (ESP, Arduino, LAMP servers) as required.

As mentioned, I am not speaking from "theory". I am speaking from direct experience testing all these configs (LoRA, NB-IoT, ESP/4G, many varieties). Theory is cool, but what works "operationally" well is what I am interested in. I have stress tested these devices under many scenarios (network failures, reboot, loss of signal, loss of power, reboots, crashes). The ESP32 is the best, hands down, and certainly consumes the least power. It is an all around winner in all my tests in real-world conditions in the field.

Of course, YMMV.

Cheers.

12

Please don’t be offended as I’m not offended.

But I still can’t agree to:

There is a use case for every system and as someone said: “the is not such a thing like a bad microcontroller, you have to choose the right one which fits your needs”

I did LoRa experiments before and didn’t had reliable problems at all. The german rail has (had?) many LoRa gateway around (all between 1-5km away my home) any I don’t think that they are playing with toys. Even not that this project spend quite a lot of money on toys:

I stopped my experiments only because I didn’t had currently use of a long range low power network.

When it comes to power consumption the ESP is not known for being the winner. If I compare my battery powered ESP8266s running on a 18650 cell with my thermostats running on 2 AA batteries for 2 years with RF 868Mhz (same band as LoRa) I can say the 868mhz is the clear winner. always available (no long deep sleep periods) and even powering a motor many times during the day is possible.

As before: there are many possible ways and the difficult part is to choose the right one and implement it the best way you can.

13

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.