<div dir="ltr"><div dir="ltr">Hi Mark,<div><br></div><div>Thanks, your info is helpful.</div><div><br></div><div>In my previous email:</div><div><br></div><div><div> > Looking at the code I'm also trying to understand what exactly a "client" is. Here's how it looks to me: </div><div> > a client sends a message with topic <prefix>/client/<clientid>/ active with the payload being non-0 to "connect"</div><div> > and 0 or empty to disconnect. Must send that at least once every 120 seconds to stay connected.</div><div><br></div><div> > 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).<br></div></div></div><div><br></div><div>So in case it helps anyone else - I tested this and it works like I wrote it up - </div><div><br></div><div>When I send the "active" message (<font face="monospace">mosquitto_pub -h ... -p ... -u ... -P ... -t 'ovms/vehicleid/client/test/active' -m '1'</font>) I see this logged:</div><div><br></div><div><font face="monospace"> I (55489522) ovms-server-v3: Incoming message ovms/vehicleid/client/test/active: 1<br> I (55489522) ovms-server-v3: MQTT client test has connected<br> I (55489532) ovms-server-v3: Tx metric ovms/vehicleid/metric/s/v3/peers=1<br> I (55489532) ovms-server-v3: One or more peers have connected<br> I (55489542) ovms-server-v3: Tx event app.connected<br></font></div><div><br></div><div>And at this point I see the metrics published every 10 seconds as I had set the updatetime.connected to 10:</div><div><br></div><div><font face="monospace"> # config set server.v3 updatetime.connected 10</font></div><div><font face="monospace"> # config set server.v3 updatetime.idle 300</font></div><div><font face="monospace"> # config set vehicle stream 0</font></div><div><br></div><div>When I mark the client as in-active then the update time goes back to every 5 minutes.</div><div><br></div><div>This seems more manageable than the continuous streaming, a sensible compromise.</div><div><br></div><div>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.</div><div class="gmail_quote"><div><br></div><div>You say:</div><div><br></div><div> > 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.</div><div><br></div><div>So the blunt question is whether this MQTT / V3 approach is dying on the vine or if it is worth investing time into. </div><div><br></div><div>Looks like Mark wrote most of it 3 years ago.</div><div><br></div><div>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.</div><div><br></div><div>But OVMS is already invested in the V2 protocol and you are still developing it.</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>What are your thoughts?</div><div><br></div><div>Thanks,</div><div>Steve</div><div><br></div><div><br></div></div></div>