12V battery graph | Open Vehicles

5 posts / 0 new

21 October, 2025 - 10:21

Alenux

12V battery graph

I'm running the V2 server (API v3) on a VM and I noticed that I no longer have access to the 12V battery history that used to be shown when I used the official public server. Is there an existing way to add this functionality to the self-hosted server or is it something that needs development (or just isn't possible)?

23 October, 2025 - 04:21

markwj

Which public server were you

Which public server were you using? The api.openvehicles.com server just uses the standard v3 server code. Are you sure you have setup the database correctly? Historical data should be stored in the OVMS historical data table.

25 November, 2025 - 09:05

Alenux

Sorry, I didn't see the

Sorry, I didn't see the notification for your reply, but I've started looking at this again. I was definitely using api.openvehicles.com previously. I do have the ovms_historicalmessages table and it has about 5500 rows.

I'm writing this quite late at night so I hope this is coherent; I was hoping to get this down before I forgot about it.

-Alex

25 November, 2025 - 18:19

Alenux

Additional info

A couple updates now that I'm a bit more caffeinated. With DESCRIBE ovms_historicalmessages;, I get the following columns:

+----------------+--------------+------+-----+---------------------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------------+--------------+------+-----+---------------------+-------+
| owner | int unsigned | NO | PRI | 0 | |
| vehicleid | varchar(32) | NO | PRI | | |
| h_timestamp | datetime | NO | PRI | 0000-00-00 00:00:00 | |
| h_recordtype | varchar(32) | NO | PRI | | |
| h_recordnumber | int | NO | PRI | 0 | |
| h_data | text | NO | | NULL | |
| h_expires | datetime | NO | MUL | 0000-00-00 00:00:00 | |
+----------------+--------------+------+-----+---------------------+-------+
7 rows in set (0.00 sec)

And these are the message types that I see in the table with SELECT DISTINCT h_recordtype FROM ovms_historicalmessages ORDER BY h_recordtype;:

+--------------------+
| h_recordtype |
+--------------------+
| *-LOG-Grid |
| *-Log-Notification |
| *-LOG-Trip |
| *-OVM-DebugCrash |
| *-OVM-ServerLogs |
| *-OVM-Utilisation |
| D |
| F |
| L |
| S |
| W |
| Y |
+--------------------+
12 rows in set (0.00 sec)

And here's a sample of a D message with sensitive info redacted:

| 1 | [vehicle_id] | 2025-11-25 03:45:49 | D | 0 | 0,8,4,10,18.8889,12,75,1107617,0,680,5,0,0,0,12.28,0,12.31,0,0,0,15.5556 | 2025-11-26 03:45:49 |

So I think the data is stored properly, but maybe it isn't being grabbed properly by the app?

I have app version 5.2.3 (2025082192) and I'm running FW version 3.3.005-3-g4f3f7688/ota_1_main (build idf v3.3.4-851-gfa4f07fb3b Sep 7 2025 08:02:51)

-Alex

25 November, 2025 - 20:26

Alenux

Issue resolved

I think I've resolved the issue! Whenever I clicked the refresh button on the 12V graph within the app, I'd see the following on the server side:

2025-11-25 12:03:55.410593 -0800 info OVMS::Server::ApiV2: #11 A [Owner]/[Vehicle_ID] rx msg C 32,D DBD::mysql::st execute failed: Incorrect DATETIME value: '0000-00-00' at plugins/system/OVMS/Server/DbDBI.pm line 315. DBD::mysql::st fetchrow_hashref failed: fetch() without execute() at plugins/system/OVMS/Server/DbDBI.pm line 318. 2025-11-25 12:03:55.414911 -0800 info OVMS::Server::ApiV2: #11 A [Owner]/[Vehicle_ID] tx msg c 32,1,No historical data available

Then inside DbDBI.pm I changed line $since='0000-00-00' if (!defined $since); inside functions DbGetHistoricalRecords and DbGetHistoricalSummary to:

if (!defined $since || $since eq '0000-00-00' || $since eq '0000-00-00 00:00:00') {
$since = '1970-01-01 00:00:00';

and my 12V graph now populates properly within the app after a server reboot. So it looks like a date formatting issue? Does that make sense?

-Alex