<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Chris,<div><br></div><div>I think long-term, MQTT (and the IOT way of doing things) is going to be easier and more flexible (even for single user case).</div><div><br></div><div>But for that, I/we need to get our mongoose library to support MQTT v5 topics properly, and then see if the data usage is acceptable. If so, then all that will be required would be a MQTT server (like mosquito) with no OVMS server required at all for basic functionality (although something simple would be required for things like historical data storage).</div><div><br></div><div>The problem I am hitting now is definitely HTTP API over SSL. With hundreds of users using that (some hitting the server with the same /api/status request every 10 seconds), the server is crawling.</div><div><br></div><div>The good news is that since running this new version, I haven’t seen a single 'ClientsTransmit mismatch’ - although my simple grep on ‘mismatch’ is showing a few 'Vehicle Alert #888: VMS/PEM key mismatch - Disarm vehicle with key fob before starting’ for roadster users ;-)<br><div><br></div><div>Regards, Mark</div><div><br><blockquote type="cite"><div>On 17 May 2023, at 4:17 PM, Chris van der Meijden <chris@arachnon.de> wrote:</div><br class="Apple-interchange-newline"><div><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div>Hi Mark,</div><div><br></div><div>thanks for the new development and for your thoughts on V3 and V2.</div><div><br></div><div>I would like to add, that the V2 server for me is still a good server to use as a selfhostet, standalone server.</div><div><br></div><div>This, simple, functionallity should ideally be kept in future development from my perspective.</div><div><br></div><div>Regards</div><div><br></div><div>Chris</div><div><br></div><div>Am Mittwoch, dem 17.05.2023 um 13:07 +0800 schrieb Mark Webb-Johnson:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>I have committed some small changes today that address nagging problems I’ve seen on the <a href="http://api.openvehicles.com/">api.openvehicles.com</a> server.</div><div><br></div><div>The most interesting of these shows in the logs as:</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>11:04:30.799832 +0800 info OVMS::Server::ApiV2: #497 - - new connection from <redacted>:<redacted></div><div>11:04:30.800143 +0800 info OVMS::Server::Core: #497 - - ConnStart</div><div>11:04:32.147232 +0800 error OVMS::Server::ApiV2: #497 A <owner/vehicle> disconnected</div><div>11:04:32.149214 +0800 info OVMS::Server::Core: #497 A <span style="caret-color: rgb(0, 0, 0);"><owner/vehicle></span> AppDisconnect</div><div>11:04:32.149614 +0800 info OVMS::Server::Core: #497 - - ConnFinish</div><div>11:04:32.149924 +0800 info OVMS::Server::ApiV2: #497 A <span style="caret-color: rgb(0, 0, 0);"><owner/vehicle></span> got proto #/A login</div><div>11:04:32.150859 +0800 info OVMS::Server::Core: #497 - <span style="caret-color: rgb(0, 0, 0);"><owner/vehicle></span> AppConnect</div><div>11:04:45.071599 +0800 info OVMS::Server::ApiV2: #501 C <span style="caret-color: rgb(0, 0, 0);"><owner/vehicle></span> got proto #0/C login</div><div>11:04:45.072874 +0800 info OVMS::Server::Core: #501 C <span style="caret-color: rgb(0, 0, 0);"><owner/vehicle></span> CarConnect</div><div>11:04:45.073157 +0800 error OVMS::Server::Core: #497 <span style="caret-color: rgb(0, 0, 0);"><owner/vehicle></span> ClientsTransmit mismatch /</div></blockquote><div><br></div><div>So at <span style="caret-color: rgb(0, 0, 0);">11:04:30.799832 we got a new connection from an App. Then at </span><font><span style="caret-color: rgb(0, 0, 0);">11:04:32.147232 it disconnected. Then at 11:04:32.149924 we got the login. Huh? The rest is the car loging in and trying to inform the messed up app connection.</span></font></div><div><span style="caret-color: rgb(0, 0, 0);"><br></span></div><div><span style="caret-color: rgb(0, 0, 0);">I guess the login message was held in a push_read buffer within AnyEvent::Handle, but the disconnect error took priority and was delivered first. Fix I made for this is to shutdown reads when handling the disconnect, and another check to not login if the connection has been cleared half way through negotiation.</span></div><div><span style="caret-color: rgb(0, 0, 0);"><br></span></div><div><font><span style="caret-color: rgb(0, 0, 0);">Anyway, seems better now, but </span></font><a href="http://api.openvehicles.com/" style="caret-color: rgb(0, 0, 0);">api.openvehicles.com</a><font> is still experiencing heavy load (due to sheer number of concurrent users we have now, combined with a large number of HTTP API users and cpu-intensive SSL connections). It seems that one single HTTPS API user is equivalent to about 50 API v2 users. I think the only way of easily scaling this further now is a switch to MQTT, and have been wondering if the API v2 server could just be a simple bi-directional translator to/from MQTT (which would give us a nice migration path and better support IOT).</font></div><div><br></div><div><font>Regards, Mark.</font></div><div><font><br></font></div><div>_______________________________________________<br></div><div>OvmsDev mailing list<br></div><div><a href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a><br></div><div><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br></div></blockquote><div><br></div><div><span></span></div></div>
_______________________________________________<br>OvmsDev mailing list<br>OvmsDev@lists.openvehicles.com<br>http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br></div></blockquote></div><br></div></body></html>