Hi Mark, Thanks, your info is helpful. In my previous email:
Looking at the code I'm also trying to understand what exactly a "client" is. Here's how it looks to me: a client sends a message with topic <prefix>/client/<clientid>/ active with the payload being non-0 to "connect" and 0 or empty to disconnect. Must send that at least once every 120 seconds to stay connected.
With a client "connected" the MQTT server will send metrics at the updatetime.connected rate rather than the idle rate (nowithstanding that with "stream 1" they are sent immediately).
So in case it helps anyone else - I tested this and it works like I wrote it up - When I send the "active" message (mosquitto_pub -h ... -p ... -u ... -P ... -t 'ovms/vehicleid/client/test/active' -m '1') I see this logged: I (55489522) ovms-server-v3: Incoming message ovms/vehicleid/client/test/active: 1 I (55489522) ovms-server-v3: MQTT client test has connected I (55489532) ovms-server-v3: Tx metric ovms/vehicleid/metric/s/v3/peers=1 I (55489532) ovms-server-v3: One or more peers have connected I (55489542) ovms-server-v3: Tx event app.connected And at this point I see the metrics published every 10 seconds as I had set the updatetime.connected to 10: # config set server.v3 updatetime.connected 10 # config set server.v3 updatetime.idle 300 # config set vehicle stream 0 When I mark the client as in-active then the update time goes back to every 5 minutes. This seems more manageable than the continuous streaming, a sensible compromise. But should I be working with MQTT? Right now Mark and Michael you are by far the biggest contributors so I'd definitely take a steer from you about this. I don't think it helps the project to have two different approaches "competing" in the same code base. You say:
The V3 server needs further development from actual users like you. I don't use MQTT because of the protocol overhead. So go ahead, refine it.
So the blunt question is whether this MQTT / V3 approach is dying on the vine or if it is worth investing time into. Looks like Mark wrote most of it 3 years ago. For me I'm used to MQTT, I like it and use it in my house control systems, energy monitoring, OpenEVSE etc. It's exactly designed for the IOT world. NodeRed, Homeassistant and other tools support it well. But OVMS is already invested in the V2 protocol and you are still developing it. As implemented, the V3/MQTT approach will definitely have more overhead - and indeed sending every metric in a separate message will use a lot more data. But nothing says that we can't have a "compact" format similar to the data messages that V2 sends. MQTT adds just a few bytes per published message for the MQTT protocol so that would end up being nearly as efficient unless I've missed something? It does mean that consumers of the MQTT messages need to work harder to parse them - they would need to know the order of the values. We couldn't use a self-describing format like JSON since that has plenty of overhead of its own. Another approach is - instead of having the V3/MQTT "server" on OVMS, to rather have a two way gateway that runs server-side that connects to the V2 server and proxies back and forth from MQTT. I would see this as an "app" side gateway - so metric records coming from the car get published to mqtt (v2->v3) and commands are translated back the other way (v3->v2). Then the extra protocol overhead for the existing MQTT format doesn't matter since we aren't going to be sending over an "IOT" SIM over 3G. What are your thoughts? Thanks, Steve