[Ovmsdev] General trip & grid log proposal

[Steve Davies]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210115/ebef4005/attachment-0001.htm>