The DCDC_3V3_400V_V1 module is a high voltage source for powering a wide range of Geiger-Muller tubes with different anode-cathode voltage levels, and can also be used as a low-power high voltage source in other DIY projects.

The need to set different output voltage levels is one of the reasons for installing a tuning potentiometer in the module.

The other adjustment components are resistor R1 and capacitor C1.

For explanation, please see the block diagram below.

The left part of the block diagram shows the structure of the high-voltage converter DCDC_3V3_400_V1 module.

The right part of the block diagram shows the components of the power consumers from the DCDC_3V3_400_V1 module integrated into the DIY project, according to the user’s design.

The output cascade of the DCDC_3V3_400_V1 module is a high-voltage multiplier. In projects of radiation detectors based on the Geiger-Muller counter, the tube receives a high voltage of 300 to 2000 volts through the R1C1 circuit.

The resistance, capacitance and voltage values for R1 and C1 depend on the type of tube or DIY circuitry. For this reason, R1 and C1 are not installed on the DCDC_3V3_400_V1 module.

Another reason for the absence of R1 and C1 on the module is the possibility of damage (electrical breakdown) of C1 when adjusting the voltage with a potentiometer.

Taking these factors into account, we recommend that when testing the DCDC_3V3_400_V1 module, you solder or connect a circuit to the output contacts according to the following scheme:

The voltage adjustment and measurement should be performed similarly to the steps described in the Initial Diagnostics Manual for the Geiger counter module GGreg20_V3.

Second part of the description, see the link: Connecting the GGreg20_V3 Radiation Sensor to the Home Assistant Server via ESP Home Integration – part 2

Note . This publication is suitable for all versions of the ionizing radiation detector manufactured by IoT-devices: GGreg20_V1, GGreg20_V2, GGreg20_V3
Since the entire line of these detectors is focused on the SBM-20 tube, all versions of the devices have the same algorithm and coefficients for calculating the power level and dose of ionizing radiation.
The accuracy of the measurement is affected only by the individual properties of the SBM-20 tube installed in each GGreg20_V3 detector. The specifications of the tube manufacturer indicate a limit range of measurement accuracy of 20% . On practice, this means that two identical GGreg20 devices, but with different SBM-20 tubes, can give results (not more than) with the specified deviation in the number of pulses.

Steps to connect GGreg20 to Home Assistant – continued.

Step 8. Check the log of the new ESP8266 controller with GGreg20 connected
Step 9. Check for new entities on the server side
Step 10. Add GGreg20 radiation sensor widgets to the Dashboard
Step 11. Add a push notification automation script to the Home Assistant application for crossing thresholds

Entities and values of the device on the server

Step 8 . Check the log of the new ESP8266 controller with GGreg20 connected

Here is an example of an active device console with GGreg20 and yaml settings similar to the ones we developed above.

Fig. Output to the device console (Logs) via the ESP Home interface

Step 9 . Check for new entities on the server side

There are two ways to verify that the corresponding GGreg20 entities are formed in the ESP Home plug-in and that the Home Assistant server sees them:

• go to the Developer Tools menu on the sidebar of the Home Assistant interface and search for the relevant data as shown in Fig.

Fig. Find the right entities through the Developer Tools menu

• or go to the menu Configuration -> Integration and search as shown in the following figures.

Fig. Search for the desired entities through the menu Configuration -> Integration

Fig. Search for the required entities through the menu Configuration -> Integration : Devices / Entities

Visualization and Automation

Step 10 . Add GGreg20 radiation sensor widgets to the Dashboard

Here is an example of a demo tab from an active server for two devices GGreg20_V1 and GGreg20_V3 located in different coordinate axes. Each device uses the same yaml file as we created above.

Fig. The dashboard shows widgets with radiation level data from two sensors GGreg20_V1 and GGreg20_V3 located on different coordinate axes.

Step 11 . Add a push notification automation script to the Home Assistant application for crossing thresholds

Once we have made sure that the new device works and sends reliable data, it is possible to move on to the main task – Automation. This powerful tool is available to the administrator through the menu Configuration -> Automation.

Because the entities with the power and dose of ionizing radiation created by ESP Home are available through all components and functions of Home Assistant, the administrator can create any events, functions, scenarios with their use.

For example, it is possible to create an automated exceeding notification of the normal power threshold of ionizing radiation with a message on a smartphone. And so on.

However, these topics go far beyond this publication and we do not have the opportunity to consider them here.

Conclusions

In parts one and two , we covered the steps

Server
Step 1. Install (or start) the Home Assistant server

ESP Home plugin for Home Assistant
Step 2. Connect the ESP Home extension for the Home Assistant server via the Supervisor -> Add-on Store menu

YAML-config of the new ESP device with GGreg
Step 3. Download the ready example of a batch yaml-configuration file of the GGreg20_V3 device for ESP8266 from our website
Step 4. Create (based on the example) in ESP Home the appropriate yaml configuration file

Hardware connection GGreg20_V3 and controller
Step 5. Select the GPIO pin on the controller that will register the pulses from GGreg20
Step 6. Connect the GGreg20_V3 radiation detector to the ESP8266 controller via the Out connector to the selected GPIO of the controller

Flashing the ESP device with GGreg
Step 7. Build and write firmware for the controller

Next, we performed the following steps to connect GGreg20 to Home Assistant:

Step 8. Check the log of the new ESP8266 controller with GGreg20 connected
Step 9. Check for new entities on the server side
Step 10. Add GGreg20 radiation sensor widgets to the Dashboard
Step 11. Add a push notification automation script to the Home Assistant application for crossing thresholds

We have considered in detail the easiest way to connect the GGreg20 detector with the ESP8266 controller to the Home Assistant server with the ESP Home plug-in.

And we made sure that it is not difficult at all, because all the work for us is performed by :

• Detector GGreg20_V3 – Immediately registers the pulses and transmits them to ESP8266;
• ESP Home plugin – provides an interface for building firmware and programming ESP8266;
• Ready-to-use yaml-file frees us from self-writing guidelines for sensor GGreg20;
• The Home Assistant server allows us to conveniently connect, administer and receive information from any of our devices.

That’s all. Good luck!

First part of the description, see the linkConnecting the GGreg20_V3 Radiation Sensor to the Home Assistant Server via ESP Home Integration

Note . This publication is suitable for all versions of the ionizing radiation detector manufactured by IoT-devices: GGreg20_V1, GGreg20_V2, GGreg20_V3

Since the entire line of these detectors is focused on the SBM-20 tube, all versions of the devices have the same algorithm and coefficients for calculating the power level and dose of ionizing radiation.

The accuracy of the measurement is affected only by the individual properties of the SBM-20 tube installed in each GGreg20_V3 detector. The specifications of the tube manufacturer indicate a limit range of measurement accuracy of 20% . On practice, this means that two identical GGreg20 devices, but with different SBM-20 tubes, can give results (not more than) with the specified deviation in the number of pulses.

Steps to connect GGreg20 to Home Assistant – continued.

Step 5. Select the GPIO pin on the controller that will register the pulses from GGreg20
Step 6. Connect the GGreg20_V3 radiation detector to the ESP8266 controller via the Out connector to the selected GPIO of the controller
Step 7. Build and write firmware for the controller

Hardware connection GGreg20_V3 and controller

In steps 5 and 6, we give an example of a connection for ESP8266. For the ESP32 controller, everything is the same. The only difference is the number, purpose and numbering of ESP32’s GPIOs as a more powerful hardware platform. But the general technological logic is identical.

Fig. Connecting GGreg20_V3 to a classic NodeMCU board with ESP8266

Step 5. Select the GPIO pin on the controller that will register the pulses from GGreg20

If this is your first time dealing with ESP8266 and you do not know which GPIO is best to use for a pulse counter, we recommend using Сthe GPIO Planning and Application Standard for ESP8266-12 / NodeMCU / Lua projects, developed by alterstrategy.lab .

For example, it could be GPIO0 (D3). This pin is convenient because it has a built-in Flash button in most devices and boards based on the ESP8266 module – in case you need to check how the controller counts pulses without a sensor, it is possible to simulate pulses with a button. That is why all the examples in this publication are for GPIO0 (D3).

Step 6.. Connect the GGreg20_V3 radiation detector to the ESP8266 controller via the Out connector to the selected GPIO of the controller

As you can see, the connection is quite simple – you only need to supply power from the NodeMCU for the GGreg20 module, and connect the output (Out) of the sensor to the input (D3) of the controller and supply 5V to the micro USB connector of the NodeMCU.

Note. Note that you may not have GGreg20 at all – in this case, you can simulate the pulses by simply pressing the Flash button (GPIO0 / D3) a certain number of times per minute.

Flashing the ESP device with GGreg

Step 7. Build and write firmware for the controller

Before building the firmware, you need to validate the yaml file we created. This will protect us from file errors that we may have accidentally made.

Fig. YAML code of the counter, which is planned to be flashed to the controller ESP8266

Fig. Yaml code validation was successful

Fig. Start compiling the firmware binary for a specific yaml code

If the controller is new – you need to compile and download to the PC a binary firmware bin-file in the ESP Home interface – click DOWNLOAD BINARY after successful compilation.

Fig. Compilation completed successfully

Next you need to write the firmware to the controller (ESP8266 / ESP32). This can be done by means of the ESPHome-Flasher utility. It can be freely found and downloaded via the Internet.

Fig. General view of the esphome-flasher utility

If the controller has already been flashed with ESP Home – just fill in the updated firmware over the air via OTA Update. But note that we deliberately do not consider this option to update the firmware, because the purpose of the article is to show how to connect the new GGreg20 with the new ESP8266 to Home Assistant.

Fig. Launch of an alternative procedure for updating the firmware via WiFi-air – OTA Update

After flashing the firmware and restarting the new device, it is recommended to restart the Home Assistant server too.

Important! After starting the server you need to go to the menu Configuration -> Integration. Find there a new device that we flashed and connect it to the server configuration, if it is not connected automatically.

Conclusions

We’ve completed the following steps to connect GGreg20 to Home Assistant:

Step 5. Select the GPIO pin on the controller that will register the pulses from GGreg20
Step 6. Connect the GGreg20_V3 radiation detector to the ESP8266 controller via the Out connector to the selected GPIO of the controller
Step 7. Build and write firmware for the controller

Next, we look at the following steps in detail – part 3 :

Step 8. Check the log of the new ESP8266 controller with GGreg20 connected
Step 9. Check for new entities on the server side
Step 10. Add GGreg20 radiation sensor widgets to the Dashboard
Step 11. Add a push notification automation script to the Home Assistant application for crossing thresholds

That’s all. Good luck!

If you already have experience setting up and deploying devices in ESP Home running Home Assistant, you can skip the introductory sections and go straight to the example of a configuration yaml file that you can use as a basis for your own system and devices.

All sample files are working and run on a real-deployed server and controller ESP8266 with a GGreg20 Geiger counter. ESP32 is also supported by ESP Home and on the example of ESP8266, the reader can make a variant of the yaml file for the ESP32 platform. In this publication, we demonstrate how to work with ESP32 in a limited way, because in terms of ESP Home and Home Assistant settings, the ESP8266 and ESP32 platforms are almost the same.

Note . This publication is suitable for all versions of the ionizing radiation detector manufactured by IoT-devices: GGreg20_V1, GGreg20_V2, GGreg20_V3

Since the entire line of these detectors is focused on the SBM-20 tube, all versions of the devices have the same algorithm and coefficients for calculating the power level and dose of ionizing radiation.

The accuracy of the measurement is affected only by the individual properties of the SBM-20 tube installed in each GGreg20_V3 detector. The specifications of the tube manufacturer indicate a limit range of measurement accuracy of 20% . On practice, this means that two identical GGreg20 devices, but with different SBM-20 tubes, can give results (not more than) with the specified deviation in the number of pulses.

Steps to connect GGreg20 to Home Assistant

Next, we consider in detail the steps for connecting a detector (sensor) GGreg20. Honestly, we have to cite a lot of text and pictures to explain some important points – because of this, the publication seems procedural horror. It does not! All these steps are simple, automated and performed in 15-20 minutes.

Server

Step 1 . Install (or start) the Home Assistant server

If you already have a server installed, just start it. If you need to deploy the server, we recommend that you review the instructions we developed for deploying Home Assistant in a virtual machine running Windows 10

ESP Home plugin for Home Assistant

Step 2 . Connect the ESP Home extension for the Home Assistant server via the Supervisor -> Add-on Store menu

The procedure for installing an official plugin, such as ESP Home, in Home Assistant is quite simple. We recommend that you review Step 8. Installing the ESP Home Plugin (Option) the instructions mentioned earlier.

YAML-config of the new ESP device with GGreg

This is a key part of this publication, which interests us more than any other general data on the preparatory steps of the environment. In steps 3 and 4, we will develop our own config for ESP with GGreg based on real-world examples from our Home Assistant test server.

Step 3. Download the ready example of a batch yaml-configuration file of the GGreg20_V3 device for ESP8266 from our website

The YAML file is a common text script file in Home Assistant, in this case with instructions for ESP Home, which are used when building the firmware.

We have developed such a file for ESP8266 and GGreg20 and posted it on our website for free download and use by anyone who needs to connect GGreg20 to Home Assistant via ESP Home. You can download the file by following this link .

The full file you just downloaded has the following content:

Open YAML text

Let’s consider the main parts of the ggreg20_esp8266_esphome.yaml file prepared by us.

To calculate the value of the ionizing radiation power of microsieverts per hour, use Pulse Counter Sensor – an API-component of the ESP Home plug-in:

https://esphome.io/components/sensor/pulse_counter.html

This part of the yaml code is responsible for that:

sensor:
- platform: pulse_counter
 pin: D3
 unit_of_measurement: 'mkSv/Hour'
 name: 'Ionizing Radiation Power'
 count_mode: 
 rising_edge: DISABLE
 falling_edge: INCREMENT
 update_interval: 60s
 accuracy_decimals: 3
 id: my_doze_meter
 filters:
 - sliding_window_moving_average: # 5-minutes moving average (MA5) here
 window_size: 5
 send_every: 5 
 - multiply: 0.0054 # SBM20 tube conversion factor of pulses into mkSv/Hour 

To calculate the total radiation dose received in microsieverts, the Integration Sensor, also a component of the ESP Home API, is used:

https://esphome.io/components/sensor/integration.htm

This part of the yaml code is responsible for that:

- platform: integration
 name: "Total Ionizing Radiation Dose"
 unit_of_measurement: "mkSv"
 sensor: my_dose_meter # link entity id to the pulse_counter values above
 icon: "mdi:radioactive"
 accuracy_decimals: 5
 time_unit: min # integrate values every next minute
 filters:
 # obtained dose. Converting from mkSv/hour into mkSv/minute: [mkSv/h / 60] OR [mkSv/h * 0.0166666667].
 # if my_dose_meter in CPM, then [0.0054 / 60 minutes] = 0.00009; so CPM * 0.00009 = dose every next minute, mkSv.
 - multiply: 0.0166666667

Also, in order to be able to test the pulse counter without the GGreg20 sensor, a discrete Flash sensor ESP8266 has been added to the configuration – on the same GPIO0 (D3) as the Pulse Counter – but another ESP Home API component, GPIO Binary Sensor, is already used:

https://esphome.io/components/binary_sensor/gpio.html

This part of the yaml code is responsible for that:

binary_sensor:
 - platform: gpio
 name: "D3 Input Button"
 pin:
 number: 0
 inverted: True
 mode: INPUT_PULLUP

The ESP Home plugin has sufficient documentation for these components with examples, so we will not go into detailed explanations. Where we saw fit, we added comments inside the yaml code.

Step 4. Create (based on the example) in ESP Home the appropriate yaml configuration file

After downloading the file, we suggest you open it with any text editor and become familiar with its contents.

Next, in the interface of the ESP Home plugin on the Home Assistant web page with administrator access rights, you need to create your own yaml file by clicking “+” and answering a few initial questions of the wizard.

Fig. General view of the ESP Home plugin interface in Home Assistant

Fig. We give the name to our new device

Fig. Choose the right platform according to the type of controller

Fig. Specify the parameters of the WiFi router and password for OTA update

After completing the “wizard”, a file with the basic parameters that we have already configured appears in the ESP Home interface. Now you need to add to this file the parts that you will find in the ggreg20_esp8266_esphome.yaml file.

Fig. Basic configuration for ESP8266 / NodeMCU created by the “wizard”.

For example, here is a similar initial yaml file for ESP32. As you can see, it is almost no different from the file for ESP8266.

Fig. Basic configuration for ESP32 / WROVER that creates a “wizard”.

If you compile the firmware with such an initial file – it will work and do the basics – connect to the server, raise the access point for settings and so on. But such a controller will not perform any application tasks.

That’s why you need the file we developed – you need to copy the rest of the settings from our file to yours. You can also completely replace the contents of your file with data from ggreg20_esp8266_esphome.yaml, of course, if you have an ESP8266 controller. If you have a different controller – you need to replace the relevant parts of the file, and leave the rest unchanged.

Conclusions

We’ve completed the following steps to connect GGreg20 to Home Assistant:

Step 1. Install (or start) the Home Assistant server
Step 2. Connect the ESP Home extension for the Home Assistant server via the Supervisor -> Add-on Store menu
Крок 3. Download the ready example of a batch yaml-configuration file of the GGreg20_V3 device for ESP8266 from our website
Step 4. Create (based on the example) in ESP Home the appropriate yaml configuration file

Next, we consider the following steps in detail:

Part 2:

Step 5. Select the GPIO pin on the controller that will register the pulses from GGreg20
Step 6. Connect the GGreg20_V3 radiation detector to the ESP8266 controller via the Out connector to the selected GPIO of the controller
Step 7. Build and write firmware for the controller

Part 3:

Step 8. Check the log of the new ESP8266 controller with GGreg20 connected
Step 9. Check for new entities on the server side
Step 10. Add GGreg20 radiation sensor widgets to the Dashboard
Step 11. Add a push notification automation script to the Home Assistant application for crossing thresholds

That’s all. Good luck!

We have a main system controller and several devices with an I2C interface that need to be connected to it. The figure shows an approximate classic set of modules that may need to be connected to the main controller (MCU).

Fig. Various I2C Modules Example

Most microcontrollers (MCUs) are miniature devices and have a very limited budget for free I / O ports. Typically, on Arduino / ESP8266 / ESP32 / STM32 controllers, only one interface can be reserved for the I2C bus (even if there are two) – two GPIO ports for SDA and SCL signal channels.

There are at least two reasons for this.

First , GPIO ports are a valuable resource on the main controller. They are involved in no less important external interfaces – UART, SPI, Deep Sleep Wakeup, sub-button inputs, actuator outputs (s), etc.

Secondly , the design of the main controller module board must take into account the size limitations: the more connectors installed on this board, the greater the linear dimensions it will have.

Note . We also know that the I2C serial bus can be implemented not only in hardware, with fixed I / O ports on the MCU, but also in software, when the bus signal lines can be assigned to any MCU’s GPIO ports. Moreover, the software implementation of the bus allows to declare multiple I2C software buses with different Bus_ID.

Fig. MCU I2C bus hardware and software implementations

But the manifestation of several I2C software buses simultaneously within one MCU reduces the number of free pins for other tasks. Because of this, such opportunities are rarely used. Exceptions to this may be situations when such a technique avoids problems that cannot be solved in any other way. For example, addressing collisions (two different devices with the same 7-bit address) and similar problems. But even for such problems, it is more efficient to use an I2C hardware multiplexer than multiple I2C software buses.

Problem solution

To solve the problem of one I2C port on the MCU, the hardware I2C bus interface splitter is most often used. It is a passive hub that splits one existing I2C interface into the required number of the same interfaces.

There are many similar devices on the market, but we will give an example of a device of our own production – I2CHUB_V1 , which has 6 I2C ports: 3 x 4 pin JST HX2.54, 3 x 4 pin Dupont and two additional dedicated “bidirectional” 2 pin power ports.

Fig. I2C bus interface splitter – I2CHUB_V1 as an example

Another way to solve the problem in the case of a bus-type serial interface, such as I2C, may be to use predefined end-to-end interfaces in individual sensor modules or actuators that connect to the bus.

Fig. Not widespread In-Out (two-connector) I2C sensor modules connection example

The “input” interface of each such module is connected to the MCU or the previous sensor module on the bus, and the “output” interface allows you to cascade the next module. Some manufacturers provide two I2C bus interfaces for this purpose. But, unfortunately, most modules are not equipped with such capabilities. Therefore, we consider I2C HUB as a more common and universal approach. Below you will find the basic schemes for modules connection with use of the hub.

Note . As the number of connections increases, it exponentially increases:
– number of failure points (PoF, Point of Failure);
– the risk of human error when making interface signal connections.

For the protection of equipment from failure and installation errors, in order to increase the overall reliability of the system, we recommend:

• to use connectors with a safety key as often as possible;
• to use modules with mutually compatible electrical interfaces and physical connectors.

While we recommend using key connectors whenever possible, we also try to take into account the realities of the electronic components market and meet the needs of consumers. That’s why we’ve given the I2CHUB_V1 splitter the ability to act as a type connector converter from JST to Dupont and vice versa.

We consider this a very useful feature, because thanks to the ability of freely reversing JST – Dupont interface cables from one side to the other, the user can connect almost any existing I2C interface modules to the hub. Also, the user is free to use their own Dupont – Dupont pin cables.
For the ” Order with cables ” option in the module I2CHUB_V1 connectors are always soldered in the same way: half of them are 2.54 mm JST connectors (with key), the other half are Dupont pin connectors. This is done to ensure the above-mentioned flexibility of interconnection of various I2C modules.

Schemes of modular connection to the interface splitter

Star

The most common scheme is when all modules are connected to the divider by I2C interfaces. Let’s call her “Star”.

Fig. “The Star” module connection example

Cascading

The next topology is a cascade of two or more “Stars”. Let’s call it “Cascading”.

Fig. “Cascading” module connection example

Because one of the interface splitter ports is always used as an “input”, there may be a lack of free splitter ports in some situations. In this case, the necessary number of splitters is cascaded to provide the desired number of interface ports on the I2C bus.

For example, IoT-devices I2CHUB_V1 has 6 I2C ports. If it is planned to connect more than 5 slave devices to MCU in the project, it is possible to apply cascading of two splitters and distribute the corresponding slave devices between their interfaces.

Long line

The last possible implementation scheme to be included in this publication is a topology with a long data line and two remote independent sources of power. Let’s call it “Long Line”.

Fig. “Long line” connection with remote power source example

In this scheme, only three signal lines are used, while the power for the devices comes from a local, independent source on each side. This arrangement allows a relatively long data line to be organized on the I2C serial bus interface without the use of special bus repeaters / amplifiers.

Compatibility of splitters with other systems

If you use modules with different supply voltages in one project, you should pay special attention to the signal matching of such components. But if you choose to apply a passive splitter that has no conversion or voltage leveling elements just take into consideration that the voltage that you apply to the splitter connectors will reach all the modules connected to the splitter via the respective I2C bus signaling lines.

However, since the classical I2C splitter (such as I2CHUB_V1) is a passive device and does not change the voltage level, it is automatically compatible with any controller you choose to connect it to: Arduino, STM32, ESP8266, ESP32, Raspberry Pi, etc.

Warning! Only you decide which logical levels the components of the project should work with: 1.8V, 3.3V or 5V.

Detailed I2C bus specifications

To view details of all I2C bus features, we recommend reading the official guidelines and specs here: https://www.nxp.com/docs/en/user-guide/UM10204.pdf
As well as other resources on the Internet.

That’s all we planned to tell in this publication. We have considered the features and connectivity of the slave modules to the I2C bus interface of the main controller. We have also shown the main application patterns of the splitter, such as Star, Cascading, Long Line, with the possibility of remote independent powering of individual bus chunks, thanks to the special power “input/output” ports in the splitter.

Thank you for your attention. Ask questions on our social networks.
Good luck!

The I2C bus offers all the necessary functions:

• a simple physical interface: the SDA data and SCL synchronization signals require only two wires to connect to the bus;

• the addressing of devices on the bus with unique 7-bit addresses;
• identification of devices on the bus by their address or by unique identifiers (if provided by the chip manufacturer);
• hot device plugging / unplugging like Plug & Play;
• the unit is powered by the bus or by each module’s own power supply;
• the support for different supply voltages of devices on the bus (provided that the signals are matched to the voltage level);
• an advanced infrastructure of amplifiers, repeaters, splitters and multiplexers to build complex topologies offered by chip manufacturers;

All that allows about a hundred devices to be connected to the controller on a single interface at the same time. The I/O port budget of the main controller is minimal when the I2C bus is used to connect the sensors.

Sensors or actuators might be on an extension cord, or all the chips might be concentrated on one module. Or all chips can be focused on one module.

The master controller and slave devices can be powered independently. Or all devices on the bus can be powered from a common source.

The I2C is supported by the vast majority of microelectronics manufacturers. All popular controllers, IoT / Smart Home platforms, and related development environments are compatible with the bus.

Most IoT devices support the I2C interface as basic. Moreover, the support of the I2C bus is usually a decisive factor in the selection of chips in our projects. But any system has not only advantages. There are also shortcomings and hidden problems that we reveal in the publications.

Today we would like to talk about the software problem of choosing the right hardware sensors with I2C bus support. We will not go into the theory, but rather suggest a practical example using our devices.

Let’s start with the popular radiation sensor module GGreg20 .

Example №1. GGreg20 and I2C GGreg20 and I2C

From time to time we are asked if it would be better to equip the GGreg20 module with the I2C interface and offer such a product as an alternative to the product with a pulse output, which is now GGreg20_V3.

In short, no. Let’s try to justify our opinion in more detail. Let’s try to justify our opinion in more detail.

We really like the I2C bus. We, moreover, already have an I2C interface splitter module, I2CHUB, which would be well suited to a hypothetical GGreg20 with I2C interface. So we can take a budget microcontroller – a companion like STM32, which must perform the necessary pulse calculations and give calculated values of the power and dose of ionizing radiation to the main controller at a low level via I2C interface.

But let’s ask ourselves how many common and very popular IoT platforms and microcontrollers will have driver support for such an I2C sensor? The answer will be disappointing since it is not an industrial sensor with a huge sales market.

The answer will be disappointing since it is not an industrial sensor with a huge sales market.

Certainly, our company needs everyone to be able to connect our sensors. It is our customers who must choose the type of controller or platform. We need to provide versatility for Arduino, ESP32 / ESP8266, Raspberry Pi, or for NodeMCU, Node-RED and ESPHome in Home Assistant, and many other IoT development environments that we might not have even heard of.

GGreg20 is now supported by any controller, development environment, and IoT platform, precisely because it has a versatile pulse output. If we equipped the GGreg20 with an I2C interface, we would have a completely different result.

Note . What if you make two interfaces on the GGreg20 module at once – pulse output and I2C? It would be very convenient, but in this case we believe that these costs at the expense of customers would be unjustified. The companion controller occupies a certain area on the module board. The I2C bus takes up twice as many controller ports as the pulse output. All this significantly increases the unit cost of the product. While the Pulse interface takes up only one GPIO controller with an interrupt handler and is much easier to program. And if we talk about maximum simplification, the GGreg20 module can work without a controller at all. The user can measure radiation (in circumstances that require it) only with a clock to record the measurement time in minutes.

We will next consider another example of two similar devices. They both have an I2C interface, but different application perspectives.

Example №2. I2CUI3, I2CUI4 and I2C

We first developed I2CUI3 – a useful and reliable product. It is a universal module of user interfaces with the I2C interface, which provides input of user instructions with the help of five navigation buttons and output of data to the RGB LED and the bazaar about the status or events of the IoT device. It is based on the 8-bit NXP PCA9538 port expander. For many years we have been using this chip for various tasks, including as the main component of the I2CUI3 module. The PCA9538 port expander is convenient, as it works semi-automatically after power supply and for some tasks does not require pre-programming at all, and therefore can work even without the main microcontroller.

And then it became clear that we need not 8-bit, but 16-bit similar module for certain tasks. So we created a new product with an I2C interface – I2CUI4 module based on the MCP23017 port expander chip.

For the new I2CUI4, we could use NXP’s older expander in the line. They have several 16-bit expander chips like PCA6416, PCA9539, PCA9575, PCA9673. But there are no official libraries for any of the chips either on the arduino.cc site or on the esphome.io site. There are also no drivers for the NodeMCU firmware.

There are only a few libraries for PCA9539 on Github, but neither Adafruit nor Seeed Studio has drivers for any NXP chip.

That is why the new product I2CUI4 is compatible with common platforms and has probably the most popular chip MCP23017 from Microchip Technology with I2C interface.

Thanks to that, our MCP23017-based product can boast a wide range of support by Arduino, NodeMCU, ESPHome / Home Assistant, Node-RED, Blynk, MicroPython, Raspberry Pi, STM32, and other brands. GitHub has hundreds of repositories with drivers in C / C ++, Python, JS, Lua, and other languages.

Conclusion

We gave two examples of identifying and solving the problem of driver support for devices equipped with an I2C interface from our own experience.

Unless you plan to provide on your own driver support for an I2C device you are about to buy, please pay attention to the hidden external risks described in this publication. You should choose a device, module, or chip with an I2C interface, which, in addition to other factors, will have the widest driver support among third-party systems. Special attention concerning compatibility and support should be given to the target microcontrollers, platforms, development environments. You have to be sure that all of these systems will support your chip before using it in your designs.

We have used these principles to develop two excellent products, GGreg20 and I2CUI4, to minimize the risks and avoid the problems mentioned above.

We hope you find this material useful.

Thank you for your attention.