p-f-g
Member
Will do the same. And it says:
During that time span it sure was over utilized with all the installation processes!
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
hingus2000
Member
Questions are fine, I know some of my descriptions might be shorthand.
So based on what you've said, find an existing charge you have for the location you want in the Charges dashboard, then click through to the relevant Charge Details dashboard for that charge.
In the URL shown in the browser you’ll then see the ID for the charging process shown at the end of the URL, ‘4’ in the example below. Make a note of your relevant charging_process_id.
http://127.0.0.1:3000/d/BHhxFeZRz/charge-details?orgId=1&from=1591759802000&to=1591761621000&var-car_id=1&var-charging_process_id=4
Go to your database, and then execute the command below, replacing ‘4’ with the charging_process_id you noted above.
Code:SELECT position_id FROM public.charging_processes WHERE id = 4;
This will return something like this:
Code:position_id ------------- 37 (1 row)
You can then use this position_id value, ’37’ in my example as the position_id in the INSERT statement I gave you.
Note that this is a slight short-cut, doing this will just associate your new charge with a position record which already exists for the same physical location but at a different point in time. Otherwise we’d have to find the position record that existed for where you car was at the date/time you charged BUT I guess that doesn’t exist as otherwise you wouldn’t need to add the charge manually in the first place
The position_id only really seems to be used on the Charge Details dashboard, as it used to show the charging location on the local area map panel. For your faked charge session you won’t have the detailed charging data for the Charge Details to be viewable anyway for the faked session.
I think if you set position_id to the value you look up and also set the geofence_id (think you said you can find that already?) to match your supercharger location then you’ll get something sensible regarding the location summaries on the Charging Stats dashboard.
A revised example of the INSERT statement I gave you originally but with the geofence_id added will look like this:
Code:INSERT INTO public.charging_processes( id, start_date, end_date, charge_energy_added, duration_min, car_id, position_id, geofence_id, cost ) VALUES( nextval('public.charging_processes_id_seq'), TIMESTAMP '2020-06-29 22:00:00', TIMESTAMP '2020-06-29 22:30:00', 2.75, 30, 1, 37, 1, 0.12 );
This all worked flawlessly, thanks so much!
The only thing I can't work out is whether it has thrown some of the efficiency/total Kwh used stats off. Not because they necessarily look off, but just because I can't remember what they were before.
I'm hoping not, given the limited effect of the database change? I would guess the efficiency and usage stats are based on actual usaged measured by Teslamate, as opposed to a crude calculation using the total charging stats?
No change in display (still greyed out)
Checked used swap, was just under 18mb yesterday, today:
NAME TYPE SIZE USED PRIO
/swapfile file 1024M 65.6M -1
So it's definitely doing something, hopefully it takes some of the pressure off the box.
I've updated my instructions to include the step to create the swap file, you can do this retrospectively too, I'd recommend doing a backup before hand though, just in case!
I got the Google Cloud warning today as well after adding the Cron script to autobackup to GoogleDrive (h/t to TeslaEV.co.uk for the excellent write up!)
I believe the memory exhaustion is incidental to the extra resources requested when adjusting my TeslaMate setup. Once it is peddling along with just running TeslaMate I expect the average memory usage will come down and this free f1-micro instance is more than adequate.
My TeslaMate running for free in GoogleCloud is fully functional for now. Checking adriankumpf/teslamate for the next version release
Glad my guides are working for you, the Google Cloud one seems to be popular
I too think the resource is fine, the way the text read is that at some point it as has reached it's threshold, but based on the memory it used on my Pi, having thought about it a little more) I think it was more or less using 400 mb memory.
Glad my guides are working for you, the Google Cloud one seems to be popular
I too think the resource is fine, the way the text read is that at some point it as has reached it's threshold, but based on the memory it used on my Pi, having thought about it a little more) I think it was more or less using 400 mb memory.
Your guides just work. Much appreciated.
Do you think that next to the tmbackup Cron script it is necessary to also schedule Google Snapshots as a backup for the entire Google Cloud Instance?
Good to hear
I've personally not gone down that route, it's so easy to restore the data using the google drive method (even being able to click from the browser SSH and upload!) I'm not sure it's worth setting up snapshots for me
Yes, shouldn't affect the numbers on the Efficiency dashboard as the charging_process record you inserted only describes energy added. I just inserted a bunch of extra records into my test database to 100% confirm and nothing on that specific Grafana dashboard was affected.
Glad it all worked ok for you
hingus2000
Member
Would adding the 83 miles, driven on my collection date, work in a similar way?
Don't care about detailed stats within those 83 miles, but just for the sake of completeness of totals.
No need to provide the code, I'll have a go at it (and might check my working on here), but interested to hear if a similar principle would apply or if manually adding drive stats would have lots of difficult implications.
Don't care about detailed stats within those 83 miles, but just for the sake of completeness of totals.
No need to provide the code, I'll have a go at it (and might check my working on here), but interested to hear if a similar principle would apply or if manually adding drive stats would have lots of difficult implications.
Rather than type out the contents of the files this time, I've put this in instead, hopefully that'll cover it:
In theory yes, should work. I've not looked into what distance or mileage (km) metrics are used to calculate which other metrics.
A record in the drives table only has a couple of values that are mandatory as far as the database design is concerned, namely the car_id and the start_date. For a completed drive some of the application logic might assume that other column values are populated.
If you get stuck then let me know.
I normally try to avoid doing too much database tinkering in the backend of an application, it's basically changing data through the back door rather than using the front door (teslamate). Best to keep whatever you do to a minimum just in case the application changes or makes assumptions when accessing data.
@Niek on the Dutch forum is a Curl specialist and cooked the whole Teslamate for Pi installation in one line of Curl
curl -s https://raw.githubusercontent.com/adriankumpf/teslamate/master/website/docs/installation/docker.md | sed -n '/```yml/,/```/ p' | sed '/```/ d' > docker-compose.yml
curl -s https://raw.githubusercontent.com/adriankumpf/teslamate/master/website/docs/installation/docker.md | sed -n '/```yml/,/```/ p' | sed '/```/ d' > docker-compose.yml
TeslaMate has settings?
Edit: found them. Streaming API enabled (it is the default).
Thought it was, but just wanted to double check as TeslaMate shouldn't be contacting the car directly, it should just be listening for events on the streaming API is my understanding.
Roy's advice to test this is the best next step.
Similar threads
