[Ovmsdev] MQTT and Ovms Server v3

[Mark Webb-Johnson]

> 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 at 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 at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180831/afcba775/attachment.htm>