Octopus Indoor Air Quality Monitor

Im Blogbeitrag #IoT OCTOPUS hatte ich die Erfassung der #Luftqualität mit den on-board Mitteln des #Octopus-Boards vorgestellt.

Der ESP8266 bietet WLAN, wodurch eine Menge von Möglichkeiten besteht, die erfassten Daten im Internet verfügbar zu machen.

Eine weitere Möglichkeit besteht durch Einsatz des im Bild gezeigten LoRaWAN-Feather-Wings oder eines hierzu kompatiblen Moduls wie dem Adafruit LoRa Radio FeatherWing und der Übertragung der Daten an einen #LoRaWAN Network Server (#LNS) und einer anschließenden Visualisierung.

Ich bin hier diesen Weg gegangen und habe die erfassten Daten – iAQ, Temperatur und relative Luftfeuchtigkeit- an den TTN LNS gesendet.

Allerdings können bei Einsatz des LoRaWAN-Feather-Wings die Neopixel auf dem Board nicht ohne einen Hardware-Patch verwendet werden. GPIO13 des ESP8266 wird als MOSI-Leitung für das SPI-Interface und als DIN für die WS2812 verwendet. Eins geht nur, deshalb verzichte ich auf die Neopixel on-board.

Zur Visualisierung sende ich die erfassten Daten über einen Webhook an die Visualisierungsapplikation von Datacake. Das betreffende Programm finden Sie auf GitHub unter Octopus_TTN_OTAA.

Der folgende Screenshot zeigt das Datacake Dashboard für den PC. Es gibt auch ein reduziertes Dashboard für Mobil Devices.

Die visualisierten Daten können Sie über den nebenstehenden Public Link abrufen.


2024-01-22/CK

Solar-buffered WisBlock Node

Autonomous operating sensor nodes need wireless communication and wireless powering.

For a battery-powered IoT node buffered by a solar cell, I use the WisBlock ecosystem to build this IoT device. The RAK19007 WisBlock Base Board 2nd Gen is an excellent approach to use as a baseboard for WisBlock Core and WisBlock Sensor modules. RAK19007 supports low-power battery power supply, lithium (LiPo) battery charging, and solar panel charging of a connected LiPo battery.

RAK4631-R is a low-power WisBlock Core based on nRF52840 MCU and a SX1262 LoRa chip offering BLE and LoRaWAN. RAK4631-R is equipped with RAKwireless Unified Interface V3 (RUI3), significantly simplifying software creation for IoT nodes. For the programming of the application, I use the RUI3 API.

The battery discharge must be balanced to ensure the autonomous operation of such an IoT node. The RAK19007 baseboard can recharge the battery by connecting it to a solar cell and sufficient sunlight.

I use an RAKBox-B5 Transparent Acrylic Enclosure to operate the test device safely, bearing in mind that it is not weatherproof. An advantage is that this enclosure already has a battery holder for a LiPo 18650. I like to use this type of LiPo battery because, due to the shape of the case, they are more easily manageable than conventional LiPo batteries.

We get the device under test with these specifications, as shown in the following image.

Device under test

RAK19007 does not have a power management system like AXP192 or similar; therefore, only the available voltages can be used to check the LiPo battery’s charge level.

The battery voltage VBAT is measured using a voltage divider available on analog input AIN0 of the RAK4631-R MCU. For measuring the Green Power voltage, analog input AIN1 is available on the J11 Header of the RAK19007. A voltage divider is also required there.

In a practical test, I will record the two voltages Vsol and Vbat and use them to form the quotient State = Vsol/Vbat. If Vsol > 1, the battery is charged, and the solar cell supplies the device. If Vsol < 1, the battery must source the device and will be discharged.

Different communication solutions are available for an autonomous working IoT node. I use LoRaWAN here and will test NB-IoT as an alternative where no LoRaWAN coverage exists.

LoRaWAN Communication of IoT Node

The test has been completed and shows that the solar cell easily compensates for the low power requirement of LoRaWAN communication during the day.

NB-IoT Communication of IoT Node

I took a two-step approach.

First, I put the NB-IoT Communication into operation without paying attention to the power consumption. Here, the modem is permanently switched on. The following daily battery voltage curve shows the expected result.

On a sunny day, the recharge can compensate for the capacity loss over the day. This compensation is not possible on cloudy or rainy days, and a lost connection follows.

As expected, we have to reduce the power consumption while the device is not sending data. This was implemented for the LoRaWAN node from the beginning. This brings us to the 2nd step.

Based on the program structure of the LoRaWAN application, the NB-IoT application implements a timer-controlled reboot and uses the loop() function for going to sleep only. This means that all program activities have to be placed into the setup() function. The setup() has to implement the following functionality:

  • Setup serial interface for the console
  • Setup LoRa P2P (only when LoRaWAN was running and connected to LNS before)
  • Setup reboot timer and its handler
  • Setup serial interface to RAK5860 (BG77 modem)
  • Initialization of ADC for voltage measurement
  • Initializing and connecting the modem
  • Connecting HiveMQ MQTT broker
  • Reading voltages of solar cell and battery
  • Build and send MQTT message
  • Switch off modem
  • RAK4631-R going to sleep

This procedure is finalized in less than a minute, and the entire device goes to sleep. After four more minutes, the timer reboots the device.

Current consumption

In very different weather conditions, measurements taken over the last few weeks show that solar radiation balances the battery capacity.

The device is running since 12/2023. Here, you can find the actual data of the RAK Sensor Node with NB-IoT Communication Public Link.


2023-12-02/CK

2025-05-05/CK changed

#IoT OCTOPUS

Typische IoT-Projekte erfordern Kommunikation, Sensoren und ein Energiemanagement, welches nach Möglichkeit dann auch Batteriebetrieb ermöglicht. Guido Burger entwickelte den Octopus, der die Dinge. die einen IoT-Knoten ausmachen, in einem Kit zusammenfasst.

Technische Spezifikationen:

  • ESP8266 (ESP-12F)
  • Low power options (20uA in Deep Sleep)
  • 2 x RGBW NeoPixel on board
  • 2 x Grove Connectors (1 x analog, 1 x I2C)
  • Adafruit-kompatibler FeatherWing header
  • Bosch BME680 Sensor (Gas/VOC, Humidity, Barometer, Temperatur)
  • Credit Card Größe

Durch den Espressif ESP8266 steht eine WiFi-Schnittstelle für den Internet-Zugang zur Verfügung. Neben dem BME680 Sensor on-board stehen mit den Grove Konnektoren und dem Feather Wings Header flexible Erweiterungsmöglichkeiten zur Verfügung.

Der Octopus hat durch die genannten Eigenschaften einen breiten Einsatz in der Ausbildung gefunden. Ich möchte an dieser Stelle auf zahlreiche Veröffentlichungen des Umweltcampus Birkenfeld der Hochschule Trier und den Blogbeitrag Mut zu MINT verweisen.

Die Programmbeispiele im Ausbildungsumfeld sind oft in Scratch bzw. ArduBlock geschrieben. Für alle diejenigen, die die Programmierung des Octopus außerhalb von Scratch erkunden wollen, kann die Programmierung auch in C++ mit Hilfe der Arduino oder PlatformIO IDE oder in MicroPython vorgenommen werden.

Der Beitrag COVID-19 Prävention: CO2-Messung und bedarfsorientierte Lüftung und eigene frühere Arbeiten zur Messung von CO2 und VOC haben mich veranlasst, den Gedanken der CO2-Ampel noch mal aufzugreifen. Der Octopus hat dazu bereits alles an Bord.

Der BME680 Sensor ermittelt die Daten zur Erfassung der Luftqualität gemäß den Definitionen von Bosch.

Ich verwende die Neopixel auf dem Bord, um eine farblich auf die oben gezeigte Tabelle abgestimmte Anzeige zu erstellen. Zwei Beispiele sollen das Ergebnis verdeutlichen.

iAQ 58
iAQ 162

Ich habe die Programmierung mit der Arduino IDE vorgenommen. Das betreffende Programm selbst finden Sie auf Github unter https://github.com/ckuehnel/Arduino2023/tree/main/ESP8266/Octopus_CO2_Ampel.


2023-12-11/CK

ideaSpark Nano V3.0

Der Arduino Nano ist ein beliebtes Arduino-Board mit einer kompakten Bauform. Zahlreiche Anwendungen zeigen den breiten Einsatz dieses Boards. Auch der Arduino Nano selbst unterliegt diversen Modifikationen, wie es die Arduino Nano Family zeigt.

Von ideaSpark gibt es einen Nano V3, der bis auf den Footprint zum Arduino Nano V3 kompatibel ist, aber zusätzlich ein OLED mit 132×32 Pixeln on-board aufweist.

Die Power-LED ist leider sehr hell, was als störend empfunden werden kann. Das Anpassen des Vorwiderstands ist die beste Lösung, ein Abkleben der LED die einfachste.

ideaSpark Nano 091 V3 mit abweichendem Footprint

Die Programmierung unterscheidet sich nicht von der eines Arduino Nano mit über den I2C-Bus angeschlossenen OLED mit SSD1306- Controller.

Bei den bekannten Online-Shops (u.a. hier) ist das Board mitunter für weniger als € 7.00 zu haben.

ideaSpark Nano 091 V3

Für die Inbetriebnahme können Sie die beiden Anwendungen IdeaSpark_HW und IdeaSpark_U8g2Logo verwenden.


2023-09-23/CK

Einfache Handmessgeräte mit M5StickC

M5StickC und M5StickCPlus sind mit Espressif’s ESP32 und einem LCD ausgestattete kleine, tragbare Computer. Sie verfügen über eine Reihe von Sensoren und Anschlüssen, die sie zu einem vielseitigen Gerät machen, das zusätzlich BLE- und WiFi-Kommunikation ermöglicht.

Die Unterschiede zwischen den beiden Varianten habe ich im Blogbeitrag https://ckarduino.wordpress.com/2020/09/12/m5stickc-plus-vs-m5stickc/ beschrieben.

Die folgenden Bilder zeigen beide M5StickC-Varianten und den passenden „Handgriff“, der einen LiPo-Akku 18650 mit 2200 mAh aufweist. Über einen USB-Typ-C-Anschluss kann dieser Akku geladen werden.

Für ein Messgerät wichtig ist die zur Verfügung stehende Sensorik. Hier bietet M5Stack eine Reihe sogenannter Hats an. Das sind kleine steckbare Module, die einfach oben am jeweiligen M5Stick angesteckt werden können. Die folgenden Bilder zeigen die aktuell angebotenen Hats:

Im Blog hier hatte ich Anwendungen zur Objektzählung mit PIR-Sensor und zur berührungslosen Temperaturmessung mit NCIR-Sensor vorgestellt.

Im Arduino-Handbuch sind dann noch Temperaturlogger mit DS18B20 zur Messung der Wassertemperatur in 1 m Wassertiefe und mit einem ENV Hat zur Messung der Umgebungsbedingungen aufgenommen worden. Von den ENV Hats gibt es mehrere Varianten, die sich durch die eingesetzte Sensorik unterscheiden.

Obwohl das LCD des hier verwendeten M5StickC (0.96 inch, 80*160 Colorful TFT LCD) durchaus gewissen Einschränkungen unterliegt, zeigt das nebenstehende Bild eine durchaus brauchbare Anzeige für Temperatur und relative Luftfeuchte und den barometrischen Druck. Kleiner dargestellt sind die Angaben zum Ladezustand mit Batteriespannung Vbat und Ladestrom Ichrg. Wird die dem Nachladen dienende USB-Verbindung getrennt, dann kennzeichnet ein negativer Strom Ichrg das Entladen des Akkus. Für Batteriespannung unter 3.5 V wird diese Anzeige dann auch rot geschaltet.

Mit dem etwas größeren LCD des M5StackCPlus (1.14 inch, 135*240 Colorful TFT LCD) bekommt man etwas mehr Gestaltungsspielraum für das Userinterface.

Mit dem DAC- bzw. ADC-Hat lassen sich noch die Signale beliebiger weiterer Sensoren abfragen und mit dem RS485-Hat könnte bspw. ein Modbus-RTU Client abgefragt werden.

Wem das noch nicht reicht, der bekommt mit dem Prototyping Hat noch die Möglichkeit, einen eigenen Hat aufzubauen.

Da von M5Stack eine Vielzahl von Sensoren mit einem Grove-Interface angeboten wird, könnte der Prototyping Hat beispielsweise mit einem Grove-Konnektor ausgestattet werden und es erschließen sich zahlreiche weitere Möglichkeiten.

Prototyping Hat

Der im Blogbeitrag CO2-Monitor mit M5StickC Plus & Sensirion SGP30 vorgestellte CO2-Monitor könnte so auch als Handheld-Device ausgelegt werden.

Welche Ideen haben Sie für ein solches Handheld-Messsystem? Teilen Sie diese gern mit uns.


2023-08-17/CK

Arduino Nano ESP32

Der Arduino Nano ESP32 ist eine sehr erwartete Erweiterung der beliebten Arduino Nano Familie. Das kompakte Nano-W106 Modul von u-Blox weist den leistungsstarken ESP32-S3 auf, wodurch viele IoT-Aufgaben einfach lösbar werden.

Arduino Nano ESP32

Das Datenblatt ist auf der Arduino Website unter https://docs.arduino.cc/resources/datasheets/ABX00083-datasheet.pdf zu finden.

Um einen Eindruck von der Performance des Arduino Nano ESP32 zu bekommen, habe ich den CoreMark Benchmark laufen lassen. Das Ergebnis zeigt den beachtlichen Wert von 450.92, der natürlich nichtzuletzt der hohen Taktfrequenz des ESP32 geschuldet ist.

Auf der Website https://ckarduino.blog/benchmarks/ sind weitere Benchmarks zum Vergleich zu finden.


2023-08-04/CK

Mobile Datenerfassung

Im Blogpost Mobile Datenerfassung über LTE-M hatte ich Hard- und Software eines LTE-M-Knotens beschrieben, der GPS-Daten sowie Messwerte von Temperatur- und Luftfeuchtigkeit bereitstellt. Bedingung für diese Art der Datenerfassung ist eine IoT-SIM-Card.

Nutzt man sein Mobiltelefon als Hotspot, dann kann man auf diese spezielle SIM-Card verzichten und mit gegebenenfalls vorhandenem Equipment bereits diese Aufgabe lösen. Beim Einsatz im Fahrzeug kann die Einrichtung über USB mit Spannung versorgt werden, so dass dem Aspekt des Stromverbrauchs erst einmal weniger Priorität eingeräumt werden muss.

Beim LilyGo SIM7000G kann der ESP32-WROVER nicht nur als steuernde CPU verwendet werden, sondern auch die WiFi-Verbindung zum Mobiltelefon herstellen, das hier als Hotspot dient und die Verbindung ins Internet sichert.

LilyGo SIM7000G

Vom SIM7000G-Modul wird hier nur die GPS-Funktionalität verwendet, denn es ist ohnehin nur NB-IoT und nicht 4G tauglich.

Außerdem schließe ich wieder eine M5Stack ENV.II Unit zur Erfassung von Temperatur und Luftfeuchtigkeit an und bin damit in der Lage, mit Hilfe der GPS-Daten die Koordinaten des betreffenden Standorts und die Geschwindigkeit, mit Hilfe der Daten des ENV.II Sensors Temperatur, Luftfeuchtigkeit und barometrischen Druck (hier nicht verwendet) und die Batteriespannung des 18650 LiPo Akkus zu messen. Die erfassten Daten übermittle ich via MQTT an den Public Broker von HiveMQ (https://www.hivemq.com/demos/websocket-client/).

Im folgenden Screenshot (Bild links) ist der statische Einsatz (sp(ee)d = 0.0) des Sensorknoten mit Spannungsversorgung durch USB gezeigt. Das Bild rechts zeigt einen Screenshot vom Mobiltelefon mit praktisch identischem Inhalt. In der Statuszeile sind der Hotspot und die 4G-Verbindung ins Netz rot markiert.


Um das Mobiltelefon nicht unnötig vom WLAN zu trennen, habe ich das TP-Link M7350 WiFi-LTE-Modem getestet.

Mit einer SIM-Karte von Things Mobile erhält man in der DACH-Region die folgende Netzabdeckung:

Austria (A)

Germany (D)

Switzerland (CH)

4G resp. LTE ist in allen drei Ländern verfügbar und somit kann das Mobiltelefon wieder seinem ursprünglichen Zweck zugeführt werden und das TP-Link M7350, mit einer SIM-Card von Things Mobile ausgestattet, übernimmt die Verbindung ins Internet.

Nach Installation der SIM-Card und Aktivierung des Roamings ist das Modem betriebsbereit.

Im Programm TTGO_GPS_MQTT_WiFi.ino sind nun noch die WiFi-Zugangsdaten anzupassen und das Programm meldet sich über die Console wie folgt:

Starting TTGO-GPS-WiFi-MQTT Client...
Initializing...

Connecting to TP-Link_0447
MAC: 24:6F:28:D0:18:98
........
WiFi connected
IP address: 192.168.0.183
Initializing modem...
SHT31 Heater Enabled State: DISABLED

Initialization finished.

...

Vbat  =     0 mV
SHT31  Temp  = 28.72 *C SHT31 Hum.   = 48.81 %rH
BMP280 Temp  = 28.98 *C BMP280 Press = 968.90 hPa
USB powered device
Count = 1
Count = 2
...
Count = 10
Count = 11
Count = 12
The location has been locked, the latitude and longitude are:
latitude:47.191994
longitude:8.814975
speed:0.0
altitude:399.3
GNSS satellites used:20
{
  "node": "TTGO-LTE",
  "lat": "47.191994",
  "lon": "8.814975",
  "alt": "399.3",
  "spd": "0.0",
  "usat": "20",
  "temp": "28.7",
  "humi": "49",
  "vbat": "USB powered"
}
Message length = 186
Connecting to broker.hivemq.com success

Wie die folgenden Screenshots zeigen, kommen die Daten über LTE und MQTT zu Datacake zur Visualisierung.

Die resultierende Datenrate kann anhand der Ausgaben auf dem Display des TP-Link M7350 ermittelt werden. Über einen Zeitraum von vier Stunden wurden 168 KB an Daten versendet. Hochgerechnet ergibt das einen Tagesdurchsatz von ca. 1 MB, was durch die Betrachtung über mehrere Tage bestätigt werden konnte.

Bei der Inbetriebnahme habe ich bei der Spannungsversorgung des Modems über ein USB-Port meines PCs festgestellt, das ein massiver Datendurchsatz von nahezu 100 MB am ersten Tag erfolgte. Nach dem ich die Spannungsversorgung über ein USB-Netzteil (keine Datenleitungen) vorgenommen habe, war der Datendurchsatz wie oben beschrieben.


2023-08-21/CK

Arduino UNO R4

Arduino UNO R4 ist in den Varianten Minima und WiFi erschienen und entsprechend medial begleitet worden.

Arduino UNO R4 WiFi Top View

Die Bewertung im Netz ist jedoch durchaus kontrovers, was vor allem die Kombination RA4M1 Mikrocontroller von Renesas (Cortex-M4) und ESP32-S3 WiFi Modul anbelangt. Anhand des Datenblatts zum Arduino UNO R4 kann sich hier jeder seine Meinung bilden.

Ich habe in einem ersten Schritt zwei Aspekte untersucht – die Performance des eingesetzten Haupt-Prozessors RA4M1 mit einem CoreMark Benchmark und die Charakteristik des DAC-ADC-Subsystems.

CoreMark Benchmark

Die Cortex-M4 kompatible CPU wird im Arduino UNO R4 mit nur 48 MHz getaktet, weshalb ein CoreMark Ergebnis von 81.81 nicht verwundert. Mit 1.704/MHz liegt die Renesas CPU absolut im Cortex-M4 Erwartungsbereich.

Der im Wifi-Modul eingesetzte ESP32-S3 übersteigt diesen Wert bei Weitem.

CoreMark Resultat für Arduino UNO R4 WiFi

Auf der Seite https://ckarduino.blog/benchmarks/ finden Sie eine Übersicht zu Benchmark-Resultaten verschiedener Mikrocontroller von 8-Bit biszu 64-Bit.

DAC-ADC-Subsystem

Der RA4M1 Mikrocontroller von Renesas weist ein komplexes DAC-ADC-Subsystem einschließlich Operationsverstärker und Komparator auf.

Die folgenden Auszüge aus dem RA4M1  Datenblatt zeigen die zu erwartenden Resultate.

12-Bit ADC Kennwerte – Auszug aus dem Datenblatt
12-Bit DAC Kennwerte -Auszug aus dem Datenblatt

Grund genug die Charakteristik des DAC-ADC-Subsystems etwas genauer zu betrachten. Die Vorgehensweise ist vergleichbar zum Test beim ESP32 (https://ckblog2016.net/2018/03/03/esp32-adc-dac/).

Obwohl der ADC eine Auflösung von bis zu 14 Bit aufweist, untersuche ich ausgehend vom DAC die 12-Bit Option.

Für einen Test „über alles“ wird vom DAC (A0) eine analoge Ausgangsspannung bereitgestellt, die dann vom ADC (A1) gemessen und über die Console zur Anzeige gebracht wird. Es genügt also eine Verbindung der beiden Anschlüsse A0 und A1 am Arduino UNO R4 WiFi.

Die beiden folgenden Bilder zeigen die Auswertung der ermittelten Daten.

Die DAC-ADC-Kennlinie übermittelt erstmal nur einen Gesamteindruck von der Linearität des Subsystems. Beim ESP32 war das Verhalten deutlich schlechter.

DAC-ADC-Kennlinie

Die Fehlerfunktion zeigt größere Abweichungen nur an den Bereichsenden, die allerdings im Rahmen der Specs liegen. Über einen weiten Bereich zeigt das Subsystem hervorragende Werte.

Fehler DAC-ADC

Alles in allem ist das DAC-ADC-Subsystem für die meisten Anwendungen sehr geeignet.

Fazit

Mit dem Arduino UNO R4 WiFi liegt ein direkter Nachfolger für den Arduino UNO WiFi Rev2 und den Arduino UNO generell vor.

Die dort eingesetzten 8-Bit Atmel AVR werden durch ein 32-Bit Cortex-M4 Derivat abgelöst und das verspricht eine Steigerung von Ausstattung und Performance.

Die Zeit wird zeigen, inwieweit der „Neue“ von der Community angenommen werden wird.


2023-07-04/CK

Efento NB-IoT Devices

IoT-Devices auf Basis von LoRaWAN benötigen eine entsprechende LoRaWAN-Abdeckung durch einen Provider oder ein eigenes Gateway, um die über LoRa übertragenen Daten über eine Internetverbindung an den betreffenden LoRaWAN-Server zu senden.

Gibt es keine hinreichende LoRaWAN-Abdeckung und ein eigenes LoRaWAN-Gateway kommt, aus welchen Gründen auch immer, nicht in Frage, dann bieten sich die zwei Mobilfunktechnologien NB-IoT oder LTE-M (auch CAT M1 genannt) an. Einen Vergleich der beiden Technologien finden Sie u.a. bei 1NCE.

1NCE ist ein globaler Anbieter von IoT-Konnektivitätslösungen. Sie können von 1NCE eine SIM-Karte kaufen, die über eine Laufzeit von 10 Jahren oder eine bestimmte Datenmenge gültig ist. Dieses Preismodell ermöglicht es IoT-Anwendern, während der Testphase die Kosten für die Konnektivität sehr einfach im Blick zu behalten.

IoT devices based on LoRaWAN require appropriate LoRaWAN coverage from a provider or their own gateway in order to send the data transmitted via LoRa to the relevant LoRaWAN server via an Internet connection.

If there is insufficient LoRaWAN coverage and a dedicated LoRaWAN gateway is out of the question for whatever reason, the two mobile radio technologies, NB-IoT or LTE-M (also known as CAT M1), are available. You can find a comparison of the two technologies at 1NCE.

1NCE is a global provider of IoT connectivity solutions. You can buy a SIM card from 1NCE that is valid for a period of 10 years or a certain amount of data. This pricing model allows IoT users to easily keep track of connectivity costs during the trial period.

NB-IoT Coverage

Die NB-IoT Abdeckung von 1NCE ist für den DACH- Bereich gegeben und kostenmäßig für Maker-Anwendungen optimal.

Für stationäre Anwendungen bietet sich nicht nur aus Kostengründen NB-IoT an, d.h. ein Sensorknoten zur Datenerfassung muss mit einem NB-IoT-Modem ausgestattet werden.

Es gibt mittlerweile genug Evaluationboards für diesen Zweck, bei kostengünstigen Geräten ist die Situation weniger komfortabel.

Bei der Recherche nach entsprechenden Fertiggeräten bin ich auf das Angebot der polnischen Fa. Efento gestoßen.

Efento entwickelt und vertreibt BLE- und NB-IoT-Sensoren zur Erfassung von Umweltdaten. Um NB-IoT als Technologie zur drahtlosen Datenübertragung zu evaluieren, bietet sich der Einsatz eines preisgünstigen Temperatur Loggers an.

Die Sensoren sind mit einer BLE-Schnittstelle ausgestattet, die eine schnelle und einfache Konfiguration mit einem Smartphone ermöglicht.

NB-IoT-Sensoren senden die Daten über das Mobilfunknetz an die Efento Cloud oder eine andere Cloud-Plattform. Die Inbetriebnahme ist im Quick Start Manual sehr gut beschrieben.

The NB-IoT coverage of 1NCE is given for the DACH region and is optimal in terms of costs for maker applications.

NB-IoT is not only suitable for stationary applications for cost reasons, i.e., a sensor node for data acquisition must be equipped with an NB-IoT modem.

There are now enough evaluation boards for this purpose, but the situation is less convenient with inexpensive devices.

While searching for suitable ready-made devices, I came across an offer from the Polish company Efento.

Efento develops and sells BLE and NB-IoT sensors for recording environmental data. In order to evaluate NB-IoT as a technology for wireless data transmission, the use of an inexpensive temperature logger is a good option.

The sensors are equipped with a BLE interface, which enables quick and easy configuration with a smartphone.

NB-IoT sensors send the data to the Efento Cloud or another cloud platform via the mobile network. Commissioning is described very well in the Quick Start Manual.

Efento HC5

Technische Daten:

Messzeitraum: 1 Minute – 10 Tage (vom Benutzer konfigurierbar)
Batterie garantiert bis zu 5 Jahre wartungsfreien Betrieb.
Das Gerät speichert 40.000 Messungen, wenn der Speicher voll ist, werden die ältesten Messungen überschrieben.
Die Konfiguration des Sensors kann über die Cloud oder mit einer mobilen Anwendung über BLE geändert werden.

Sind die Daten in der Efento Cloud abgelegt, dann kann auf diese über ein API zugegriffen werden. Details hierzu sind in der Dokumentation Getting measurements from Efento Cloud through API zu finden.

Einfacher ist aber die Verbindung zu einem für die Visualisierung zuständigen Server über einen Webhook, wie er im Efento Cloud User Manual beschrieben ist.

Ich habe den Temperatur Logger so konfiguriert, dass alle 10 Minuten eine Messung erfolgt und nach einer Stunde das gesamte Datenpaket zur Efento Cloud übertragen wird. Über den Webhook wird dann beispielsweise das folgende JSON-Paket weitergeleitet. Unter dem Key events sind dann auch die sechs Einzelmessungen im Abstand von 10 Minuten gelistet.

Technical data:

Measuring period: 1 minute – 10 days (user configurable)
The battery guarantees up to 5 years of maintenance-free operation.
The device stores 40,000 measurements; when the memory is full, the oldest measurements are overwritten.
The configuration of the sensor can be changed via the cloud or with a mobile application via BLE.

If the data is stored in the Efento Cloud, it can be accessed via an API. Details can be found in the Getting measurements from Efento Cloud through API documentation.


However, connecting to a server responsible for visualization via a webhook is easier, as described in the Efento Cloud User Manual.

I have configured the temperature logger to take a measurement every 10 minutes, and the entire data package is transferred to the Efento Cloud after one hour. The following JSON packet, for example, is then forwarded via the webhook. The six individual measurements at 10-minute intervals are then also listed under the key events.

{
"deviceSerialNumber": "282C02419C98",
"firstMeasurementTimestamp": "2023-06-23 14:40:00",
"lastMeasurementTimestamp": "2023-06-23 15:30:00",
"measurementPointId": 999294,
"measurementPointName": "Efento HC5",
"measurementsReceivedAt": "2023-06-23 15:35:12",
"signalStrength": 26,
"batteryStatus": "OK",
"measurementsEvents": [
{
"channelNumber": 1,
"channelType": "TEMPERATURE",
"events": [
{
"timestamp": "2023-06-23 14:40:00",
"value": 25.6,
"period": 600,
"status": "OK"
},
{
"timestamp": "2023-06-23 14:50:00",
"value": 25.8,
"period": 600,
"status": "OK"
},
{
"timestamp": "2023-06-23 15:00:00",
"value": 25.9,
"period": 600,
"status": "OK"
},
{
"timestamp": "2023-06-23 15:20:00",
"value": 25.8,
"period": 600,
"status": "OK"
},
{
"timestamp": "2023-06-23 15:30:00",
"value": 25.6,
"period": 600,
"status": "OK"
}
]
}
]
}

Meine bevorzugte Option zur Visualisierung von Daten ist Datacake, weshalb ich hier versucht habe, die übertragene Payload zu interpretieren.

Die Integration des Webhooks auf der Datacake Seite ist unter https://docs.datacake.de/integrations/webhook beschrieben. Wichtig und in der Verantwortung des Anwenders ist wiederum der Payload Decoder, der die übertragenen Daten für die Datacake Anwendung passend decodieren muss.

Im Payload Decoder unten wird erwartungsgemäß durch die events iteriert. Zu einigem Kopfzerbrechen und notwendiger Unterstützung von Datacake haben die unterschiedlichen Datenformate der jeweiligen Timestamps geführt. Datacake verarbeitet grundsätzlich das UNIX-Format, während im JSON-Paket von Efento das Datum als String formuliert war. Ein böser Stolperstein, der einer zusätzlichen Konvertierung bedurfte.

My preferred option for visualizing data is Datacake, which is why I have tried to interpret the transmitted payload here.

The integration of the webhook on the Datacake page is described at https://docs.datacake.de/integrations/webhook. The payload decoder, which must decode the transmitted data appropriately for the Datacake application, is important and the responsibility of the user.

As expected, the payload decoder below iterates through the events. The different data formats of the respective timestamps have led to some headaches and necessary support from Datacake. Datacake always processes the UNIX format, while in the JSON package from Efento, the date was formulated as a string. It was a nasty stumbling block that required additional conversion.

function Decoder(request) {
    // Parse the payload from the request body
    var payload = JSON.parse(request.body);
    // Initialize an array to store the formatted measurements
    var formattedMeasurements = [];
    // Extract the device serial number from the payload
    var deviceSerialNumber = payload.deviceSerialNumber;
    // Iterate through the measurementsEvents in the payload
    var measurementsEvents = payload.measurementsEvents || [];
    for (var i = 0; i < measurementsEvents.length; i++) {
        var events = measurementsEvents[i].events || [];
        // Iterate through the events
        for (var j = 0; j < events.length; j++) {
            var event = events[j];
            // Parse timestamp string in the format "YYYY-MM-DD HH:mm:ss" to Date object
            var timestampComponents = event.timestamp.match(/(\d{4})-(\d{2})-(\d{2}) (\d{2}):(\d{2}):(\d{2})/);
            if (!timestampComponents) {
                console.error('Invalid timestamp format:', event.timestamp);
                continue;
            }
            var dateUTC = new Date(Date.UTC(
                +timestampComponents[1],
                +timestampComponents[2] - 1,
                +timestampComponents[3],
                +timestampComponents[4],
                +timestampComponents[5],
                +timestampComponents[6]
            ));
            // Convert the date to UNIX UTC timestamp (seconds since 1970-01-01)
            var timestampUTC = dateUTC.getTime() / 1000;
            // Construct the formatted measurement object for temperature
            var formattedMeasurement = {
                device: deviceSerialNumber,
                field: 'temperature', // You can change this to the actual field name in your database
                value: event.value,
                timestamp: timestampUTC
            };
            // Add the formatted measurement to the array
            formattedMeasurements.push(formattedMeasurement);
        }
    }
    // Add signalStrength if present
    if (payload.signalStrength !== undefined) {
        formattedMeasurements.push({
            device: deviceSerialNumber,
            field: 'signalStrength',
            value: payload.signalStrength
        });
    }
    // Add batteryStatus if present
    if (payload.batteryStatus !== undefined) {
        formattedMeasurements.push({
            device: deviceSerialNumber,
            field: 'batteryStatus',
            value: payload.batteryStatus
        });
    }
    // Return the array of formatted measurements
    return formattedMeasurements;
}

Nach vollzogener Integration können die erhobenen Messdaten des Temperatur Loggers nun von der Efento Cloud abgefragt oder aber über ein Datacake Dashboard visualisiert werden.

Once the integration has been completed, the temperature logger’s measurement data can now be retrieved from the Efento Cloud or visualized via a Datacake dashboard.

Efento Cloud
Datacake Dashboard

Danke an Simon Kemper von Datacake für die speditive Unterstützung beim Payload Decoder.

Thanks to Simon Kemper from Datacake for his speedy support with the payload decoder.


Nachdem nun alles eingerichtet ist und erwartungsgemäß läuft, steht die Frage nach der resultierenden Batterielaufzeit.

Nach kurzer Zeit war die interne Batterie mit 3.7 V und 6300 mAh entladen. Also galt es, dem auf den Grund zu gehen.

Ich nutze Efento HC5 in der Schweiz, also außerhalb des Homenetzes von 1NCE. In der Schweiz bietet nur Swisscom NB-IoT an. Die Kosten entsprechen aber nicht dem Maker-Ansatz.

Da 1NCE das Swisscom Netz in der Schweiz nutzt, kann die PLMN fest auf den Wert von Swisscom (22801) eingestellt werden und so das Scannen nach der Home-PLMN der SIM-Card vermieden und Strom gespart werden.

Now that everything is set up and running as expected, the next question is the resulting battery life.

After a short time, the internal battery with 3.7 V and 6300 mAh was discharged. So, it was time to find the underlying cause of it.

I use Efento HC5 in Switzerland, i.e., outside the home network of 1NCE. In Switzerland, only Swisscom offers NB-IoT. However, the costs do not correspond to the Maker approach.

Since 1NCE uses the Swisscom network in Switzerland, the PLMN can be permanently set to the Swisscom value (22801), thus avoiding scanning for the SIM card’s home PLMN and saving power.


Ich habe den Verlauf der Batteriespannung verfolgt und eine Laufzeit von ca. 20 Tagen erreicht. Für meinen Einsatzfall (Einsatz in der CH, Provider in D, also Roaming) sehe ich derzeit keine Möglichkeit den Strombedarf zu reduzieren.

Da NB-IoT ohnehin für den stationären Einsatz gedacht ist, werde ich die Stromversorgung über ein Steckernetzteil vornehmen.

I have tracked the battery voltage and achieved a runtime of approx. 20 days. For my use case (use in Switzerland, provider in Germany, i.e., roaming), I currently see no possibility of reducing the power requirement.

As NB-IoT is intended for stationary use, I will use a plug-in power supply.

USB generated VBAT

Die im Bild oben angezeigte kleine Zusatzschaltung erzeugt durch einen Step-Down-Converter die vom Efento HC5 benötigte Versorgungsspannung von 3.6 V DC und ersetzt somit die Batterie.

Die Zusatzschaltung kann leicht an Stelle der Batterie auf der Oberschale des Gehäuses mit Klebeband fixiert werden.

Der Batteriestatus zeigt nun die am Step-Down-Converter einstellbare Versorgungsspannung für den Efento HC5.

The small additional circuit shown in the picture above uses a step-down converter to generate the supply voltage of 3.6 V DC required by the Efento HC5, thus replacing the battery.

The additional circuit can easily be fixed in place of the battery on the top shell of the housing with adhesive tape.

Now, the battery status shows the supply voltage for the Efento HC5 that can be set on the step-down converter.

Sie können die erfassten Messwerte über den Public Link verfolgen:

You can track the measured values via the public link:

Efento HC5 Public Link
Efento HC5 Smartphone Dashboard

2023-11-14/CK

Test der mobilen Datenerfassung mit LTE-M

Im Blogpost Mobile Datenerfassung über LTE-M hatte ich Hard- und Software eines LTE-M-Knotens beschrieben, der GPS-Daten sowie Messwerte von Temperatur- und Luftfeuchtigkeit bereitstellt.

Jetzt bei einer Reise von der CH nach D sollen folgende Punkte getestet werden:

  • Stationärer Test (CH, D)
  • Mobiler Test aus dem fahrenden Fahrzeug (Übergang von Funkzelle zu Funkzelle)
  • Roaming über Ländergrenzen (CH – A – D)
Screenshots MQTT Dashboard (Beschreibung im Bild)
Stationärer Test in der Schweiz
Dieses Bild hat ein leeres alt-Attribut; sein Dateiname ist screenshot_20230527_172334_mqttdashboard7749781390653124050-2.webpDieses Bild hat ein leeres alt-Attribut; sein Dateiname ist screenshot-2023-05-28-000345-1.png
Stationärer Standort CH

Findings:

Ausgabe der Werte für Lat und Lon mit zwei Dezimalstellen ist nicht ausreichend, um den Punkt (z.B. mit Google Maps) zu rekonstruieren

Die Höhenangabe schwankt zwischen 422.5 und 430.4 m (Betrachtung über kurzen Zeitraum). Die zu erwartende Schwankung der GPS-Höhenangaben ist allerdings noch grösser.
Zur Genauigkeit der Höhenmessung über GPS sind hier einige Angaben tzu finden: https://support.garmin.com/de-DE/?faq=QPc5x3ZFUv1QyoxITW2vZ6.
Zum Vergleich bietet sich die App Genauer Höhenmesser an.
Im nebenstehenden Bild sind Höhenangaben durch GPS, standortbezogen und barometrisch gemessen gegenübergestellt. Mit diesen Abweichungen muss also gerechnet werden.

Mobiler Test aus dem fahrenden Fahrzeug
auf dem Weg nach Zürich mit 100 km/h auf der Autobahn
Mobiler Test aus dem fahrenden Fahrzeug in Österreich
auf der Rheintal-Autbahn mit 124.4 km/h
Mobiler Test aus dem fahrenden Fahrzeug in Deutschland
keine Verbindung
Stationärer Test in Deutschland
keine Verbindung

Aktuell kann ich mir den Ausfall beim Roaming mit der 1NCE SIM-Card nicht erklären und werde den Test mit einer SIM-Card von der Telekom wiederholen.


2023-06-24/CK