Why Renewable Energy Data Is Still Flowing the Wrong Way

Svet Bajlekov, Co-founder and CEO, AMMP Technologies | April 2021

Today's most popular method for accessing data from devices and sensors via the internet is the REST API. REST APIs work on a request-response model: you make a request for data, and you get a response. They're widely used, well-documented, and for many applications, they work great.

But for renewable energy systems – particularly distributed portfolios with hundreds or thousands of assets – this model has significant limitations.

"Get Me a Plumber"

Let me explain with an analogy. Imagine you have a leaky pipe in your house. With a REST API approach, fixing it would work like this:

1. You call a plumber and ask: "Is there a leak?" (Request)
2. The plumber visits, checks, and says: "No leak." (Response)
3. You wait 5 minutes and call again: "Is there a leak now?"
4. Plumber visits again: "No leak."
5. You repeat this every 5 minutes...
6. Eventually, on the 50th call, the plumber arrives and says: "Yes, there's a leak!"

By this point, you've paid for 50 plumber visits, and your floor has been flooded for 4 hours.

A better approach? Give the plumber a key and say: "Let me know when there's a problem." The plumber checks periodically (at their convenience, not yours) and calls you immediately when they find something.

Pull vs. Push

The REST API model is a "pull" model – you constantly pull data from the source, whether or not anything has changed. This has several drawbacks for energy monitoring:

• Latency: You only discover problems at your polling interval. If you poll every 5 minutes, a fault could go undetected for up to 5 minutes.
• Bandwidth: Most requests return "no change," wasting bandwidth and server resources.
• Scalability: As your portfolio grows, the number of requests grows linearly (or worse). Managing API rate limits across thousands of sites becomes a challenge.
• Cost: Many vendor APIs charge per request, making high-frequency polling expensive.

The alternative is a "push" model – data sources publish updates when something changes, and interested parties receive those updates automatically.

Enter Pub/Sub

The publish-subscribe (pub/sub) pattern solves these problems elegantly. In a pub/sub system:

• Publishers (devices, sensors, systems) send data to a central message broker whenever they have something to report
• Subscribers (monitoring platforms, analytics systems, alerting engines) register their interest in specific topics or data streams
• The broker routes messages from publishers to all interested subscribers

This architecture offers significant advantages:

• Real-time updates: Data arrives as soon as it's available, not at the next polling interval
• Efficient: Only changed data is transmitted
• Scalable: Adding new subscribers doesn't increase load on the publishers
• Decoupled: Publishers and subscribers don't need to know about each other

Why This Matters for Distributed Energy

Distributed renewable energy systems are uniquely suited to the pub/sub model:

• Assets are geographically dispersed: A centralized polling system needs to reach out to each location; a pub/sub system receives data from all locations through a single interface
• Multiple stakeholders need the same data: Operators, investors, grid managers, and customers all want visibility into system performance. With pub/sub, each can subscribe to the data they need without duplicating requests to the source
• Alerting is time-critical: When an inverter trips or a battery reaches a critical state, you need to know immediately – not at the next poll
• Data volumes are growing: As systems add more sensors and higher-resolution monitoring, efficient data transport becomes essential

Making the Shift

At AMMP, we've built our data infrastructure around the pub/sub model from the beginning. Our edge devices publish data to our cloud platform in real-time, and our platform makes that data available to users, APIs, and integrations as a continuous stream.

We also support integration with vendors that have adopted similar approaches – like Victron Energy's VRM platform, which uses MQTT (a popular pub/sub protocol) for real-time data access.

The energy industry is gradually making this shift, but there's still a long way to go. Many vendor portals still rely on REST APIs with strict rate limits, making real-time monitoring challenging.

Learn More

We've written more about our data architecture and how it enables real-time monitoring and analytics for distributed energy portfolios.Get in touch to learn how AMMP can help you get your data flowing the right way.