The short answer

Begin with decisions the site may need to reconstruct: why one bay overheated, whether irrigation reached a crop, when a pump began short cycling, which alarm came first, how energy use changed after maintenance, or what condition applied to a crop lot. For each question, identify source tags, units, zone, sampling interval, raw or aggregated value, command and feedback, alarm and acknowledgement, weather, setpoint, recipe, equipment state and crop context. Keep a tag dictionary and configuration history so renamed or recalibrated sensors remain interpretable. Use synchronized time and record offsets when systems differ. Export in an open documented format on a schedule, protect original event files, verify backup and restore, and test whether a person who did not create the export can answer the intended question.

Retention is a tradeoff. Fast data supports short events and control tuning but consumes storage. Long-term summaries support seasonal review but can hide spikes, cycling and sequence. Keep different resolutions for defined periods when needed. Do not collect every available point indefinitely without purpose, ownership, access and cost review.

Context disappears faster than files. A tag called Zone 3 Temperature may move to another physical location, change units, use a new calibration or represent a different crop after renovation. Preserve sensor location, serial or identifier, calibration, unit, controller, zone, crop period and relevant configuration revision. This allows later reviewers to distinguish a real process change from a data-definition change.

This guide is an operating-control framework. The approved design, crop plan, product labels, manufacturer instructions, site safety procedures, local law and directions from competent local professionals govern the actual work.

What the buyer should control

Greenhouse grower and controls engineer reviewing exported climate and irrigation trends
Useful historical data keeps source, units, time, zone, sampling, configuration and crop context together so later users can reconstruct the event.
Greenhouse sensor data and export control register
Control pointRequired record or actionRelease evidence
Decision purposeState the crop, equipment, energy, quality, commissioning, incident or claim question the data must answer.Approved use case and responsible owner.
Source and definitionRecord tag, physical location, zone, device, unit, range, calibration, controller and raw or calculated status.Current data dictionary linked to drawings and asset records.
Time and resolutionDefine time source, timezone, clock check, sample interval, event data, aggregation and expected gaps.Verified timestamp and retention-resolution schedule.
Operating contextKeep setpoints, commands, feedback, alarm state, recipes, crop stage, weather, maintenance and configuration revision.Linked contextual record that supports reconstruction.
Retention and accessSet online, archive and event retention, storage capacity, privacy, roles, audit access and legal or customer needs.Approved retention and access matrix.
Export and integrityChoose format, field names, units, delimiter, time representation, file naming, original protection and checks.Repeatable export with schema and integrity evidence.
Restore and usabilityRecover a sample period, compare counts and values, open it in the intended tool and answer a real operational question.Completed restore and independent usability test.

Every open item needs an owner, due date, status and effect on safety, production, cost and recovery time. A note that something was discussed or is being handled does not prove closure.

A practical workflow

1. List the questions before the tags

Interview growers, maintenance, controls, quality and energy staff. Gather recent investigations that lacked evidence. Convert each into a decision question and the minimum timeline needed. This prevents unlimited collection with no clear user.

2. Build the data dictionary

Walk from the physical sensor to the displayed tag. Record location, unit, scale, sample behavior, controller, calculation, calibration and crop zone. Resolve duplicated names and ambiguous abbreviations. Keep retired tags in history rather than silently reusing them.

3. Choose useful time resolution

Match fast raw data to alarms, cycling and control sequences, and slower summaries to crop or energy review. Preserve event windows at higher resolution where needed. Document aggregation, missing values and any change to sampling.

4. Keep configuration and crop context

Link setpoints, schedules, commands, actuator feedback, recipes, weather, maintenance and crop stage. When a sensor moves or a zone changes, issue a dated dictionary revision and preserve the earlier interpretation.

5. Export before systems roll over

Use a scheduled documented export to an approved protected location. Prefer open formats with explicit units and timestamps. Keep native exports for incident evidence and avoid editing the original file before analysis.

6. Test recovery and interpretation

Restore a chosen period into a separate location, check file count, time range, units and representative values, then ask another team member to answer the original question. Record confusion as a data-design defect.

7. Review value and cost

Remove redundant collection only through a controlled decision. Adjust retention after equipment, crop, customer, legal or storage changes. Keep enough history to compare seasons and changes where that comparison has a stated business use.

Preserve the event sequence and earlier versions of records. The team should be able to reconstruct what was observed, which condition applied, who decided, what changed, how the result was tested and which limitation remained.

Who owns each decision

Data owner

Approves purpose, retention, access and disposal and ensures the data supports a real operational need.

Controls owner

Maintains tag definitions, time, sampling, configuration history, exports and technical integrity.

Grower and maintenance users

Define crop and equipment questions, supply context and test whether exports are understandable and useful.

IT or OT administrator

Protects storage, access, backups, capacity, logs and tested recovery without altering source meaning.

Release evidence before the next step

Call an export usable only after the team verifies its source, units, timestamps, resolution, completeness, configuration and crop context, restores it from protected storage and answers a representative question without relying on undocumented knowledge. A file that opens is not necessarily evidence.

Common failure modes

Problems to catch before they compound the incident
FailureBuyer response
Only hourly averages are retainedPreserve suitable higher-resolution event windows for alarms, cycling and sequence analysis.
Tag names are reused after renovationKeep a dated data dictionary and retire old definitions without erasing their history.
Controller clocks drift apartUse approved time sources, monitor offsets and preserve original timestamps with any reconciliation.
Exports omit units and command stateInclude schema, units, setpoint, command, feedback and relevant configuration context.
Backups are never restoredRecover a sample period and verify completeness and usability in the intended analysis tool.
Everything is kept foreverSet purpose-based retention, access and cost review, subject to legal and contractual requirements.

Buyer decision questions

Which decision should this data support? What physical point does the tag represent today? Are units and time explicit? What spikes or sequences disappear in aggregation? Which setpoint, command, recipe and crop stage applied? When will the source overwrite the data? Can a second person restore the export and understand it without calling the original engineer?

Keep these decisions connected to the climate data review guide, the maintenance KPI and downtime log, the incident evidence preservation. The emergency plan, equipment evidence and crop plan should describe the same operating reality.

Frequently asked questions

How long should greenhouse data be retained?

There is no universal period. Use crop cycles, seasonal comparison, equipment warranty, incidents, customer and legal requirements, storage cost and the resolution needed.

Should raw data be kept forever?

Usually not. Keep raw or high-resolution data for a defined operational period and preserve selected event windows longer when justified.

Is CSV enough?

It can be useful if fields, units, timestamps, missing values and schema are documented. Keep native exports where they preserve alarms or audit information that CSV omits.

What if sensor names change?

Create a dated mapping from old to new names and physical locations. Do not overwrite historical meaning.

Who may access the data?

Use role-based access based on operational need, privacy, security and contractual obligations. Keep recovery access available to authorized alternates.

Turn the requirement into a controlled deliverable

Provide the sensor and tag list, controller and historian architecture, crop zones, current exports and the decisions you need to support. Chengfei Greenhouse can clarify supplied-system data while the owner sets retention, access and legal controls.

Contact Chengfei Greenhouse

References

  1. NIST Guide to Computer Security Log Management.
  2. NIST Contingency Planning Guide for Federal Information Systems.
  3. CISA Back Up Business Data.
  4. U.S. Department of Energy Operations and Maintenance Best Practices Guide.