Push notifications bei Ladestart/Ende/usw.

[mrhund]

Wäre ein feature request, den ich für sinnvoll halten würde.
Gibts da schon Pläne?

[webalexeu]

Hello @naltatis ,

Really interesting to add notifications directly within the application.
Do you plan also push notifications ? (Then I guess you will use cloud service like for optimizer.evcc.io ?)

I did it already for another application so I can participate if you are interested ?

[naltatis]

We'll likely want to use Expo Notifications to handle the platform specific abstractions.

Possible high level overview:

Enable Notifications on device (push permission)

   ┌──────────┐  push token  ┌─────────────────┐  push token  ┌────────────┐
   │ evcc-app │─────────────▶│ WebView (evcc)  │─────────────▶│ local evcc │
   └──────────┘              └─────────────────┘              └────────────┘

Sending notification to devices

   ┌────────────┐  message  ┌──────────────────────┐  forward  ┌───────────┐  APNs/FCM  ┌──────────┐
   │ local evcc │──────────▶│ push.evcc.io (relay) │──────────▶│ Expo Push │───────────▶│ evcc-app │
   └────────────┘           └──────────────────────┘           └───────────┘            └──────────┘

We'll need to provide a very thin, stateless push relay service (go) that encapsulates the expo secrets. All user secrets (push token) should stay in the local evcc instance. Maybe sponsor only if we see misuse, but can be open for start.

I'd keep it simple for start: multiple devices can be registered, all registered devices receive the same messages. This aligns with our current messaging model. We can get more granular later if we need it.

Enabling notifications should be done via the evcc web ui. users can active it when they use the web ui through the native app (existing app detection, web view post message bridge). The service "e.g. App Notifications" can always be visible (also in pure web context), but the ui for dis/enabling push is only visible/active in an app context.