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