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”).

Seems reasonable, and easy to implement.

So long as there is some mechanism to keep the MQTT connection alive, there is no requirement to send data periodically. We do that purely to (a) keep the connection alive, (b) provide historical data for storage at the server, and (c) provide the App with a view of the last known state of the car (even if the car is disconnected).

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.

While going without a server seems like a good idea (in the early days of OVMS that is what we tried), it has a fatal flaw; on the vast majority of cellular networks (if not all), you don’t get a public IP and certainly don’t get one that is Internet routable inbound. There is no way for the App to connect to the cellular module.

For example, this is what I get:

OVMS# network
Interface#2: pp2 (ifup=1 linkup=1)
  IPv4: 10.52.40.80/255.255.255.255 gateway 10.64.64.64

A RFC1918 private IP address.

There are a bunch of ‘tricks’ around this, involving a broker in the cloud, UDP protocol, and relying on connection tracking idiosyncrasies. That would work for a custom protocol, but not for something like MQTT.

Regards, Mark.

On 30 Aug 2018, at 5:57 PM, Robin O'Leary <ovmsdev@caederus.org> wrote:

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?
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev