The timing of training and inference are very application and algorithm dependent. tepeo uses ML to learn the daily profile of heat demand of each ZEB installation throughout the year. The models are then used to predict future heat demand, so that each ZEB's charging can be scheduled effectively. So in this case training and inference are happening daily.

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.     

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. 

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.

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:

https://youtu.be/G4hkO0n-t2o

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?

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.

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.

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

Can that be interrogated using Modbus?

Over an RS485 connection, or ethernet?

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?)

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.

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.