advanhooft

14 augustus 2026 om 23:21

Communication with a smart home system is definitely not required. The smart home system should control the charger not the car. The bsoc of the Twike is not relevant for how much you need to charge over night. It is the next day planned usage that determines de amount that needs to be charged overnight. That overnight charge amount will be user input in your domatica system. Bidirectional charging with your Twike is an expensive solution. A home battery is 4 cent per kWh. The price per kWh on the Twike will be 10 times more expensive.

Twike.Team

17 augustus 2026 om 16:34

We agree that the smart-home system should remain responsible for the overall energy management. However, we would not treat the TWIKE battery like a separately purchased home battery.

The traction battery is primarily purchased for vehicle range and is already available whenever the vehicle is parked and connected. For its use as an additional home-storage resource, the relevant economics are therefore mainly the incremental effort for integration, control and communication rather than the full battery cost.

If bidirectional charging can be implemented without causing disproportionate additional battery ageing, it can make sense to use part of the available capacity alongside a stationary home battery. Especially considering calendar ageing, useful additional use of an existing traction battery can be more efficient than leaving most of its capacity unused while the vehicle is parked.

For us, the key question is therefore not “TWIKE battery versus home battery”, but how both can be integrated intelligently and used where each makes the most sense.

— TWIKE Team

TWIKE Team

19 augustus 2026 om 09:11

In the driver test vehicle, we are using AutoPi to test the TWIKE 5’s own wireless communication channel with the outside world for the first time. This allows us to evaluate a potential technical foundation for remote access and future connected features.

A future TWIKE Commander could, for example, provide charging and vehicle status, consumption or driving data, diagnostic information, and charging-related functions. The TWIKE itself is designed to function independently, even without such additional systems.

We’re particularly excited to explore which interfaces we should open up for technically inclined users—such as for integration into their own energy or smart-home systems.

We’re deliberately choosing not to finalize which features actually make sense just yet.

What should a TWIKE Commander really be able to do for you—and what should it avoid?

Read the full NEWS article.

benedikt

21 augustus 2026 om 00:00

As one of those users who would prefer that my devices do not connect to some vendor’s cloud, but rather to my own server, reading https://github.com/autopi-io/autopi-core I see autopi-core is open source, which is very good news! So it would be really to nice to have adaptions to be released under an open source license as well (preferably public, but delivering it the Twike 5/6 owner’s under an open source license would also be okay). And please don’t introduce any functions which require to have a smartphone running Apple iOS or Google Android and download some app from their stores!

TWIKE Team

21 augustus 2026 om 08:33

Hello Benedikt,

thank you for your very constructive thoughts – this is exactly the kind of perspective that makes the development of the TWIKE Commander interesting.

We also see the advantages of open interfaces and understand the desire not to depend on a single cloud or platform. The possibility of integrating your own systems or servers is therefore a very interesting approach.

At the same time, we need to carefully distinguish between different layers of a vehicle system: not every part of a vehicle can or should be completely open. Safety, reliability and a simple user experience for all pilots are equally important to us.

Our first step is therefore to create a clearly defined interface that different applications can build upon in the future. How far an open architecture and possible open-source components make sense is something we would like to develop further together with the technical possibilities and the needs of our community.

And regarding smartphones, we agree with your point as well: A TWIKE should not depend on every user having a specific mobile operating system or a specific app.

Thank you for this valuable input!