Hey team, I’ve been experiencing some weird behaviour where the application is completely reset after some time of inactivity. I get logged out and my settings, garage and gauges all reset to default.
I’ve tried testing with a day of inactivity and up to a week. A week will almost always reset, a day sometimes doesn’t. In both instances internet connection can be on or off.
This is experienced in both Android and (now) Linux.
For added context, my car is infrequently driven.
That is strange indeed. In DEATHFISH 2, we have Android and Linux installations, and it also sits sometimes for a long time. Never experienced anything like that though.
Don’t really know what could cause this. I will try to investigate though.
Thanks for that!
I also couldn’t find any crash logs or something to help explain it.
For added context, both devices are physically switched off, the android device is a phone so still retains power state via the battery (for RTC) but is physically off (not locked, off). The Linux device is a Raspberry Pi 4 with no RTC and is also powered off.
That could be the difference, as we use shutdown scripts to ‘gracefully’ close RealDash before pulling power from the devices.
If you just pull the power, it is possible that filesystem has ‘unflushed’ files, and if RealDash detects a partially saved/corrupted settings it will revert to default settings.
Ok makes sense, I’ll run through some tests by shutting down Realdash first, then shutting down the system properly.
Depending on the application and other circumstances, this might be a big problem.
For example:
While shutting down is the best way to handle the OS, a setup I’m building will run the system in the background and has some protections built in to shut down the OS and system after a period of time or if voltage on the car gets too low, to help prevent battery drain. Due to bootup time of most any OS, I am not shutting the system down everytime the car is turned off (who wants to let their car boot up? lol)
However, a situation that I could see happen is if a person drives their car to the store to replace the battery, and when the battery is removed from the car, the system will shut off, and under the situation you mentioned about revert to default settings seems to be a problem waiting to happen. In the application I am working towards, having a person shut down their dash before pulling a battery would be burdensome.
I have the same concerns, would it be a far stretch to propose the application has the ability to at least revert to a previous “known working state”? i.e having a rolling file system where you have files that are deemed “safe” and ones that are currently open and collecting data, the application can periodically update the “safe” files. In the event of an unsafe shutdown those unlocked files are discarded and the “safe” ones used instead.
OR if areas like settings (and possibly garage) don’t change unless a user invokes that change, so saving those separately to say running metrics could also avoid a lot of issues.
I was thinking of shutting down my Pi on HDMI disconnect, so the Pi would be hardwired to the battery and the display to ignition. The problem with this is the Pi has no ability to wake natively, so am now just working on a low power state instead of full shutdown.
Low power state and disabling HDMI has worked very well in our project. Car has been sitting for a long time with no noticeable battery drain.
Real vehicle ECUs have OS that guarantees that files are written into actual filesystem. Devices that we use typically have not, but instead use all sort of caching systems to make file operations faster. If you pull power from Android device you may lose files from surprisingly long period of time.
Any ‘rotate backup files’ system will not fix this. It may make the corruption of the files less frequent, but it will still happen eventually.
If we use these mobile devices and Linux SBC computers, you have to design it to shut down gracefully in order to make it 100% reliable.
Do you have a write up or guide for your low power state SBC?
I’ll be embarking down that path over the weekend 
I agree that they need to be designed to shut down, but like I mentioned above that the average user would look at this as more of an appliance and not a computer in their car if it’s designed as a instrument cluster replacement. Us as technical people will remember that we need to shutdown the computer before removing the battery, but average people would not.
While the rotate backup files would not fix the issue, depending on the frequency of the backups, it will minimize the impact, additionally most of the data would likely not change, such as the connection settings and information about the car. The odometer is one that I can see as being a major impact if that data is lost.
On RPI we use a simple python script that is run at system startup. DEATHFISH 2 uses 3 screens that share data with Multicasting. Thus, we can use this script to launch RealDash immediately when Multicasting address can be connected to (the screen with Multicasting host has started). Multicasting host will also send a shutdown command to all others in Multicasting network.
Script requires two parameters, ip address and port of the RD Multicasting host. It puts RPI CPU governor into power save mode and disables the HDMI output when RealDash is not running and just attempts to connect to Multicast host. If connection is successful, CPU is set to performance mode, HDMI is enabled and RealDash is launched.
Hope this is helpful, if you don’t use Multicasting, maybe you can rip out the interesting parts from this script.
import socket
from time import sleep
import subprocess
import psutil
import sys
HOST = sys.argv[1] #'172.17.0.1'
PORT = int(sys.argv[2]) #6558
def connect(host, port):
try:
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
ip = socket.gethostbyname(HOST)
s.connect((ip, PORT))
return s
except Exception as e:
print(e)
return None
def enable_hdmi(enable):
try:
if enable:
subprocess.call(["xset", "dpms", "force", "on"])
subprocess.call(["xset", "dpms", "0", "0", "0"])
else:
subprocess.call(["xset", "dpms", "force", "off"])
subprocess.call(["xset", "dpms", "0", "0", "60"])
except:
print('no xset')
def enable_powersave(enable):
try:
if enable:
subprocess.call(["sudo", "cpufreq-set", "-g", "powersave"])
else:
subprocess.call(["sudo", "cpufreq-set", "-g", "performance"])
except:
print('no cpufreq-set')
def is_running(processName):
for proc in psutil.process_iter():
#print(proc.name)
try:
if processName.lower() in proc.name().lower() and proc.status() != 'zombie':
return True
except (psutil.NoSuchProcess, psutil.AccessDenied, psutil.ZombieProcess):
pass
return False
try:
while True:
if not is_running('realdash'):
enable_hdmi(False)
enable_powersave(True)
s = connect(HOST, PORT)
if s != None:
print('Multicasting is online at', HOST, PORT)
s.shutdown(2)
s.close()
enable_powersave(False)
enable_hdmi(True)
print('Launching RealDash')
subprocess.Popen(['realdash'])
sleep(30)
else:
print('Multicasting is offline at', HOST, PORT)
sleep(1.0)
else:
sleep(1.0)
except:
print("out")
enable_hdmi(True)
Thanks for that, would you mind also posting any Pi settings that can help? Mine is currently drawing about 250mA, adjusting cpu governor doesn’t really do much to the draw.
I can’t see that lasting more than a few days at best 
I have not measured the actual draw, but for me car can sit for a week and starts without an issue. I do have a big battery though.
maybe i get same problem
GolfCar
android 10 RockChip 3399
is start from 100% power off (not sleep mode) some time fall ( reset ) all settings in garage and load default skin
Jani i hope you found this problem
I believe this is OS level problem and there is nothing I can do to fix this.