Helioduino coordinates solar panels, sensors, actuators, motion drivers, scheduling, storage, logging, and optional user interfaces.

The system separates these responsibilities into objects with specific roles.

For a calculated tracking panel, the control path is roughly:

1. The controller maintains current time and location.
2. The panel calculates the native sun position locally.
3. If optional network solar-position data is available, the panel can learn a daily correction relative to the native calculation.
4. The panel applies any available daily correction and then the configured mechanical axis offset.
5. The panel resolves the desired facing position.
6. The scheduler assigns and maintains axis drivers.
7. Each driver compares the target position with the available actuator position data or output model.
8. The driver requests motion from one or more actuators.
9. Sensors and triggers enforce position, travel, environmental, and safety conditions.
10. The panel state is updated as alignment changes.

For an LDR-balanced panel:

1. Opposing LDR sensors measure light intensity.
2. The panel compares the sensors on each active axis.
3. The panel determines which direction reduces the imbalance.
4. The appropriate axis driver requests motion.
5. The process stops once the configured alignment tolerance is reached or usable light is too low.

The main Helioduino object provides system-wide services including:

• Object registration and lookup
• Update processing
• RTC and system time
• Location
• Solar and twilight calculations
• EEPROM and SD support
• Optional WiFi-backed storage
• Configuration loading and saving
• Autosave
• Sensor polling
• Scheduler
• Logger and publisher
• Optional networking
• Optional local and remote UI
• Measurement-mode configuration

Helioduino can be initialized around calculated tracking or LDR balancing.

This system mode affects the normal panel-control strategy, but the underlying object model remains reusable.

A calculated panel still uses sensors for axis feedback, wind, temperature, and power when those are installed.

An LDR-balanced panel still uses the same actuator, rail, logging, and storage infrastructure.

Calculated tracking depends on good time and location data.

A normal offline setup can use:

• RTC
• Static latitude and longitude
• Optional static altitude

GPS can be added to provide location.

The controller uses SolarCalculator for local solar position and daily twilight calculations. This keeps the basic tracking system independent of an Internet service.

The local calculation is always the baseline for calculated tracking.

An optional network source may provide solar-position data that differs slightly from the locally calculated value.

Helioduino does not treat this as a second independent tracking target.

Instead, the panel can compare network samples against the native local calculation and build a running correction for the current day.

The effective target is resolved in this order:

1. Native locally calculated solar position
2. Optional learned daily network correction
3. Mechanical or user axis offset
4. Driver target

This keeps remote data separate from the tracker installation calibration.

Only a small running average needs to be maintained. The controller does not need to store an entire day's remote solar curve.

If the network disappears after a useful correction has been learned, the current correction remains active for the rest of that day. The tracker therefore does not jump back and forth between slightly different local and remote targets as connectivity changes.

At the next date change, the learned correction is cleared and can be learned again from new samples.

If network solar-position data is never available, calculated tracking continues normally using the native SolarCalculator result.

See Panels for the panel-level tracking behavior.

Helioduino can save system and object configuration as JSON or binary data.

Typical backing stores include EEPROM and SD card. WiFi-backed storage is optional.

System data contains settings such as:

• System and measurement modes
• Time-zone offset
• Polling interval
• Autosave mode
• Location
• Scheduler settings
• Logger and publisher settings
• Optional network configuration

See Objects & Data for the runtime-object and serialized-data relationship.

The scheduler owns the larger daily tracking process rather than individual motors.

The sequence is:

Init → Warm → Uncover → Clean → Track → Cover

This gives the controller places to coordinate de-icing, covers, cleaning, normal tracking, night return, and storm-related behavior.

Motion details remain the responsibility of the axis drivers and actuators. Free-running relay motors can account for expected mechanical coast so the scheduler does not need to manage that behavior itself.

See Drivers & Scheduling.

A tracker does not require WiFi, Ethernet, MQTT, a cloud service, or any network connection.

Networking can add:

• MQTT publishing
• Remote UI
• Network storage
• Optional solar-position refinement
• Other integrations

The basic solar calculation, daily scheduling, panel targeting, and motion control remain local.

Optional network features are intended to add capabilities without becoming dependencies for normal tracker operation.

A loss of connectivity should therefore remove only the capability that depends on that connection. It should not prevent the tracker from continuing its normal local control process.

The GUI can be disabled or built in smaller and larger configurations depending on the target MCU.

tcMenu provides the main UI framework when GUI support is enabled.

Helioduino can run core logic tests without a physical tracker:

cmake -S tests -B build-host
cmake --build build-host
ctest --test-dir build-host --output-on-failure
python3 tests/validate_source.py

Host tests are particularly useful for driver behavior, scheduler state changes, calculations, source validation, and serialization.

Real hardware testing is still required for motor direction, limit switches, feedback sensors, actuator travel, coast behavior, structural behavior, and electrical interfaces.

Useful starting files include:

• src/Helioduino.* - controller
• src/HelioObject.* - object model
• src/HelioPanels.* - panel classes and solar-facing logic
• src/HelioDrivers.* - motion control
• src/HelioActuators.* - relays, motors, and variable outputs
• src/HelioSensors.* - sensor classes
• src/HelioTriggers.* - thresholds and ranges
• src/HelioScheduler.* - daily tracking process
• src/HelioRails.* - power limits
• src/HelioMeasurements.* - measurement data

The examples directory shows these pieces assembled into actual tracker configurations.