Seamless Integration of Radiation Monitoring

The ggreg20_v3 component is designed for smart home enthusiasts and developers who seek to add ionizing radiation monitoring capabilities to their devices.

It provides a comprehensive set of data points essential for complete environmental control, including:

• Radiation Power (μSv/h)
• Equivalent Absorbed Dose (μSv/h)
• Total Accumulated Dose (μSv)
• Counts Per Minute (CPM) over the defined measurement period
• Instantaneous pulse count value
• System Status (alerts for danger, normal levels, or sensor errors)

This component autonomously handles all complex calculations, including dead time correction for the tube, delivering all necessary data for seamless automation within Home Assistant.

Key Advantage: Cross-Controller Compatibility

The core value of the component developed by IoT-devices LLC lies in its versatility. The ggreg20_v3 component is cross-controller compatible, supporting any microcontroller that runs ESPHome (including ESP32, ESP8266, Raspberry Pi Pico W, and others).

This eliminates the need to write individual code for different hardware platforms, allowing users to rapidly integrate radiation monitoring regardless of the specific controller used for their projects.

“We built ggreg20_v3 with the ESPHome community in mind. Our goal is to make environmental monitoring as accessible and reliable as possible by providing a single, flexible solution that works across all supported controllers,” commented IoT-devices LLC representatives.

How to Get Started

The ggreg20_v3 component is available as an external Git component.

To install: Add our repository to your ESPHome configuration and follow our detailed documentation.

• GitHub Repository: [https://github.com/iotdevicesdev/esphome_external_components]
• Documentation: Review the README.md file for full installation and configuration instructions.

IoT-devices LLC welcomes the community to test, provide feedback, and contribute to the component’s development.

Testing methodology

To conduct the measurements, we developed a special test bench based on the Home Assistant platform. The central element of the system was the Raspberry Pi Pico W controller with ESPHome firmware, which controlled the operation of the GGreg20_V3 module. To accurately measure the energy consumption, we used an INA219 sensor connected to a NodeMCU/ESP8266 controller also running ESPHome firmware. We used a laboratory power supply as a power source for the GGreg20_V3, which set the exact voltage level during testing.

Since the GGreg20_V3 module supports a wide range of supply voltages, from at least 3.0V to 5.5V, we used the three most common supply voltage levels to show how the test result differs: 3.3V, 3.7V, 5.0V. These voltages give us an idea of the module’s consumption when powered by:

• another controller or source with a voltage of 3.3V;
• a 3.7V lithium battery;
• another controller or source with a voltage of 5V.

It is important to note that the INA219 sensor measured only the power consumption of the GGreg20_V3 module, while the controllers were powered separately. This allowed us to obtain the most accurate data.

Also note that the supply voltage level did not change over time during the 60-minute test. Therefore, you should not expect that we have performed a complete emulation, for example, of a lithium battery that discharges under load and, accordingly, loses voltage from 4.2V to 2.5V during the test. Although this would have been a really useful and interesting experiment, we decided not to bother with it that much.

Test bench

Software on the side of the measuring sensor of consumed electric energy based on ESP8266 + INA219 with ESPHome firmware:

sensor:
 - platform: ina219
 address: 0x40
 shunt_resistance: 0.1 ohm

 current:
 name: "INA219 Current"
 accuracy_decimals: 5
 id: current_value

 power:
 name: "INA219 Power"
 accuracy_decimals: 5
 id: power_value

 bus_voltage:
 name: "INA219 Bus Voltage"
 accuracy_decimals: 5

 shunt_voltage:
 name: "INA219 Shunt Voltage"
 accuracy_decimals: 5

 max_voltage: 32.0V
 max_current: 3.2A
 update_interval: 1min

 - platform: integration
 name: "Total Energy Consumed"
 id: total_energy
 sensor: power_value
 time_unit: min
 accuracy_decimals: 5
 unit_of_measurement: "Wh"
 filters:
 - multiply: 0.0166666666666667

 - platform: integration
 name: "Total Current Consumed"
 id: total_current
 sensor: current_value
 time_unit: min
 accuracy_decimals: 5
 unit_of_measurement: "Ah"
 filters:
 - multiply: 0.0166666666666667

This YAML configuration snippet provides all the necessary data for our planned testing of the GGreg20_V3 radiation sensor module in terms of power consumption during operation under normal background radiation conditions.

Measurement process

The power consumption was measured every minute, with data accumulated for previous periods. The test lasted for an hour, which allowed us to obtain the real consumption of the GGreg20_V3 module for 60 minutes for each of the three supply voltages.

The Home Assistant platform was used to collect and record sensor data. It also provided tools for creating visual graphs of electricity consumption.

Results and conclusions

Thanks to the testing, we have obtained detailed data on the power consumption of the GGreg20_V3 module at different supply voltages. These results allow users to optimize the power consumption of their DIY projects using this module.

Power supply with a voltage of 3.3V

Power supply with a voltage of 3.7V

Power supply with a voltage of 5.0V

Summary of results

The power consumption of the GGreg20_V3 module was tested for 60 minutes at different voltages under normal conditions. INA219 measurement update cycle: 1 minute

Test dates: 27.08. – 31.08.2023

No deviations in radiation level measurements were observed during testing

Testing was performed in the default settings of the GGreg20_V3 module. The buzzer is enabled. The Schottky protection diode is installed. Blue power supply LED lights constantly. The supply voltage remained unchanged throughout the test cycle.

Appendix. Theoretical battery discharge diagram

We also decided to show the theoretical discharge graph at three different voltages when the GGreg20_V3 module is powered by batteries of different chemistry and capacity.

The basis for our calculations was the battery characteristics available on the Internet:

However, please note once again that this graph is a theoretical assumption and does not take into account the discharge of real batteries under load over time and changes in voltage and current consumption during discharge.

About GGreg20_V3

The Geiger counter module GGreg20_V3 manufactured by IoT-devices, LLC is the company’s flagship product, which has found its users in more than 30 countries.

All over the world, radio amateurs use GGreg20_V3 to create their own DIY projects, learn and conduct experiments related to radiation measurement.

When developing this product and improving it since 2020, we tried to make the module compact, ready-to-use, compatible with as many DIY platforms and systems as possible, undemanding in terms of power supply voltages, easy to program, and harmonized in terms of operating characteristics with various Geiger tubes.

We have also developed a number of examples and posted them on GitHub for various hardware and software platforms such as Arduino UNO, ESP32, ESP8266, Raspberry Pi Pico W, NodeMCU, ESPHome, Tasmota, MicroPython, Home Assistant.

And we, at IoT-devices Company, hope that our Customers will have a great user experience and real pleasure by implementing this module in their projects.

We also thank everyone for supporting and choosing this product designed and manufactured in Ukraine. We really appreciate it!

Keywords

Geiger counter

GGreg20_V3

Testing of energy consumption

DIY-projects

Home Assistant

Raspberry Pi Pico W

ESPHome

INA219

NodeMCU

ESP8266

I2C

WiFi

YAML

But its main advantage is that it works via the I2C bus.

Why these thermometers are underrated

Someone may say that LM75 is not the best sensor in terms of its technological features and design as a chip. Indeed, there are many other types of temperature sensors, such as 1-Wire Dallas DS18b20. These sensors have a one-wire connection and many other design advantages, such as waterproof metallized capsule-shaped housings, etc. It is possible to connect many thermometers to the 1-Wire bus on a single wire, 1-Wire supports error detection and device identification, etc.

But the 1-Wire bus has one and the most important drawback – there are no other devices for this bus except thermometers. That’s not exactly true, they are produced, but it’s such an unpopular segment that they are impossible to buy.

When we need to build a device of medium complexity, such as a weather station, several different sensors and other peripherals need to be connected to the main controller (a list, for example):

• BME680 / BME280 I2C / SPI;
• DS18b20 1-Wire;
• SPI / I2C display;
• Lightning sensor AS3935 SPI / I2C;
• Light sensor MAX44009 I2C;
• Temperature and humidity HDC1080 I2C;
• CCS811 I2C sensor;
• SCD4X I2C sensor.

And even with the powerful ESP32 (not to mention the ESP8266 and similar controllers, such as Arduino or RPI Pico W), we will have to solve the problem of optimizing the number of interfaces and protocols. After all, the processing of several different protocols will sooner or later affect our development and will require simplification not only on the hardware side (budget of free I/O ports), but also the software implementation of drivers for different protocols and interfaces that must run in parallel in the main loop of the controller.

Note. We are not writing about SPI here, because it is a specialized protocol with a completely different purpose and strengths that apply only to exceptional situations when it comes to sensors.

Therefore, in our opinion, you should choose solutions that can be easily expanded and operated in the future. 1-Wire and SPI devices are not well suited for such requirements and therefore we recommend not considering them unless it is absolutely necessary (as in the SPI case for high-resolution displays or measuring values at near real-time speeds).

It is worth trying to build an optimal hardware and software solution – we take a step towards the I2C bus. That is, since we will have an SSD1306 display with I2C on the main controller, an I2CUI4_V1 keypad with I2C, why would we need to install temperature sensors with any other interface? – So we decided to use only the I2C bus. All connections will be made through the I2CHUB_V1, splitter/hub, which supports the connection of 5 devices to the controller at the same time.

Note. As a reminder, I2C is a great bus – it not only allows you to connect many devices simultaneously, but also provides the ability to identify devices on the bus, control erroneous data, and hot-swap (connect and disconnect devices by the user on the go).

Built-in drivers in ESPHome

However, when we search on the ESPHome website, it turns out that the LM75 sensor, which we were going to use in the project as a thermometer, is not supported – there is no built-in driver.

We begin to do our own little investigation into the available drivers in ESPHome for temperature sensors like the LM75 ($0.89 USD on Mouser). And we find out that there are two other thermometers for which a built-in driver is already written in ESPHome:

• MCP9808 (1.39 USD on Mouser)
• TMP1075 (0.74 USD on Mouser)

Both sensors would have suited us technically. They are available on Mouser and other similar platforms. But we could not find ready-made modules with these chips at a price that would be close to the price of modules with LM75.

We thought that this was not acceptable to us, as it would not be to most of our readers. Given the similarity of these chips, no one wants to overpay 5-10 times for a thermometer module if you can buy an LM75-based module in every store.

Interestingly, the TMP1075 sensor is compatible with the LM75 specification (this is clearly stated in the datasheet), which is de facto the industry standard. Therefore, we concluded that we could try to connect our LM75 thermometer with the drivers for TM1075 that are built into ESPHome.

Unfortunately, we failed to make such a connection, even though the addressing on the bus and the internal registers are identical for the mentioned sensors. The only difference is that the TMP1075 also has a special identification register, which the LM75 sensor does not have. But even attempts to make changes to the sensor type checking at the CPP-code level of this driver did not allow us to use it with the LM75 chip.

Note. To be honest, we still don’t understand why the developers and contributors of ESPHome haven’t made a built-in driver for the LM75 yet. We wouldn’t have to write this article and spend a lot of time doing strange experiments.

So we went back to the starting point and did what we should have done from the very beginning.

Connecting the driver externally

As you probably know, ESPHome has at least two mechanisms for connecting custom device drivers from the outside: Custom Component and External Component.

Custom component is currently considered an obsolete integration option and is not recommended by the ESPHome documentation.

Instead, the documentation recommends using another, alternative way, which in our opinion is currently the only, easiest and best way to perform driver integration yourself – External Component.

The difference of the External Component is that the ESPHome user does not manually write interfaces for data flows from the sensor through low-code roundabouts, but uses fully defined mechanisms, which, by the way, are also used by all other ESPHome components:

So, to connect an External Component, you first need to describe its mapping correctly. We won’t dive into the details of programming and configurations here, because we found a ready-made component for the LM75 on GitHub.

To add LM75 sensors, you only need to add a few lines to the YAML configuration of the device in ESPHome:

• connect an external component (External Component):

• add LM75 sensor entities:

For convenience, we have forked the esphome-lm75 repository provided by https://github.com/btomala on GitHub to our account https://github.com/iotdevicesdev/esphome-lm75

An example of how the connection of LM75 drivers for the ESP12.OLED_V1 controller manufactured by IoT-devices, LLC looks like in ESPHome:

# YAML Config Example
esphome:
  name: esp12oled-lm75
  friendly_name: esp12oled-lm75
  comment: "Configuration example of two LM75 for ESP12.OLED_V1 with ESPHome firmware"
  project:
    name: "iot-devices.esp12oled-lm75"
    version: "1.0.0"


external_components:
  - source: github://iotdevicesdev/esphome-lm75
    components: [ lm75 ]


esp8266:
  board: nodemcuv2


logger:


api:
  encryption:
    key: "8tDDLc3S5dnSjADItGR5+7KxoUBhUIqeOiJZIXy"


ota:
  password: "c15e9a44e1408352d945b8cd35b79"


wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password


  ap:
    ssid: "Test-Node Fallback Hotspot"
    password: "rtF1XxDZ9"


captive_portal:


i2c:
  sda: 4
  scl: 5
  id: i2c_bus


sensor:
  - platform: lm75
    id: temperature
    name: "LM75 temperature"
    update_interval: 30s
    address: 0x48


  - platform: lm75
    id: temperature2
    name: "LM75 temperature2"
    update_interval: 30s
    address: 0x49
# END YAML Config Example

Note. This code is also available on our GitHub: github.com/iotdevicesdev/ESP12.OLED_V1-LM75-ESPHome

Project components

1 x ESP12.OLED_V1 module with ESPHome 2023.12.5 firmware;

1 x I2CHUB_V1 module:

1 x LM75 module (no brand);

1 x CJMCU-75 module.

Project results

This is the main thing we wanted to tell you in this text:

1. We have connected the LM75 via the External Component mechanism so easily and simply that we could not believe it ourselves after some complicated experiments with the TMP1075 driver.
2. The dependencies are pulled directly from GitHub, or can be linked from a local repository on your ESPHome/HomeAssistant drive. The External Component connected in this way is automatically included in the firmware during its compilation.
3. We have verified that there are no problems with addressing multiple LM75 sensors simultaneously with this component.
4. It’s as simple as connecting a sensor with a built-in driver like BME280 to ESPHome. The simplicity of using an off-the-shelf component via the External Component method is nothing compared to using the obsolete Custom Component method that we used to do for our other applications with the VEML6070 UV sensor.

As you can see in the following screenshots, our project has been successfully completed:

• LM75 is connected to the ESP12.OLED_V1 controller with ESPHome firmware;
• Two LM75 sensors work simultaneously with the main controller. Where two sensors work, eight can work (if necessary, the LM75 has three I2C address pins, which allows you to work with eight sensors on each I2C bus at the same time);
• The data from the sensors is sent to Home Assistant and displayed on the Dashboard;
• Further, the sensor values can either be displayed independently on the ESP12.OLED_V1 controller display using the ESPHome firmware, and/or can be used in Home Assistant automation scenarios.

LM75 sensor values on the Home Assistant server Dashboard:

Graphs from the Home Assistant server’s Logbook:

LM75 sensor values in the Developer Tools menu of the Home Assistant server:

Screenshots of the ESPHome console:

• Devices found during I2C bus scan (display and two thermometers)

• Drivers for LM75 sensors initialized

• ESPHome receives sensor data and transmits it to Home Assistant

That’s all we have planned to discuss on this topic for now.

Thank you for your attention!

Good luck!

This mechanism is called Pin Reuse validation: https://esphome.io/changelog/2023.12.0.html#pin-reuse-validation

These updates in ESPHome version 2023.12.0 also affected the examples developed by our company for the GGreg20_V3 Geiger counter ionizing radiation detector module.

According to the user’s request (https://github.com/iotdevicesdev/GGreg20_V3-ESP32-HomeAssistant-ESPHome/issues/2) regarding the repository for GGreg20_V3-ESP32-HomeAssistant-ESPHome, we have made the necessary updates to the configuration YAML file.

Now this example will work properly with the new ESHome configuration validation and you will be able to upgrade to newer versions of ESPHome without any problems.

We also plan to update other repositories with this issue.

You can also make changes to your ESPHome YAML configuration files yourself.

As of now, we know of two ways to fix the configuration so that it passes the new configuration validation rules:

Way #1. If you need to reuse the pin, use https://esphome.io/components/copy.html instead

This is the more correct path that we recommend using.

For sensor entities:

https://esphome.io/components/copy.html#copy-sensor

For binary sensor entities:

https://esphome.io/components/copy.html#copy-binary-sensor

An example of the code you should get is given here:

https://github.com/iotdevicesdev/GGreg20_V3-ESP32-HomeAssistant-ESPHome/issues/2#issuecomment-1867814996

Way #2. You can also use the exception described in the ESPHome Pin Schema document:

https://esphome.io/guides/configuration-types#config-pin-schema

config key: “allow_other_uses”

You can use this config key to override the control of reusing pins in exceptional situations.

Please note that the key must be specified not only in duplicate entities, but in each entity where a particular pin is used for the configuration to pass validation:

Wrong keys:

Right keys:

You should get the following code using the “alow_other_uses” key:

# YAML code example:
- platform: pulse_counter
    pin: 
      number: GPIO2
      allow_other_uses: true
    state_class: "measurement"
    unit_of_measurement: 'CPM'
    name: 'Ionizing Radiation Power CPM'
    count_mode: 
      rising_edge: DISABLE
      falling_edge: INCREMENT # GGreg20_V3 uses Active-Low logic
  # It seems that only one instance of pulse counter internal filters can be set
  # So here no any debounce filters for CPM value 
    use_pcnt: False
    internal_filter: 180us
    update_interval: 60s
    accuracy_decimals: 0
    id: my_cpm_meter
 
  - platform: pulse_counter
    pin:
      number: GPIO2
      allow_other_uses: true
      inverted: True
      mode: 
        input: True 
        pullup: False
        pulldown: False
    unit_of_measurement: 'uSv/Hour'
    name: 'Ionizing Radiation Power'
    count_mode: 
      rising_edge: DISABLE
      falling_edge: INCREMENT
    update_interval: 60s
    accuracy_decimals: 3
    id: my_dose_meter
    filters:
  #    - sliding_window_moving_average: # 5-minutes moving average (MA5) here
  #        window_size: 5
  #        send_every: 1      
      - multiply: 0.0057 # or 0.00332 for J305 by IoT-devices tube conversion factor of pulses into uSv/Hour
# END of YAML code example

You can choose which of the methods suits your DIY project.

That’s all. Good luck!

The main features of this example configuration compared to our previous ones:

• two types of tubes are taken into account and supported: J305 and SBM20. The user can switch between the two types of tubes with a convenient selector to calculate the values directly during operation, via the frontend, for example, through the Home Assistant dashboard widget.
• the Geiger tube internal noise compensation mode was taken into account and offered. This mode can also be switched directly during operation via the frontend.
• the calculation of internal noise compensation also takes into account the situation when the number of pulses is not enough to compensate. In this case, no compensation is performed. Please note that our example contains the coefficients provided by Geiger tube manufacturers: for J305: 0.2 pulses per second; for SBM20: 1 pulse per second.
• the configuration creates a separate text sensor that automatically shows the current status according to the radiation level: normal / warning / danger.
• the text status sensor also supports the situation when no pulses are received from the GGreg20_V3 module. In this case, this sensor will have the value “sensor error”.

https://github.com/iotdevicesdev/RPi-Pico-W_GGreg20_V3-ESPHome

We wondered what would happen if we took our DIY Geiger counter module GGreg20_V3 and put it in a freezer with a target temperature of -23 Celsius together with the ESP32 controller.

Will our sensor work at such a low temperature? Will we see any failures or deviations in the radiation sensor measurements?

My colleagues and I were betting that sooner or later we would get False-Positive pulses at the ESP32 input during strong cooling.

The fact is that when it comes to such a modular system, it may contain several points of failure that can show up during operation at low temperatures. Before starting the test, we considered the following as possible points of failure:

• the Geiger counter module board,
• the ESP32 controller board,
• the connections between them,
• and the Geiger-Muller tube SBM20.

Each of these components could stop working or become unstable due to deformation of materials, changes in the conductivity of wires and contacts, or the formation of dew or ice on the surface of the electronics.

Although the Geiger-Muller tube has an appropriate temperature rating (-60°C to +70°C) from the manufacturer, it can also change its behavior when exposed to low temperatures. For example, loss of pulse generation capability due to slowing down of molecular/electronic processes due to a decrease in the energy of particles in the gases filling the tube, or, conversely, avalanche-like ionization inside the flask due to the thermodynamic characteristics of these gases (Ne+Br2+Ar).

For this reason, it was interesting and important to conduct such a test of the GGreg20_V3 module and the circuit with the ESP32 controller that they create in DIY projects to answer potential questions from our users and customers who plan to use the GGreg20_V3 Geiger counter in harsh weather conditions.

We kept the sensor at such low temperatures for several hours. At the same time, we recorded measurements from the sensor by the Home Assistant server wirelessly and observed the measurement graphs.

And…. And we are satisfied with this test, but let’s not get ahead of ourselves and tell you how everything happened step by step.

So, in this experiment, we aimed to investigate the performance of a DIY Geiger counter module at low temperatures. We placed the Geiger counter module and ESP32 controller in a freezer with a temperature of -23 Celsius and kept it there for 5 hours. We recorded measurements from the sensor and observed the measurement graphs to evaluate any failures or deviations in the radiation sensor measurements.

We were also able to measure the temperature of the sensor during the test because we had a temperature probe on hand (1-wire DS18b20 12-bit). However, we also monitored the external temperature of the module box several times during the test using a non-contact infrared thermometer

Results

We did not notice any failure or deviation in the radiation sensor measurements during the entire test period. The measurements from the sensor remained within the normal background radiation during the entire test period.

We also used these practical tests to check how the system would behave during the transition from warmth to deep cold, as well as from the cold of the freezer to normal room conditions, and found that there were no problems that could be detected by simple monitoring tools. The absolute value of the temperature drop (sharp decrease and increase) during the test was more than forty degrees.

Discussion

Our results suggest that the GGreg20_V3 radiation sensor is capable of performing reliably at low temperatures. This is an important finding as it implies that the sensor can be used in low-temperature environments without any significant loss of accuracy or reliability.

However, it is worth noting that our experiment was limited in scope, and further tests may be required to confirm the findings.

In particular, we did not do any statistical verification of the obtained data, but only conducted several long-term (up to six hours long) experiments and practically checked whether the sensor and the microcontroller would work normally.

Conclusions

In conclusion, our experiment showed that the GGreg20_V3 radiation sensor can perform reliably at low temperatures. We did not observe any failures or deviations in the radiation sensor measurements during the entire test period, indicating that the sensor can be used in low-temperature environments without any significant loss of accuracy or reliability. However, further tests may be required to confirm these findings and evaluate the performance of the sensor over an extended period.

Now you also know what happens if the Geiger counter GGreg20_V3 is placed in a low temperature environment.

We hope that you found this post as interesting and useful as the experiment we conducted.

The repository describes the procedure in detail and allows you to connect our sensor to the Home Assistant server with minimal effort and time.

We will be glad if this feature adds another useful function to your server configuration and adds a new experience for you personally.

Previously, we did not notice that the ESPHome Pulse Counter API has the ability to apply a low-pass filter. We hope that this example will help many users to counteract the bounce that can sometimes occur in GM-tubed and high voltage systems.

Link:

https://github.com/iotdevicesdev/GGreg20_V3-ESP32-HomeAssistant-ESPHome

1. GGReg20_V3 Geiger counter connected to RPi Pico W controller running ESPHome on HomeAssistant

Users use the GGreg20_V3 with the RPi Pico W controller.

mastodon.social/@sboger/109510482022928362

Now it is very convenient, thanks to the support of this line of controllers in ESPHome.

Here is a link to the documentation:

https://esphome.io/components/rp2040.html

And this is a link about the support news:

https://esphome.io/changelog/2022.11.0.html#raspberry-pi-pico-w

2.Geiger counter based on ESPHome: radiation measurement and data publication on safecast.org

The user made an interesting project with GGreg20_V3 and TTGO T-Display controller, ESPHome firmware and data transfer to the safecast.org server:

3D Model:

https://www.printables.com/model/330675-ggreg20_v3-ionizing-radiation-geiger-counter

Code for ESPHome:

https://www.homeassistant-cz.cz/viewtopic.php?t=569

Library for TTGO T-Display:

https://github.com/Xinyuan-LilyGO/TTGO-T-Display

Safecast API:

https://api.safecast.org/en-US

Detailed description of the GGReg20_V3 module and the possibility to order it:

https://www.tindie.com/products/iotdev/ggreg20_v3-ionizing-radiation-geiger-counter/

Or:

For now, to satisfy curiosity, we can only say that these will be software and hardware IoT devices that have the following properties:

• dual purpose devices: stock and custom firmware;
• absence of rigid binding to IoT-devices LLC as a vendor;
• easy configuration and quick start of use;
• Plug & Play connection of additional sensors;
• data proxy by nodes, as mesh networks do;
• connectionless and serverless architecture;
• component compatibility with ESPHome;
• and thus support in Home Assistant.

On the screenshot, we solve the problem of connecting various sensors to the ESP8266 controller. More precisely, the task of compact and meaningful coding of measurement data into sensor packages so that they are useful for a mobile application that will process them on a smartphone and are readable enough for the users if they don’t want to use the app.

Most importantly, the new devices will have a dual purpose. The user can turn on the device he just bought with the firmware ready and immediately use its functions without complicated setup and connection procedures. Or he can develop his own firmware, because the well-known ESP8266 will be inside the devices.