FAQ: How to read AlphaMon Boot Logs – The AlphaMon Platform

When you first power on your AlphaMon or reset it, the device performs a series of self-checks and configuration steps. By connecting your AlphaMon to a computer via USB and using a third-party “Serial Monitor” app such as Putty you can watch this process in real-time.

Understanding this log is the best way to verify your AlphaMon is working correctly. You can also modify configuration settings and troubleshoot connection issues using the log.

Device Identification

The very first lines you see come from the AlphaMon’s central processor. This section identifies the specific hardware and software version you are running, as shown in the log trace example below.

ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x1 (POWERON),boot:0x2b (SPI_FAST_FLASH_BOOT)

Welcome to The AlphaMon Platform
LoRa Energy Monitor
AlphaMon V4.17.3
Built: May 1 2026 15:58:36 
(c)2023-26 Solargy Innovation
https://AlphaMon.net
Free RAM: 223008 bytes
MAC:64E833-637690

What is being checked here?

1. Hardware Power-On (rst: 0x1 POWERON)

This confirms why the device started. In this case, it was a clean “Power On” reset (someone plugged it in or flipped the switch).

2. Firmware Version (AlphaMon V4.17.3)

This tells you exactly which version of the AlphaMon “Firmware” (the internal software) is installed. Knowing the Build Date is critical if you ever need support, as it tells us if your device is eligible for an OTA Update.

Term Alert: OTA (Over-the-Air) Update: This is a method of updating the AlphaMon’s software wirelessly over your WiFi, similar to how your smartphone updates its operating system.

3. Memory Check (Free RAM)

The AlphaMon checks its internal memory (RAM) to ensure there is enough “breathing room” to process energy data, manage your WiFi connection, and run complex mathematical expressions.

4. The MAC Address (MAC: 64E833-637690)

Every AlphaMon in the world has a unique MAC Address. Think of this as the device’s permanent, physical fingerprint.

The first half (64E833): Identifies the manufacturer of the processor.
The second half (637690): Is unique to your specific AlphaMon.
This ID is used to build your unique MQTT Device ID and your WiFi Access Point name.

ESP32 Setup

The term “ESP32” refers to the type of central processing unit (CPU) used by the AlphaMon device, much like terms “Intel” or “AMD” used to refer to desktop computers. The ESP32 chip set is a powerful and very popular CPU chip used in compact, portable devices like mobile phones, indoor displays and, of course, the AlphaMon.

Once restarted, the AlphaMon begins “waking up” its various storage areas and the built-in screen. Think of this as the device checking its backpack to see what tools and maps it has available for the journey ahead.

Once the AlphaMon logging has started the internal clock keeps track of the time each event takes place. you can see the time displayed in the following log example where the time of “00:00:02.0220” tells us this event tool place 02 seconds and 220 milliseconds after the CPU was restarted. These time stamps are updated to show the current time once the ESP32 has established an Internet connecting using it’s internal WiFi hardware.

The next item on each log line is the Message Priority flag, shown as “(I)” in the example below. Using the Config File settings you can filter messages based on their Message Priority level. Refer to the LOGGING_LEVEL parameter in the Config Setup section below, where the first letter of that parameter specifies the desired filter. For example, if LOGGING_LEVEL = “Warnings”, the AlphaMon will only display Error (E) and Warning (W) Message Priority logs whilst a Config File setting of LOGGING_LEVEL = “Info” will display (E), (W) and (I) message types.

Here is a list of the standard Message Priority codes and their meanings:

(E) = Error. This message type generally indicates an unrecoverable error has occurred.
(W) = Warning. Warning messages indicate a recoverable error or event has occurred.
(I) = Information. Information messages generally contain details about the device status.
(V) = Verbose. Verbose messages are generally used for detailed debugging.

**ESP32 Setup
>00:00:02.0220 (I)ESP32_Setup: Found OLED display: 128x64 
>00:00:02.0220 (I)ESP32_Setup: Found NVS storage 
>00:00:02.0281 (I)ESP32_Setup: Found SPIFFS storage. 7% used 
Directory of SP:/
  DDS6619.417   Size:  4617                     
  AlphaMon.cfg  Size:  2198                     
  ACR10R-D.417  Size:  4348  2026-04-18 03:58:57
  SMILE5.417    Size: 89449  2026-04-18 03:58:59
  Total: 4 file/s  100612 Byte/s 

>00:00:02.0373 (I)ESP32_Setup: Found SD Card: Type=3 Size=29988MB Used=1MB Free=29987MB 
Directory of SD:/
  AlphaMon.cfg  Size:  2393                     
  ALPHA5KW.417  Size:119262  2026-04-15 02:40:24
  Solargy.tmp   Size:   955  2024-12-17 13:59:08
  GEN24.417     Size: 15620  2026-04-18 13:59:48
  ACR10R-D.417  Size:  4348  2026-04-18 13:59:40
  DDS238-7.417  Size:  5959  2026-04-21 14:30:38
  DDS665.417    Size:  5302  2026-04-21 16:24:48
  DDS6619.417   Size:  4617  2026-04-25 16:49:30
  DTSU666.417   Size:  4345  2026-04-21 14:08:04
  SMILE5.417    Size: 89449  2026-04-18 13:59:36
  Total: 10 file/s  252250 Byte/s 
 
ESP32 Setup ✅ OK

What is being checked here?

1. The OLED Display (128x64)

The AlphaMon confirms it can talk to its built-in screen. The tiny built-in display shows you real-time power usage and system alerts but a more comprehensive source of information is ths log we’re currently reviewing.

2. NVS Storage (The “Safe”)

NVS stands for Non-Volatile Storage. This is a small, protected area of memory where the AlphaMon keeps its most important secrets, like your WiFi password and security keys. Even if the power is cut, the “Safe” remembers this information.

3. SPIFFS (The “Internal Hard Drive”)

SPIFFS is the AlphaMon’s built-in filing system. As you can see in the directory list (SP:/), this is where the device stores:

DDF Files (ending in .417): These are “Device Driver Files”—the instruction manuals that tell the AlphaMon how to talk to specific meters and inverters (like the AlphaESS SMILE5 battery inverter, the SinoTimer DDS6619 bi-directional smart energy meter or even your own Modbus-enabled device).
AlphaMon.cfg: Your custom configuration file that holds your specific settings.

4. The microSD Card (The “External Library”)

If you have a microSD card inserted, the log will show its size and type. The AlphaMon uses the SD card for long-term data logging and as a backup for your configuration files. If no card is found, the device simply switches to using its internal SPIFFS memory, so it never stops working!

You may note there are more files on the microSD card than on the internal SPIFFS drive. That’s because the AlphaMon firmware will pull the required files from the microSD based on the Configuration File settings you specify. Only the files actually required for operation are pulled across, which happens in a “file sync” operation which you’ll see later in the log.

Config Setup

Now the AlphaMon has its “heartbeat” and can access its storage, it needs to know how you want it to behave. It does this by loading your custom settings from the AlphaMon.cfg file. Think of this as the AlphaMon reading its daily “To-Do” list.

After location and reading the AlphaMon.cfg file on the internal SPIFFS drive the AlphaMon lists its current Configuration File settings so you can double-check which settings are currently in use. Later you’ll see there are Command Line Interface (CLI) options to edit, backup and reload your Config File preferences.

The Config FIle Listing automatically hides sensitive information such as your local WiFi password, as in the log file example below.

**Config setup
WiFi reconnect to www.littlepond.com.au_EXT2G
WiFi=Yes Inet=Yes NTP=No Zone=No (2190ms)
Load settings..
Opening Config file SP:/AlphaMon.cfg
Config_Read: 5 value/s read
Updating SP:/AlphaMon.cfg 
Config_Write: 62 line/s written
Config_Save OK
List Config Settings:
  CONFIG_VERSION = 4.17.3
  PCB_VERSION = 2.3
  ALPHAMON_ID = "MAC:64E833-637690"
  ALPHAMON_LOCATION = "Not set. Update Config"
  DEVICE_LOAD = "DDS6619, ACR10R-D, SMILE5"
  LOCAL_TIME_ZONE = "Australia/Sydney"
  LOCAL_TIME_DEFAULT = "+11:00"
  LOGGING_LEVEL = "Verbose"
  KEYBOARD_ECHO = "Y"
  LORA_ENABLED = "Y"
  LORA_FREQUENCY = 915.0
  LORA_BANDWIDTH = 31.25
  LORA_SPREAD_FACTOR = 10
  LORA_TX_POWER = 22
  LORA_TX_INTERVAL = 250
  LORA_1 = "00:00:00:00:00:00"
  LORA_2 = "00:00:00:00:00:00"
  LORA_3 = "00:00:00:00:00:00"
  LORA_4 = "00:00:00:00:00:00"
  LORA_5 = "00:00:00:00:00:00"
  VALET_1 = "00:00:00:00:00:00"
  VALET_2 = "00:00:00:00:00:00"
  VALET_3 = "00:00:00:00:00:00"
  VALET_4 = "00:00:00:00:00:00"
  VALET_5 = "00:00:00:00:00:00"
  VALET_TTL = 180
  VALET_SCAN_MS = 1500
  VALET_SCAN_INTERVAL = 20
  OLED_ENABLED = "Y"
  OLED_DISPLAY_TIME = "5"
  GRAPH_TIME_SOURCE = "GRID"
  GRAPH_TIME_MODE = PEAK
  GRAPH_TIME_INTERVAL = 60
  WIFI_SSID = "www.littlepond.com.au_EXT2G"
  WIFI_PWD = "****"
  AP_SSID = "AlphaMon"
  AP_PWD = "****"
  UDP_PORT_LOG = 4216
  UDP_PORT_INPUT = 4217
  GATEWAY_STATIC_IP = "192.168.10.201"
  GATEWAY_SUBNET_MASK = "255.255.255.0"
  GATEWAY_ROUTER_IP = "192.168.10.1"
  MODBUS_TCP_PORT = 502
  MODBUS_TCP_SLAVE = "85"
  NTP_SERVER_1 = "time.google.com"
  NTP_SERVER_2 = "0.freebsd.pool.ntp.org"
  MQTT_SERVER = "mqtt.solargy.com.au"
  MQTT_PORT = 1883
  MQTT_ROOT = "AlphaMon:Demo"
  MQTT_ENTITY = "demo_entity_1"
  MQTT_ACCOUNT = "demo_account_1"
  MQTT_USERNAME = "mqtt_test"
  MQTT_PWD = "****"
  GRID_IMPORT_MAX_WATTS = 32000
  GRID_EXPORT_MAX_WATTS = 32000
  EXPN_1 = "GPIO:GENLED = (MOD(LOCAL:SS, 2) == 0)"
  EXPN_2 = "GPIO:GENSTART = (DDS6619:Volts<230.5)"
  EXPN_3 = ""
  EXPN_4 = ""
  EXPN_5 = ""
Config setup ✅ OK

Specifically note the following line in the Config File above, which tells the AlphaMon which external Modbus-enabled devices we want to connect to in the current setup. This line tells the AlphaMon; “I want to connect to three external Modbus devices, namely a SinoTimer DDS6619 smart meter, an Acrel ACR10R-D smart meter and an AlphaESS SMILE5 5kW hybrid inverter and battery”. You can edit the DEVICE_LOAD parameter to specify your own selection of DDFs to match your personal, site-specific requirements.

DEVICE_LOAD = "DDS6619, ACR10R-D, SMILE5"

The listed device names are references to Device Definition Files (DDFs) stored on the AlphaMon’s internal SPIFFS drive, which are discussed later in this tutorial.

What is being checked here?

1. The “Fast Connect” WiFi Step

Before reading the config file, the AlphaMon checks its NVS (Safe) for the last WiFi network it successfully used.

The Benefit: It attempts a “Fast Connect” immediately. As you can see in the log, it took only 2190ms (about 2 seconds) to get back online.
Status Check: It confirms WiFi=Yes and Inet=Yes (Internet is working), but NTP=No (it hasn’t synchronised the time yet).

2. Factory Defaults vs. User Preferences

The AlphaMon is smart about how it handles settings:

Step 1: It loads “Factory Defaults” into memory (safe starting values).
Step 2: It looks for your custom file (AlphaMon.cfg).
Step 3: It overwrites the defaults with your specific settings (e.g., your LoRa frequency or MQTT server).

3. Automatic Housekeeping (Config_Write)

You might notice the log says 62 line/s written. If your config file is missing new settings from a recent firmware update, the AlphaMon automatically adds them for you with safe default values. It keeps your configuration file clean and up-to-date without you having to lift a finger.

4. The “Expression Evaluator” (EXPN_1)

In the list of settings, you’ll see lines like EXPN_1. These are Expressions—custom logic rules you’ve written. In this example, the user has a rule to toggle an LED light (GENLED) based on the time. We will see these “compiled” and put to work later in the boot log.

Key Terms in this Section

SSID: This is simply the “Public Name” of your WiFi network (e.g., “Home_WiFi”).
Parameters: These are individual settings, like LORA_FREQUENCY.
NTP (Network Time Protocol): A system used by the AlphaMon to ensure its internal clock is perfectly accurate by checking in with a time server on the internet.

WiFi Setup

After loading your preferences, the AlphaMon attempts to establish a wireless connection. It is designed to be “resilient,” meaning it will try multiple ways to get online before falling back to its own internal hotspot.

**WiFi setup
WiFi setup ✅ OK

What is being checked here?

1. Connection Mode (Station vs. Access Point)

The AlphaMon firmware checks your configuration to decide how to act:

Station Mode (STA): The AlphaMon acts like your phone or laptop, connecting to your home WiFi router.
Access Point Mode (AP): If no WiFi is found, the AlphaMon becomes its own “Mini-Router.” You can connect your phone directly to it (look for “AlphaMon_XXXXXX”) to change settings or view data.

2. The “Fast Connect” Logic

To get you up and running quickly, the AlphaMon uses a “Lean” connection attempt first. It pulls your last successful WiFi name (SSID) and password from the internal “Safe” (NVS memory) and tries to reconnect. Usually, this happens in under 2 seconds!

3. IP Address Assignment

Once connected, your router gives the AlphaMon a unique IP Address (e.g., 192.168.1.50). The AlphaMon saves this and uses it to communicate with other devices on your home or work network.

Term Alert: IP Address: A unique numerical label assigned to each device connected to a computer network. Think of it as the mailing address for your AlphaMon on your home network.

4. Internet & Time Readiness

As soon as the WiFi is “Ready,” the AlphaMon immediately attempts two background tasks:

Internet_Connect: Verifies that it can actually reach the outside world, not just your router.
Time_Connect: Starts looking for a time server so it can date-stamp log events accurately.

Key Terms in this Section

SSID: The public name of your WiFi network.
Credentials: Your WiFi username and password.
Station (STA): A mode where the AlphaMon connects to a router.
Access Point (AP): A mode where the AlphaMon acts as the router for setup purposes.

.RS485 Setup

Now that the AlphaMon is online, it needs to prepare its primary physical port to enable Modbus communications. The RS-485 port is designed to carry data over long distances with high reliability. It is the standard way that solar inverters and smart meters talk to the world.

**RS485 setup
>00:00:07.0230 (I)RS485_Setup: Set RS485 to 9600 8N1, Rx=7, Tx=6 
RS485 setup ✅ OK

What is being checked here?

1. Baud Rate (9600)

The Baud Rate is the speed at which data travels over the wire. Both the AlphaMon and your Inverter must “speak” at the same speed to understand each other. The default is 9600 bits per second (bps), which is the “gold standard” for stability in solar monitoring.

2. Data Framing (8N1)

Data Framing is a technical shorthand for how each “packet” of data is wrapped.

8 bits of data.
No parity (no extra error-checking bit).
1 stop bit (signalling the end of a byte).
Almost every modern Modbus device uses this specific setting.

3. Pin Mapping (Rx=7, Tx=6)

The AlphaMon processor confirms it has assigned its internal pins to handle the incoming (Rx – Receive) and outgoing (Tx – Transmit) signals. By showing you these numbers, the log helps you verify that the firmware is correctly aligned with the physical circuit board version you are using.

Key Terms in this Section

RS-485: A physical communication standard that uses two wires to send data reliably, even in “noisy” electrical environments like a power board or cabinet.
Rx / Tx: Receive and Transmit. The two communication channels of the RS-485 bus.
Modbus: The software language (or protocol) that travels over the RS-485 wires.

Device Setup

The AlphaMon doesn’t just talk to a single type of inverter, battery or smart meter; it can speak the language of many brands and models. It does this using Device Driver Files (or DDFs, for short). Each DDF on the AlphaMon’s internal SPIFFS drive describes a single inverter, battery system, smart meter or other Modbus-enabled device.

You can identify the DDFs in the example log file listing below because each DDF file name ends in “.417”. The “.417” signifies the AlphaMon firmware version that supports this DDF; namely Version 4.17.x. Later firmware versions are typically backwards compatible with existing DDF files

In the Device Setup phase, the AlphaMon identifies which external Modbus devices you want to install and prepares its memory to handle them. Refer to the Config Setup section above to see how the list of DDFs to be loaded is specified by the DEVICE_LOAD parameter of the AlphaMon.cfg Config File.

**Device setup
Config:DEVICE_LOAD is 'DDS6619, ACR10R-D, SMILE5'. 3 device/s
>00:00:07.0665 (V)File_Sync: /DDS6619.417 OK 
>00:00:08.0236 (V)File_Sync: /ACR10R-D.417 OK 
>00:00:09.0176 (V)File_Sync: /SMILE5.417 OK 
>00:00:10.0901 (I)Device_LoadStatus: #1 Built-in (Alias GPIO) OK 
>00:00:11.0196 (I)Device_LoadStatus: #2 /DDS6619.417 (Alias DDS6619) OK 
>00:00:11.0680 (I)Device_LoadStatus: #3 /ACR10R-D.417 (Alias ACR10R) OK 
>00:00:14.0784 (W)Alias_Add: Skip dup. Alias 'BFAULT1' for Device #4 
>00:00:15.0289 (I)Device_LoadStatus: #4 /SMILE5.417 (Alias SMILE5) OK 
>00:00:15.0290 (E)Device_Setup: Disable ACR10R (Dup. SlaveID #1) 
Loaded 3 device/s
Device setup ✅ OK

What is being checked here?

1. The Sync Phase (File_Sync)

Before loading, the AlphaMon checks if there are newer versions of the driver files on your microSD card (if connected). If it finds a newer file, it automatically copies it to the internal high-speed memory (SPIFFS). This ensures your device is always running the latest DDFs.

Technical Note: A DDF is a Json formatted text file containing information about the device and its registers, as shown in the opening snippet of the DDS6619.417 file below. The "rev": "22" line, near the top, tells the AlphaMon the DDF contains the 22nd revision of the data, which supersedes a DDF with "rev": "21" and earlier. Thus for example, if your microSD contains rev 22 of this file and SPIFFS contains rev 21 or less the AlphaMon will automatically overwrite the SPIFFS version of the file with the newer version from your microSD card during the Sync Phase.

The DDF Revision Number is automatically assigned by the AlphaMon support team from our database of popular brands and models and thus the “rev” number shouldn’t be manually edited. If you need to edit a DDF then you can keep track of your changes by incrementing the “patch” number. The Patch Number is always reset to zero when AlphaMon Support releases an official update of the DDF.

{
  "slug": "DDS6619",
  "ver": "4.17",
  "rev": "22",
  "patch": "0",
  "device": {"cClass": "M", "eType": 0, "cUserName": "SinoTimer DDS6619", "cMake": "SinoTimer", "cModel": "DDS6619", "cAlias": "DDS6619", "cSerialNo": "", "ui8SlaveId": 1, "ui16Baud": 9600, "ui16TTL_Secs": 300, "ui32MaxSolar": 0, "ui32MaxUps": 0, "ui32MaxGrid": 22000, "ui32LoRaSecs": 0, "ui32MqttSecs": 0},
  "registers":
    [

2. Building the “Internal Map”

The AlphaMon performs a two-pass scan of every DDF:

Pass 1: It “counts” how many data points (registers) are in the file to allocate exactly the right amount of memory. This keeps the device fast and efficient.
Pass 2: It loads the data into working memory, creating an internal dictionary of terms like Volts, Watts, and Battery SoC, known as Aliases. An Alias is simply a short name for devices and registers that normally many have much longer working names, often specified by the device manufacturer.

3. Handling Conflicts (Disable ACR10R)

The AlphaMon is self-policing. In this log, it detected two devices (the DDS6619 and the ACR10R) both trying to use Slave ID #1 on the RS-485/Modbus bus. To prevent data corruption, the AlphaMon automatically disabled the second device and alerted you in the log. This is a clear signal that you need to change the ID on one of your meters by patching the DDF and also changing the settings on the connected 3rd party device.

4. The “Built-in” Device (#1 GPIO)

You will always see “Device #1” as the Built-in GPIO. This is the AlphaMon itself! It treats its own internal pins (for buzzers, LEDs, and switches) as a device, allowing you to use them in your custom logic just like an external meter.

Key Terms in this Section

DDF (.417): A “Device Driver File.” A unified asset file that tells AlphaMon exactly how to read a specific piece of equipment.
Alias: A friendly, shortened name for a complex data point. Instead of “Register 0x001D”, you can just use the word “Watts”.
Duplicate Alias: A warning triggered when two different pieces of data try to use the same name.

Alias Setup

In the previous step, the AlphaMon loaded the DDF files. Now, it organises all that information into a master list called the Alias Table. This is one of the AlphaMon’s most powerful features: it allows you to use simple words like “VOLTS" or “BATTSOC" in your scripts instead of complex register numbers or device names.

**Alias Setup
|  #  | Alias        | Device Alias | Dev#| Reg#| Device: Reg/Pin Name
| 001 | ACR10R       | ACR10R       | 003 | 000 | Acrel ACR10R-D 
| 002 | AMPS         | DDS6619      | 002 | 002 | SinoTimer DDS6619: Current                   
| 003 | BATTAMPS     | SMILE5       | 004 | 032 | AlphaESS SMILE5: REG_BATTERY_HOME_R_CURRENT 
| 004 | BATTCAP      | SMILE5       | 004 | 056 | AlphaESS SMILE5: REG_BATTERY_HOME_R_BATTERY_CAPACITY 
| 005 | BATTCOUNT    | SMILE5       | 004 | 055 | AlphaESS SMILE5: REG_BATTERY_HOME_R_BATTERY_NUMBER 
| 006 | BATTREADY    | SMILE5       | 004 | 125 | AlphaESS SMILE5: REG_SYSTEM_CONFIG_RW_BATTERY_READY 
| 007 | BATTRELAY    | SMILE5       | 004 | 035 | AlphaESS SMILE5: REG_BATTERY_HOME_R_RELAY_STATUS 
| 008 | BATTRESSOC   | SMILE5       | 004 | 133 | AlphaESS SMILE5: REG_TIMING_RW_UPS_RESERVE_SOC 
.
.
| 208 | UPSAMPS      | SMILE5       | 004 | 092 | AlphaESS SMILE5: REG_INVERTER_HOME_R_BACKUP_CURRENT_L1 
| 209 | UPSVOLTS     | SMILE5       | 004 | 091 | AlphaESS SMILE5: REG_INVERTER_HOME_R_BACKUP_VOLTAGE_L1 
| 210 | UPSWATTS     | SMILE5       | 004 | 093 | AlphaESS SMILE5: REG_INVERTER_HOME_R_BACKUP_POWER_L1_1 
| 211 | UPSWATTSTOT  | SMILE5       | 004 | 094 | AlphaESS SMILE5: REG_INVERTER_HOME_R_BACKUP_POWER_TOTAL_1 
| 212 | VOLTS        | DDS6619      | 002 | 001 | SinoTimer DDS6619: Voltage                   
| 213 | WATTS        | DDS6619      | 002 | 003 | SinoTimer DDS6619: Active power              
| 214 | WORKMODE     | SMILE5       | 004 | 108 | AlphaESS SMILE5: REG_INVERTER_HOME_R_WORKING_MODE 
Alias Setup ✅ OK

What is being checked here?

1. Human-Readable Mapping (Alias)

The AlphaMon takes the Alias (the short name) and links it to a specific Device Number (Dev#) and Register Number (Reg#).

You might notice multiple devices can have similar data. The Device Alias column (like “SMILE5" or “DDS6619") acts as an anchor for the registers within each device. For example, if you have two meters that both measure volts, you can specify SMILE5:VOLTS or DDS6619:VOLTS to be precise, using the device Alias as a prefix. Note: Device aliases appear in the Alias Listing with a REG# value of 0.

2. Search Efficiency

Behind the scenes, AlphaMon maintains this entire alias table sorted alphabetically. This allows the AlphaMon to perform fast binary searches, ensuring your custom logic rules run instantly without lagging the device.

Key Terms in this Section

Alias: A shorthand name for a device or register (e.g., “BATTAMPS” instead of “Modbus Register 32“).
Register (Reg#): A specific “slot” in an external device’s memory that holds a single value, like current temperature or total power.

Modbus setup

Modbus is a universal communications protocol for industrial and renewable energy equipment. In this next log phase, the AlphaMon reaches out to every device you’ve configured to see if they are “awake” and ready to share data.

The AlphaMon is sophisticated: it attempts to connect using TCP over your business or home local area network (LAN) and RTU (over physical wires) to ensure it finds the most reliable path to your data, as shown in the following log trace.

**Modbus setup
>00:00:17.0426 Modbus_Setup: Config Modbus TCP IP=192.168.10.201, Port=502 
Modbus TCP connect FAIL (250ms)
>00:00:20.0791 Modbus_RtuConnect: DDS6619 Try RTU Slave=1 FC=4 Baud=9600 Addr=0x0000 Size=1 SUCCESS 
>00:00:22.0137 Modbus_RtuConnect: SMILE5 Try RTU Slave=85 FC=3 Baud=9600 Addr=0x0000 Size=1 FAIL [Timeout] 
>00:00:22.0143 Modbus_Setup: Connected 1 RTU & 0 TCP device/s 
Modbus setup ✅ OK

What is being checked here?

1. Smart Failover (RTU vs. TCP)

The AlphaMon firmware is programmed to be thorough. As seen in this log example it first tests for a hard-wired connection (RTU). If that doesn’t answer, it automatically attempts a network (TCP) connection over your LAN using it’s built-in WiFi hardware. This dual-path approach ensures that if you migrate your inverter from a wired connection to a WiFi bridge, the AlphaMon adapts automatically.

2. Network Discovery (TCP connect FAIL)

The AlphaMon checks your configured Gateway IP (e.g., 192.168.10.201).

The Log says: FAIL (250ms).
Translation: The AlphaMon reached out on the network, but no device answered on Port 502 within 250 milliseconds. This is perfectly normal if you are only using physical, wired RS-485 connection to the device.

3. The Wired Connection (RTU SUCCESS)

Next, the AlphaMon probes the physical RS-485 serial port.

DDS6619: The AlphaMon asked Slave ID #1 to read its first “Register” (Addr=0x0000). The meter replied instantly. The AlphaMon now flags this device as “Seen” and calculates how often it should be polled based on settings in the related DDF file.

4. Handling the Silence (SMILE5 FAIL [Timeout])

When the AlphaMon tried to reach the SMILE5 on Slave ID #85, it received no reply.

What this means: The hardware wiring might be loose, or the device might be powered down.
Resilience: Because at least one device connected successfully the overall Modbus Setup process returns a status of “OK”. The AlphaMon will keep trying to talk to the SMILE5 in the background, in case it becomes available, while successfully monitoring your other devices and meters.

5. Fallback: Listener Mode

If no devices are found, either hard-wired or via your LAN, the AlphaMon doesn’t give up. It enters Listener Mode. In Listener Mode mode, it “eavesdrops” for other remote AlphaMon devices on your LAN. Optionally, it cal also listen for other AlphaMon devices on your network using its built-in long range (LoRa) radio.

Key Terms in this Section

RTU / TCP: The two ways Modbus travels—either over physical wires (RTU) or your WiFi/Ethernet network (TCP).
Slave ID: The unique “Address” of your meter (like a house number).
Polling Mode: The strategy the AlphaMon uses to gather data (Master or Listener).

MQTT Setup

MQTT is an industry standard, Internet communications protocol typically used by low cost sensors and IoT devices. It is lightweight, highly reliable, fast, and designed to work even on slow connections. An MQTT server (called an MQTT Broker) is much like an email server in that it stores and forwards short messages, such as the state of charge of your battery system.

MQTT Servers/Brokers are typically used by AlphaMon users for the following purposes:

To allow remote access of battery, inverter and smart meter data; across your local LAN or even across the globe,
To allow multiple AlphaMon devices to exchange and consolidate their data, and
To allow third party apps such as Home Assistant to easily connect to and harvest data collected by AlphaMon devices.
You can also manually browse and verify the MQTT server’s data on your desktop, phone or tablet using third party apps such as the free MQTT Explorer app.

In the MQTT Setup phase, the AlphaMon connects to the MQTT Broker using the settings and credentials stored in your Config File (see the parameters prefixed with “MQTT_”) and organises its “Topics” and “Paths”, which are the specific digital folders where your data will be stored.

By changing the Config File settings you can optionally connect to one of the following:

A shared, public area on the Solargy MQTT Broker service, located at mqtt.solargy.com.au (good for testing),
A private, leased area on mqtt.solargy.com.au (god for next-stage testing), or
Your own public or private MQTT Broker (on premises or in the cloud. Good for production environments).

**MQTT setup
Connect to mqtt.solargy.com.au 
>00:00:25.0270 MQTT_Connect: mqtt.solargy.com.au CONNECTED 
>00:00:25.0278 (E)MQTT_StatusUpdate: Invalid Payload for Topic _TimeOffset 
>00:00:25.0280 (I)MQTT_Setup: PATH1=[AlphaMon:Demo/] 
>00:00:25.0280 (I)MQTT_Setup: PATH2=[AlphaMon:Demo/AM637690/] 
>00:00:25.0291 (I)MQTT_Setup: PATH3=[AlphaMon:Demo/demo_entity_1/] 
>00:00:25.0291 (I)MQTT_Setup: PATH4=[AlphaMon:Demo/demo_entity_1/Locations/Australia:Sydney/AM637690/] 
>00:00:25.0302 (I)MQTT_Setup: PATH5=[AlphaMon:Demo/demo_entity_1/Accounts/demo_account_1/] 
>00:00:25.0314 (I)MQTT_Setup: PATH6=[AlphaMon:Demo/demo_entity_1/Accounts/demo_account_1/AM637690/] 
>00:00:25.0486 (I)Device_LoadDiscovery: Pub 5 HA topic/s for DDS6619 
>00:00:27.0132 (I)Device_LoadDiscovery: Pub 32 HA topic/s for SMILE5 
MQTT setup ✅ OK

What is being checked here?

1. Establishing the Connection

The AlphaMon checks if it has an internet connection and then attempts to log into the MQTT server/ message broker using the credentials specified in your Config File; in this case mqtt.solargy.com.au.

The Log says: CONNECTED.
What happens next: The AlphaMon immediately sends a “Status Update” to let the system know it is alive and well.

2. Building the Topic Hierarchy (The “Sandbox”)

To keep your data private and organised, the AlphaMon dynamically builds “Paths.” Instead of just throwing data into a single topic/folder, it uses a hierarchical folder structure:

PATH2 (The Flat Path): This is where your raw device data goes (e.g., Watts or Volts). It uses a unique ID (AM637690), which is automatically calculated from your AlphaMon’s MAC address, so your data never gets mixed up with anyone else’s.
PATH4 (Location-based): This includes your Time Zone (Australia:Sydney). This allows users with multiple global sites to see exactly where their data is coming from.

3. Home Assistant Auto-Discovery (HA topic/s)

The AlphaMon is designed as a “Plug-and-Play” solution for Home Assistant (HA) users, utilising Home Assistant’s “MQTT Discovery” method for locating and identifying data sources. During the Discovery step the AlphaMon creates links, much like links on a web page, that are used by HA to locate AlphaMon’s data.

NOTE: HA normally expects the Discovery links to be located in the “homeassistant/” folder or topic, however you may need to edit that setting in HA using the information provided here.

The Log says: Pub 32 HA topic/s for SMILE5.
Translation: The AlphaMon has just configured the MQTT broker Discovery integration so that the SMILE5 hybrid inverter is visible to a Home Assistant user. The Discovery step automatically tells Home Assistant what sensors are available, what they are named, and what units or measurement they use (like Watts or %). You don’t have to write a single line of configuration in Home Assistant!

Key Terms in this Section

MQTT Broker: The central store-and-forward message server that receives data from the AlphaMon and sends it to your HA dashboard and/or other AlphaMon devices.
Topic/Path: The MQTT’s digital folder or address for a specific piece of data.
Home Assistant (HA): A popular open-source smart home platform that the AlphaMon supports “out of the box.”
Discovery: A feature where the AlphaMon automatically configures itself in your smart home software.
Payload: The actual content of the message (e.g., the number “230.5" inside the MQTT message labelled “Volts").

LoRa Setup

LoRa stands for “Long Range.” It is a radio technology that allows the AlphaMon to send and receive data packets over several kilometres using very little power, but typically using very low data rates. Find out more about LoRa here and here.

In this next boot-up phase, the AlphaMon tunes its radio to the correct “channel” so it can talk to other AlphaMon devices in your network.

**LoRa setup
>00:00:27.0137 (I)LoRa_Setup: Freq: 915.00 MHz 
>00:00:27.0137 (I)LoRa_Setup: Bandwidth: 31.2 kHz 
>00:00:27.0149 (I)LoRa_Setup: Spreading Factor: 10 
>00:00:27.0149 (I)LoRa_Setup: TX power: 22 dBm 
>00:00:27.0210 (I)LoRa_Setup: LoRa Connected 
LoRa Start Rx Mode
Waiting for data
LoRa setup ✅ OK

What is being checked here?

1. Regional Frequency (915.00 MHz)

Radio laws vary by country. In this log, the AlphaMon is set to 915 MHz, which is the legal frequency for “unlicensed” radio use in Australia and the USA. “Unlicensed” means you don’t need a radio operator’s license to transmit radio signals, provided you stay within the maximum power and related regulatory requirements applicable to your country. Unlicensed radio bands are also often called the ISM radio band.

The AlphaMon automatically adjusts this based on your configuration to ensure you stay legal. Note: AlphaMon devices don’t support all frequencies used in all countries, however you can custom order an AlphaMon to suit your local legal frequency ranges. For example, China and Europe use different frequency ranges compared to the USA and Australia.

2. Tuning the Signal (Bandwidth & Spreading Factor)

These following technical settings affect the maximum range and transmission speed:

Spreading Factor (10): This determines how much the signal is “stretched.” A higher number makes the signal much more likely to punch through thick walls or travel long distances, but it makes the transmission slower.
Bandwidth (31.2 kHz): This is the width of the radio lane the AlphaMon is using, which determines the transmission speed.

3. Transmission Power (22 dBm)

This is the “volume” of the radio’s voice. At 22 dBm, the AlphaMon is speaking at its maximum legal volume to ensure your data reaches the receiver, even in difficult terrain.

4. The “Listener” State (Rx Mode)

The AlphaMon is now sitting in Rx (Receive) Mode.

Waiting for data: Since this specific AlphaMon didn’t find another local AlphaMon to transmit to it automatically assumes it is a Receiving Station. It is now “listening” to the airwaves, waiting for other AlphaMons in the area to send their data so it can forward it to your dashboard.

5. Error Checking (CRC)

The code shows a. CRC (Cyclic Redundancy Check). A CRC is a mathematical checksum placed on every radio packet. When the AlphaMon receives a signal, it checks the CRC to ensure the data wasn’t corrupted by static or background noise during its journey through the air. Data packets with invalid CRC checksums are automatically ignored.

Key Terms in this Section

LoRa: A low-power, long-range wireless technology perfect for sending energy data where WiFi can’t reach.
MHz (Megahertz): The unit of measurement for radio frequency.
dBm: A unit used to measure the power of a radio signal.
ISR (Interrupt Service Routine): A high-priority “alarm” in the code. When a radio packet arrives, the ISR instantly tells the processor to stop what it’s doing and save the data.
CRC: An automatic method of ensuring LoRa data is received without errors.

NTP Setup

The AlphaMon Platform adds a timestamp to every event and reading, using both Local Time (adjusted for Daylight Savings where applicable) and global Coordinated Universal Time, also known as “UTC” time.

To ensure the timestamps are always accurate and synchronised the AlphaMon reaches out to atomic clocks on the Internet. It also calculates your local time from the UTC time, so it knows the exact time in your home town or city.

**NTP setup
>00:00:27.0221 (I)NTP_Setup: Config NTP server/s: time.google.com, 0.freebsd.pool.ntp.org 
>00:00:27.0222 (I)NTP_GetLocalOffset: Searching https://api.ipgeolocation.io/timezone for [Australia/Sydney] 
..... 
>00:00:36.0366 NTP_GetLocalOffset: API error -1. Use Config default: [+11:00] 
>00:00:36.0367 NTP_TimeLog: UTC-0 May 01 2026 06:32:50 
>00:00:36.0378 NTP_TimeLog: UTC-0 May 01 2026 06:32:50 
>00:00:36.0378 (I)NTP_Setup: Starting AlphaMon V4.17.3 MAC:64E833637690 IP:192.168.10.133 
NTP setup ✅ OK

What is being checked here?

1. Finding the Time Servers (NTP server/s)

The AlphaMon is configured to check multiple Network Time Protocol (NTP) servers. By default, it prioritises time.google.com for its high reliability. If one server is down, it automatically moves to the next. You can specify which NTP servers are used in your Config File settings.

2. The Time Zone Detective (GetLocalOffset)

To convert UTC time to your local time and adjust for daylight savings, the AlphaMon needs to know what time zone you live in. You can specify your time zone in the Config File settings using a “country/town” format as specified in the official list of “tz” time server codes.

The Search: It reaches out to a geolocation service to find the exact time offset for your configured location (e.g., Australia/Sydney).
The Fallback: As seen in the log (API error -1), sometimes the selected Internet-based time server is busy or unreachable. In this case, the AlphaMon is smart enough to use your Config File default (+11:00) so it can keep working without delay. The AlphaMon will assume the local time is the UTC time +11 hours, until the NTP server can provide the correct time offset.

3. Perfect Synchronisation

Behind the scenes, the firmware uses a “Smooth Sync” mode. Instead of suddenly jumping the clock forward or backward (which can confuse data logs), it gradually slews the clock to match the internet time perfectly over a short period.

4. The Final Session Stamp

Once the time is set, the AlphaMon logs a “Starting” message that combines its Version, MAC Address, and IP Address. This is the definitive confirmation that the device is fully online, identifies itself correctly to the network, and knows what time it is.

Key Terms in this Section

NTP (Network Time Protocol): The standard internet language used to synchronise computer clocks.
UTC (Coordinated Universal Time): The primary time standard by which the world regulates clocks and time (also known as Greenwich Mean Time or GMT).
Offset: The number of hours and minutes your local time is ahead of or behind UTC.
API (Application Programming Interface): A way for the AlphaMon to “ask a question” of another website (like asking the Geolocation server for your time zone).

Timer Setup

Your AlphaMon follows a strict schedule. Some data needs to be sent to your MQTT server HA dashboard every minute, while other more technical information might only be needed once an hour. Other critical data such as your grid voltage needs to be monitored many times each second.

The Timer Setup phase creates the “stopwatches” that manage these different tasks.

**Timer setup
Alloc 8 dynamic & 300 static timers
Timer setup ✅ OK

What is being checked here?

1. Static Timers (The Routine Tasks)

The AlphaMon reserves 300 static timers. These are for “fixed” jobs that happen every single time the device runs, such as checking if the WiFi is still connected, flashing the status LED, or refreshing the clock.

2. Dynamic Timers (The Custom Schedule)

This is where the AlphaMon gets clever. It scans through all your connected devices (like your SMILE5 or DDS6619) and looks at your preferences for data reporting.

MQTT Schedule: How often do you want specific register data sent to the MQTT server or HA?
LoRa Schedule: How often should it broadcast over the long-range LoRa radio?
The Log says: Alloc 8 dynamic timers. In this case, the AlphaMon found 8 unique reporting intervals across your equipment and created a dedicated “stopwatch” for each one.

3. Forced Polling on Start-up

You might notice that as soon as the AlphaMon finishes booting, your dashboard updates immediately. This is because the code sets the polling interval of every register to its maximum value. This tells the AlphaMon: “You’ve just woken up, so go and get fresh data right now instead of waiting for the next scheduled interval.”

Key Terms in this Section

Static Timer: A fixed timer for essential system maintenance tasks.
Dynamic Timer: A flexible timer created automatically based on your specific device settings (e.g., Poll the register containing the “Watts” data every 10 seconds).
Polling Interval: The amount of time (in seconds) the AlphaMon waits between asking a device for new information.
Alloc (Allocate): A technical way of saying “Reserve a specific timer interval to trigger internal events such as reading a register.”

Expn. Setup

The AlphaMon doesn’t just collect data; it can act on it. Using the Expressions defined in your Config File you can tell the AlphaMon to “Turn on the pool pump if the solar export is over 3000 Watts” or “Flash a red light if the battery is low.” In the Expn. Setup phase, the AlphaMon reads, analyses and memorizes these rules and checks them for errors.

**Expn. Setup
Load Expn #1: 'GPIO:GENLED = (MOD(LOCAL:SS, 2) == 0)' OK
Load Expn #2: 'GPIO:GENSTART = (DDS6619:Volts<230.5)' OK
Expn. Setup ✅ OK

What is being checked here?

1. The Syntax Check step

Before the AlphaMon attempts to execute a rule defined in your Config File it performs a “Syntax Check.” It looks for typos, missing brackets, or unknown device and/or register names/aliases.

The Log says: OK.
Translation: The AlphaMon has successfully “compiled” your Expression, such as the displayed GPIO:GENLED = (MOD(LOCAL:SS, 2) == 0). That means it has read, analysed and translated the text from your Config File setting into a high-speed internal format which allow the AlphaMon to almost instantly calculate the result of that expression, many times a second. Sub-second response times are critical for stabilising micro-grids by enabling shedding of loads and turning on new loads to balance generation with energy demand using a technique called “Demand Response”.

2. Real-Time Logic Examples

In this specific log, the AlphaMon has loaded two powerful rules, specific to an AlphaMon user’s local site conditions:

Rule #1: GPIO:GENLED = (MOD(LOCAL:SS, 2) == 0). This rule tells the AlphaMon to look at the Local Time seconds field (LOCAL:SS) and perform a “Modulo” math operation which results in a True/False or On/Off output. The On/Off result is then used to set the value of GPIO:GENLED, which is the Alias for the AlphaMon’s on-board Generator Start LED which is connected to a General Purpose Input.Output (GPIO) pin on the ESP32. Essentially, it makes the status LED blink on and off exactly every two seconds.
Rule #2: GPIO:GENSTART = (DDS6619:Volts < 230.5). This is a protection rule. It says “if the voltage read by your SinoTimer meter drops below 230.5 Volts, the AlphaMon should instantly trigger the GPIO GENSTART pin”. The GENSTART pin or “Realy Output” might then be connected to the “two-wire start” terminals of your external backup generator or “generator set” (genset) or an alert buzzer.

3. Continuous Evaluation

Once the setup is complete, the AlphaMon enters its main loop. It runs these rules approximately every 50 milliseconds (20 times per second). This ensures that your automation logic responds to energy changes in real-time, much faster than you can manually flip a switch.

4. Safety Guardrails

If you make a mistake in a rule—like trying to divide by zero or asking for a device that isn’t plugged in—the AlphaMon won’t crash. It will catch the error, stop that specific rule, and log the error code so you can fix it in your Config File, at your leisure.

Key Terms in this Section

Syntax Checker (SC): The part of the AlphaMon firmware responsible for checking that the expressions you write are syntactically correct.
Expression Evaluator (EE): The AlphaMon firmware that constantly calculates the result of your rules and optionally applies the result to an output/s.
Modulo (MOD): A math operation that finds the “remainder” of a division. It’s often used in programming to create repeating patterns or timers. Example: The result of MOD(3, 2), which means “get the remainder of 3 divided by 2”, is 1, which also evaluates to On and True. In contrast MOD(4,2) evaluates to 0, Off and False.

Setup Complete

When you see the following log message it confirms the AlphaMon has transitioned from “Setup Mode” to “Operating Mode.” The heavy lifting of the boot process is over, and the device is now standing-by for the first packet of data to arrive from your inverter, smart meter, other Modbus-enabled device, or even another AlphaMon installed in your network.

*Setup complete. Awaiting data...

What happens now?

1. Transition to the Main Loop

The AlphaMon firmware now hands control over to the Main Loop. In this state, the processor constantly cycles through a series of high-speed tasks:

Polling: Asking your meters for their current Watts, Volts, and Amps.
Calculating: Running your custom logic rules (Expressions) many times a second.
Publishing: Sending your data to MQTT and optionally Home Assistant.
Broadcasting: Sending long-range updates via LoRa if enabled.

2. The OLED Transformation

At this exact moment, the AlphaMon clears the text from its built-in screen. To preserve the life of the display, it reduces the brightness and switches to the Graphical Interface. You will typically see:

A real-time line graph showing your grid import/export.
Status icons for WiFi, MQTT, and LoRa.
A “heartbeat” indicator showing that the system is actively processing data.

3. First Data Arrival

The very next lines you see in the log (after a few seconds) will be the raw data packets. For example:
Modbus_Pub: DDS6619:0x001D Total active power=[110.52kWh]
This confirms that the “Awaiting data” phase is over and the first real-world energy reading has been captured and formatted.

What should I look for if it gets stuck here?

If your AlphaMon says “Awaiting data” but your graphical display and/or your HA dashboard remains empty:

Check the Modbus wiring: Go back to the Modbus Setup part of the log. Did your devices say SUCCESS?
Check the Config Settings: Did any of your Expressions report an Eval Error?
Check the WiFi connection: Did the WiFi Setup, NTP Setup and MQTT Setup show CONNECTED?