I have committed some small changes today that address nagging problems I’ve seen on the api.openvehicles.com <http://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 <http://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.