←back to thread

Understanding Solar Energy

(www.construction-physics.com)
261 points chmaynard | 2 comments | 20 Mar 25 12:09 UTC | HN request time: 0.944s | source
Show context
doctoboggan ◴[20 Mar 25 15:14 UTC] No.43424521[source]▶
The company I work for (as a data engineer) does utility scale solar + battery installation and site management. We recently finished a large scale installation just outside of Las Vegas (by some measures the largest in the US). It was backed by a PE firm. Costs are getting so low, the tech so predictable, and with battery warranties around 20 years the PE firm is able to get pretty high return with a fairly low risk. They enter into a "power purchase agreement" with the utility so they know how much they will be able to sell the power for, and as long as we collect data on the batteries they will be able to be warrantied if there is an issue (but there rarely are issues).

The batteries are by far the most expensive portion of the setup. The solar by comparison is dirt cheap. We have single axis tracking like mentioned in the article. Every day we fully charge the batteries, and discharge them in the evening.

replies(3): >>43424777 #>>43425210 #>>43435626 #
algo_trader ◴[20 Mar 25 15:38 UTC] No.43424777[source]▶
> I work for (as a data engineer) does utility scale solar + battery installation and site management.

Did you build your own excel/python nightmare or is everyone using 3rd party management software for this?

> as long as we collect data on the batteries they will be able to be warrantied

Can you share some of the data? Beyond power in/out, do you monitor humidity, vibrations, temperature ?

replies(1): >>43424880 #
doctoboggan ◴[20 Mar 25 15:47 UTC] No.43424880[source]▶
Our data pipeline looks like this:

hardware/PLC --modbus--> kepware --mqtt--> mosquito broker --mqtt--> mqtt2prometheustool --http--> Victoria Metrics

The mqtt2prometheustool is something we developed in house. I am looking at removing one or more of the above steps and using telegraf instead, as it can ingest OPCUA or modbus data directly.

We use excel files just as the output of our reporting tools. For analysis it's the standard python data science stack of pands/numpy/scipy. Most people work in Jupyter notebooks, and their tools are eventually moved to services in our k8s cluster.

Temp and voltage are the main "cell level" datapoints we collect. I don't think we have any vibration sensors at site now.

replies(3): >>43433669 #>>43434732 #>>43437099 #
notTooFarGone ◴[21 Mar 25 15:50 UTC] No.43437099[source]▶
As someone working in the IoT space - why pay for kepware for something that can be done in a few weeks by a developer? Telegraf or even a bit of programming will save a lot of pain
replies(1): >>43439615 #
1. doctoboggan ◴[21 Mar 25 18:55 UTC] No.43439615[source]▶
I am actively exploring replacing kepware with telegraf. It seems very promising. Kepware was purchased and deployed before I joined the company. I think it's the defacto standard in the controls world and they never really considered anything else.

Do you have experience with modbus in telegraf? If so I'd love to chat for a bit to learn what you've learned.

replies(1): >>43460182 #
2. notTooFarGone ◴[24 Mar 25 12:24 UTC] No.43460182[source]▶
It's just making mqtt messages from modbus is such a simple task that you can just write the software yourself. There are many intricate stuff in modbus that maybe does not translate too well for generic translators and where you want to have full control. For example messages over multiple registers, breaking interfaces between vender versions and all that legacy stuff.

Telegraf is also nice (but only used it for mqtt topics) but the same applies here. The functionality is fairly simple. In telegraf depending on your data your .conf file gets fairly large and has to be maintained. If you have your data model already in code it's fairly easy to just write it yourself and gain the simplicity of just using the classes you have anyway.

In my current stack the data ingestion both the initial data->mqtt and mqtt-> database/cloud is just small programs that share their internal data objects. It's very easy to maintain for a small team imo.