<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Steve,<br>
<br>
forgot to mention: the V3 server already supports "data"
notifications. These are published under the topic scheme
"<prefix>/notify/data/<subtype>/<id>/<timestamp>".<br>
<br>
So you can already send compact custom records. V2 "history" records
are sent that way, see <font face="monospace">OvmsVehicleRenaultTwizy::SendTripLog()</font>
for an example.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.01.21 um 13:55 schrieb Michael
Balzer:<br>
</div>
<blockquote type="cite"
cite="mid:0e8b32cd-d4f5-263a-b391-21e173acddf5@expeedo.de">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Steve,<br>
<br>
<div class="moz-cite-prefix">Am 15.01.21 um 10:04 schrieb Steve
Davies:<br>
</div>
<blockquote type="cite"
cite="mid:CABFTEGU6q3H2=PsPTiyreoWUyuixxPge=aD3BDipxfe2StkZCg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div dir="ltr">This seems more manageable than the continuous
streaming, a sensible compromise.</div>
</blockquote>
<br>
As I said, the streaming mode wasn't meant to stream all metrics.
The V3 server lacks a means to control metrics update rates. Feel
free to add one, also take into account what has been discussed on
this before, i.e.
<a class="moz-txt-link-freetext"
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/344"
moz-do-not-send="true">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/344</a><br>
<br>
<blockquote type="cite"
cite="mid:CABFTEGU6q3H2=PsPTiyreoWUyuixxPge=aD3BDipxfe2StkZCg@mail.gmail.com">
<div dir="ltr">
<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>
</blockquote>
<br>
It's not a competition, it's supporting two different approaches.
We even support a third approach in form of our WebSocket
protocol, which can be used for direct local connections to the
module.<br>
<br>
V2 / MP is a custom protocol and more of a legacy support. But it
has undeniable advantages over the current MQTT implementation.<br>
<br>
<blockquote type="cite"
cite="mid:CABFTEGU6q3H2=PsPTiyreoWUyuixxPge=aD3BDipxfe2StkZCg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
</div>
</blockquote>
<br>
I think you're describing a valid approach to reduce the MQTT
overhead, basically something like sending the V2 MP records over
MQTT instead of single metrics.<br>
<br>
I just don't know if that's what people expect from MQTT. It
removes all the simplicity from receiving metric values via MQTT.
Will standard MQTT clients & tools be able to parse such
records? And even if they do, it would still introduce a hurdle
for users trying to get into telemetry processing. Part of the
appeal of MQTT is being able to use a broad selection of generic
standard clients.<br>
<br>
<blockquote type="cite"
cite="mid:CABFTEGU6q3H2=PsPTiyreoWUyuixxPge=aD3BDipxfe2StkZCg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
</div>
</blockquote>
<br>
That would introduce the need for a second server / gateway
instance just to attach to MP via MQTT. Possible, but then, MP
isn't that hard to connect directly to. There are many example
clients. The gateway would still have a benefit if MQTT clients
can parse MP records though.<br>
<br>
How about eliminating the need for that gateway by adding optional
standard & configurable custom topic record structures to the
V3 server? In the most simple form, a record structure is simply a
list of metric names to join under a definable topic. A little bit
of number formatting would be useful, e.g. using printf style
format strings.<br>
<br>
Example: the MP "L" record structure could be described by some
string like this:<br>
<br>
<font face="monospace">{v.p.latitude},{v.p.longitude},{v.p.direction},{v.p.altitude},{v.p.gpslock},{v.p.speed},{v.p.trip},{v.e.drivemode%x},{v.b.power%.3f},{v.b.energy.used%.3f},…</font><br>
<br>
JSON format could be supported by some keyword to request JSON
value encoding. You could even introduce a way to get the value
from a Javascript function, like Greg does for the obd2ecu system.<br>
<br>
Combine that with a decent metric filter & update rate
configuration (see issue link above – btw, we already have topic
pattern support from Mongoose…), and you get the best of both
approaches, without any added transport complexity or points of
failure.<br>
<br>
Standard users will be able to subscribe to single metric values,
and power users will be able to easily create custom records.<br>
<br>
Just my 2 cents as a yet-to-become MQTT user.<br>
<br>
<blockquote type="cite"
cite="mid:CABFTEGU6q3H2=PsPTiyreoWUyuixxPge=aD3BDipxfe2StkZCg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>Thanks,</div>
<div>Steve</div>
</div>
</div>
</blockquote>
<br>
Regards,<br>
Michael<br>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26</pre>
</body>
</html>