I have a Hyundai IONIQ electric (2018 model) and don't drive it every day thanks to home office.
Therefore, I wanted to reduce standby power consumption and configured the power management of the OVMS to shutdown the module when voltage drops below 13.3V (which will be the case a short time after parking the car) within 5 minutes.
While the shutdown seems to work in general, there is a wake up triggered exactly every 132 seconds ruining the intended power savings (as the module stays powered down for those 132 secs only and then is awake for another nearly 354 secs before the next shutdown is triggered).
Unfortunately, I can't see which triggers the wake up despite setting log level to verbose. I have a gut feeling that the OVMS v3 server is the culprit as I did enable it two weeks ago and did see the module asleep for days without any wake ups before that.
Find attached some screenshots of my current settings as well as an excerpt of the log file showing the unintended wake ups (simply search for shutdown and you will spot the cycles quickly).
I hope that somebody can give me a hint about how to solve this issue.
Best regards,
FNW
I don't think this feature of the power management module was ever meant to shutdown the system with a normal voltage level, or ever finished to work properly with regards to the 12V alert as described.
The system has no wakeup capability on events like CAN bus or network activity (yet), and it cannot read the 12V alert configuration on wakeup. You can currently only do deep sleeps for certain time periods, with some margin of error the longer the period gets. The default sleep period is 60 seconds, which is what the power management module uses. If the 12V level looks usable on wakeup, the module will do a normal boot.
Being able to tell the module to not do a full boot until a certain (calibrated) voltage level is available could be a nice feature. There was some developer trying to implement that, but it seems he didn't succeed or didn't share his results.
For now, to minimize power usage, consider switching off Wifi AP mode and GPS, or possibly the whole modem, while parking. You can automate that easily by a script, as suggested in the manual. You can also use a script to schedule long deep sleep periods for the times you know you won't need the module.
Be aware you cannot totally switch off the module, even in deep sleep it will consume some power. See manual on details.
Regards,
Michael
I perfectly understand that my (ab)use of the power management feature might not work 100% perfect.
But what makes me frown (and curious) is the fact that a have seen the module nicely asleep for several days before I activated the v3 web server (MQTT) and that the wake up always occurs exactly 132 seconds after the shutdown, now.
The logs show a clear pattern so there must be something going on "behind the scenes" that triggers that reboot / wakeup. Unfortunately, I am already at the lowest log level (verbose) which still does not seem to log the wakeup-related event(s). Only the status screen mentions a generic "wakeup" but without any further details which would likely be very useful to find the culprit.
But you mention that I could use scripting to shut down everything. I guess I could do that, but how do I wake the module up again if I have sent it to sleep and therefore it doesn't react to any external event anymore? It seems like the only option would be to use a "wakeup" cycle (e.g. every minute), check the battery voltage and send it to sleep again if it is below the then script-defined threshold.
But as this seems to be exactly what the power management-triggered shutdown is doing, I still wonder why this doesn't work as expected and keeps waking up the module with all "external components" (WiFi, GPS, LTE modem) at certain intervals for no apparent reason.
I just disabled the v3 server again and we will see if the repeating wakeup cycles disappear again (as this was the only significant change I remember before it stopped working with longer continous shutdown times).
If you only check the logs written to SD card or to the web UI, you won't be able to see the early boot logging and final shutdown log entries, these can only be seen via USB. There is no wakeup related to network events, a deep sleep shutdown terminates all open network connections.
Anyway, regarding getting the feature working as it should, I've just checked in my implementation of a 12V auto shutdown/reboot feature. This works independent of the power management module. I've also fixed the PM module to use the alert level when triggering a reboot, but for your use case, you shouldn't use that.
Use the new 12V shutdown/wakeup configuration instead, I've placed that in the Config→Vehicle→12V page. That way you don't need the 12V alert to trigger the shutdown indirectly. I've also added a configuration for the reboot test interval, for your case I'd recommend trying something like 15 seconds.
Firmware build is edge / 3.3.003-539-gfbb768bd, currently available on my server, will be on Mark's within 24 hours.
You're welcome to test this.
If you encounter issues with this, I'll need the early boot log (USB) for debugging.
Regards,
Michael
Hi Michael,
first my apologies for not getting back to you earlier. I had a private "emergency" and therefore have been unable to continue working on the integration of the OVMS in my smart home solution.
And then a BIG THANK YOU for directly integrating my definitely pretty special request into the firmware and providing me with a new version! That really came completely unexpected and is an amazing "service" and far more than I expected - hats off!
I installed it and can clearly say that it works like a charm: There are no unexpected wake-ups anymore and the current draw is down to those 18mA mentioned in the technical data part of the documentation. Combined with about 15mA of standby power drawn by the car itself, this means less then 1 Ah from the 12 V auxiliary battery is required per day - I can perfectly live with that. :)
Nevertheless, there might be a small catch regarding the new shutdown voltage limit: As there is no delay when the shutdown voltage has been reached (which the power management option does provide) it can happen that a certain event causing a high power draw for just a second leads to a shutdown. It did not happen to me, yet, but I know that for examole the automatic doors consume about 25A for a fraction of a second when opening or closing the electric locks which might result in a voltage drop lower than these 13,3V that I defined as shutdown voltage (to avoid keeping the module on unnecessary long while the car is parked).
So maybe you could add an optional delay (in minutes or "check cycles") for which the shutdown voltage must be undercut to actually trigger the shutdown. If you would use "check cycles" instead of a specific time interval as unit here, I guess it wouldn't be overly hard to implement: For each voltage check cycle (which length is defined by the corresponding parameter) where the voltage is found below the threshold, the delay cycle counter gets reduced by one and if it reaches zero the module is shut down. If the voltage rises above the threshold once during a check, the delay cycle counter is reset to its initial (user-entered) value. With this simple delay routine in place no accidental shutdowns will occur by short high current demands when the general voltage of the battery is still higher than the threshold.
If you can make this work - or tell me how to trigger the new "controlled shutdown" with cyclic voltage checks via scripting myself (as a "simple" scripted shutdown does not cover the automatic reboot if the 12V battery gets charged), I will definitely buy a second OVMS unit for my Nissan Leaf and also donate 100 € to support this amazing project!
Trying to prevent waste of energy is something that most smart device developers don't see as a priority and I never met anybody who immediately patched the firmware for that after just a simple question. Considering my efforts to protect the environment, I highly appreciate your efforts to manage the balancing act of a convenient high-tech solution on the one hand but keeping the environmental footprint of it as low as reasonably possible.
Thanks a lot for your help again and keep up the good work!
Best regards,
Andreas (FNW)
Related issue I raised with the Ref Voltage logic here:
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/931
One of the suggestions was to incorporate a delay before triggering the sleep.
Andreas, you're welcome.
The 12V level is smoothed over 5 seconds/measurements, so a short peak won't trigger anything. But for the use case of following a vehicle operational state, a delay makes sense, as you often only switch off the car for a short period, e.g. when parking at a charging station.
So I've just added a shutdown delay configuration and set that to a default of 2 minutes. Firmware update is on my server, will be on Mark's in 24 hours.
I've also added a notification for the shutdown, as most users will like to know about that to happen. If you don't want that notification, do…
Regarding donating: if you want to thank me specifically, see here: https://dexters-web.de/spenden
@RowdyDoc: I think that's only losely related, I'll add a note on the issue.
Regards,
Michael
Hi Michael,
I updated my OVMS device with the most recent firmware and set the new parameters to my preferred values - and it works like a charm with no depletion after several days of keeping the car parked!
When I start the vehicle, the device is up and running again within less than a minute which it fast enough for me. So all I need to do is write the "GPS logging" script (which I have mentioned in another thread here) to be able to save all the roads I've been on - especially during a vacation. :)
As announced, I have donated 100 € for your outstanding support and will buy another OVMS as soon as the GPS script is ready (so I can track that car as well).
Just one last question (completely different topic) as I am rather stuck with that: I am working on a Windows (10 Pro) machine here and was unable to establish a SCP connection to modify some files on the SD card (or the internal memory as well). I did use WinSCP for that purpose and tried lots of different settings without success. These are the most "backward compatible" ones I guess:
I can also provide a verbose debug log which clearly shows that the client was able to establish a SCP connection but seems to be unable to receive a correct directory listing:
Maybe it's a simple thing to resolve - but maybe it's just impossible to use a Windows-based client to connect to the system (which is OK for me as this would just make things a bit more convenient than having to deal with a console each time I just want to e.g. delete some old log files from the SD card).
Best regards,
Andreas
Andreas,
I don't know WinSCP. You could try replacing the "listing command" by the OVMS command "vfs ls /sd", possibly combined with some other shell type available, but WinSCP will probably not be able to parse the output and offer a file list from that, as the "vfs ls" output is OVMS specific.
If so I'd recommend using a standard scp command.
Regards,
Michael