[Ovmsdev] MQTT and Ovms Server v3

Robin O'Leary ovmsdev at caederus.org
Thu Aug 30 17:57:49 HKT 2018

I've been using the "MQTT Dash" Android app in preference to the old v2
app for the past month, and it's been great.  But one thing I have run in
to is that data usage to the v3 server has shot up compared with v2---so
much so, that I exceeded the free quota from Hologram (which had been
plenty when only using v2).

I know I can increase the config value "server.v3.updatetime.idle", which
made me wonder what I lose by setting it really high: if no client is
connected, is there much point in sending updates at all?  I suppose it
makes sense if the server is logging it, but is that the case?  I found
old documentation for getting historical data from the v2 server, but
no mention of v3.

Maybe a more useful config setting would be a way to limit the update
rate depending on the "cost" of the network connection.  The simple case
would just distinguish wifi or modem; there might also be justification to
treat particular SSIDs or GSM providers differently (e.g. treat mobile wifi
hotspot as "expensive", or a GSM provider with unlimited data as "cheap").

I then started musing about adding some way to be more selective about
which metrics are sent to the server in these cases, which made me
realise that the real problem is that the server (or "MQTT broker")
is in the wrong place: it should be on the module itself.  This would
be especially useful for local clients, e.g. phone running MQTT app
connected to OVMS in "Access point" mode.  Remote clients would have
the additional problem of discovering the broker's address, but maybe
that could be solved some other way, e.g. DDNS, sshtunnel, VPN.  One down
side would be that multiple remote clients interested in the same metrics
would cause them to be sent multiple times, but maybe that is acceptable
for the gain in simplicity.

It looks like mongoose can run as a broker (MG_ENABLE_MQTT_BROKER).
That's obviously a big change in architecture, which no doubt has
implications I haven't though of, but might that be a viable option?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180830/843318c9/attachment.sig>

More information about the OvmsDev mailing list