I am trying to figure out the options for sending commands to a vehicle, specifically door lock/unlock, without the native app. that would allow me to integrate it into my app.
Is the best path to create my own v3 server, and send commands through that server?
thanks for any help...
I would suggest you either use protocol v3 (MQTT), or the HTTP API to the existing servers:
https://docs.openvehicles.com/en/latest/protocol_httpapi/index.html
Looking at my mqtt server I see that my ovms is subscribed to /ovms/ovmsleaf/[vehiculeid]/client/+/command/+ and /ovms/ovmsleaf/[vehiculeid]/client/+/active.
I assume there is a way to send commands on the +/command/+ topic but I can't seem to find any documentation on the command format and syntax expected. Is it something that is ready to be used or is it there in preparation for future features?
I have a Leaf 2015 that I have integrated in home-assistant as sensors but I would also like to send some commands like start charge or HVAC from home-assistant via MQTT.
There is an experimental implementation of this in the current firmware.
The v3 code in the module firmware listens on <topic_prefix>/client/+/command/+. It is expecting client/<client>/command/<id> and the command itself in the payload.
The command is run, and the response returned in the payload of <topic_prefix>/client/<client>/response/<id>.
The overall design approach is to separate each connecting client into their own namespace (identified by unique <client>), and to allow each client to run multiple commands perhaps concurrently or pipelined (each command/response connected via unique <id> within each client namespace).
I am very excited to try this. In my case I am trying to publish the following without success:
The raw payload is the following:
I am using the session client name of my current mqtt client (MQTT Explorer) but I assume I could use pretty much any string, such as "home-assistant" when I get to integrate further?
The <id> is just a number, incremental or not, for the specific command and it's result? If I just want to send the occasional climatecontrol on/off I could reuse the same ID?
Do I need to send something on the /client/<client>/active topic for OVMS to start listening to commands?
Am I wrong to assume that the behavior should be about the same as using the shell?
Sorry if this is a lot of questions at once.
The prefix 'ovms/ovmsleaf/', seems strange, but so long as you are sure that matches the ovms config, it should be ok.
The client ID is up to you. So long as it is unique.
So long as the server v3 component is enabled, started and connected, it should pickup commands, and the commands themselves are simple shell commands.
Probably easiest to turn on debug logging for the server v3 component (log level verbose ovms-server-v3), and see what that shows.
ovmsleaf is the mqtt username used to login to my mqtt server. It gets in the topic automatically.
I just got to testing this again and it worked perfectly this time, I was able to start and stop climate control and got the response to the command in MQTT. Is there anything you would like to be tested to help with the developpement of the v3 server? I am in the process of integrating this in my home-assistant, when I am satisfied with the results I will post some of the configs to help other people get going.
A home assistant integration would be cool. Just not sure if that should be via MQTT (v3) or the v2 HTTP API.
I was also interested in sending commands and
HERE IS THE ULTIMATE GUIDE
1) Find out the mqtt prefix by looking for messages in your mqtt server with <prefix>/metric/<suffix>. There should be a quite of them once the module is connected to the V3 server.
2) Having the <prefix>, your command looks like <prefix>/client/<vehicleID>/command/<whatyoulike>.
<vehicleID> is the unique ID you have given to your module.
<whatyoulike>: at least it seems to me that it doesn't matter what to put here. I put homelink because of other examples here, but something else did the same thing.
3) Having the command, now you can have different payloads. What I found is:
metrics
climatecontrol
charge
homelink
4) The great thing is:The module will always respond with <prefix>/client/<vehicleID>/response/<whatyoulike>. And it will explan the usage of one of the commands, if you put nothing else. E.g. if you put only
metrics
as payload, the module will respond:
Subcommand required
Usage: metrics list|persist|set|trace
And you can even get more help if you put one of the subcommands. If you put
metrics list
you get the whole lists of all metrics including their values.
5) FInd out your own usage, I will be using
charge start
charge stop
metrics set v.c.limit.soc 80 (or another number)
climatecontrol on
climatecontrol off
I would be happy if someone could post possible other commands, if you find more.
ENJOY!
Here is how to get the whole list of commands:
Just post ? as payload, then it responds (in my case, I have a Nissan Leaf):
. Run a script
bms BMS framework
boot BOOT framework
can CAN framework
cellular CELLULAR MODEM framework
charge Charging framework
climatecontrol (De)Activate Climate Control
config CONFIG framework
copen CANopen framework
dbc DBC framework
disable Leave secure mode (disable access to most commands)
echo Script utility: output text
egpio EGPIO framework
enable Enter secure mode (enable access to all commands)
event EVENT framework
exit End console session
help Ask for help
homelink Activate specified homelink button
location LOCATION framework
lock Lock vehicle
log LOG framework
metrics METRICS framework
module MODULE framework
network NETWORK framework
notify NOTIFICATION framework
obdii OBDII framework
ota OTA framework
plugin PLUGIN framework
power Power control
pushover pushover notification framework
re RE framework
script SCRIPT framework
sd SD CARD framework
server OVMS Server Connection framework
sleep Script utility: pause execution
stat Show vehicle status
store STORE framework
test Test framework
time TIME framework
tls SSL/TLS Framework
tpms TPMS framework
unlock Unlock vehicle
unvalet Deactivate valet mode
valet Activate valet mode
vehicle Vehicle framework
vfs Virtual File System framework
wakeup Wake up vehicle
wifi WIFI framework
xnl Nissan Leaf framework
I've been working through connecting my OVMS directly to my Home Assistant and it's own MQTT server (working).
But, I can't seem to figure out why the above isn't working for me. I've tried multiple iterations and just can't get OVMS to react to the Command topic.
I currently have an MQTT switch setup that writes a payload of charge start at command topic of "ovms/leaf/<vehicle_id>/command/1"
I can see it being written on the MQTT server, so I must be missing something crucial to get OVMS's attention. Any help would be amazing.
I figured it out, but the instructions above weren't as clear as I needed (or I'm just dense).
The format of the MQTT messages is as Schup011 says: <prefix>/client/<vehicleID>/command/<whatyoulike>
The <prefix> is what you set in your OVMS in Config/Server V3, in "Topic Prefix". In my case I set it to ovms/leaf/
The <vehicleID> is what you set in your OVMS in Config/Server V2, in "Vehicle ID". This will be what you used to identify your vehicle to connect to OpenVehicles.com
It took me a long time to figure those out properly.
The rest is as above, for example, mine was: ovms/leaf/client/<My Cars Registration>/command/<whatyoulike>
My final topic, I have split each function into its own topic, but it doesn't really seem to matter. As long as the payload of the message contains the commands that you would enter into the Shell on the OVMS.
So, finally we get: ovms/leaf/client/<My Cars Registration>/command/charge with a payload of charge start
When successful, aside from the car charging, if you are using something like MQTT explorer, a new topic will be created called ovms/leaf/client/<My Cars Registration>/response/<whatyoulike>
This will contain the messages sent back by OVMS for those commands.
Hope I've helped someone, or maybe you're not as dense as me.
Helpful, thanks.
Note that the purpose of the <whatyoulike> is so that the requester can provide an ID for the command, that will come back in the response. This allows multiple commands to be issued, and the responses matched to the command. I suggest either using a UUID (best), or incrementing ID, for that.