<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="" style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif; font-size: 13px;"><div class=""><div class=""><div class="">- what is the best way to signal that the charging connector is plugged? ms_v_charge_pilot?</div><div class="">previously it was cardoorbits1. </div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">From OVMS v2:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class="">extern unsigned char car_doors1;</div><div class="">typedef struct {</div><div class="">  unsigned FrontLeftDoor:1;     // 0x01</div><div class="">  unsigned FrontRightDoor:1;    // 0x02</div><div class="">  unsigned ChargePort:1;        // 0x04</div><div class="">  unsigned PilotSignal:1;       // 0x08</div><div class="">  unsigned Charging:1;          // 0x10</div><div class="">  unsigned :1;                  // 0x20</div><div class="">  unsigned HandBrake:1;         // 0x40</div><div class="">  unsigned CarON:1;             // 0x80</div><div class="">} car_doors1bits_t;</div><div class="">#define car_doors1bits (*((car_doors1bits_t*)&car_doors1))</div></div></blockquote><div class=""><br class=""></div><div class="">For v3, ChargePort is MS_V_DOOR_CHARGEPORT (v.d.cp), PilotSignal is MS_V_CHARGE_PILOT (v.c.pilot), and Charging is MS_V_CHARGE_INPROGRESS (v.c.charging).</div><div class=""><br class=""></div><div class="">If you don’t have charge port detection, probably best to change that along with MS_V_CHARGE_PILOT.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="" style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif; font-size: 13px;"><div class=""><div class=""><div class="">- what is the best way to compare OvmsMetricStrings? Or should I dublicate the state in an enum and use that?</div><div class="">- what is the best way to compare the OvmsMetricFloat to a literal float?</div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Not really sure what you mean by these. You typically don’t need to compare (just set the value and the metrics system will work out if it is modified and change appropriately). You can retrieve the current value with functions like AsString, AsInt, AsFloat, etc.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-family: "Helvetica Neue", Helvetica, Arial, sans-serif; font-size: 13px;"><div class=""><div class=""><div class="">- what is the current way of doing <span class="">net_req_notification</span></div></div></div></div></div></blockquote><div><br class=""></div><div>Not required in v3. If you change a metric that needs notification, the serverv2 and serverv3 will act appropriately.</div><div><br class=""></div><div>In general, we’ve tried to make it as easy for the vehicle modules as possible, and remove duplicate code. All you need to do is read the value off the bus, and set the appropriate metric. If you need that for later comparison (in native form), store it as well as a m_* member variable of your vehicle object and use that.</div><div><br class=""></div><div>Regards, Mark.</div><div><br class=""><blockquote type="cite" class=""><div class="">On 19 Jul 2018, at 6:00 AM, Nikolay Shishkov <<a href="mailto:nshishkov@yahoo.com" class="">nshishkov@yahoo.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><div style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;" class=""><div style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;" class=""><div style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;" class=""><div class=""></div>
        <div class="">Hi, </div><div class="">I am working on the Think City EV code and have some questions.</div><div class="">- what is the best way to signal that the charging connector is plugged? ms_v_charge_pilot?</div><div class="">previously it was cardoorbits1. </div><div class=""><br class=""></div><div class="">- what is the best way to compare OvmsMetricStrings? Or should I dublicate the state in an enum and use that?</div><div class=""><br class=""></div><div class="">- what is the best way to compare the OvmsMetricFloat to a literal float?</div><div class=""><br class=""></div><div class="">- what is the current way of doing <span class="">net_req_notification</span></div><div class=""><br class=""></div><div class="">Thanks in advance,</div><div class="">Nikolay</div>
        
        </div></div><div id="yahoo_quoted_1950539485" class="yahoo_quoted">
            <div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;" class="">
                
                <div class="">
                    On Tuesday, July 17, 2018, 3:37:49 AM GMT+2, Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net" class="">mark@webb-johnson.net</a>> wrote:
                </div>
                <div class=""><br class=""></div>
                <div class=""><br class=""></div>
                <div class=""><div dir="ltr" class="">Jacob,<br clear="none" class=""><br clear="none" class="">> Is there a reason why OVMS bundles three different SSL libraries?<br clear="none" class=""><br clear="none" class=""><br clear="none" class="">I think wolfSSL is there (but WOLFCRYPT_ONLY) because wolfSSH needs it.<br clear="none" class=""><br clear="none" class="">The ESP-IDF offers mbedtls and openssl libraries, but we don’t currently use either.<br clear="none" class=""><br clear="none" class="">> Also why is there a custom HTTP implementation when mongoose already has one?<br clear="none" class=""><br clear="none" class=""><br clear="none" class="">Primarily because we wrote those before we included mongoose into the project. But also because the mongoose http_client code sucks. It reads the entire message body into RAM, before passing it on to the client; that just won’t work for something like a firmware image.<br clear="none" class=""><br clear="none" class="">To complicate the choice further, ESP now includes a esp_http_client in their latest 3.x IDF (which wasn’t there before).<br clear="none" class=""><br clear="none" class="">I did try to convert our TCP and HTTP client libraries to mongoose a while ago, but failed. Those libraries are blocking (with i/o done in the context of the thread calling them), but the mongoose library is event-based non-blocking (with i/o output in the context of the calling thread, and i/o input in the context of the mongoose thread). Mongoose didn’t use to be thread safe, and that caused us all sorts of issues (now solved, by the work Michael and others did to make it thread safe).<br clear="none" class=""><br clear="none" class="">> IMO the best way would be to rewrite ovms_net and<br clear="none" class="">> ovms_http to use mongoose and configure mongoose to compile with SSL<br clear="none" class="">> support (probably mbedtls as the other two don't work).<br clear="none" class=""><br clear="none" class="">I agree. In general, I prefer the mongoose approach, and we are trying to standardise on that (for good or bad).<br clear="none" class=""><br clear="none" class="">Probably the best would be to fix the http client in mongoose to work properly (or at least have an option to deliver the body block by block as they arrive), then convert our stuff that uses ovms tcp/http libraries, then drop the tcp and http libraries. Not trivial given the different models (blocking vs non-blocking events).<br clear="none" class=""><br clear="none" class="">Between openssl vs mbedtls, I don’t really care. I think we’re going to have to manage certificate loading ourselves anyway (as we need to load from a combination of statically defined (in flash using COMPONENT_EMBED_TXTFILES and asm(“_binary_* start/end) and dynamic (in /store/tls/trustedca/* or somewhere like that).<br clear="none" class=""><br clear="none" class="">Regards, Mark.<br clear="none" class=""><br clear="none" class="">> On 17 Jul 2018, at 1:02 AM, Jakob Löw <<a shape="rect" ymailto="mailto:ovms@m4gnus.de" href="mailto:ovms@m4gnus.de" class="">ovms@m4gnus.de</a>> wrote:<br clear="none" class="">> <br clear="none" class="">> Hey,<br clear="none" class="">> <br clear="none" class="">> I've been playing around a bit with implementing SSL/TLS support. For<br clear="none" class="">> starters I wanted to implement an OvmsNetTlsConnection class which<br clear="none" class="">> could then be used for https requests. At first I tried using wolfSSL<br clear="none" class="">> but it turns out wolfSSL is compiled with WOLFCRYPT_ONLY. OpenSSL also<br clear="none" class="">> didn't work as SSL_CTX_load_verify_locations is missing in ESP-IDF's<br clear="none" class="">> OpenSSL. I didn't try mbedtls yet. Is there a reason why OVMS bundles<br clear="none" class="">> three different SSL libraries? Also why is there a custom HTTP<br clear="none" class="">> implementation when mongoose already has one? Speaking of mongoose, it<br clear="none" class="">> seems to have an abstraction layer which allows to use one of the three<br clear="none" class="">> SSL/TLS libraries. IMO the best way would be to rewrite ovms_net and<br clear="none" class="">> ovms_http to use mongoose and configure mongoose to compile with SSL<br clear="none" class="">> support (probably mbedtls as the other two don't work).<br clear="none" class="">> <br clear="none" class="">> - Jakob<br clear="none" class="">> <br clear="none" class="">> On Mon, 2018-07-16 at 12:47 +0800, Mark Webb-Johnson wrote:<br clear="none" class="">>> Drupal authentication is done, and working against mosquitto now on<br clear="none" class="">>> the live <a href="http://api.openvehicles.com" class="">api.openvehicles.com</a> site. Plain text MQTT only at the<br clear="none" class="">>> moment (I still need to get mosquitto and OVMS module firmware<br clear="none" class="">>> supporting SSL).<br clear="none" class="">>> <br clear="none" class="">>> To configure OVMS v3 to use Server V3 protocol:<br clear="none" class="">>> <br clear="none" class="">>> config set:<br clear="none" class="">>> vehicle id <vehicleid><br clear="none" class="">>> server.v3 server <a href="http://api.openvehicles.com" class="">api.openvehicles.com</a><br clear="none" class="">>> server.v3 port 1883<br clear="none" class="">>> server.v3 user <<a href="http://openvehicles.com" class="">openvehicles.com</a> username><br clear="none" class="">>> password server.v3 <<a href="http://openvehicles.com" class="">openvehicles.com</a> password><br clear="none" class="">>> <br clear="none" class="">>> server v3 start<br clear="none" class="">>> <br clear="none" class="">>> Can also 'config set auto server.v3 yes’ to auto-start at boot<br clear="none" class="">>> <br clear="none" class="">>> If you have an MQTT client, you can connect to the same server to<br clear="none" class="">>> query the metrics, issue commands, etc. The default topic hierarchy<br clear="none" class="">>> is ovms/<username>/<vehicleid>.<br clear="none" class="">>> <br clear="none" class="">>> I think we are close now. Just need SSL support. And then Apps…<br clear="none" class="">>> <br clear="none" class="">>> Feedback appreciated.<br clear="none" class="">>> <br clear="none" class="">>> Regards, Mark.<br clear="none" class="">>> <br clear="none" class="">>>> On 10 Jul 2018, at 2:42 PM, Mark Webb-Johnson <<a shape="rect" ymailto="mailto:mark@webb-johnson.ne" href="mailto:mark@webb-johnson.ne" class="">mark@webb-johnson.ne</a><br clear="none" class="">>>> t> wrote:<br clear="none" class="">>>> <br clear="none" class="">>>> I’ve just pushed the support for notifications in OVMS Server v3.<br clear="none" class="">>>> <br clear="none" class="">>>> With that, the server v3 is functionally complete (at least on the<br clear="none" class="">>>> car side). We can:<br clear="none" class="">>>> <br clear="none" class="">>>> Connect/disconnect<br clear="none" class="">>>> Handle lists of apps connecting/disconnecting<br clear="none" class="">>>> Send metrics<br clear="none" class="">>>> Send events<br clear="none" class="">>>> Send notifications (including info, error, alert, and historical<br clear="none" class="">>>> data)<br clear="none" class="">>>> Receive commands, run them, and return the results<br clear="none" class="">>>> <br clear="none" class="">>>> I’m still struggling against drupal authentication at the server<br clear="none" class="">>>> side; once that is done we can open this up to wider testing.<br clear="none" class="">>>> <br clear="none" class="">>>> Overall, I’m pretty happy with it. We need SSL/TLS support, but at<br clear="none" class="">>>> least functionally now it works and is complete.<br clear="none" class="">>>> <br clear="none" class="">>>> Regards, Mark<br clear="none" class="">>>> <br clear="none" class="">>>>> On 6 Jul 2018, at 4:16 PM, Mark Webb-Johnson <<a shape="rect" ymailto="mailto:mark@webb-johnson.n" href="mailto:mark@webb-johnson.n" class="">mark@webb-johnson.n</a><br clear="none" class="">>>>> et> wrote:<br clear="none" class="">>>>> <br clear="none" class="">>>>>>>> I suppose the following topic names:<br clear="none" class="">>>>>>>> metrics:       <prefix>/metric/#<br clear="none" class="">>>>>>>> events:        <prefix>/event/#<br clear="none" class="">>>>>>>> notifications: <prefix>/notify/#<br clear="none" class="">>>>>>>> config:        <prefix>/config/#<br clear="none" class="">>>>>>>> logs:          <prefix>/log/<tag><br clear="none" class="">>>>>>>> active:        <prefix>/client/<clientid>/active<br clear="none" class="">>>>>>>> requests:      <prefix>/client/<clientid>/request/#<br clear="none" class="">>>>>>>> commands:      <prefix>/client/<clientid>/command/<command<br clear="none" class="">>>>>>>> id><br clear="none" class="">>>>>>>> cmd responses: <prefix>/client/<clientid>/response/<command<br clear="none" class="">>>>>>>> id><br clear="none" class="">>>>>>> <br clear="none" class="">>>>>>> All ok. I am fine with this, and looks clean. I will make the<br clear="none" class="">>>>>>> changes today, as I want to get this into some cars asap so<br clear="none" class="">>>>>>> we can get a feel for how it behaves.<br clear="none" class="">>>>> <br clear="none" class="">>>>> Ok. Now implemented, and tested:<br clear="none" class="">>>>> <br clear="none" class="">>>>> <prefix>/metric/#<br clear="none" class="">>>>> <prefix>/client/<clientid>/active<br clear="none" class="">>>>> <prefix>/client/<clientid>/command/<command id><br clear="none" class="">>>>> <prefix>/client/<clientid>/response/<command id><br clear="none" class="">>>>> <br clear="none" class="">>>>> I don’t think config, logs, and requests are critical or urgent.<br clear="none" class="">>>>> So, I will try to finish events tonight (as that is relatively<br clear="none" class="">>>>> simple). Notifications over the weekend (more tricky, especially<br clear="none" class="">>>>> for historical data). It can go in my car with tonight’s nightly<br clear="none" class="">>>>> ota, for real world testing.<br clear="none" class="">>>>> <br clear="none" class="">>>>> I’m still trying to get the authentication working for drupal vs<br clear="none" class="">>>>> mosquitto. Once that is done, I can open up<br clear="none" class="">>>>> <a href="http://api.openvehicles.com" class="">api.openvehicles.com</a> MQTT for public use. If I can’t get it done<br clear="none" class="">>>>> within the next couple of days, I’ll try another broker (lua<br clear="none" class="">>>>> scripting, anyone?).<br clear="none" class="">>>>> <br clear="none" class="">>>>> P.S. Commands over MQTT are pretty cool:<br clear="none" class="">>>>> <br clear="none" class="">>>>> <PastedGraphic-2.tiff><br clear="none" class="">>>>> <PastedGraphic-3.tiff><br clear="none" class="">>>>> <br clear="none" class="">>>>> Regards, Mark.<br clear="none" class="">>>>> _______________________________________________<br clear="none" class="">>>>> OvmsDev mailing list<br clear="none" class="">>>>> <a shape="rect" ymailto="mailto:OvmsDev@lists.openvehicles.com" href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br clear="none" class="">>>>> <a shape="rect" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><div class="yqt4699584052" id="yqtfd16403"><br clear="none" class="">>>> <br clear="none" class="">>>> _______________________________________________<br clear="none" class="">>>> OvmsDev mailing list<br clear="none" class="">>>> <a shape="rect" ymailto="mailto:OvmsDev@lists.openvehicles.com" href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br clear="none" class="">>>> <a shape="rect" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br clear="none" class="">>> <br clear="none" class="">>> _______________________________________________<br clear="none" class="">>> OvmsDev mailing list<br clear="none" class="">>> <a shape="rect" ymailto="mailto:OvmsDev@lists.openvehicles.com" href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br clear="none" class="">>> <a shape="rect" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br clear="none" class="">> _______________________________________________<br clear="none" class="">> OvmsDev mailing list<br clear="none" class="">> <a shape="rect" ymailto="mailto:OvmsDev@lists.openvehicles.com" href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br clear="none" class="">> <a shape="rect" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br clear="none" class=""><br clear="none" class="">_______________________________________________<br clear="none" class="">OvmsDev mailing list<br clear="none" class=""><a shape="rect" ymailto="mailto:OvmsDev@lists.openvehicles.com" href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br clear="none" class=""><a shape="rect" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br clear="none" class=""></div></div></div>
            </div>
        </div></div></div>_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></body></html>