I have committed some small changes today that address nagging problems I’ve seen on the api.openvehicles.com server.

The most interesting of these shows in the logs as:

11:04:30.799832 +0800 info  OVMS::Server::ApiV2: #497 - - new connection from <redacted>:<redacted>
11:04:30.800143 +0800 info  OVMS::Server::Core: #497 - - ConnStart
11:04:32.147232 +0800 error OVMS::Server::ApiV2: #497 A <owner/vehicle> disconnected
11:04:32.149214 +0800 info  OVMS::Server::Core: #497 A <owner/vehicle> AppDisconnect
11:04:32.149614 +0800 info  OVMS::Server::Core: #497 - - ConnFinish
11:04:32.149924 +0800 info  OVMS::Server::ApiV2: #497 A <owner/vehicle> got proto #/A login
11:04:32.150859 +0800 info  OVMS::Server::Core: #497 - <owner/vehicle> AppConnect
11:04:45.071599 +0800 info  OVMS::Server::ApiV2: #501 C <owner/vehicle> got proto #0/C login
11:04:45.072874 +0800 info  OVMS::Server::Core: #501 C <owner/vehicle> CarConnect
11:04:45.073157 +0800 error OVMS::Server::Core: #497  <owner/vehicle> ClientsTransmit mismatch /

So at 11:04:30.799832 we got a new connection from an App. Then at 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.

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.

Anyway, seems better now, but api.openvehicles.com 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).

Regards, Mark.