Develop a "basic backup schedule" mode for when Tado outage or loss of internet

People have mentioned that tado probably don't - for understandable business reasons - want the system to be locally programmable. I've thought of a couple of potential solutions to this massive issue that strike me, which I don't think would require tado to make it locally programmable. Clearly I can't tell how feasible these would be given that specs of the devices and the server/device protocols aren't available, but perhaps they may have some mileage.

1) Just store the smart schedules locally. Given that this would essentially be a backup functionality, I think most users would be happy to at least have their existing smart schedules carry on, even if they can't alter them or control the heating through the app during the net outage. This could perhaps be accomplished through either:

a) if the devices (either room thermostats and TRVs or the internet bridge) have the hardware (storage/memory, RTCs, etc) to store and run the schedules locally, pushing this capability out in firmware updates; or

b) releasing an upgraded Internet Bridge with this capability.

2) Release an upgraded Internet Bridge that can store/retain the smart schedules and also has backup bluetooth capability and build this capability to communicate directly with the bridge into the App. If tado is worried that people will workaround this to create a solution without their servers (e.g. use an old phone without a SIM), they could make it work only if there's at least periodic mobile internet connectivity.

I can't see how this would be impossible, even if none of these options quite work.

I support this.

I am in favour of loss of server connection or internet failure mode being to maintain last known schedule using local memory as opposed to having to rely on the current solution of manual control of each and every device.

Still no reply from Tado. Nice.

@lost_customer Given this site supports members of many countries, can I assume the Building regs quoted are EU or UK or both?

I’d try Netatmo then, I believe that system stores the heating schedules locally so they keep working in case of connectivity loss. Tado will just maintain last temperature.

Yeah, but they don’t have radiator valves. And if they do, they cannot ask for heat themselves I think (only regulate heat that’s already available). Which is why I chose tado (and considered netatmo). Could be wrong though @Sim.

Just wanted to post a quote from Tado-support on a request I recently made, just to put more concrete into their rigid policy of not hearing their customer out.

"The tado° devices cannot store the Smart Schedule, it is only in the cloud. This is not schedule to change soon.

Please consider that we cannot make further comments on our internal processes."

Brilliant, and I was just starting to hope they would at least start investigating the possibilities...

murr

I've just talked with customer service and wrote our problem.
In the reply which was extremely fast I was told that they investigated the possibility of local schedule earlier and didn't seem to be trivial. However I must accept that Tado needs stable internet connection and there are only _a few_ customer having problem with internet loss therefore need local schedule.
Everybody can judge own their own how satisfied with the reply...

Hi @XVG if you bought it last November then it will still be under guarantee with Tado.

This has bacome the 2nd highest ranked improvement idea and still no answer from customer service.

@Jurian thanks. Can you clarify the HK Details?

I connected all of them to HK with an Apple TV as the base. Does that mean that even if the app tells me no remote access possible my schedules will still run?

I was unaware that the Tado architecture was built on no local knowledge of time, but (as an IT Architect myself) can understand the original design decisions behind this - and I can therefore understand the concern about the complexity of rearchitecting the system to add local timekeeping and cope with any resulting time sync issues.

However, as one way to approach this, surely the Tado bridge could be sync'ing its time back to the Tado service when it connected and, if the service is down or Internet connectivity lost, then and only then would the local time be needed - together with the "backup" schedule. Once internet connectivity was re-established, the system would revert to full online mode, with all timing, etc. from the service - and only added step of syncing the internal clock at reconnection and every hour or so (like many clock sync tasks on other devices).

I can understand that this is still a relatively complex change, but surely if this were approached as a separate "offline mode" module within the bridge that would only be used when there was no connectivity - maybe even calling on the integration points used for Apple Kit, etc. as a way to maintain separation between the new module and the main online-mode code. The main code would then only need to add a simple time-sync process as well as the handling of switching between online and offline modes based on connectivity status.

Obviously there would also be complexity in how this was then surfaced for users, but otherwise could this approach (albeit with a slightly less "pure" architectural model) provide what is being requested for offline working (and what may be/become a regulatory issue for some countries) without the fundamental re-architecture of the design that seems to be the concern from the engineering teams.

I agree that improving reliability (and recoverablity) for the online/wireless services is also something that is really important, but there are plenty of scenarios where Internet connectivity can be an issue and even if this is a low probability event, it can be a major impact for those users and so really should be addressed in some form.