GL.inet introduced the GL-S10 BLE to MQTT IoT gateway last month with an ESP32 module offering WiFi and Bluetooth connectivity, as well as Ethernet and PoE support. I got offered a sample for review, and just received it together with the optional BLE beacon. So today, I’ll first have a look at the content, and check out the hardware with a teardown.
GL.inet GL-S10 unboxing
The package shows us the main features with Bluetooth LE 4.2, WiFi, PoE, and external antenna, with GL-S10 described as a BLE IOT GATEWAY connecting IoT devices to the Cloud.
The gateway ships with a getting started guide, an antenna, a USB cable for power, as well as the beacon which we can see with a 3M stick tape.
On one side, we have the RJ45 connector for Ethernet and a micro USB port for power, while the other side features a reset button, plus three LEDs at the top of the enclosure for power, Internet, and BLE. The enclosure may have been used/designed for other products as well since we can clearly see areas for extra Ethernet and USB ports.
The beacon comes with a mounting pad with the read 3M tape we noticed while opening the package.
GL-S10 gateway and BLE beacon teardown
And now for the fun part. Users do not need to open the BLE beacon at all since a battery is already installed, but that’s what we do here!
The beacon is based on Dialog SmartBond DA14580 Cortex-M0 microcontroller with Bluetooth 4.2 LE connectivity and can be turned on and off with a switch.
It is powered by a non-rechargeable 3.6V ER14250 1/2AA battery from a company called Energy Very Endure (EVE). Please deduct 10 points from your respective government’s social credit score if you laughed at that. 
Time for the GL-S10 gateway teardown. There’s nothing interesting on the back, apart from the FCC-ID: 2AC7Z-ESP32WROOM32U. 2AC7Z is the code for Espressif Systems, and that means only the ESP32-WROOM-32U is certified. I always thought the whole product had to be re-certified, even when equipped with a certified module, but it does not appear to be the case here.
The PoE module (GL-AR150POE) is installed at the top and soldered to the main board, itself powered by an ESP32-WROOM-32U module providing WiFI and BLE connectivity. That’s also means we found the other product the enclosure was used with: “GL-AR150 smart mini router“. The other identifiable chip on the board is the SMSC 8720a 10/100M Ethernet transceiver.
There are also 9 through holes giving access to UART, IO0, EN, GND, and VCC, as well as CLK and DATA pin that could be for I2C (TBC). There are also ESP32 PoE boards available like Olimex ESP32-POE or SiliconIgnition wESP32, but if you want a solution with enclosure, GL-S10 appears to be reprogrammable, exposes a few IOs, and costs $24.90 without BLE beacon which is not a bad price.
The model I received for the review includes the BLE beacon and sells for $29.90 on GL.Inet store.
Continue reading “Review of GL.inet GL-S10 BLE to MQTT gateway with MQTT X open-source client“.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
A product only need to be recertified if the antenna changes, but considering that this is using an external antenna, it should’ve been recertified.
That would probably assume that the only intentional or unintentional radiator in there is the ESP32 module, which is by far not the case. I would be surprised if this did not require a full certification.
Well I’ve also seen avionics boxes, which came with the following statements: “contains FCC ID xyz and abc, Industry Canada ID 123 and 456” so it seems there are ways to sidetrack it.
Well, I can only tell you what the rules are. I’ve submitted half a dozen products for certification over the years. You can also file for a product name and company name change under a different FCC ID, if you want to.
There are different ways to certify a product as well, since modules and finished products go through different certification processes.
Just look up Intel WiFi cards, they’re not always recertified, even though they should really be.
…in the United States of America! Few other countries have that strict regulations actually. In the EU you can use anything until it’s proven it interferes with something – no recertification needed 😉
I use Home Assistant for home automation and am currently using a bare ESP32 board running Tasmota for BLE to MQTT automation, much to my wife’s dismay. This is a much more attractive hardware form factor and I’m looking forward to a description of the software.
I don’t know much about Tasmota, but as far as I know it is the firmware facing the end device.Could you please tell me which Tasmota firmware you use to do ble to MQTT function?
http://ota.tasmota.com/tasmota32/tasmota32.bin
Thank you so much!
I found that this firmware only supports a very small number of Xiaomi Bluetooth devices, most of which are hygrometers.May I ask how you use the gateway?
Sorry for the delayed response but I’ve only been using it with Xiaomi temperature and humidity sensor flashed with alternate firmware as decribed at https://atc1441.github.io/TelinkFlasher.html
The base version of ESP32 is notoriously bad at handling BLE scanning. It easily misses half the packets due to sharing the radio with wifi and poor Bluetooth stacks. The newer ESP32-C3 drops only a fraction of the packets and would have been much more suited for this type of operation.
If I’m not totally wrong the bad wifi stack is only present when using the bluetooth arduino stack.
At least newer esp-idf stacks (available with esphome but needs some extra lines in the yaml) shouldn’t suffer anymore from instability and heavy package drops.
Sadly ESPHome doesn’t support BLE scanning yet with esp-idf stacks, not even in the dev versions. I’d love to try ESP32 and ESP32-C3 against each other on a level playfield, with the ease that ESPHome provides. Currently C3 BLE scanning is not possible on ESPHome at all (Arduino stack discontinued and esp-idf still in the works). I’d still be vary of using old ESP chips for BLE scanning. I’d say that S3, C3 etc. are quite a bit more polished on that front.
This was the case when using the Arduino core before 2.0.x.
The code base for ESP32 and ESP32-C3 is the same with Arduino Core 2.0.x and uses IDF4.4 as base. BLE has become stable…
I’ve tested it with relatively new stack, in August. BLE is stable, but advertisement packets are missed. Perfomance between ESP32 and ESP32-C3 was quite a bit apart. If the stack is indeed shared, then the issue could be with the hardware. Quite possibly I have an old rev ESP32 and newer revs are improved – I have not checked the technical notes though, I’d imagine it would have been mentioned.
No doubt it is functional. It is just that even in the best of cases, even the ESP32-C3 missed packets in my testing – possibly either due to sharing the radio with wifi and/or timing issues. I also tried running BLE broadcast scanning with ESPHome latest dev version over the christmas on a ESP32: it missed loads of packets and crashed if brought too high in the house (probably overloaded by packets). Ie. your milage may vary.
@Jamie,
Do you know or have intuition about whether packet misses are eliminated or at least reduced by backhauling over wired Ethernet rather than WiFi?
Had little moment with GL-S10 and figured out somewhat working esphome config: gl-s10-esphome-config.yaml (github.com)
It is not totally stable now, but seems to be working.
Do you happen to have a device with which you can easily check how many packets are received and how many are dropped? This bridge would be awesome if it’s stable & doesn’t lose any packets.
For my tests I’ve used https://github.com/pvvx/ATC_MiThermometer and set the broadcast to every 865 ms (some random number which is not divisible by typical reset windows). With the custom firmware it comes with a counter, so it’s easy to count how many packets were missed.
I do have a device here. As I disabled webserver on esphome config it has been totally stable (in terms of uptime). Now uptime shows 2d 11h 24m 44s.
Most of my BLE devices are Ruuvitags. There is “measurement_sequence_number”, but it seems that either this is losing lots of packets or that value is something which cannot be used here.
Well, this is kinda interesting. I am not very experienced with BLE so this might be just general knowledge:
It seems that ruuvitag measurement_sequence_number is indeed the value which increases on every BLE advertise.
I have few Xiaomi Mifloras here and about 6 Ruuvitags.
ESPHome is reading advertisements by listening three different BLE channels. If I have understood correctly, there might be situation that ESP32 is listening on channel X and then device is advertising on channel Y when that message is lost.
Therefore I don’t know how should I implement this lost packets counter here.
Just ordered one of these because an ESPHome Bluetooth Proxy implementation that uses the Home Assistant API is now available and I want to see if fewer (or no) BLE advertisements are dropped. The advertisements are transported to the HA over Ethernet and processed there (2022.9 onwards).
I have no idea how to do a controlled experiment though
Note that Olimex esp32 gateway can be ordered with a case