Posted by: @transparent

↑

…

Most EVs use a CCS connector, which has no bi-directional capability.

….

Um, not accurate, I’m afraid.

CCS type 2 connectors are perfectly capable of bidirectional charging. The limitation is the car’s software. A demonstration of this can be seen by the recent over-the-air software update for Volkswagen’s ID3, whereby all post  December 2021 cars with a 77kWh battery have become V2G capable. It certainly also requires a compatible bidirectional charging capable wall charger but the CCS charging port remains the unchanged.

As I understand it, there are issues with CCS type 1 connections but that’s common in the US; CCS2 is the European and UK standard and does not suffer the same limitations.

I suppose I should also point out that the bidirectional charging bit is technically pretty easy to implement. The trickier part is implementing the battery management and cooling to ensure the battery’s life doesn’t suffer unduly. Most of what’s in the software updates is there to deal with this part as far as I understand it.

Thanks for that clarification @majordennisbloodnok - much appreciated.

I knew that Indra had received funding to develop a CCS V2G prototype,
but the OVO Directors on its board then decided not to proceed with that project.

The remaining problems encountered during Project Sciurus were too serious to ignore.

There were considerable difficulties in the installation processes, which used large amounts of engineering expertise on-site,
and then there were V2G homes which had safety trips failing, or even getting so hot that they melted!

The DNOs also had to impose current limitation on some of the Trial Sites.
That had the unintended consequence of limiting the current in both directions.
There were no external sensors to 'understand' what stored charge was to be used within the home, and change the current limits accordingly.

I have an ID3, and received an announcement from VW four years ago about its plans for a V2G charging system.

However, I was dismayed to note that it was to be a VW-only strategy (akin to Tesla!)
and would allow VW to draw on energy stored in its customers' EVs to make themselves a profit.

Hauling this back on-topic, we should also note that the households need some sort of 'smart' priority control mechanism once you have in-home storage.

Imagine a small townhouse with

• an EV and a matching V2G charger
• a home-storage battery connected to a hybrid inverter (solar and/or grid charging)
• a ZEB heat battery

There needs to be some logic to prevent unhelpful/wasteful energy transfers.

Taking electricity from the home-battery to recharge the EV would quickly deplete it, for example...
... and it wouldn't make financial sense using the EV's battery to replenish the ZEB if there was going to be cheap-rate grid electricity available within an hour of the ZEB running out.

Perhaps that example better explains why I think a Smart Controller needs to be Forward Acting.

Unless there is a common interface and protocol, how could Mr Average or his approved Installer define such a prioritisation mechanism?

On this Forum we have a number of members who could devise their own micro-controller for their particular set of in-home appliances.
But that's a long way short of what would be required to facilitate a universal approach.

How could you get manufacturers of such diverse equipment to implement a common standard?

DESNZ are going to find it difficult getting manufacturers to build variants of their appliances which could be certified as ESAs
and hence used within the proposed CLF strategy.
... and they're only going to be in talks with heat-pump companies!

Have a look back at @wully said in the previous page about the ZEB:

Posted by: @wully

↑

Smart Charging also uses NESO's prediction of the grid's future carbon intensity, and customer's can choose whether to cost optimise charging, carbon optimise charging, or a blend of the two. Carbon optimised is not a popular choice with ZEB customers.

Tepeo wanted to implement a mode which better combats Climate Change, which is great!

But consumers are then faced with a binary choice of saving the planet or reducing running costs.  🤔 

I tackled this issue in discussions with Western Power, before NGED took over those four Licences.
In consumers' minds it's an analogue choice.

They might be prepared to set a bias towards electricity from renewable-sources, but only up to an amount which they find affordable.

Then there's the anti-nuclear consumer-base to consider too.
Nuclear is Zero Carbon if you ignore that CO2 released in producing its massive concrete construction(!)
but the Climate Change activists sector include a sizeable proportion who don't approve of power from nuclear fission.

In broad terms, it's at least a 3-way analogue priority decision:

But each corner of that triangle is then being pulled out of its 2D-plane by two additional forces:

• time of day
• cost of energy

Yes, I managed to create a user-interface which facilitated configuring such choices,
but that has to be mapped onto the two-dozen Energy-mix categories which are captured by NESO...
... including the category "interconnectors" which doesn't define the actual energy source.

We shouldn't just release energy products and services and expect consumers to adjust themselves to the technology.
It has to be the other way around.

Posted by: @transparent

↑

...

Imagine a small townhouse with

• an EV and a matching V2G charger
• a home-storage battery connected to a hybrid inverter (solar and/or grid charging)
• a ZEB heat battery

There needs to be some logic to prevent unhelpful/wasteful energy transfers.

Taking electricity from the home-battery to recharge the EV would quickly deplete it, for example...
... and it wouldn't make financial sense using the EV's battery to replenish the ZEB if there was going to be cheap-rate grid electricity available within an hour of the ZEB running out.

...

On this Forum we have a number of members who could devise their own micro-controller for their particular set of in-home appliances.
But that's a long way short of what would be required to facilitate a universal approach.

How could you get manufacturers of such diverse equipment to implement a common standard?

...

Absolutely. I am one of those members and I most certainly do have some rules to stop the car from charging from the battery, since the inverter only sees the car charger as "load" the same as it views the oven.

Even more, though, than getting manufacturers to adopt a common standard is the problem of manufacturers AND SUPPLIERS relinquishing the wish for their kit to be seen as the most important component. We've seen it already with Octopus and its various intelligent tariffs; Octopus offer to take control of your heat pump/EV/battery and do all the clever balancing of which does what and when for you. That's great - and I'm not knocking Octopus for what it's trying to do - but it's still offering to take control, not to fit in. Now Octopus have a good track record of customer service - I use them myself - so the issue of control is arguably less concerning than it might be. But what about Samsung? Their customer service track record is far less stellar. Or Tesla? I'll let you decide how nicely they tend to play with other companies.

Posted by: @transparent

↑

Posted by: @wully

↑

The historical available capacity of the local infrastructure could be fed into Smart Charging as a 3rd signal, alongside tariff price and carbon intensity. Smart Charging would then prioritise charging at times of day when the local infrastructure had the most available capacity. This is in effect a flexibility signal, and something that tepeo is working on with flexibility service providers.

You have flexibility providers with data on the available cable capacity at the 11kV level?

Apologies. I meant that tepeo is working with flexibility providers to make the ZEB an asset they can influence, rather than the flexibility providers have capacity information about the local infrastructure.

However ZEBs (and I suspect other smart home appliances) have metering-grade power monitoring built into them. I'd expect the supply voltage at each house to be a good, dynamic indicator of the load on the local infrastructure. Potentially this data could be aggregated to provide that sort of insight, and avoid the expense and complication of installing telemetry on the infrastructure itself.

Posted by: @majordennisbloodnok

↑

...I most certainly do have some rules to stop the car from charging from the battery, since the inverter only sees the car charger as "load" the same as it views the oven.

I've gone down the Myenergi ecosystem route to achieve this sort of system behaviour. So whilst a couple of tickboxes in the app ensures the battery won't power the hot water or car charger, unfortunately the battery sees the ZEB as a load. So for Saving Sessions, and the like, the battery has to be paused so that the ZEB can charge from the grid. In this specific scenario, having the battery as the orchestrator of home energy flows, with a standardised data interface to the ZEB, would meet my needs. This wouldn't mean that the battery would need to know how to do the clever charging stuff the ZEB does, just not to try and power the ZEB when the ZEB is charging.

@wully I have had my Eddi set by MyEnergi to minimise the occasions when the Sunamp Thermino is charged from the battery rather than the grid - not totally successfully though☹️. Toodles.

Posted by: @wully

↑

However ZEBs ... have metering-grade power monitoring built into them.

Can that be interrogated using Modbus?

Over an RS485 connection, or ethernet?

Posted by: @wully

↑

I'd expect the supply voltage at each house to be a good, dynamic indicator of the load on the local infrastructure. Potentially this data could be aggregated to provide that sort of insight

That's going to depend on the wiring to the ZEB.

Depending on the cross-sectional area and distance between the ZEB and the consumer unit there could still be several volts drop.

That's another reason for a ZEB to spread its demand over as long a time as possible.
The lower the current in that cable, the more accurate will be the voltage measurement.

As I live in a rural area, I'm able to glean a fair amount of information on how the long 11kV routes work.
By looking at 240v/440v data I can easily see what's happening at 11kV and above.
In time, that knowledge could be used to train an AI tool.

It helps that I've got access to the DNO's network maps, but even that doesn't show me where the 'breaks' have been left following a fault-recovery.
The engineers often don't bother to set them back to a 'default' scenario once they've restored power to properties, especially in poor weather.

I'm very close to an 11kV circuit that is well known for significant voltage drop, which provides me with a useful test area. 🙂 

I hear your point about 'telemetry', and I've obtained readings both from very complex professional monitor systems and from in-home monitoring.

My clear preference is to facilitate members of the community to get involved in the monitoring process, rather than companies looking for profit.
Local Councillors are very helpful to this end, and appreciate the benefits to be gained by residents 'taking some responsibility' for their area grid.

If it's possible to glean voltage data from a ZEB, then that's worthwhile knowing.
But we'd still need an embedded microcontroller to package that data and send it to a storage area in the cloud.

Does Tepeo keep a register of where each unit has been installed?
Have you considered how that might be amalgamated with information on grid topology?
Who is your DNO?

(I assume others at Tepeo are still reading this discussion?)

Posted by: @transparent

↑

Posted by: @wully

↑

However ZEBs ... have metering-grade power monitoring built into them.

Can that be interrogated using Modbus?

Over an RS485 connection, or ethernet?

The power monitoring is integrated into the power switching PCB in the ZEB, so the data from it is only available within the ZEB. Every half hour the ZEB uploads the last half hour of ZEB data, including power, to the tepeo cloud platform. So the data can be batch extracted for historical analysis, but isn't available locally in real-time.

Posted by: @transparent

↑

Posted by: @wully

↑

I'd expect the supply voltage at each house to be a good, dynamic indicator of the load on the local infrastructure. Potentially this data could be aggregated to provide that sort of insight

That's going to depend on the wiring to the ZEB.

Depending on the cross-sectional area and distance between the ZEB and the consumer unit there could still be several volts drop.

That's another reason for a ZEB to spread its demand over as long a time as possible.
The lower the current in that cable, the more accurate will be the voltage measurement.

The wiring to the ZEB will have an effect on the absolute voltage reading, when the ZEB is pulling 9kW down the cable. But for most of the day the ZEB is either idle or using a small enough current not have a material impact on the voltage reading. It feels like its the profile of the relative variation of the voltage over many days that might give insights into the typical loading of the local infrastructure.

Posted by: @wully

↑

the data from it is only available within the ZEB. Every half hour the ZEB uploads the last half hour of ZEB data, including power, to the tepeo cloud platform.

Ah.... I'd like to make a couple of observations:

1: I spent 2 years on a home battery trial which was a partnership between an Energy Supplier and a British storage battery manufacturer.
There were no controls or monitoring available on the battery, although there had been on earlier models.
Everything got uploaded to the cloud and was monitored/managed by their own in-house software.

I could see an average of what was happening on a web interface, typically with a 3-min delay.

I added further monitoring of my own, including energy meters on each solar input.
That allowed me to see instability in the way the battery operated... which they were unaware of. 😮 

The following video-clip shows the MPPT algorithm within the battery's inverter collapsing twice within a minute:

The additional data I gathered also allowed me to roughly calculate the round-trip efficiency of the system over a year as slightly above 60%, which is appallingly bad.

When the manufacturer's own server went down I was unable to see what the battery was doing or issue a command.

As you can imagine, I quickly lost confidence in energy devices which rely on data going to the cloud and get managed by the manufacturer/supplier.
The equipment is 'locked in' to a service over which the consumer has no control, and could stop if the manufacturer ceased trading.

2: Let's imagine that a Social Housing Provider wants to put 80 ZEB units into their 1-bed and 2-bed properties.

These are sited within a square-mile, which is supplied from three local substations, one of which is on a different 11kV feeder cable.

All 80 units need recharging during an overnight cheap-rate period.
Fifteen of the properties also have EV chargers, and more are planned.

The DNO calculates the overall loading and states that the sub-station feed cables 'in the street' will need upgrading.
The cost will be £46k for the first substation and £33k for the second.

However the cabling can easily take the additional load, provided that

• ZEB unit recharges are spread evenly across the three phases fed from each sub-station
• the recharge periods are time-sliced (staggered) so as present less than 30% of the total demand simultaneously

The £79k network upgrades would make the Zeb installations unviable,
but the alternative 'smart' solution would require access to monitor and control the Zeb unit in each property.

Now what?

Posted by: @transparent

↑

As you can imagine, I quickly lost confidence in energy devices which rely on data going to the cloud and get managed by the manufacturer/supplier.
The equipment is 'locked in' to a service over which the consumer has no control, and could stop if the manufacturer ceased trading.

This is an important and relevant topic of discussion in 2025. Any product or service using remote servers or a cloud platform has a dependency on the ongoing support and existence of the organisations running those resources. When I look around my own home I see plenty of connected products, and it feels like every day businesses are ceasing trading, and cloud platforms are being turned off. Are any of my own products living on borrowed time? Mostly it appears that decisions like this are purely financial; either the product hasn't attracted sufficient customers, or the business hasn't found a business model that works for both itself and customers. This all seems like customers have to take an enormous leap of faith when buying into a connected product.

But the engineers building these products are choosing to use servers and the cloud for good reasons. In some cases there isn't a reasonable alternative, for example when providing customers with the ability to monitor and control their products when away from home. In other cases, giving the product the necessary computing and storage so that it can perform the sorts of machine learning and data science that are now commonplace would make the product cost excessive. The alternative is to restrict the functionality of the product and lose competitive advantage, most likely resulting in the product not attracting sufficient customers.

So the ideal product could have both local monitoring and control that gives basic functionality, backed with a cloud platform that provides advanced functionality. That means the product doesn't become an expensive doorstop if the manufacturer shutters the cloud platform, but it also means that the customer will likely lose some functionality they've become accustomed to. For me the ideal product also has a subscription, to pay for the cloud platform. It might be a contrarian view, but if a company is backing a product with a cloud platform, and paying for that cloud platform with a portion of future product sales revenues, then you can be sure that the company will close that cloud platform down asap if product sales drop. Conversely a company bringing in recurring revenue to pay for a cloud platform, with a bit of margin, is incentivised to keep that platform running, even if they stop selling the product itself.

Posted by: @wully

↑

But the engineers building these products are choosing to use servers and the cloud for good reasons. In some cases there isn't a reasonable alternative, for example when providing customers with the ability to monitor and control their products when away from home. In other cases, giving the product the necessary computing and storage so that it can perform the sorts of machine learning and data science that are now commonplace would make the product cost excessive.

Yes, you make a good point and beyond servers, engineers use whole platforms and open protocols, at least for common devices. So if their app stops working or you prefer another app, it often works as there are common platforms behind. And the same happens when a manufacturer stops making it.   

When a product only operates locally, the vendor disengages and cybersecurity issues are more commonly overlooked, firmware upgrades are harder to make, etc.

Most ML takes place before any deployment happens. Not much is needed to run most of these models.     

Posted by: @wully

↑

So the ideal product could have both local monitoring and control that gives basic functionality, backed with a cloud platform that provides advanced functionality. That means the product doesn't become an expensive doorstop if the manufacturer shutters the cloud platform, but it also means that the customer will likely lose some functionality they've become accustomed to. For me the ideal product also has a subscription, to pay for the cloud platform. It might be a contrarian view, but if a company is backing a product with a cloud platform, and paying for that cloud platform with a portion of future product sales revenues, then you can be sure that the company will close that cloud platform down asap if product sales drop. Conversely a company bringing in recurring revenue to pay for a cloud platform, with a bit of margin, is incentivised to keep that platform running, even if they stop selling the product itself.

I agree paying regularly can be a better model. Still, well designed software can have little incremental cost and still cater for previous product models. 

When a company suddenly exits a market, I have seen the home assistant type of organisation/community stepping in and collaboratively finding a way to reach out to them and devise a way to extend its lifetime. Then many have to add another toy to their collection!   😉

And as some of the folks in the HA community are into not relying on the cloud, often the local solution is already tried and tested.

Recently Ohme stopped supporting some EV charging functionality due to a BMW APi change and HA already has some of it working.