Configuring Ignition for Gateway Solar Calculations

On a Linux Ignition gateway, a global timer script can calculate solar values locally and write them to tags, avoiding a live web-service dependency; the shared NOAA-based sample is only a starting point, not a complete drop-in library.

Which request path fits the gateway?

For a local calculation, the data path is straightforward: the Ignition Gateway timer invokes a shared script, the script calculates values from the gateway time and configured location, and it writes results into gateway tags. Transaction groups, lighting logic, and other consumers then read those tags. This path does not require a request to leave the site network.

A web-service approach has a different path: the gateway sends a request over the site network and broadband connection to an external service, receives a response, and maps returned fields into tags. If the connection fails, the returned values may become stale or unavailable. The installation described rejected this dependency because the feeds tried did not reliably provide timely data or all required values.

The third option is to integrate a Java library through the Ignition module SDK. That changes the implementation boundary: instead of importing a Python package, the calculation runs through a Java integration. It is an alternative when the required library cannot run in Ignition's Python environment, but it is a larger integration than a small gateway script.

For the stated use—sunrise, sunset, sun position, and a theoretical clear-sky radiation estimate—recommend local calculation if the algorithm can be validated for the site and the deployed Ignition environment. The evidence reports that Pysolar ran but was incomplete, buggy, and not actively maintained at the time; do not select it solely because it is Python.

What does the sample calculate and publish?

The shared script example follows a NOAA spreadsheet-based solar calculation. Its setup accepts latitude, longitude, and a time-zone value, then creates tags for inputs and intermediate results. The shown fields include Latitude, Longitude, TimeZone, CurrentTime, TimePastLocalMidnight, JulianDay, and JulianCentury. It also shows intermediate solar terms such as GeomMeanLongSunDeg, GeomMeanAnomSunDeg, EccentEarthOrbit, SunEqofCtr, SunTrueLongDeg, SunTrueAnomDeg, SunRadVectorAUs, SunAppLongDeg, MeanObliqEclipticDeg, ObliqCorrDeg, and SunRtAscenDeg.

These intermediate values make the calculation inspectable in Ignition tags, but they do not by themselves prove that sunrise, sunset, sun position, or irradiance outputs are implemented correctly. The supplied code excerpt ends during a print statement and does not show the complete calculation or final tag set. Treat it as a partial algorithm reference: obtain and review the complete body before deploying, and check that it initializes the location inputs and reaches the final calculations on each invocation.

The code describes tags as memory tags and uses Float8 for numeric values and DateTime for the current-time tag. Keep numeric values and date-time values typed appropriately in the actual implementation. Select a clear tag folder for the script's outputs, and map only the values your lighting logic, transaction group, or monitoring logic needs.

Which time and location settings control the result?

Solar calculations depend on both the instant being evaluated and the site coordinates. Set latitude and longitude for the gateway's monitored site, not for the engineer's workstation or a remote service. Confirm the sign convention and units expected by the completed algorithm before entering coordinates; the excerpt names the inputs but does not document those conventions.

The sample exposes a numeric TimeZone value and calculates a Julian day using a time-zone adjustment. A fixed numeric offset is not automatically the same as a civil time zone with daylight-saving transitions. Confirm whether the algorithm expects an offset or a zone-aware timestamp, and test timestamps on both sides of a daylight-saving change if the site observes one. Also confirm the gateway clock and time zone, because a correct location paired with an incorrect timestamp shifts every calculated value.

One critical correction is visible in the excerpt: it obtains datetime.datetime.now(), but later replaces the epoch-difference input with the fixed test timestamp datetime.datetime(2016, 3, 11, 0, 6, 0) before deriving JulianDay. If that test assignment remains active, the calculation uses a fixed date rather than the current gateway date. Remove or isolate the test assignment, then verify that the production Julian day changes as time advances.

How should the gateway timer update tags?

The example proposes a shared gateway script library named something like noaa_solar, invoked from a gateway timer script with shared.noaa_solar.begin() about once a minute. It also proposes editing latitude, longitude, time zone, and the preferred root tag folder. A one-minute invocation interval is the sample's suggested schedule, not a universal requirement; choose an interval that fits the lighting decision, group sampling, and gateway workload.

1. Create the shared gateway script and confirm the deployed script is complete, syntactically valid, and callable from the gateway timer context.
2. Configure the site's latitude, longitude, time-zone handling, and output tag folder. Keep test timestamps out of the production path.
3. Have each invocation calculate from the current gateway time and write the outputs needed by consumers. Check that existing tags receive refreshed values, not only newly created tags.
4. Configure the timer at the chosen interval and inspect script execution and tag quality after a run.
5. Connect lighting logic and transaction-group items to the calculated tags only after confirming the tags represent the intended local date and time.

Tag creation and tag updating are separate concerns. The excerpt includes helper logic using system.tag.exists, system.tag.addTag, and system.tag.write; inspect the indentation and control flow in the full script. If a write occurs only inside the branch that creates a missing tag, subsequent timer runs will not refresh an already-existing tag. Test both a first run with no output tags and a later run with the tags already present.

How do the output values map to control decisions?

Keep calculated astronomical quantities separate from control commands. A sunrise or sunset value can provide a schedule input for parking-lot lights, but the lighting logic should evaluate the correct local day and handle a missing or invalid calculation without treating it as a valid event. Sun position can be logged alongside PV or heating-system data, provided timestamps align with the process measurements.

Theoretical solar radiation is a clear-sky model value, not a direct measurement of cloud cover. A local cloud estimate requires comparing the modeled expectation with a measured irradiance value or another defined observation. The source identifies clear-sky model literature as a reference but gives no model selection, units, sensor, or threshold. Choose those from the site instrumentation and intended decision; do not treat the model output alone as evidence that clouds are present.

For heat or lighting backup decisions, use explicit thresholds and stale-data handling in the consuming logic. A timer script can fail, a tag write can fail, and a model can return an edge-case result; consumers need to distinguish current valid values from old values. Review the tag timestamps and quality along with numeric values rather than relying on the displayed number alone.

How can the local result be validated?

The developer of the sample reported results within a couple of minutes for sunrise, solar noon, and sunset against the NOAA calculation reference they used. Treat that as a reported outcome for the sample, not a guaranteed accuracy specification for every site or implementation. Decide the acceptable timing tolerance from the actual lighting and analysis requirements.

Validate multiple dates and compare like-for-like local timestamps against a trusted solar calculation reference. Include a date near a seasonal transition, a known site coordinate, and tests across any applicable daylight-saving change. Check sunrise, solar noon, and sunset independently; a plausible noon value does not validate all date or time-zone handling.

Then verify the Ignition path: confirm the timer runs, the script uses the current date, the output tags update on repeated invocations, and the transaction group records matching timestamps. Confirm that a script failure or invalid calculation does not silently leave a value looking current. Test the lighting and backup logic against expected event times before relying on it for automatic operation.

FAQ: What do Ignition solar calculation searches ask?