A Renewable-Energy Measurement Provider Runs Decade-Long Datalogger Campaigns Through a Write-Only Files.com Drop Point

A renewable-energy measurement provider tests wind-turbine performance and monitors renewable-energy resources with met masts, lidar, and solar stations. It owns the instruments, deploys them on customer sites, and runs the data pipeline that comes off them. When a wind farm owner needs a turbine's power curve verified against the supplier's warranty, the verification runs on data those instruments collected.

That proposition set the requirement. The company's own instruments sit on other companies' remote sites, each producing a file every day. The business only works if those files come home, and if the customer who paid for the campaign can get at them.

Instruments Commissioned Once, for Campaigns That Run a Decade

The dataloggers are an industrial breed, built to survive years on a met mast or a turbine, and nothing about a deployed device changes after commissioning. Updating a logger's configuration by hand means an expensive trip to a remote site, and the campaigns the fleet serves can run for as long as ten years. Whatever address and credentials a logger carried on the day it was commissioned had to stay valid for as much as a decade.

In 2017 the team set out to give that data one home: a repository that received every logger's daily file, and one that its own customers could log in to and collect their data and reports from.

The shape of the fleet set the design. The loggers serve campaigns for different customers, but the team wanted one logger program with identical login parameters for every device, regardless of whose campaign it served. So the ingest account had to be able to write without being able to list or read what was already there, and the isolation between customers had to happen downstream rather than on the device.

A Clearing House the Loggers Can Write To but Never Read

What the team needed was specific. An endpoint that speaks the fleet's own protocol, with one program and one login for the whole fleet. Customers kept invisible to each other on one drop point. An ingest credential that can write but cannot read directory contents. An address stable enough to outlast a ten-year campaign. A web interface where customers collect their own data and reports. And the data's permanent home on the company's own file server.

The company selected Files.com to be that endpoint, and the team configured the whole design itself.

The isolation comes from Files.com's per-folder permission model. Every logger writes into a single repository directory through a handful of machine accounts, one per equipment class, and those accounts hold write and delete permission with no read. In normal operation, the company's downstream script pulls each file and deletes it from Files.com. The ingest account cannot list the directory, cannot open a file, and cannot see that any other customer's data exists.

The site behaves as a clearing house rather than storage. A script on the company's own file server pulls everything off the site on a short cycle, and an SCP step fans the files out into each customer's project directories. A file rests on Files.com only briefly; its permanent home is the company's own infrastructure. The design is governed delivery from hardware that is configured once and never revisited.

The same site is the company's customer face. Customers log in through the Files.com web interface, collect their data and reports, and log out. The service also accepts SCADA data from third parties and feeds a repository used by other teams in the company. Downstream, the collected logger data feeds the company's power performance analysis against turbine-supplier warranty requirements.

Site credentials were embedded into the device fleet in the field, once, at deployment. Nothing since has required going back.

One Program, No Field Visits, and a Five-Minute Repair

The design the team stood up in 2017 was still running unchanged in its essentials in 2024, and what it removed is a whole category of field work.

• Commissioning a logger for any campaign, for any customer, means loading the same program with the same login. There is no per-customer setup on the device, and no path by which one customer can reach another's data.
• The pipeline never sends anyone into the field. Credentials embedded at deployment stay valid for the life of a campaign, and the expensive remote-site trip that a configuration change would otherwise cost is work nobody does.
• The company's internal infrastructure changes without the fleet noticing. When the entire file server was re-rooted over a weekend, the team set aside half a day to repair the pipeline. It took five minutes: a find-and-replace on one path in one script, while every logger in the field kept delivering to the same address it always had.
• The team runs the whole operation: dozens of devices delivering daily, customer self-service through the web interface, and the analytical work the data feeds.

The immediate result was a fleet with one governed place to deliver. The compounding one is architectural: another device is another copy of the same program pointed at the same address, and another campaign is another project directory downstream. Nothing in the pipeline is bespoke to any customer or any device.

Governing the Drop Point, Not the Fleet

The loggers run the same program they were commissioned with in 2017. What the team built is everything around them. The ingest credentials can deposit files but cannot list or read anything already there. The address the fleet delivers to has not moved in seven years, so no logger has needed a site visit to change it. An engineer commissions a logger once, and its data arrives every day for as long as the mast stands; the customer logs in to Files.com and collects it.

The company governs the Files.com drop point its instruments deliver to, and the instruments never have to change.