I've been assuming that any time a Standard Metric gets "set", the OVMS sets in motion an update of that metric sending the data to the server promptly.
Similarly, I've assumed that any time I "check" (e.g. in an if(metricname.asbool()) statement, this may trigger a download data check (and delay) from the server.
None of this is clear from any documentation I've read.
Based on my assumptions, and seeing that THINKCity vehicle updates most of its metrics at the CAN message level (i.e. about every 200ms), I'm guessing I could save up to 80% of the data traffic by moving these to the one second ticker. Similarly, I assume I should not be comparing the state of an actual metric in these 200ms updates.
I did make some changes along these lines and I "think" that the data load has reduced quite a lot---but I don't want to commit changes without some corroboration about all of this.
Any thoughts and guidance on this?
Thanks much!
-Myles Twete, Portland
Depends on whether you are talking about v2 or v3 servers.
For v3, the MQTT channel pretty much mimics the real live data.
For v2, without an App connected, metrics are sent every 10 minutes. With an App connected they are sent every 1 minute. They are also sent every time an App connects.
Thanks Mark.
Yes, I am using v2 server.
I think I need more clarification here in terms of an answer.
I do see the once-per-minute updating when I look at 12v Battery History data --- clearly 5 discrete data points for each 5 minute period.
But AFAIK, that may simply mean that the server "sends" updates to the App at a 1x per minute rate, while perhaps getting 12v data sent from the box to the server much more often.
Q1: If a particular Standard Metric gets updated "in the CAN message handler firmware" every 200ms, does the firmware send this metric to the server every 200ms, 1sec, 10sec or 60sec?
Q2: If a Standard Metric is checked (e.g. say in Ticker1) does this download data from the server each time or is the metric value grabbed locally?
I'm not a real software expert, so consider that---have done some embedded design over the years, but it was never that complicated.
My main interest is to reduce SIM data costs. I have had SIM sessions (7hours) that have recorded as much as 1.5-2Mbytes! These tended to be charging sessions with Standard Metrics being updated every 200ms and 1sec for a handful of them. My thought then was that I'd save SIM data costs by saving local copies of the raw or calculated values for these metrics, then to save to the Standard Metric at Ticker1 or Ticker10.
Recommendations welcome.
-Myles
That is historical data, not a standard metric, so operates differently (and at whatever rate the historical data is stored at).
The data goes module -> server at the rates I indicated. It also goes server -> app if one or more apps are connected.
Every 1 minute or 10 minutes, depending on whether one or more apps are connected.
The module never downloads data from the server.
The vehicle support code in the module reads data off the can bus (either passive or via polling) and stores that in the metrics in the module.
Independently, the module v2 protocol code sends snapshots of metrics to the server every 1 minute (if an app is connected) or 10 minutes (otherwise).
There are two exceptions to this, that I am aware of:
I don't see how that is possible in the standard code. Unless an App is connected and you are streaming data. Or this is v3 protocol.
The v2 protocol is designed to be very bandwidth conservative - typically 60kb or so per day for normal use cases without extensive app usage.
Perhaps simplest it to turn on logging for the v2 protocol in the module.
log level info ovms-server-v2
Thanks again Mark. It wasn't clear to me that data rate was dependent on whether or not the APP was open. But this explains a lot. As example, overnight, while my car has just been sitting there in the yard, hologram has racked up more than 200kbytes of data charges---the car is asleep, so the only data being updated is the 12vDC and I presume the car's location...every second, overnight, updating these... So I think folks need to understand that they need to turn the App OFF when they don't need to see location updates or get 12v battery updates---once every 10 minutes is fine for the 12v battery history. I certainly didn't realize this. The biggest historic session data usages I have seen were (1) during automatic updates (which I've now disabled) and (2) during charge sessions and especially after the software fails to recognize charge session has ended. So it's that last one that I still would like to get a handle on. Of course I can shut the App OFF and/or pull the power on the OVMS, but I'd rather be able to keep the App open and be able to remotely monitor my charging. But I don't need to know the location, so I'd like to disable those 1sec updates. And I only need charging data updates like once very minute or even less. I've been assuming that only changed metrics get sent to the server at intervals, so that if I only send ones that changed I save on SIM data. So in the charging state machine in ThinkCity vehicle module, I figured that it makes no sense then to update the voltage and power metrics more than every 10 seconds, current at 1 second and energy, SOC, etc at 60sec or so. Currently these pretty much all get updated every 200ms. Would this indeed reduce my data usage?