-
Notifications
You must be signed in to change notification settings - Fork 171
Description
Is your feature request related to a problem? Please describe.
Evcc publishes topic evcc/loadpoints/{loadpoint_id}/vehicleName
which shows which car was selected / autodetected as connected to the given loadpoint. It however doesn't allow the user to update this value through MQTT.
Describe the solution you'd like
Please make the topic evcc/loadpoints/{loadpoint_id}/vehicleName
writeable. A message to evcc/loadpoints/{loadpoint_id}/vehicleName/set
would update the vehicleName.
Three scenarios here
- the payload represents a valid vehicle name - the update happens.
- the payload is empty - update happens by setting 'guest vehicle / no vehicle'
- the payload is not empty, but not represents valid vehicle name - ignore
Describe alternatives you've considered
HTTP integration already supports updating the vehicleName through POST and DELETE methods. Having everything supported through MQTT would be beneficial for consistency.
Additional context
Add any other context or screenshots about the feature request here.
Activity
andig commentedon May 28, 2025
If you want to change the vehicle name then that needs to be under vehicles, not loadpoints.
grogi commentedon May 28, 2025
@andig The
vehicleName
in this context is an identifier (indeed defined in vehicles) referencing a vehicle. Changing thevehicleName
updates the reference, not the name of the vehicle itself.This is already implemented, but in REST API integration. But it is missing in the MQTT integration.
Please consider reopening this request - I think you dismissed it too quickly because of miscommunication from my side.
I accept if it is low on the priority list and might never be implemented. But I feel it should not be closed because I misunderstand what I want to do :)
andig commentedon May 28, 2025
In oder words: you don't want to update the vehicle name but select a different vehicle? Das geht unter
vehicle
./cc @Maschga
[-]MQTT Integration: evcc/loadpoints/{id}/vehicleName is not writeable[/-][+]Mqtt: document vehicle selection[/+]grogi commentedon May 28, 2025
Genau :) Select a different vehicle that is assigned to given loadpoint.
Basically the same to those two REST API endpoints, but through MQTT.
DELETE /loadpoints/{id}/vehicle
POST /loadpoints/{id}/vehicle/{name}
Maschga commentedon May 28, 2025
Ich schreibe das Issue auf meine TODO Liste.
Ich weiß aber nicht, wann ich Zeit dafür finde.
Maschga commentedon May 28, 2025
Gehört dieses Issue nicht eigentlich ins evcc-io/evcc Repo, @andig ?
andig commentedon May 28, 2025
Die Lösung ist ja nur Doku, nicht Software, deshalb hier.
Maschga commentedon May 28, 2025
Achso, ich dachte, dass muss noch implementiert werden.
In dem Fall verweise ich hierauf: #782 (comment)
andig commentedon May 28, 2025
Kann ich helfen? Eigentlich ist mqtt.go halbwegs gut strukturiert :O
Maschga commentedon May 28, 2025
Die mqtt.go ist super, aber beinhaltet nur die Setter. Alle anderen Read-Only Felder sind da leider nicht dokumentiert.
andig commentedon May 28, 2025
Das stimmt. Die sind aber alle 1:1 identisch mit dem HTTP Api. Aus Slices werden 1-based Index Topics, Structs werden hierarchische Topics. Mehr Magie ist eigentlich nicht :) Im Gegensatz zu HTTP ist das aber eigentlich auch egal- was es gibt sieht man ja auch Mqtt!
grogi commentedon May 28, 2025
Ok, I think I have a handle on it. I found were all the setters are defined, I can help document the MQTT API.
Maschga commentedon May 29, 2025
That's great! In #746 every Setter should already be documented.
However, it would be nice, to have all the Getters included.
Do you know whether is it possible in Go to extract the Getters from the source Code, @andig ?
andig commentedon May 29, 2025
Basically every single publish becomes a getter. I don‘t think its useful to define these though as they might change any time. The ones from REST api can be considered stable.
Maschga commentedon May 29, 2025
OK, I'll make a PR with Setters only.
But what to do with #714?
naltatis commentedon May 29, 2025
Yes, but there's definitely in value in having a list of all the possibilities on one page. Inferring from REST + a set of transformation rules is not trivial.