By Nick McGrath, Chief Technology Officer at Evergen.
In 2018 Evergen made a huge shift from designing, manufacturing, installing and maintaining IoT devices for control of batteries to a pure software approach, and here’s why.
When Evergen started optimising the way residential solar / battery installations operated in 2016, we did so by creating an IoT device that we’d install at the site so we could receive telemetry from (listen to) and send commands to (control) batteries and inverters in order to optimise the way energy was consumed at the site using our Intelligent Control.
Modern batteries and inverters are IoT devices themselves, they use the internet to be able to communicate their state, any faults, or other information at regular intervals to a centralised location in the form of telemetry and have the ability to receive commands to alter the battery’s behaviour.
Evergen’s old IoT devices and other vendors current IoT device add-ons do exactly the same thing, though the format and frequency may vary from the battery or inverter manufacturers’ format.
The benefit of having an IoT device on a physical battery / inverter system (an IoT device on an IoT device 🤔) was that the format and frequency of that telemetry were up to us and control of the device was very low level.
This is a Secondary IoT device approach.
Installing these secondary IoT devices takes an expert and can contribute thousands of dollars to the installation costs of a battery system onto a home
So, we shifted focus away from creating and using secondary IoT devices to start using APIs for listening to and controlling batteries.
We did this for a few main reasons:
- Distributed Energy Resources (DERs) are a huge part of the future of a decentralised energy system and their numbers were only going to explode
- The number of manufacturers was going to increase significantly
- The number of types of DER devices is growing, think DRED (Demand Response Enabled Device) controllers, air conditioners, EV chargers, pool pumps, hot water systems
- Installing and maintaining tens of thousands of IoT devices across a wide geographical area would provide an enormous logistical challenge for us, particularly internationally
- DERs are moving towards API driven control to increase security, safety, maintainability and warranty protection
- Ultimately, we’re a software business, we’d rather use our skills and effort in interfacing with as many different APIs as we can to coordinate the control of DERs rather than creating, installing and maintaining IoT devices
- Evergen strives to provide the greatest possible value to our end-users which makes it hard to justify adding another cost to the installation
The future of a decentralised energy system
DERs, including rooftop solar PV units, battery storage, thermal energy storage and electric vehicles and chargers are a part of the decentralised energy system and have exploded in number as their efficiency has gone up and their costs have come down and attitudes to climate change have altered.
This trend will continue as governments around the world start encouraging consumers through financial incentives or even mandating their use in certain circumstances (already England is looking at mandating all new home builds include an EV charger).
Even Australia saw more than 31,000* battery systems installed on houses last year.
Installation and maintenance
Installing and maintaining tens of thousands of physical IoT devices across a wide geographical area is always going to be difficult to scale.
Coupled with all the new PV, battery and inverter manufacturers entering the market all the time, our research and development costs on many types of physical systems was going to be prohibitive in itself.
Creating, installing and maintaining secondary IoT devices was only ever a stop-gap for Evergen as we worked closely with manufacturers to advise and develop APIs to help them become more mature and widespread.
Interfacing with hundreds of thousands of devices is significantly easier, faster and safer if we’re connecting via an API rather than via a secondary IoT device.
So making the decision to concentrate on working with APIs presented a much more scalable solution for us as a business and allowed us to concentrate on what we do best, which is creating software that saves our customers money.
Make no mistake, interfacing with APIs is difficult and every manufacturer has their own take on what their API should look like and how we should consume it, but updates are easy and fast, and one single update can affect our entire fleet in seconds.
We also work closely with our manufacturing partners to help guide their API direction and development.
So, no more physical installations, no more travel, no more communication issues, no more geographical challenges, and no more unnecessary expense for consumers.
Security is always at the forefront of our minds here at Evergen, it has to be given that we are controlling devices that can have a material effect on the energy system. This was the catalyst that led us to get ISO27001 accredited in early 2021 and continues to inform our decisions daily.
Side note, whether you are looking for direct API cloud control like Evergen or for an IoT based company its good practice to search if they are ISO 27001 accredited here: https://register.jas-anz.org/certified-organisations
Secondary IoT devices represent a security risk that Evergen is not comfortable with as they increase the potential attack vectors on a physical site which could open up more avenues for compromise and in turn, nefarious control.
Simply put, the more doors you have in your home the more likely you are to accidentally leave one unlocked.
Our internal risk assessment identified this potential and played a significant part in our decision to cease manufacturing and installing secondary IoT devices and concentrate on our API first approach as we knew we could control the security more thoroughly and ensure it’s unique to every single manufacturer’s specifications.
This recent article highlights the potential danger associated with security flaws in IoT devices.
Our entire software platform is routinely audited by third parties for vulnerabilities and is considered a regular part of life here at Evergen.
Manufacturers push to API
Manufacturers are spending more time and effort on their API offering as it means they can absolutely control the input and output of their devices and increase their capability over time.
Secondary IoT devices on DER systems with the ability to control the device can represent a safety concern, particularly if they’re controlling a device in an inappropriate manner. If a battery manufacturer finds they’ve got an issue with their control system they can update it, but they have no way of being able to update the third party secondary IoT device itself.
The only way a battery manufacturer can stand by their warranty is by ensuring they know exactly how the system has been used. Secondary IoT devices amount to a black box with no visibility for the manufacturers and unknown issues could be caused as a result of their installation and use.
An API first approach on the other hand provides full visibility to the manufacturers and affords them the ability to ensure that their product is being used within the security, safety, maintainability and warranty parameters prescribed by themselves.
After all, who knows the battery system better than the manufacturer?
Increasingly more manufacturers are moving away from the ability to use secondary IoT devices to be able to control their systems and are pushing aggregators like Evergen to use their APIs as a default position, we expect this trend to continue as DER manufacturers shore up their approach to security, safety, maintainability and warranty protection.
By reducing the number of ways to physically control a device we can reduce the number of attack vectors available to cyber attacks. It means that the security of the DER system itself is the responsibility of one party, i.e. the manufacturer and is not subject to multiple approaches of compromise, thus reducing the number of potentially vulnerable points.
An API first approach ensures that the battery system cannot be used in a way not designed by the manufacturer which ensures the safety, maintainability and warranty of the system.
* Sunwiz Australian Battery Market Report 2021