January 2021 - OvmsDev - Open Vehicles

Getting data off the OVMS unit and archived
by Steve Davies 12 Jan '21

12 Jan '21

Hi, What do people do to retain data from OVMS for later review and analysis? Are there any projects around for longer term analysis? I see the ovms_historicalmessages table and I assume I can find docs on those record types and what all the fields are. But I have Influxdb and Homeassistant / openenergymonitor / NodeRed so my inclination would be to push all the data in there since InfluxDB can do nice time analysis of data. It looks like data is only sent to the server once per minute - so I'm not going to be getting things like motor power, speed, throttle position at a high resolution? On the mqtt side is it sent at the same rate? Is there any existing method to collect high resolution samples but send in a chunk each minute, or dump once back in wifi range? Thanks, Steve

2 2

GMAIL is unhappy about receiving an inbound mail from the list with my email as from
by Steve Davies 11 Jan '21

11 Jan '21

Hi, In case anyone is interested, my problem with sending to the list from gmail is actually like so: - I send to the list - it's actually delivered to the mail expander fine. - Expander sends the mail back to me (and presumably to everyone else) - Gmail decides this incoming mail is suspicious. That's fair since it has a gmail message id and comes from my own email address. - GMail quarantines the inbound message - But Gmail quarantine admin page shows this quarantined mail as "Outbound". That is wrong, it's actually inbound. Cue lots of confusion. Seems to fix I need to whitelist the mailman 175.45.17.210 address in my gmail advanced setup. Holding thumbs. Steve

1 0

Please excuse this second and hopefully last test
by Steve Davies 11 Jan '21

11 Jan '21

Trying to resolve my "quarantine" problems with Google Workspace support.

1 0

Please excuse this test message
by Steve Davies 11 Jan '21

11 Jan '21

Test for gmail support.

1 0

Queue overflows
by Steve Davies 11 Jan '21

11 Jan '21

Hi, I generally debug by watching the shell via the web interface with logging from my vehicle module at debug or verbose. I seem to be hitting throughput limitations for the websocket pushing the output to my client, though, and see many of these: log.20210110-144200:2021-01-10 14:17:39 SAST W (1630612) websocket: WebSocketHandler[0x3f8531a4]: job queue overflow resolved, 133 drops This especially happened when I went to a charger for a test and was connected to the OVMS system on 192.168.4.1 on the local Wifi AP that the OVMS creates. Is this to be expected? Is it more efficient to "log monitor" via ssh, or do I really need a serial connection over USB? I do see that the websocket overflows seem to occur when any client is connected whether you are looking at the shell or not. In my case I'm logging quite a lot and I guess I exceed the 100 deep queue. I see that I can make the queue bigger for the websocket - would it be a big problem to increase the 100 to 200 by default? Thanks, Steve

3 3

CAN drivers: fix & harmonize frame transmission failure handling
by Michael Balzer 10 Jan '21

10 Jan '21

Everyone, please pull & test the new "can-txfail-fix" branch. It's up to date and includes the BMW i3 code already. I need to get feedback from users of both can1 (esp32can) & can2/3/4 (mcp2515), as changes had to be made to both drivers. I'll quote from my commit: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/c94… Design goals: - any TX can either fail or succeed, the result state is terminal - the respective TX callback is called exactly once - transmissions fail on reaching the error-passive bus state and on message/bus errors while in error-passive state - a failed TX will be aborted (no retries after bus recovery), i.e. will be retried at most 128 times (in error-active phase) - reduce excessive CAN error logging - reduce excessive interrupt load with switched-off buses This results in the application being able to reliably detect a switched-off vehicle bus by the TX callback's success indicator. It also results in frames no longer being held in the TX buffer or added to the TX queue when the bus is switched off. The application can now rely on getting a clean bus state on every reconnect, without any queued old frames to be sent automatically. Secondary benefit from aborting the transmission is, the module doesn't need to handle the load from the continuously triggered CAN error interrupts by retransmission attempts in error-passive state. Reason for this was a) Steve's question on aborting transmissions / flushing the queue and b) my new car now also switching off the bus, with the annoying effect of a frozen can1 every 2-3 days, needing to reboot the module. I'm not sure yet if the freeze issue is solved, but I haven't had it since running these changes on my module. The other issue of the transceivers resending frames queued long ago may have caused all sorts of strange & unrepeatable issues. I remember the VW crew having problems that fell into this category. I've verified the new MCP2515 implementation only on my workbench (with an Arduino as the CAN tester), so real life tests are necessary. Thanks, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

5 11

PR #516 followup, and looking for ideas as to h
by Steve Davies 09 Jan '21

09 Jan '21

Hi Michael, In respect to PR #516 and the pack voltage: Thanks for clarifying about the staleness and on your explanation I agree my PR is wrong. I went through my logs and I can't find a case where we read 0v from the car. (I will put a little sanity check in the code though in case we do read something unreasonable). But: my OVMS reboots sometimes. I didn't really look into the details. But I notice that the SOC is persistent, but the pack voltage is not. Is it a credible guess that this is actually what is happening? That the OVMS rebooted, and since the car is asleep we can't get a new value and are left with no value. Would also explain why my change seemed to fix the problem - since seeing the issue depended on whether there was a reboot or not. Thanks, Steve

2 1

PubSub error
by Derek Caudwell 09 Jan '21

09 Jan '21

Hi all, Does anyone else periodically receive the following error message? E (3886120) script: [int/PubSub.js:1] TypeError: not object coercible ……: at [anon] (duk_api_stack.c:3661) internal ……: at hasKeys (int/PubSub.js:1) strict ……: at messageHasSubscribers (int/PubSub.js:1) strict ……: at publish (int/PubSub.js:1) strict ……: at [anon] (int/PubSub.js:1) strict preventsyield

2 1

Re: [Ovmsdev] CAN drivers: fix & harmonize frame transmission failure handling
by Derek Caudwell 09 Jan '21

09 Jan '21

Hi Steve, You can also use the Poll State feature to manage different poll requests, ie automatically turning off requests when the bus is not alive then when the bus comes alive changing state to request the PIDs at a set frequency. Take a look at the Nissan Leaf code by way of example, other cars use this approach also. Regards Derek

2 1

Metrics: Cabin Fan
by jaunius＠gmx.com 06 Jan '21

06 Jan '21

Hi, I would like to bring back this topic. Back in 2019 we discussed on how the standard metrics for climate and cabin should look like. I remember we initially discussed of adding cabinfan as number of steps, but latter decided to go with percentage. However as it is still better for the user to show the same scale as in car, we need to relay the number of steps available. I added this metric a while to Nissan Leaf. And it works great for me. So would suggest to add it to the standard metrics as well like this. v.e.cabinfansteps [integer] Number of cabin fan speed steps. Kind Regards, Jaunius Sent using the GMX mail app

2 2