Replies: 13 comments 25 replies
-
|
Hi @aesculus What sort of wall charger do you have - is this a Tesla Wall Charger + Tesla car for instance? If so, my understanding is that we are not currently getting any EV charging data from e.g. Tesla Wall chargers. However, you may want to check out #382 where this has been discussed previously. I believe @youzer-name may have a solution here utilising Teslamate to show when your EV is charging. Or did you have another idea to extrapolate out the power usage from your EV? I have been toying with this myself, however with a myenergi Zappi wall charger for my Polestar 2. I've written another tool similar to the tesla-history script (zappi-history) which polls for and extracts historical EV charging data from the Zappi wall charger and imports into InfluxDB. Thankfully myenergi has an API that can be used and also there was an existing Python module making this easy (credit to @CJNE for this). This may not be useful for everyone (have not seen mention of anyone else here using a myenergi Zappi as yet), but I have been thinking to release as another tool, including my custom dashboard, since it could be useful as a guide/basis for including EV charging data in Powerwall-Dashboard generally, from various EV charge platforms. This is what I have so far from a dashboard perspective. Is this the sort of thing you would be looking at achieving?
The example above shows when I was charging my car during the day (boosting in this case, however I normally only charge from excess solar). Dashboard changed to show:
|
Beta Was this translation helpful? Give feedback.
-
|
While I'm still using Teslamate, I'm also now subscribing to Tessie, which is a cloud-based paid Tesla data tracker. I'm using Node Red to pull data from Tessie's API and storing it in InfluxDB. I'd be happy to share the details if anyone else is interested. |
Beta Was this translation helpful? Give feedback.
-
|
@mcbirse My use case is fairly simple as is my environment. I have a Gen 2 Tesla Wall Charger and an older Model X with dual chargers. The car is set to consume at a rate of 72 amps (17 kW) and use the scheduled charge only starting at midnight. Rarely it will charge a little bit during the night period for a few minutes to top off a battery that did not seem to need it at midnight. By 6am, all charging has always been finished. My car is too old for "charge by solar" and I really don't have that much excess only plus on Time Based Control with export everything, I would be much better sending my solar back during peak rate periods for the best monetary return. So my thought was to easily determine what part of the home load was the charger (seeing anything greater than 17 kW and just subtracting that from Home). So wherever the Home values gets written into InfluxDB (what Docker container?) I would perform this modification and write another attribute with the car charge value. Then obviously I would need to create another line graph in Grafana to show the car value. If there is a way to separate this out in Grafana vs modifying InfluxDB that would be fine too. PS: I do like your modified Dashboard but in my use case it would not have much value as I do all my charging from the grid based on the cost differential I am faced with via TOU. In the future that may change. And since my car has FUSC, I have been using SCs much more that previous as my rates have climbed dramatically. But that also means I get a lot more for my solar energy returned to the utility during peak rates (Export Everything), so solar is sent to the PWs and is used to get me through the peak periods and anything extra I need to send to the utility at the most profitable rate. The Tesla algorithms do a great job of managing this. Its amazing what we have gotten ourselves into as a society but with solar, Powerwalls and an EV, I have an opportunity to play the most profitable game as the rules seem to change daily. |
Beta Was this translation helpful? Give feedback.
-
|
I think I figured out some queries that will get you close, but running them against my data I'm only able to get within about 4% of the values I show on my dashboard from other calculations that I trust. I'm taking the integral of the home use from autogen per minute. Where the integral is > 0.2833 per minute, those minutes represent charging times. (0.2833 per minute * 60 minutes = 16.998 kw per hour... add as many 3's to the end of the number as you want for more precision) Subtracting .2833 from each of the 1-minute values where the value was > .2833 should be the home use above the car charging for the minutes when the car was charging. Any of the per-minute values that are below 0.2833 represent minutes when you were not charging. Here are the queries. I don't guarantee they are correct, but they produce reasonable values for my data. Total home use is this: Total home use while charging: Non-charging home use while charging: Home use while not charging: Charging use: Unfortunately I don't think there's any easy way to get InfluxDB to return (pseudo code) "multiply 0.2833 x (the number of minutes spent charging), but you should be able to get charging use by using a Grafana expression to subtract the "non-charging home use while charging" query from "total home use while charging" query, which should result in exactly 0.2833 kw per minute of charging. |
Beta Was this translation helpful? Give feedback.
-
|
@youzer-name Thanks for those Grafana queries. I may be able to take that approach rather than doing it on the db input side. Give me a few days to experiment. Grafana quires are not my strong suite. :-) |
Beta Was this translation helpful? Give feedback.
-
|
I played around doing this all in Grafana but ran into a few issues in graphing: So it looks like I will really need to do my adjustments during the InfluxDB loading stage where I can use more logic. |
Beta Was this translation helpful? Give feedback.
-
|
Whether you do it on the front end and store the results, or do it on the back end and query it from the data, it seems the logic is the same:
It sounds like there is probably one minute at the beginning and end of each charging session that has a value above normal base use but below 17 kW since it is a 1-minute average. Or maybe the car ramps up to 17kW over a period of time longer than 1 minute? You could experiment with a lower value than 0.2833 in the query, but depending on what other large electrical loads you have when not charging, that might cause issues elsewhere. Please post your solution if you solve this on the input side. I'd be interested to see what you come up with. It's easy to look at the graph and see where the charging use is, but much harder extract that and calculate a value for it. |
Beta Was this translation helpful? Give feedback.
-
That's for sure. In my case the shoulder seems like about 1 or 2 minutes each side of the 17 kW charging. In an app I could do some intense math to figure out when this occurs and play with the shoulder numbers, but no so much in Grafana or InfluxDB. I will also need to subtract the charging rate from the home rate whenever the load is greater than 17kW too on the chart as you have done with the sums. |
Beta Was this translation helpful? Give feedback.
-
|
Poking around a bit it appears that if I wanted to do something to the InfluxDB content it would have to be in Telegraph? I see this #112 but not sure if it can be applied to not only subtracting the charger load from home accurately, but then creating a new attribute in the db for the charger data. I am way out of my league here but it appears you others have some experience here. |
Beta Was this translation helpful? Give feedback.
-
|
@mcbirse This looks interesting. I'll have to give it a try and see what it looks like. I'll probably still loose those shoulder minutes but maybe I can even do some funny SQL math there too. |
Beta Was this translation helpful? Give feedback.
-
|
@mcbirse Need some help. I created the create_cqs.sql with the two cqs and then executed the docker command as above. After a few minutes I checked the influx cqs using SHOW CONTINUOUS QUERIES and only the cq_ev1 one showed up at the bottom of the list. The cq_ev2 was not to be found. I did start charging and got two entries for the charging minutes but nothing for the non charging minutes since that cq was missing: ` select * from ev LIMIT 3 1710615780000000000 17200 301.89026988782643 Any thoughts on why the second cq did not get into the pack? |
Beta Was this translation helpful? Give feedback.
-
|
Make sure the |
Beta Was this translation helpful? Give feedback.
-
|
Who knew? :-) cq_ev1 CREATE CONTINUOUS QUERY cq_ev1 ON powerwall BEGIN SELECT mean(home) - 17200 AS home, mean(home) - mean(home) + 17200 AS ev INTO powerwall.autogen.ev FROM powerwall.autogen.http WHERE home >= 17200 GROUP BY time(1m) fill(linear) END name: ev 1710615780000000000 17200 301.89026988782643 |
Beta Was this translation helpful? Give feedback.
-
|
Nice! |
Beta Was this translation helpful? Give feedback.
-
|
I like a lot of the above suggestions as many don't require much modification to the base Powerwall Dashboard infrastructure. But ... I already have a modified version of pwpowerwall to support an odd circuit configuration where I have a solar inverter on a home load circuit. The home load is primarily lighting loads so the solar and load are pretty easy to distinguish. But this meant that without modification, my solar output could be quite negative during lighting events. Tesla solved this with the Tesla app and @jasonacox provided me a way to do this also in pypowerwall. So I have a custom version I am stuck with for the rest of my Powerwall Dashboard days. So for me, its not that big of a deal to modify pypowerwall to identify the EV charging load down to each reporting minute and strip it from the load value and add it to a new [ev] measurement. But here is the rub: I am not sure how to go about creating a new ev attribute (would it be in aggregates?), nor how this would be treated by Telegraph to stick it into InfluxDB (assuming it would go into http?). @mcbirse you seem to have some experience with pypowerwall. What do you think? |
Beta Was this translation helpful? Give feedback.
-
|
If you add the [ev] measurement to the |
Beta Was this translation helpful? Give feedback.
-
|
@jasonacox What do I need to do with all the fields that my EV will not have? Ie here is the example from load:
If I just populate data["ev"]["instant_power"] will the other variables get some sort of default or do I need to ensure that there are reasonable variables like is in the load sample above? While I only really care about the instant_power, I don't want the system to get upset. And, I guess when I do my decomposition I can figure out what the percentage is between the load and ev for all the power and current variables and distribute accordingly? I did not do this for my solar < 0 issue, because those were pretty close to rounding errors WRT total power. |
Beta Was this translation helpful? Give feedback.
-
|
@aesculus - just wondering if you tried the example CQ's before going down what seems a more complicated/difficult path? If you added those CQ's, the new measurements and fields are automatically created BTW. The example I gave would sample from the per minute data in autogen (not raw). Maybe it will give you almost what you need? (except for shoulder minutes perhaps, but then you could always sample from raw instead if that helped). |
Beta Was this translation helpful? Give feedback.
-
|
@mcbirse OK. I have not directly tried it yet and one issue I have is it looks like I would need to replace the existing home field with the new ev.home one? And that is related to my post just above because there is all this current and different types of power etc. on the original home one. If it turns out all that is garbage then it could be that the CQs are the way to go. Not sure how much of this needs to be modified other than just the [instant_power] field. Still trying to get my head around the different options. BTW even if I go for the direct data manipulation pre Telegraph, I am not sure I can solve the shoulder period issue. It does look like the ramp us it small though (2 minutes, and the middle is usually between 8kW and 12 kW). The one that starts at midnight maybe easy to catch because of the specific time. The end should be easy to catch because I can set a flag that I am currently in "EV Mode" and if the next reading is between 8-13 kW for example, its a shoulder. The ones that are probably impossible, and they are rare for me, are the odd times the car decides to put a few percent in during the middle of the night because the battery cooled more than expected and the tolerance (ie at 2% for my car) has fallen off the top end. |
Beta Was this translation helpful? Give feedback.
-
|
@aesculus Yes, you just need |
Beta Was this translation helpful? Give feedback.
-
|
Well as you can see above I was able to successfully create both EV charging and background loads using @mcbirse constant queries. They don't cover the potential shoulder minutes (1 before and 1 after), but that is kind of a rounding error anyway. Even experimenting with doing this in pwpowerwall I could create an algorithm to capture the post shoulder but not the pre. Since I have scheduled charging at midnight I could potentially capture most of those with an time based algorithm but not the occasional ones that happen during the early hours before 6 am. The advantage of doing the pwpowerwall approach is that I retain my home values and just add an ev field in http. But the CQs are far simpler to add. Using the CQs, I am trying to understand how I can utilize these new EV data attributes within the dashboard while still maintaining my current home values. What sort of needs to go on is the sql query needs to choose the old home value when there is no EV value, and then use the new values (ev and home) when the cars is charging. Here is the old sql query: SELECT max("home") FROM "autogen"."http" WHERE $timeFilter GROUP BY time($__interval) |
Beta Was this translation helpful? Give feedback.
-
|
OK. So a different approach than what I was thinking. This looks like I will back fill all my old home data with the new algorithms so when I change the dashboard over to using the ev.ev and ev.home, and remove the http.home, it will look correct? |
Beta Was this translation helpful? Give feedback.
-
|
@jasonacox Got this error when executing: [/share/CACHEDEV1_DATA/Powerwall-Dashboard/backups] # docker exec --tty influxdb sh -c "influx -import -path=/var/lib/influxdb/ev_run_once.sql" It was maybe 3-4 minutes? |
Beta Was this translation helpful? Give feedback.
-
|
You could try it inside the shell inside the container and just paste the queries into the influx client tool: # Log in to container
docker exec -it influxdb sh
# Run the interactive client
influx
# Now paste the queries |
Beta Was this translation helpful? Give feedback.
-
|
That seemed to work. But when I went to look for ev>0 it did not return any events. select * from ev where ev>0 There are home values but ev always is 0 |
Beta Was this translation helpful? Give feedback.
-
|
I think you might need to use: SELECT * FROM powerwall.autogen.ev WHERE ev > 0 |
Beta Was this translation helpful? Give feedback.
-
|
As seen in the dashboard image the queries must not be correct. That yellow area should be the home base. Not sure what it is reflecting during the charge period.
|
Beta Was this translation helpful? Give feedback.
-
|
UPDATE: Well all the means, group by and fills were causing issues. From direct experiment it appears that just simple queries copying "rows" and doing the required math is all that is necessary: CREATE CONTINUOUS QUERY cq_ev1 ON powerwall BEGIN SELECT home - 17200 AS home, home - home + 17200 AS ev INTO powerwall.autogen.ev FROM powerwall.autogen.http WHERE home >= 17200 END Now my biggest issue is trapping the shoulder minute on both sides of a charging event. Not understanding how to do that using query logic. :-( |
Beta Was this translation helpful? Give feedback.
-
|
Awesome! Great job @aesculus . What do the "shoulder minutes" look like? |
Beta Was this translation helpful? Give feedback.
-
|
Shoulder minutes in my scenario are only one minute on each side (well I have only seen it this way since my car ramps up and down in less than a minute it appears). They can be a few kW larger than the base or often 10-12 kW more than the base, but less than 17.2 kW + base. The issue for me is I use a schedule charge (always at midnight), but not all nights use the charger. So some nights 12:01 has >17.2 kW and 12:00 has something less, but larger than the 11:59 PM day before amount (base). And on the back side same sort of thing but that could be easier to capture because the next minute after the last >17.2 kW will be a shoulder minute. There are tricky ones that are rare but do happen. Its when the temperature drops and sometime during the early hours the car decides it needs to put in a few kWhrs. I will see a few minutes of 17.2kW rates with associative shoulders. But these can happen at random hours and days. I am not sure what logic I could ever use to capture these events, especially using query logic. But since the queries are looking at each minute I am not sure what query logic I could use that did a WHERE on the value of a preceding or post minute value. Beyond my query skills and maybe beyond query logic? |
Beta Was this translation helpful? Give feedback.
-
|
Ah yes, I think so. You basically need something that has memory S(x - 1) or lookahead S(x + 1) where x is current time, to be able to do that math. |
Beta Was this translation helpful? Give feedback.
-
|
Yep. I can certainly do the look behind in the logic for pypowerwall. I proved that out. I kept a flag when a reading was > 17.2 and if the next was less than 17.2 that was a ending shoulder. An in the case of a > 8 kw at the top of midnight, that is almost certainly a starting shoulder. But I have no logic for the start shoulders off of midnight. |
Beta Was this translation helpful? Give feedback.
-
|
Well after trying the various options above for awhile I decided what I really wanted was just for the Energy Usage graph to show the separate car charging. If I meddled with the data I would end up altering the Home energy values which would be wrong. Charging is a part of home. So I ended up hacking the Energy Usage graph using some of the ideas from above. First I changed the Home Usage query to reflect only the non charging data (<17.2 kW): SELECT max(home) FROM (SELECT home-17200 from "autogen"."http" WHERE home >= 17200 AND $timeFilter), (SELECT home FROM "autogen"."http" WHERE home < 17200 AND $timeFilter) GROUP BY time($__interval) fill(null) Then I created a new query (EV Charging) and moved it to the top of the stack: SELECT max(home)-max(home) + 17200 as ev from "autogen"."http" WHERE home >= 17200 AND $timeFilter GROUP BY time($__interval) Lastly I altered the visual aspects of the charging graph to represent its more "stable" nature by using a bar chart: {
"matcher": {
"id": "byName",
"options": "EV Charging"
},
"properties": [
{
"id": "custom.drawStyle",
"value": "bars"
},
{
"id": "custom.lineWidth",
"value": 2
},
{
"id": "color",
"value": {
"mode": "fixed",
"fixedColor": "#abad1f33"
}
}
]
}This resulted in a update Home Usage graph as depicted below. Note that this is a night where the car charged at midnight and then later on in the night, decided it needed to push a bit more energy into the car (probably because of ambient cooling lowering the SoC).
|
Beta Was this translation helpful? Give feedback.
-
|
Nice job @aesculus !!! That's beautiful! |
Beta Was this translation helpful? Give feedback.
-
I am toying with the idea of pulling my car charging from the home load into its own graph. For me that would be easy to do from a data perspective because the charging always starts at midnight and I have a high capacity charger at 17 kW, so its easy to spot and filter out.
The question is where would I do this and how? I am thinking of creating another attribute in the db for the charger data and then it would be easy in Grafana dashboard just to create an additional plot for the charging.
Where does the loading of the database happen in the Powerwall Dashboard? I poked around but did not see any source for that? I assume its one of the Docker containers?
BTW: I currently run a custom pypowerwall instance to adjust negative solar values, but this would not be the place to perform the charger extract as its is prior to the db. I also load the powerwall db today with data from my heat pumps so I know the structure of the db too.
Beta Was this translation helpful? Give feedback.
All reactions