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?