Teslamate go forward

[Dulanic]

Hello everyone! As we know @adriankumpf is ceasing development of this fantastic app going forward. With that said, we need to determine who if anyone can take more responsibility for this project going forward. While I myself am great on the SQL side, I know next to nothing about elixir.

I'd like to see who if anyone can step up to assist with which portions of this project. If someone wants to totally convert this over to python, I can help out more! Kidding.... I think.

Some ideas:

Dashboard/SQL - @Dulanic @DrMichael , others?
Elixir - ??
Other portions I haven't thought of: ?

If you would like to assist, please speak up here and we can start to focus on how this project will continue going forward. If anyone else would like to take this discussion over, let me know! :)

I am going on vacation in a few days and won't have a lot to say until December.

[parkr]

I'd be happy to take a look at Elixir PRs and help with general administration if you still need volunteers.

[cwanja]

I will generally be around. Elixir took me about five tries to spell correctly. I can review code today and add / modify for new features. But it will be buggy as hell. Regardless, will be active in discussions, issues and around. Better in Grafana / SQL.

[parkr]

I'd nominate @swiffer for Elixir review if he's interested, based on the excellent PR #3398.

[swiffer]

Thanks @parkr - happy to contribute with reviews, testing, issue grooming, releases, tooling, sql & grafana but sadly cannot do much when it comes to elixir. I've 0 experience.

[brianmay]

My observation is the MQTT support in Elixir is in a very sad state. Tortoise which Teslamate uses, has not received any updates in the last two years, and is stuck on MQTT 3.1 with MQTT 5 support being very experimental.

There is a fork but I think it is bug fixes only. But maybe we should seriously considering switching to that that anyway.

The Erlang emqtt library is better, but needs extra code to ensure the connection stays up (I have written and published such code), and has various support issues also (such as the hex.pm version is old, problems sending keep alives frequently enough not to get disconnected by the server, etc).

And I have seen issues in TeslaMate where the Elixir process can die (and auto restart) because something unexpected/untested happened, e.g. the Tesla API returns an unexpected response. Which might be OK, but doesn't fill me with confidence. When the process dies, that means all data that the process was keeping track of is lost.

At the risk of becoming unpopular, wondering if anybody else would be interested in participating with a complete rewrite of this project in another language. Rust is my preferred language for the task. It has strong compile time checking, which will lead to higher confidence the code is working as designed. I think this is very important for Teslamate. Ideally this would support the same database schema, same MQTT protocol, etc.

There are some things really like about Elixir, e.g. live views, etco. But I think these aren't really key features for teslamate.

(and I notice that @adriankumpf's tesla_auth app is written in Rust also...)

I don't have a huge amount of time, but do have minimal working rust code to talk to Tesla API: https://github.com/brianmay/robotica-rust/blob/main/robotica-backend/src/services/tesla/api.rs (most important missing part is streaming support - seeing as I currently use Teslamate for that...).

[JakobLichterfeld]

The main advantage of TeslaMate is not only the error security and self-healing and SW architecture and modern SW patterns and much more, but not sharing any data with the outside, as TeslaLogger always did and still does.

[brianmay]

Key question: Is it possible to run both Tesla Mate and Tesla Logger at the same time? If so, this would considerably open up my options. I could test out Tesla Logger and not mess up my Tesla Mate setup. Or I could run Tesla Mate, while developing my own solution.

I have a vague recollection that the Tesla API only supports streaming to one client at a time though. If this is true, and if this is still the case, the answer would be a no.

Wonder how hard it would be to write some sort of Tesla API simulator for testing. This might be good for any testing of any of the loggers.

But my key concern is Tesla. e.g. on some forums I have read there is speculation that Tesla could put their API behind a paywall. Which somewhat limits the time I want to spend on this.

[ngardiner]

You can, I've run them side by side for a year now

[Adminius]

Yeah... and this is the the problem, it works only with TeslaMate and also "one man show"...
Thats why I using EVCC now, more popular with more supported hadware. TeslaLogger will become EVCC integration this days (e.g. Session Price, PV %)

[JakobLichterfeld]

I am happy for you. Have fun posting in other projects.

[jlestel]

Hi, if you still need maintainers, I'm interested in helping you move forward, I do a lot of DevOps.

I must surely be able to help with:

• the review of the Elixir PRs
• CI and build optimization (at present I find it annoying not to have release candidates to be able to test particular versions on a large scale)
• I manage several hundred Teslamate installations so I can also help deploy versions and quickly get feedback on behavior

Indeed, maintaining the Elixir code seems to be the most complex part and I am not an expert.

Finally, I can offer financial support if there is a need for licenses or others.

PS: I also have access to the Fleet API etc. I am thinking about integrating Teslamate into this new ecosystem.

[DrMichael]

So we have:

• Dashboard/SQL - @Dulanic @DrMichael @cwanja @swiffer @jheredianet
• Elixir Programming - @NirKli
• Elixir Review - @jlestel @swiffer @parkr @swiffer @jsight
• Docker - @jheredianet @nelsongraca
• CI and build: @jlestel
• Home automation - @nelsongraca
• General - @JakobLichterfeld

[NirKli]

So we have:

• Dashboard/SQL - @Dulanic @DrMichael @cwanja @swiffer

• Elixir Programming -

• Elixir Review - @jlestel @swiffer @parkr @swiffer

• CI and build: @jlestel

What about @JakobLichterfeld @jsight @NirKli ?

I would like to try to fit in elixir programming

[DrMichael]

Updated. Thanks

[DrMichael]

@jheredianet where should I put you in?

[jheredianet]

Grafana Dashboards/SQL and Docker containers

[DrMichael]

Appreciated, updated...

[nelsongraca]

volunteering for Docker, CI/CD, home assistant, and general project management stuff, can try to review PRs but I know nothing about elixir as java is my expertise

[DrMichael]

Guys help me: what is CI/CD?
I would like to keep building on one hand with @jlestel ...

[jlestel]

CI/CD is a method to frequently deliver apps to customers by introducing automation into the stages of app development. The main concepts attributed to CI/CD are continuous integration, continuous delivery, and continuous deployment.

The CI is what you see here: https://github.com/teslamate-org/teslamate/actions

As you can see, last commit on master is not passing Elixir CI

[kimmilde]

So there have been a lot of merging now. is the docker image from the documentation still valid? Is that to keep in my docker-compose?

[jlestel]

Docker-compose is on latest. This is still valid.

[DrMichael]

I'd like to test PR's in advance. How would I get an image locally, where I could make changes and run with that?

[nelsongraca]

I would just create one for each PR, they can be deleted on PR merge.

[JakobLichterfeld]

Yeah, that's exactly the Plan, as you can see in my example (push on main or for all releases, and all PR to main

[micves]

That would be great. I have #3262 and several different people/platforms/architectures eager to test :)

[jlestel]

Here is the implementation I had in mind: #3432

There must be a right to be set at the org level: buildx failed with: ERROR: denied: installation not allowed to Write organization package

I don't have access to it yet.

@micves we should test it soon: ghcr.io/teslamate-org/teslamate:pr-3262 ;)

[JakobLichterfeld]

Further discussions in #3432.

[DrMichael]

Here is the implementation I had in mind: #3432

Sounds good!

There must be a right to be set at the org level: buildx failed with: ERROR: denied: installation not allowed to Write organization package
I don't have access to it yet.

Hmmm, what needs to be done on org level? I cannot add members there, probably only the owner can. That is @adriankumpf ...

[adriankumpf]

@DrMichael @jlestel I've granted actions within teslamate repository write access to the teslamate package. Please try again.

[JakobLichterfeld]

All PR are labeled now, quick wins were merged.

[DrMichael]

Thank you. Excellent work!
Perhaps we clean up the discussions also...

[cwanja]

Might be opening a can of worms here, but:

1. Do we have a central chat place for us? Discord, WhatsApp, Signal, etc.?
2. Do we have a central place for us document enhancements, changes, etc. Know @brianmay mentioned in other threads he has active items on his list.
3. Do we have a target release? There has been lots of pushes recently to master and figure incremental releases are better than big bangs.

This is the most activity I have seen in TeslaMate since 2019 / 2020 and am super excited. But want to make sure it is methodically done.

[JakobLichterfeld]

Yes, we have a central place: Since we are an open source project, we track everything here on GitHub. Either in issues or here in discussions. Personally, I prefer issues for feature ideas, bugs, etc., but that's a matter of taste.

I have already drafted the next release and voted to jump directly to 1.28.0 to show that it is the first release of teslamate-org. We just finished building GHCR containers for each PR to test things. We just need a setup from Adrian, see #3481.
I will add the latest PR in the Changelog and release notes as well and release as soon as it is tested.

[brianmay]

Github also supports wiki pages (looks like currently disabled for this project). Discussions is good for meeting and making decisions, wiki would be good for posting the results (with links as appropriate) of such discussions so that we don't forget what we decided. I think searching for old decisions in chat may be difficult after a while.

[markusdd]

Yes. I am also in favor of leveraging Github Discussions and maybe the wiki.
Also Github offers Github pages where one could even build a small webpage explaining the roadmap etc.

I strongly vote against Discord. This app is a closed-source resource hog in the hands of a chinese company. No thx.

[brianmay]

If we really wanted a instant chat system, I would vote for Matrix instead of Discord. A number of open source projects I am involved with already use it. I personally use the element client, but there are others.

But if we are happy with what Github provides, even better.

[nelsongraca]

I only see benefit in a chat system for end user support, for that Discord would be my choice as it seems to be the easiest one.
For dev talk we could leverage discussions here

[jheredianet]

@DrMichael I've opened this topic #3513

Let me know what you think. It's something we should consider when approving the PRs.

[DrMichael]

Not sure what the question is. I am sure @swiffer will take care of this in #3438
And yes, I think, we should not have separate dashboards for LFP and other batteries. So, unifying in those three cases would be good.

[JakobLichterfeld]

Follow-up, two years on: the direction discussed here has been decided and is documented in #5558 — modular data sources with an explicit event contract, and the core moving to Rust. That thread covers what is decided, what is still open, and how it will be sequenced. If you're subscribed here because you care about where the core is going, that's the thread to follow now.