Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

new charger template: TeslaLogger #13062

Closed
wants to merge 6 commits into from
Closed

new charger template: TeslaLogger #13062

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
668e183
new charger template: TeslaLogger
Adminius Mar 20, 2024
60ad605
teslalogger: typo
Adminius Mar 20, 2024
b71fdf0
teslalogger: switch to jq
Adminius Mar 20, 2024
82ba643
teslalogger: typo
Adminius Mar 20, 2024
f0577ce
teslalogger: bf target value missing
Adminius Mar 21, 2024
484fc71
Merge branch 'master' into feature/charger-teslalogger
Adminius Mar 25, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 42 additions & 0 deletions templates/definition/charger/teslalogger.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
template: teslalogger
products:
- description:
generic: TeslaLogger
requirements:
description:
en: Open source Tesla data logger https://github.com/bassmaster187/TeslaLogger, works only with "Teslalogger vehicle"
de: Open Source Tesla Datenlogger https://github.com/bassmaster187/TeslaLogger, funktioniert nur in Verbindung mit "TeslaLogger Fahrzeug"
params:
- name: url
required: true
example: http://192.0.2.2
- name: port
example: 5000
default: 5000
- name: id
description:
de: TeslaLogger CarID
en: TeslaLogger CarID
default: 1
render: |
type: custom
status:
source: combined
charging:
source: http
uri: {{ .url }}:{{ .port }}/currentjson/{{ .id }}
jq: .charging
plugged:
source: http
uri: {{ .url }}:{{ .port }}/currentjson/{{ .id }}
jq: if .plugged_in and .TLGeofenceIsHome then true else false end
enabled:
source: http
uri: {{ .url }}:{{ .port }}/currentjson/{{ .id }}
jq: .charging
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Das passt nicht: hier gehts drum, ob Ladefreigabe erteilt ist, also charge_amps > 0?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was genau macht enabled?
Mit der aktuellen Lösung meckert EVCC ab und zu "out of sync"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gibt an ob Laden freigegeben ist. Das Gegenstück zu enable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, da könnte man eine Kombinaion nehmen: Ziel SoC unter Aktuellem SoC. Plugged-in wird eh schon ausgewertet.
Was besseres fällt mir nicht ein

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Darum gehts nicht. Es geht nur darum ob evcc die Ladung freigegeben hat. Im Zweifel Freigabestrom > 0A?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wie würde die Lösung aussehen wenn ich es in TeslaLogger einbauen würde.

Das wäre wohl eine Option...

Evtl. habe ich die Logik immer noch nicht verstanden 🤔

Stell Dir das als schaltbare Steckdose vor. Die ist an oder aus, unabhängig davon ob ein Stecker steckt oder das Gerät lädt. evcc würde die Dose zwar nicht einschalten wenn kein Auto dran hängt, solang eins dran ist allerdings schon (soc mag gefallen sein, Klimaanlage lief etc).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kein Auto daran ist ja Status A
Auto dran, nicht laden ist Status B
Auto dran, laden Status C

Wenn SoC gefallen ist, wird das Auto nachladen, StatusC, egal was EVCC denkt/macht

Nun, beim Status A und B erwarte ich, dass die Dose aus ist, beim C aber an.
Hier also enabled=false bei charging=false
Enabled=true bei charging=true

Oder ist die an beim B+C?
Hier ist es also bei enabled=false: plugged_in=false
Beim True: plugged_in=true

Ich sehe z.B. keine Sinn warum bei Status A eine Dose an sein sollte.
Da wäre enabled=true einfach immer.

War es nicht gleiches Problem bei OpenWB?

Copy link
Member

@andig andig Mar 28, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Egal was Du intuitiv erwartest- denk an die Schaltsteckdose. Die schaltet sich auch nicht aus nur weil Du das Ladegerät abziehst...

Nun, beim Status A und B erwarte ich, dass die Dose aus ist, beim C aber an.

Dann erklär mir mal bitte, wie Du in Status C kommen willst wenn die Steckdose ausgeschaltet ist???

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dann erklär mir mal bitte, wie Du in Status C kommen willst wenn die Steckdose ausgeschaltet ist???
Status B: enable = false, Steckodse ist aus (Schütze in der Wallbox)
Status C: enable = true, denn zum Laden muss man die Steckdose einschalten (Schütze in der Wallbox)
Bei der Steckdose wissen wir auch nicht, dass etwas angeschlossen ist, bei der Wallbox/ dem TeslaLogger schon ;)

So oder so: ich kommen zu meiner Frage zurück: was muss ich in TeslaLogger programmieren, damit EVCC zufrieden ist? Einfach EVCCs enable "merken" und als "enabled" zurückgeben ist wohl nicht der Sinn der Sache, oder? Das könnte man bestimmt direkt in EVCC mit Script und Variablen lösen, oder?

Ich lade an einem mobilen Charger, ohne jegliche Schnittstelle, so ist die Idee auch entstanden über das Tesla zu regeln.
Nun, wenn ich Kabel anstecke und Tesla keinen Timer hat und SoC und Ziel SoC liegt startet der Ladevorgang sofort. Auch wenn EVCC jetzt enabled=false erwarten würde (z.B. zu wenig Überschuss), läuft der Ladevorgang schon, EVCC ist beleidigt, "disabled, but charging" (oder so ähnlich).

D.h. eigentlich müsste man komplette Wallbox Logik nachbauen: merken was die "externen" wollen: enable=false und sobald man Kabel einsteckt Ladevorgang sofort beenden und warten bis enable=true kommt. Dann würde auch enabled von false auf true erst dann wechseln wenn EVCC Ladevorgang erlaubt.

Nun, im Auto/in der TeslaApp kann ich den Ladevorgang aber trotzdem starten -> enable steht immer noch auf false. Also wird der wieder beendet. Ich will aber laden, jetzt. D.h. da müsste ich zuerst EVCC aufrufen um Ladevorgang zu starten. Ist das auch bei den "richtigen" Wallboxen so?

Aber auch hier, kann zu "out of sync" kommen, wenn das Timing nicht passt und EVCC die Daten in der "falschen" Sekunde abruft. Also eigentlich müsste man auch "gefilterten" isCharing Status vorgaukeln, d.h. isCharing = false, obwohl der Ladevorgang beginnt und TeslaLogger ihn aber gleich beenden wird.

So eine Programmierung wird aber wohl länger dauern... Wir wollt ihr das in der Tesla Integration lösen? Oder (noch) gar nicht?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So oder so: ich kommen zu meiner Frage zurück: was muss ich in TeslaLogger programmieren, damit EVCC zufrieden ist? Einfach EVCCs enable "merken" und als "enabled" zurückgeben ist wohl nicht der Sinn der Sache, oder? Das könnte man bestimmt direkt in EVCC mit Script und Variablen lösen, oder?

Aktuell gibts das nicht weil evcc davon ausgeht, dass sich eine WB ein- und ausschalten lässt. evcc stört sich dran wenn es a) nicht den erwarteten Wert bekommen (Wallbox neu gebootet?) oder b) der Wert nicht zu den anderen passt, z.B. disabled but charging.

Wir wollt ihr das in der Tesla Integration lösen? Oder (noch) gar nicht?

Was meinst Du? Beim TWC machen wir das so:

// Enable implements the api.Charger interface
func (c *Twc3) Enable(enable bool) error {
	// ignore disabling when vehicle is already disconnected
	// https://github.com/evcc-io/evcc/issues/10213
	status, err := c.Status()
	if err != nil {
		return err
	}
	if status == api.StatusA && !enable {
		c.enabled = false
		return nil
	}

	v, ok := c.lp.GetVehicle().(api.ChargeController)
	if !ok {
		return errors.New("vehicle not capable of start/stop")
	}

	err = v.ChargeEnable(enable)
	if err == nil {
		c.enabled = enable
	}

	return err
}

und Enabled() macht einen Workaround:

// Enabled implements the api.Charger interface
func (c *Twc3) Enabled() (bool, error) {
	return verifyEnabled(c, c.enabled)
}

// verifyEnabled validates the enabled state against the charger status
func verifyEnabled(c api.Charger, enabled bool) (bool, error) {
	if enabled {
		return true, nil
	}

	status, err := c.Status()

	// always treat charging as enabled
	return status == api.StatusC, err
}

Mit anderen Worten: in diesem Fall speichern wir einfach den vorgegebenen Wert und geben ihn gleichzeitig an das Fahrzeug weiter (ein/aus). Für die Abfrage geben wir ihn zurück und validieren ihn nochmal gegen den Status der Wallbox.

enable:
source: http
andig marked this conversation as resolved.
Show resolved Hide resolved
uri: {{ .url }}:{{ .port }}/currentjson/{{ .id }}/charge_start_stop?${enable}
maxcurrent:
source: http
uri: {{ .url }}:{{ .port }}/command/{{ .id }}/set_charging_amps?${maxcurrent}
Loading