Send OvmsDev mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of OvmsDev digest..."
Today's Topics:
1. Re: Can buses stop after some time (Stein Arne Sordal)
2. Re: Can buses stop after some time (Tom Parker)
3. Re: Nissan Leaf Support Request (Tom Parker)
4. Re: MQTT and Ovms Server v3 (Jakob L?w)
----------------------------------------------------------------------
Message: 1
Date: Thu, 5 Jul 2018 08:34:17 +0200
Subject: Re: [Ovmsdev] Can buses stop after some time
Content-Type: text/plain; charset=utf-8
Did anyone figure out what happens here?
Now the OVMS thinks my car is stolen since it?s moving (GPS) and CAN2 is dead.
Reboot of module brings CAN2 back to life for a period of time.
-Stein Arne Sordal-
>
> Hi Tom
>
> I have seen this with my Leaf.
> I?ve been on vacation, so I haven?t got time to test a lot, but it looks like one of the can buses stops. Started testing again today.
>
> -Stein Arne Sordal-
>
>
>
>>
>> Hi all,
>>
>> I synced up with master about a week ago and since then I've seen both can busses stop working. I still see the 12v battery metric changing, but everything that comes from the car stops. Rebooting the module with "module reset" does not seem to fix it, while make app-flash monitor does fix it. I haven't tried make monitor on it's own.
>>
>> Is anyone else seeing behavior like this?
>>
>> Sorry for the vague bug report. I'll spend some time later this weekend to try to gather more information.
>> _______________________________________________
>> OvmsDev mailing list
>
> _______________________________________________
> OvmsDev mailing list
------------------------------
Message: 2
Date: Thu, 5 Jul 2018 19:55:05 +1200
Subject: Re: [Ovmsdev] Can buses stop after some time
Content-Type: text/plain; charset=utf-8; format=flowed
I haven't had a chance to try to work out what is going on.
I can say that the second can interface doesn't work for very long
before stopping. This manifests most obviously on my Leaf as a stopped
odometer in the OVMS app. If you look at the metrics in the console then
everything that comes from the Car CAN bus (ie the second CAN bus) has
frozen.
The first CAN interface seems much more reliable, with SOC information
from the EV bus being fairly reliably reported.
I haven't done the modification to make my 3.0 unit's GPS work so I
haven't experienced the stolen detection.
On 05/07/18 18:34, Stein Arne Sordal wrote:
> Did anyone figure out what happens here?
> Now the OVMS thinks my car is stolen since it?s moving (GPS) and CAN2 is dead.
> Reboot of module brings CAN2 back to life for a period of time.
>
> -Stein Arne Sordal-
>
>
>
>>
>> Hi Tom
>>
>> I have seen this with my Leaf.
>> I?ve been on vacation, so I haven?t got time to test a lot, but it looks like one of the can buses stops. Started testing again today.
>>
>> -Stein Arne Sordal-
>>
>>
>>
>>>
>>> Hi all,
>>>
>>> I synced up with master about a week ago and since then I've seen both can busses stop working. I still see the 12v battery metric changing, but everything that comes from the car stops. Rebooting the module with "module reset" does not seem to fix it, while make app-flash monitor does fix it. I haven't tried make monitor on it's own.
>>>
>>> Is anyone else seeing behavior like this?
>>>
>>> Sorry for the vague bug report. I'll spend some time later this weekend to try to gather more information.
>>> _______________________________________________
>>> OvmsDev mailing list
>> _______________________________________________
>> OvmsDev mailing list
> _______________________________________________
> OvmsDev mailing list
------------------------------
Message: 3
Date: Thu, 5 Jul 2018 20:34:34 +1200
Subject: Re: [Ovmsdev] Nissan Leaf Support Request
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 01/07/18 21:23, Mark Webb-Johnson wrote:
> A user has a raised a ticket:
>
>
I can't see this link
>
> I would like to be able to turn my A/C on and off remotely as
> discussed
> I use their version of the OVMS app it just crashes repeatedly
> after I input my car's settings so I can't use it. However when I
> use the play market version of the app, there is no A/C button but
> it runs solidly and I can see my car's information (it works). Is
> there a way to turn the A/C on and off with this version of the
> app? Also, I'm assuming (perhaps incorrectly) that the latest
> hardware already has the features built in and no flashing is
> necessary.
>
You want to use the play store version. I'm running 3.12.4 from the Play
store and when connected to a Leaf, I see the AC button.
> Bonus questions:
> In the app it seems there's an ability to unlock my car and to put
> it in valet mode but those features need a pin. Where does this
> pin come from and do the features really work? What is valet mode
> anyway?
>
Not all cars support lock and unlock or valet mode. We have some code
that works for lock/unlock on the Leaf but it's not yet finished. There
are no plans to support valet mode.
> What is the 'Features' section of the app for? I see that I need
> to set my #15 CAN Write to 1 before I can expect the A/C control
> to work which I've done but is there any info on what the rest of
> it does?
>
You don't need this for OVMS v3.
> Server: 2.1.1-20121216
> Car: 3.1.006
> App: 3.12.4 (20180428
> Update: The remote A/C worked with homelink 1 and 2 when I got
> home to charge. I don't have a model with navigation or car wings
> so I don't think I have the option mentioned about when to allow
> remote A/C with respect to SOC level. Is it possible that there's
> a way to set this option with the OVMS?
>
We still support climate control with homelink 1 & 2 for old apps. This
at least lets use separate your climate control button problem questions
about how the AC works.
Which model year Leaf do you have? Older than 2013 may require extra
hardware to enable climate control when the car is asleep. 2013 through
2015 use a different remote climate control to that of 2016 & 2017. You
have to set the module year configuration option to tell the OVMS which
car you have. 2018 Leafs are not yet supported.
We made a change to how the climate control is switched off recently and
this is probably in the latest firmware (which you don't have on your
OVMS). We don't have a way way to configure the remote climate control
-- the OVMS simply sends the enable command to the car and the car does
it's thing.
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 4
Date: Thu, 05 Jul 2018 11:41:43 +0200
Subject: Re: [Ovmsdev] MQTT and Ovms Server v3
Content-Type: text/plain; charset="utf-8"
Hey,
Regarding naming:
I suppose the following topic names:
metrics: <prefix>/metric/#
events: <prefix>/event/#
notifications: <prefix>/notify/#
config: <prefix>/config/#
logs: <prefix>/log/<tag>
active: <prefix>/client/<clientid>/active
requests: <prefix>/client/<clientid>/request/#
commands: <prefix>/client/<clientid>/command/<command id>
cmd responses: <prefix>/client/<clientid>/response/<command id>
Filtering:
In order to decrease used data a blacklist of metrics which are not
send (like m.freeram or m.monotonic) would be cool.
heartbeats:
I've seen you implemented that clients have to send a message every two
minutes. A topic like the above .../<clientid>/active which is set to 1
when a client connects and to 0 by its last will would have the same
effect but not require heartbeats to be sent every two minutes and thus
use less of our precious cellular data.
Requesting values:
In order to decrease data usage even more allowing clients to request
the value of a metric using <prefix>/client/<clientid>/request/metric
and the metric name in the value or using
<prefix>/client/<clientid>/request/config and the config name in the
value. Allowing wildcards like m.net.* or just * allows to request
multiple or all metrics with a single request. Then e.g. the app would
request all metrics it wants to display.
Encryption:
TLS in general seems to be a missing thing with OVMS. Downloading
firmware updates over http and not doing any verification is kind of
meh. The problem is (as noted in my last email) with the CA certs. My
suggestion is to ship with one default CA (e.g. Let's Encrypt) and
allow the user to replace it with a different one.
I would love to implement this, but I am currently in exam phase and
won't have much time to spare until next week.
Authentification:
If you can live with moving to mosquitto[0] (MQTT broker by eclipse)
they have a very good auth plugin[1]. All you have to do is to write an
sql statement which receives the hashed passwords from the OVMS
database by username (see [2]).?If you are on debian its just an apt
install mosquitto mosquitto-auth-plugin away.
It is very important to set up ACL (access control lists) which make
sure only user X can subscribe/publish to ovms/X and noone else.
Luckily this is also handeled by mosquitto_auth_plug
On Thu, 2018-07-05 at 09:26 +0800, Mark Webb-Johnson wrote:
> I am far from an expert in MQTT. Not even a novice. So, the work
> below is ?best efforts?. Any help / comments / suggestions would be
> most appreciated. In particular, a big thanks to Jakob for his
> contributions to this so far.
>
> With yesterday?s merge, and commits, we have a very very basic OVMS
> server v3 implementation. It sends the metrics, and doesn?t crash
> (much). The overall design is as follows:
>
> We use the mongoose mqtt library. We don?t do anything special, and
> everything is following the mqtt 3.1 standard.
>
> MQTT has the concept of topics. Our default prefix for everything is:
>
> ovms/<mqtt-username>/<vehicleid>/
>
> (that can be customised with config server.v3 topic.prefix)
>
> Metrics are sent as topics. The metric name is added to the topic
> prefix + ?m/? suffix, and ?.? characters converted to ?/? to match
> the MQTT conventions. The value is simply the metric value (as a
> string). With our current arrangement, this adds m/m/, m/s/, and m/v/
> sub-trees to the the MQTT topic hierarchy. Clients can subscribe to
> <prefix>/m/# to receive all metrics. The ?retained? flag is set on
> these metrics, at QOS level 0 (so subscribing clients will get a copy
> of the last known values for these metrics, even with a disconnected
> vehicle).
>
> The metric?s.v3.connected is maintained by the ServerV3 code. When a
> successful MQTT connection is made, and login successful, that is set
> true (yes). A MQTT last-will-testament is set so that if the OVMS
> module disconnects the server will automatically update that to false
> (no). The ?retained? flag is set on this metric, at QOS level 0 (so
> subscribing clients will get a copy of the last known state). Clients
> can use this to see if the vehicle is connected to the server.
>
> Connecting clients are expected to write a ?1? value to the
> <prefix>/c/<clientid> topic, and to repeat that write once a minute.
> They are also expected to use a last-will-testament on that same
> topic with value ?0?. QOS 1 should be used, and these topics should
> not be retained. The server V3 code subscribes to this <prefix>/c/#
> topic, so it gets informed of all connected clients. It can then
> update the s.v3.peers metric appropriately. Clients are expected to
> monitor the <prefix>/s/v3/connected topic, so that if it becomes
> ?yes? (true) the client should send <prefix>/c/<clientid> ?1?
> immediately. This mechanism allows a newly connected vehicle to
> immediately know if one or more clients is connected.
>
> The Server v3 sets a timeout for <prefix>/c/<clientid> connections of
> 2 minutes. If that mqtt topic is not sent again within that time, it
> is expired (and that client is treated as disconnected).
>
> Similar to the v2 code, the server v3 transmits modified metrics once
> a minute if there are one or more clients connected, or once every
> ten minutes if there are no clients connected.
>
> All the above has been implemented. To reach parity with v2, and
> exceed it?s functionality in places, we have a few more things to do:
>
> Notifications
>
> On the vehicle side, I am proposing to use the <prefix>/notify/<type>
> namespace for these, using QOS 2 messages without retention. Clients
> can listen to those, if necessary. We can also have a central daemon
> running that listens to ovms/+/+/n/# topic pattern to receive these
> notifications and handle appropriately. Using QOS 2 we can confirm
> the reception of the notification / historical data, and mark it as
> delivered, appropriately. However, that would only confirm delivery
> to the MQTT server, not to the central daemon; if the daemon was not
> running, the notification would be lost.
>
> Textual Commands
>
> I am proposing to use the <prefix>/cmd/<clientid>/c/ and
> <prefix>/cmd/<clientid>/r/ namespaces for this, using QOS 2 messages
> without retention. The value in the /c/ would be the command, and the
> response would be written to matching the /r/ topic. The commands and
> responses could be prefixed by an identifier (like in imap protocol)
> so responses can be matched to commands by the clients). The client
> side can simply subscribe to itself, and the vehicle side subscribes
> to <prefix>/cmd/#. In this way, commands cannot be duplicated, and
> clients don?t see responses to commands they didn?t initiate (which
> was an issue with v2).
>
> Numeric Commands
>
> I am not sure if we need to implement the numeric commands, as used
> in the v2 protocol. It seems to me that we can use textual commands.
>
> Config Access
>
> I am not sure if we need this, beyond the command processor. If we
> do, we could expose a /config/ namespace.
>
> Events
>
> It would be nice to expose events (except for the ticker.* ones, of
> course). This could be done by a <prefix>/events topic, using QOS 2
> and no retention.
>
> Logs
>
> It would be nice to expose logs. This could be done by a
> <prefix>/logs topic, using QOS 1 and no retention.
>
> Security
>
> We need to add SSL support. I am trying to get an authentication
> plugin for mosquitto / vernemq written so that we can authenticate
> straight from the OVMS database that is already running on the
> servers, and give each user their own ovms/<userid>/# namespace. That
> way, the configuration for v3 on the vehicle/apps/clients is simple -
> just put in the server username and password (no separate vehicle
> passwords necessary).
>
> I think that is it. The above would form the basis of the
> specification for this. As this is the basis for future work and
> direction in OVMS, it is important that we get it right, so all
> comments / suggestions most welcome.
>
> Regards, Mark.
>
> _______________________________________________
> OvmsDev mailing list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
------------------------------
Subject: Digest Footer
_______________________________________________
OvmsDev mailing list
------------------------------
End of OvmsDev Digest, Vol 78, Issue 8
**************************************