Mqtt: document vehicle selection
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.
If you want to change the vehicle name then that needs to be under vehicles, not loadpoints.
@andig The vehicleName in this context is an identifier (indeed defined in vehicles) referencing a vehicle. Changing the vehicleName 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 :)
In oder words: you don't want to update the vehicle name but select a different vehicle? Das geht unter vehicle.
/cc @Maschga
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}
Ich schreibe das Issue auf meine TODO Liste. Ich weiß aber nicht, wann ich Zeit dafür finde.
Gehört dieses Issue nicht eigentlich ins evcc-io/evcc Repo, @andig ?
Die Lösung ist ja nur Doku, nicht Software, deshalb hier.
Achso, ich dachte, dass muss noch implementiert werden. In dem Fall verweise ich hierauf: https://github.com/evcc-io/docs/issues/782#issuecomment-2833496836
DIe mqtt-API ist viel zu groß und undurchsichtig, um sie manuell zu dokumentieren und danach zu aktualiseren.
Kann ich helfen? Eigentlich ist mqtt.go halbwegs gut strukturiert :O
Die mqtt.go ist super, aber beinhaltet nur die Setter. Alle anderen Read-Only Felder sind da leider nicht dokumentiert.
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!
Ok, I think I have a handle on it. I found were all the setters are defined, I can help document the MQTT API.
I can help document the MQTT API.
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 ?
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.
OK, I'll make a PR with Setters only. But what to do with #714?
Mehr Magie ist eigentlich nicht :)
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.