Configuring the Firmware
The firmware is extremely configurable, which provides a high flexibility. The drawback is the high number of configuration options that have to be understood to fully use the the H32. The options fall into different categories which are quite distinct, and we'll examine every one of them.
One important point regards output pins. These can be wired in different ways e.g., an LED might be turned on by switching the pin to GND (active low) or by switching it to Vcc (active high). To allow you to configure this with a minimal overhead, pin numbers that are positive are assumed to be active high, and pin numbers that are negative are considered active low. An example: We have an LED on pin 2 that turns on if the pin goes to Vcc. Then we use the pin number 2 in the configuration. If we have an LED on the same pin the turns on if the pin goes to GND, then we use the pin number -2 in the configuration.
This block of options contains the basic configuration.
| Option | Description |
|---|---|
| Device Name | The name of the device is used for the captive portal, as the WiFi device name and for the OTA identification. The default is the prefix "H32-" followed by a unique identifier for each ESP32 (part of the MAC address). |
| LED Pin | This pin is used for the LED signaling the current state. Can be turned off with the value 0. |
| Additional Trigger Pin | If this pin is set and not 0, it is used as an additional trigger pin to enter the portal mode. You can connect a button to GND or simply connect the pin to GND using a cable. |
| WeFi Connection Timeout | The WiFi connection timeout determines how long the H32_Basic tries to connect to the network before giving up. If the connection attempt was unsuccessful, dynamic backoff will be used to determine the sleep time. |
Here is a screenshot of my configuration:
Here we configure the RTC-controlled sleep time (in which the H32 is in low power mode), the dynamic backoff factor and the backoff limit.
Whenever the H32 gets a connection to the WiFi network and transmits its data, it afterwards sleeps for "sleep time" seconds. In the configuration shown in the screen shot this is 60s.
If the connection to WiFi was unsuccessful, then the sleep time is multiplied by the RTC backoff factor. In the configuration shown below this value is 1.5,so, if this happens the first time, then new sleep time is 90s. If after the 90s the connection was successful we are back at 60s. But if we again have problems connecting to the network, the 90s will again be multiplied by the backoff factor, leading to a sleep time of 135s, and an overall backoff factor of 2.25 (1.5 * 1.5). After the 135s, the next connection attempt is started. If successful, we are again back at 60s. But if we are unsuccessful for the third time, we multiply again, and we are now at a backoff factor of (1.5 * 1.5 * 1.5) or 3.375. Thus the effective sleep time will be 202.5s. This goes on until the overall backoff factor exceeds the RTC Backoff Limit, which in our screenshot is 4.00. So, if we are unsuccessful for a fourth time, the backoff factor would be (1.5 * 1.5 * 1.5 * 1.5) or 5.0625. This will be capped to the limit, so the resulting factor will be 4.0 (leading to 240s sleep time) for all the remaining unsuccessful attempts.
This allows us to very finely adjust the backoff algorithm to our needs and to the situation of the H32.
| Option | Description |
|---|---|
| RTC Sleep Time in seconds | Basic sleep time that is used whenever the last WiFi connection attempt was successful |
| RTC Backoff Factor | The backoff factor is used to determine the multiplier for the sleep time in case of unsuccessful attempts (factor^unsuccessful attempts) |
| RTC Backoff Limit | The limit is used as the maximum backoff factor that caps the calculated backoff factor after a larger number of unsuccessful events |
Here is a screenshot:
Configuration of the Voltage Measurements
The H32 can measure battery voltage and external voltage directly. You can measure other voltages as well, but you have to use the extension mechanism (see User Extensions) to implement this.
Depending on the exact revision of the H32, different pins are used for the voltage measurements. In addition, starting with revision 2 of the H32 a switch allows to turn the voltage divider for the battery measurement on and off. This further reduces power consumption.
Since the voltage is measured using a voltage divider, and since each ESP32 ADC has its own deviations from a perfect measurement, for both battery and external voltage measurement a polynomial compensation function is offered. This can be configured using a coefficient and a constant. For an explanation read Compensating Measurement Errors.
| Option | Description |
|---|---|
| Battery Measurement Activation Pin | The activation pin turns the voltage divider for the battery measurement on and off. A posivite pin number configures the pin as active high, a negative pin number as active low. |
| Battery Voltage Compensation Coefficient | This is the coefficient used for compensating the measurement error. |
| Battery Voltage Compensation Constant | This is the constant used for compensating the measurement error. |
| Battery Voltage Pin | This is the pin on which the battery voltage is measured. |
| External Voltage Compensation Coefficient | This is the coefficient used for compensating the measurement error. |
| External Voltage Compensation Constant | This is the constant used for compensating the measurement error. |
| External Voltage Pin | This is the pin on which the battery voltage is measured. |
Here is a screenshot:
The H32_Basic firmware can send its data to different cloud services. These take additional data which can be entered in the API key field and the API Additional Value field.
Only one cloud service is configurable. MQTT can be used in parallel, though. See Cloud Services for details.
| Option | Description |
|---|---|
| Service Type | The service type can be chosen from the dropdown menu. |
| API Key | The API key is the general key that allows write access to different feeds |
| API Additional Value | The additional value differs from service to service but generally identifies a specific feed |
Here is a screenshot:
MQTT configuration is straightforward and offers the server name and port, a topic with a maximum length of 100 characters (as specified for MQTT), the user and password if needed. If your MQTT server doesn't use access control, leave these fields blank.
The measurements will be written under the given topic as a JSON document. This document contains a list of data points for every measurement type (e.g. "temperature: [{21.2}]"), even though currently only one data point is used. This allows to send multiple data points if necessary (e.g., in a user extension).
| Option | Description |
|---|---|
| MQTT Server | The MQTT server. This can be either a DNS name or an IP address. |
| MQTT Port | The port is generally 1883, but you can configure a different port, if necessary. |
| MQTT Topic | The MQTT topic can be up to 100 characters long. |
| MQTT User | The MQTT user. Leave blank if not needed. |
| MQTT Password | The MQTT password. Leave blank if not needed. |
Here is a screenshot:
The NTP configuration allows you to set the NTP server from which you request the current time and date (only during the portal mode), the timezone offset and the daylight offset for the location where the H32 is placed. If you don't know it, simply look it up for your area (or look into the next Unix system's configuration).
| Option | Description |
|---|---|
| NTP Server | The NTP server used to request the time information. |
| NTP Timezone Offset | The offset of the timezone you are in. |
| NTP Daylight Offset | The offset in hours when daylight saving time is active (whether it is active is determined by the NTP server). |
Here is a screenshot:
