v4.4 #339
Replies: 19 comments 74 replies
-
v4.4.2 What's Changed?
Full Changelog: v4.4.1...v4.4.2 For automated dampening, Enphase Envoy users were impacted by a bug in the code that prevented PV generation being correctly measured. Other inverters may also have been affected. Thanks for the great bug report, @rcode6. |
Beta Was this translation helpful? Give feedback.
-
|
Back in the "old days" there was a separate discussion thread for each BJReplay Solcast integration release, major or minor. And this was good back in the day, mostly because BJ and I still had our "training wheels" on in terms of the integration code, and the code was nowhere near as robust, nor as well tested. The training wheels are well left behind, now. I am switching to the use of just one discussion topic for each significant release, because minor releases are going to be just that. Bug fixes and minor enhancements to existing capability, mostly. So this discussion topic will hang around until someone comes up with a banger of a feature that will result in a v4.bump from v4.4. One topic will also increase the reach of repeat participation, and I rate that for a community-led bit of code. The code is the result of community experience and desire, need and want, and subsequent contribution. It doesn't make itself. I reckon that automated dampening was a significant step forward in terms of evolution, and so that is why v4.3.x became v4.4. It wasn't about fixing something, rather about delivering a new and brilliant thing. So place experiences here. Put your "suggestions box" things here. Love y'all. 😘 @BJReplay, @brilthor, @dtswk, @EddieSpaghettie, @ffm777, @gcoan, @hwb45, @iainfogg, @isorin, @jeffb1974, @ladaan, @Markyt77, @Nilogax, @Noodleyman, @ProphetOfDoom, @rcode6, @rholligan, @sh00t2kill, @wimdebruyn |
Beta Was this translation helpful? Give feedback.
-
|
Loving auto-dampen as a relatively new user. I got started with v4.4.0 after finding out about this. I have a gigantic tree that shades my panels at 1pm, and then a hill/more trees around 4pm onwards that make my generation curve drop off like a cliff. When I first installed, my pv generation sensor was in MWh, so I had to create a kWh template sensor and didn't have any history. It also happened to be overcast nearly the entire first week I had it. It still picked up the end-of-day dampening perfectly after a few days, which was impressive, but couldn't capture the mid-day shading. I just figured it needed more time. Updated to v4.4.1 and v4.4.2 asap so I could swap to my MWh sensor with more history. Glad to report that it looks like it's picking up the mid-day shading which was missing before, at least according to Thanks for the great work! |
Beta Was this translation helpful? Give feedback.
-
|
Unusual azimuth warning .... (continuing the discussion) I know we have discussed this several times and together updated the wording, but having now upgraded to 4.4.1 and 4.4.2 (I could see bug fixes coming through so hung back on going to 4.4.0), and I get an unusual Azimuth warning, and having now received it, have some feedback on it ... In my logfile I see: And the warning I get in HA is: I know all the reasons for why the validation is being done, and I agree with it, I'm questioning whether this is being too zealous and think the readme isn't quite correct. In the readme it says "A Solcast configuration of roof aligned North/North-East/North-West in the northern hemisphere or South/South-East/South-West in the southern hemisphere is considered to be possibly unusual because these orientations are not directly facing the sun at any time." My roof with an azimuth of 80 has been classified as North facing - its not, I'd call it East facing, or East/North-East. Per the readme "is not directly facing the sun at any time" - this isn't correct If I go to https://www.sunpathview.com/ and put my address in I get the following sun path, yellow and blue being summer and winter solstice and green being mid August which is well past the peak generation in June. My house is highlighted with the arrow and as you can see faces almost due East with a slight Northern component so I'm pretty confident as to the azimuth 80. So maybe the readme needs to be less "doesn't face directly to sun" and be more "not an optimal orientation for best solar generation". As I might have said before, the roof is what it is, I can't move it. And even North facing roofs can generate useful solar. Second point I wanted to make is that the advice about the azimuth warning is not at all obvious in the readme. It doesn't appear in the table of contents nor in the troubleshooting section which is where people might look for it if they encounter it. |
Beta Was this translation helpful? Give feedback.
-
|
I had this as well a few days ago with my South Wales roofs facing WSW (130 degrees) and ENE (-50 degrees). Threw me a bit to start with, so I had to go check that nothing had got fudged up in Solcast. Once I was satisfied that everything was as it should be I clicked to Ignore the warning and carried on. You can stand in the bedroom window that side of the house and look straight at the sunrise for a good bit of the year, so it might not be optimal, but every kWh counts! Keep up the good work people. |
Beta Was this translation helpful? Give feedback.
-
|
@ProphetOfDoom, @gcoan: responding to discussions saying that the warning is to assertive is (generally) easier than debugging My FoReCaSt Is WrOnG issues 🤣 |
Beta Was this translation helpful? Give feedback.
-
|
Yup, but in my case I've no idea whether it's wrong or not as I don't actually have any Solar PV yet, just a continual reminder of what I'm losing out on. Take pity on me 😄 |
Beta Was this translation helpful? Give feedback.
-
|
I had written most of a very long comment about my experiences of setting up and tying to get auto dampening working, including copying in all the relevant debug logs. And then github lost it all. So to save my sanity (and so I can go to bed) I will give the summary and if you want debug logs I can supply them.
I think the sensors I have used for my PV generation may cause problems with auto dampening. Be interesting to see how it handles it when I can get it working. I have 3 arrays, G, H and FIT. For each I have today and total sensors. The today total generation would probably be best to use for solcast BUT it is only updated every 15 minutes as I currently only use it on a dashboard and by updating on a timed trigger it reduces database storage of lots of little entity changes: I thought this 15 minute granularity would not be good enough for the auto dampening so I instead have configured the integration to use the array level total solar generation entities. However these (like most of my entities) are purged to reduce unnecessary database storage. but FIT is just 1 day: I expect that by having uneven history lengths on the sensors it will cause the auto dampening to initially think that actual generation is massively suppressed. Should I use the total sensor, 15 minute granularity OK? And is the different sensor lengths another test case for you ? |
Beta Was this translation helpful? Give feedback.
-
|
Think about it, Geoff. In your own words, "17th ... wasn't a great day", so why would it be included in any matching intervals and dampening modelling? It was not a great day. These are not matching "candidates". They are matched "good" estimated actual intervals with the generated electricity shown for each matching intervals. Plus you have limited data at this stage. |
Beta Was this translation helpful? Give feedback.
-
|
Day 2, looking at the debug log to see hopefully better dampening factors being generated because the day 1 ones: are having quite a noticeable effect on my solar forecast: I noticed that at midnight the day -1 PV data actuals are captured. I hadn't realised they would be then, thought it was at 00:20 alongside the estimated actuals, but makes sense. However some warnings about excessive jumps being ignored on my FIT array: In each case the jumps are about 50W which doesn't seem excessive?? There are also 3 jumps reported for the same sensor at 13:00 and two at 18:00. which sounds wrong - is the wrong sensor name being reported? Here's the sensor history over the 13:00-13:30 time period, the line looks pretty smooth to me: The inverter energy in this sensor is sampled every minute. The auto dampening calculation has now run, graph looks better still what looks like weird stuff in the log: Things that jump out at me:
I think these erroneous generation figures are why I am getting massive dampening factors This is feeling strongly like a bug report @autoSteve not a discussion any more. Maybe it doesn't like multiple energy sensors? |
Beta Was this translation helpful? Give feedback.
-
I'm struggling with the concept and terminology here Steve ! 17th wasn't a good solar day, agreed, it was overcast and probably rainy that day. But I would have anticipated that it would still be a candidate for matching solar actuals to estimated actuals? Doesn't necessarily explain why yesterday (20th) has hardly been used in the latest dampening factor calculation (see my next comment), it was a good day, 38kWh generated. |
Beta Was this translation helpful? Give feedback.
-
|
"Good" is consistently higher generation for a given half-hour interval over fourteen days of data (which you don't have yet). Yes, it might have been a good day yesterday, but was 10:00-10:30 consistently good over recent times? Was 14:30-15:00? Both intervals may have seen some good days, but maybe they are not consistent. Build a history. Gather experience. It looks to me like there is some "garbage in, garbagage out" going on here, and not a broken model. There will be many different types of generation sensor behaviour, and this feature is in very early days. I own Enphase micro-inverters and Tesla batteries, so I have a very limited exposure to the dozens and dozens of inverter integrations for HA. How these update the generation entities matters, so having the raw figures matters. The integration is working out how much energy was generated in each half-hour interval, and if that is even slightly off then bad things will happen. You have quite a complex set-up, with three (?) inverters? That may be breaking things. |
Beta Was this translation helpful? Give feedback.
-
|
Re-looking at your logs I see massive swings in actual generation for "good" consistent est. actual intervals, and this smacks of generation gathering oddities. We need to break this analysis out into a discrete discussion or issue that spams less folk. That "excessive" intervals are being ignored might just say that the definition of excessive is too conservative. That would explain interval "dips". It would not explain intervals that seem impossible. Where generation history has been acquired before then only the past day of generation will be retrieved from history at midnight. Changing input entities at the moment is flawed. It should really invalidate all past generation history and then try to re-load what it can from the newly configured entities, and then play on at midnight moving forward. My bad. I hadn't considered it until now because most people have only one or an alternate, like one Enphase, and one Tesla. |
Beta Was this translation helpful? Give feedback.
-
|
Feature Request: use My mid-day shading has started picking up on some dampening, but is not quite enough. Looked into one of the intervals, and I believe it's because using max on the matching intervals always ends up picking the oldest value. The following intervals also all have the same estimated actual of 3.190. If you look at the matching intervals, my production during it is going down each day in a pretty stable trend. Using max in this case always chooses the oldest data. Using the average would end up being closer and more responsive to changing trends, and I think would still deal with noise relatively well. EDIT: or maybe calc the generation/estimated actual individually for each of the matching intervals, then average that? EDIT: liking median more now. as said below, early days though, will think on this and gather more data. |
Beta Was this translation helpful? Give feedback.
-
@rcode6, for your intervals with a meidan of 2.48 what was the reported agreeing estimated past actual for that interval? You did not specify, nor show that, and that is important, and bugs me. What was the "agreeing" past estimated actual reported on the preceeding line in your log? Was the past agreeing estimated actual higher than any value presented? Did it result in a dampening factor, even if insignificant, and ignored? |
Beta Was this translation helpful? Give feedback.
-
|
@autoSteve peak estimated actual of |
Beta Was this translation helpful? Give feedback.
-
|
Righto. My bad. Seasonal adjustment for the win here, which is a pretty clear "stretch goal" for the integration in this circumstance. Thanks for the clarification, @rcode6. |
Beta Was this translation helpful? Give feedback.
-
@rcode6 just checking that the inverter limit isn't playing a role here. It's not export limiting, but I wanted to check that it is correctly defined on your Solcast https://toolkit.solcast.com.au/ set up, so that your base forecast isn't overly optimistic? |
Beta Was this translation helpful? Give feedback.
-
|
@BJReplay yep it's defined correctly in the Solcast settings. Gets reflected properly in the estimated actuals too. My base forecast basically matches super closely for the first half of the day, and only really needs dampening in the latter half. It's also 100% due to a tree issue + hill/more trees. |
Beta Was this translation helpful? Give feedback.
-
|
A different topic. I think its out there, and to save me rolling my own (and yes I did look in templates.md), does anyone have the Apex chart code for a chart that shows undampened solar forecast alongside the dampened forecast for today? And not wanting to split the conversation any more, but I did start a thread a couple of days ago on unusual azimuth given I too get the warning. And yes I know I can ignore it, but I have questions/concerns about it. Less urgent than the other discussions so maybe park it, but wanted to flag its existence |
Beta Was this translation helpful? Give feedback.
-
If you're looking for something like the grey in this one: I just duplicated one of the other forecast lines, then updated the |
Beta Was this translation helpful? Give feedback.
-
|
thank you, exactly what I needed. I thought it was something like that, but Apex syntax is a pain
|
Beta Was this translation helpful? Give feedback.
-
v4.4.3 What's Different?Up to fourteen days of forecast data. (And more improved!) Ignore this. The forecast will be updated in the near future. When it updates, either on schedule or automatically that warning will disappear... You won't need to do anything in the UI. Just wait. There is also a mlnimum HA version bump. We need to keep up with that bacause deprecated things will go away. What's Changed?
Full Changelog: v4.4.2...v4.4.3 New Contributors
|
Beta Was this translation helpful? Give feedback.
-
|
Much fours in the version. Unlucky for some cultures, but there be fixes within! v4.4.4 What's Changed?
New Contributors
Daylight time adjusted interval: @autoSteve broke it, @rcode6 pointed out exactly where it was broken. Remove and suppress ignored unusual azimuth: This warning raised as an issue should remain ignored for all time once ignored once, but that has not been happening. This 'fix' makes it so, and permanent unless you hack the sites cache to want it to come back. 🙄 Full Changelog: v4.4.3...v4.4.4 |
Beta Was this translation helpful? Give feedback.
-
v4.4.5 What's Changed?Warning What's Changed?
Europe/Dublin: It turns out that the Irish are special of time zone... Fixed. Auto-dampen changes: These are mostly changes to accommodate the idiosyncrasies of various PV generation sensor variants, and also ignore a sample size of "one". Auto-dampen NEW!Auto-dampen needs reliable generation data. To that end, people exposed to wholesale energy market pricing going negative and therefore preventing export, or those who are not allowed to export at all are now covered by an advanced "generation suppression" entity. Full Changelog: v4.4.4...v4.4.5 |
Beta Was this translation helpful? Give feedback.
-
|
7000 downloads and narry a peep. |
Beta Was this translation helpful? Give feedback.
-
|
working perfectly for me! |
Beta Was this translation helpful? Give feedback.
-
|
and me |
Beta Was this translation helpful? Give feedback.
-
v4.4.6 What's Changed?Just a couple of bug fixes.
Full Changelog: v4.4.5...v4.4.6 |
Beta Was this translation helpful? Give feedback.
-
|
Updated without any issues, nothing of note in logs when re-generating dampening factors. |
Beta Was this translation helpful? Give feedback.
-
v4.4.7 What's Changed?
Add advanced options configuration I'm a bit excited about the potential that this feature can bring. It allows modification of code execution by setting defined advanced options according to preference or circumstance. Do you want automated dampening modelling over ten days and not fourteen, or ignore as "insignificant" any factor over 0.90 instead of 0.95? You can now set that up. See the documentation at Advanced options. You could even roll your own modifiable thing as a new advanced option, and submit it as a PR. Full Changelog: v4.4.6...v4.4.7 |
Beta Was this translation helpful? Give feedback.
-
I sort of understand why you would anticipate that, but there is a difference (big) between picking up a new option, and re-triggering an entire slab of code to run. Imagine if you have changed the forecast days from 7 to 8 to 9 and so on? Do you want to use up a forecast call each time you save the file? It is automatically applied, but that doesn't necessarily mean that services are called. |
Beta Was this translation helpful? Give feedback.
-
I personally dont mind the current behaviour, and have re-read the documentation on this point. Suggest instead of "Changes to this file will be detected in near-real time, changing code behaviour. Application of changed behaviour may only be seen at forecast or estimated actuals update, or possibly immediately should "reload_on_advanced_change" be set to true (see below). " it be changed to "Changes to this file will be detected in near-real time and the Solcast configuration changed. You will not see the changed integration behaviour unless you reload the integration, force a manual re-run or wait for the next scheduled forecast or estimated actuals update. If you want the change to be executed immediately, consider setting the "reload_on_advanced_change" option to true (see below)." Have to admit I had missed this |
Beta Was this translation helpful? Give feedback.
-
That's worse. It might make sense to you but is more misleading. What does "force a manual re-run" actually mean? Do you mean a forced forecast update? If so, you need to say so, if you're proposing documentation updates🤣. You've said "you won't see the change... unless you wait... without specifying how long you need to wait. Some waits will not be until midnight, or the next day. In this case, the original wording - saying less, is more precise, because it says what will happen. Code behaviour will be changed in near time. Changes will be seen, sometime later. As was noted when this was released, this is advanced nerd stuff. Read the readme. |
Beta Was this translation helpful? Give feedback.
-
|
Paragraph three is fine. Changes to this file will be detected in near-real time, changing code behaviour. Application of changed behaviour may only be seen at forecast or estimated actuals update, or possibly immediately should "reload_on_advanced_change" be set to Paragraph four. This. Maybe this one is too obtuse, referring to "impact". In your case there is impact, and that is that modelling does not immediately occur. You can cause it to occur immediately by re-loading, either via the advanced option, or manually. The impact of not restarting will vary by advanced option, and you are left to decide when the outcome should occur; this is advanced, and you are expected to be advanced. Each option does specify whether a re-load is required. Other options do not state that a re-load could cause things like dampening modelling to occur on start like after changing the number of days involved, delivering an immediately pleasing result. The timing of re-modelling is left to you. Teething issue, and not doco issue I think. |
Beta Was this translation helpful? Give feedback.
-
This has been fixed, @gcoan. An empty string is not considered a valid JSON structure. Valid JSON must be enclosed in either Thanks for reporting that experience; an empty file will now be quietly notified as being monitored for changes at The same should also apply for the PR #385. |
Beta Was this translation helpful? Give feedback.
-
|
I tested an edge case for you yesterday, my lowest ever (since my panels were installed in January 2023) generation, 0.69kWh. It rained all day. You can see the 0.1kWh granularity of my power now sensor
Pleased to say that the integration handled the non-generation without complaint: I like the extra debugging information on the entity details in case the wrong one had been chosen. Solcast has been unhappy all morning, returning 429's at each attempt to get data. Logging from the estimated actuals update: The 429's I'm fine with, but the "No valid data was returned for estimated_actuals so this may cause issues" - what does this mean, have I got problems, have I not, does the estimated actuals pickup two days tomorrow or does it just skip this day in calculating the dampening factors? I don't mind either way but the "may cause issues" is a bit vague and cause for concern. As ever, brilliant work, just suggestions for improvement |
Beta Was this translation helpful? Give feedback.
-
I believe I fixed the code at some point to do so, @gcoan. If I did not fix the code then call out the gap. I have no gaps as of now, visualising past dampened estimated actuals, despite the recent Idiocracy. I was messing with User-Agent to attempt to re-ignite acquisition, so that may explain my lack of a gap. One thing that will be thrown is the application of dampening to past actuals, which only occurs for "yesterday". I deemed that situation un-fixable with the code in its present form, declaring many days missed as extraordinary.
Gaps in Energy dashboard depending on settings chosed. Throwing off auto-dampen? Other issues unimagined because interruption of usual data flow. It is nebulous because many possible repercussions. "Have I got problems"? Dunno. What settings are set? Which options are in use?
A summary message, and technically quite correct at that point in the code. Same thing happens if the Solcast API cannot be reached because network. Earlier messages will tell the story. I agree that some of this could be cleaned up. |
Beta Was this translation helpful? Give feedback.
-
|
Feedback from the estimated actuals collection after 2 days of no Solcast, in short, nothing to see here no obvious sign that it was picking up 2 days of estimated actuals or not that I could see.
Agreed, not essential and complex, potentially rewriting history for the energy dashboard. Am seeing the auto dampening looking at time periods with historical data that are now before sunrise (e.g. 6:30) so not finding many matches, and periods around sunrise (e.g. 7:30) that the sun is still weak so are getting significant dampening factors applied, but the forecast is small at this time anyway so the big dampening makes little difference. all looking good |
Beta Was this translation helpful? Give feedback.
-
|
I believe that I coded the estimated actuals fetch to get one week, and then to "fill in the blanks" of history in the data set. If there were two days missing then it would have added two days, but then only applied dampening to the immediately prior day. Undampened actuals inform auto-dampening, so no operational foul, but possibly a visual/historical one for dampened. In the event of an unexpectedly long outage then estimated actuals (up to a week) are used to plug any historical forecast gaps, but I cannot vouch for that scenario working 100%. That is tested as far as the actuals fetch occuring when recovering from extended outage, but other flow-on aspects not so well. Agree. Looks great. Thanks for that update, Geoff. |
Beta Was this translation helpful? Give feedback.
-
|
An observation and suggestion on possible enhancement to the repair notice … Solcast been 429ing all day yesterday, and still today, so no estimated actuals or solcast forecasts downloaded. In the forecast dampening recalculation log I see: And I now get a repair notice: I understand the repair notice, and the cause of it, but wonder if it could be a bit more explicit as to what to do for new users, e.g. check the logs for errors, report a github issue if it’s NOT caused by 429 errors, etc?? And also wonder whether this really needs a repair notice for missing forecast data that is 2 weeks out? Maybe the integration could log but not issue a repair notice unless the missing data is for a week away? Or maybe be more explicit in the repair notice that ‘Forecast data from 28/11/25 onwards is missing’ which would give the novice more idea whether to ignore it? Just feedback on real world receiving the message. Cheers |
Beta Was this translation helpful? Give feedback.
-
|
I will fix the "Learn more" link to point at the FAQ, @gcoan. |
Beta Was this translation helpful? Give feedback.
-
|
"Learn more" now links to a separate It won't work, but it's now a thing. |
Beta Was this translation helpful? Give feedback.
-
|
@gcoan, I am sick, so my head is apparently not able to find your comment regarding generation acquisition at exactly midnight and things being busy. v4.4.8 will carry an advanced option to shift this acquisition up to two hours after midnight, but as long as it is before estimated actuals acquisition. The doco states that this "before actuals" is not tested for, so don't go running with scissors while setting it.
|
Beta Was this translation helpful? Give feedback.
-
its here #380 (comment) thanks for implementing so quickly hope you've not got the same cold I've had all last week, a week doing nothing and still not 100% |
Beta Was this translation helpful? Give feedback.
-
|
The scissors have been confiscated in the playground, Geoff. Correlated validation of advanced options implemented so you can't stab yourself if tripping. If I had the same cold as you then people would talk. This'n's gone straight to my chest, and I'm talking a raspy octave lower. It's sexy apparently, despite me shedding viral bits everywhere. |
Beta Was this translation helpful? Give feedback.
-
v4.4.8 What's Changed?A small but "hefty-in-places" patch release.
API failure bolstering A recent 'Solcast API availability' incident (and the turmoil that ensued) highlighted the need for both proactive and reactive improvements. Most notable, is that when ten consecutive It may be called a "repair", but nothing about this situation is repairable. Do not try to repair that which is un-repairable. The best you can do is to report this to Solcast (respectfully, because you don't pay them). This issue will be removed once the API is again available, but you can ignore it if desired. Just don't personally ignore the instruction. Do nothing. If you don't press 'Ignore' then you'll know when things have returned to normal because this 'repair' will be removed. Move all cache and configuration files to There should be no impact felt from this change. The 👀 Writing a granular dampening file at the legacy location will work until 1 June 2026, and dampening files written there will be moved to the new config location automatically. A warning will be logged. We are not aware of any users writing to the If you have anything else called Ignore adjusted automated dampening factors above 'insignificant' threshold In prior releases any automated dampening "base" factor above 0.95 was ignored. Delta-logarithmic adjustment might then push a lower modelled base factor above 0.95. This change ensures that adjusted factors are similarly ignored when they exceed 0.95 after adjustment. (Advanced options are now available to allow modification of the thresholds.) Add more advanced options Additional advanced options have been added to enable tweaking of various aspects of automated dampening, estimated actuals, and more. If a "tweak" is generaly accepted as the right thing to do, then the default model parameters will be shifted, so keep experience reports coming in discussions. (To state the obvious, experiences shared must not be issue reports). To the above point, advanced options configuration has been moved to Attribute consistency as local time zone All Full Changelog: v4.4.7...v4.4.8 |
Beta Was this translation helpful? Give feedback.
-
|
Hi @autoSteve I just upgraded to 4.4.8, I did take a copy of all my solcast files first, and a HA backup given some people had had wobbles, but I shouldn't have worried, your code was rock solid and moved all the .json files (and left behind a solcast-generation.txt file I had created a while ago). Sites cache is checked, integration API's to solcast to download the sites file which I am slightly confused as to why it did it (but not overly perturbed): JSON files upgraded from v7 to v8 then the dampening process runs tomorrow's forecast times are worked out and then the bit that confuses me, it starts an estimated actuals run, making the API calls to Solcast to retrieve the estimated actuals. It confuses me that it makes these calls now not after midnight, and I am surprised that they even worked given I am out of API calls today. Here's those lines of the log: I had set an estimated actuals delay in the advanced options file, but only for 20 minutes: |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @autoSteve I didn't raise it as bug because I wasn't sure it was a bug, it just looked unexpected so I thought I would check whether this was expected behaviour. Great you found it so quickly, and what an edge case, restarting HA in the first 15 minutes of the hour. |
Beta Was this translation helpful? Give feedback.
-
|
Not when almost all of the I can't believe I missed spotting it so many times, because my prod instance has been restarted countless times recently. I must have restarted at < xx:15 at some point, and also missed any API exhaustion events. Yeah, life will go on for now. Your other query regarding getting sites from the API even when the cache exists is normal behaviour. Sites are always re-acquired on integration reload to check whether any Solcast config has been changed and update accordingly. The cache is only ever relied upon if Solcast cannot be reached. |
Beta Was this translation helpful? Give feedback.
-
Scratches head, wonders if estimated actuals is "free". Thinks will test later on with risk of API exhaustion... |
Beta Was this translation helpful? Give feedback.
-
|
Actually, I can't replicate this, @gcoan, so likely closing. If the estimated actuals have been updated for today then the actuals update will not be scheduled. The test for whether estimated actuals has been updated goes like this... Last updated must be equal to the time of last attempt, and the date today (in local time zone) must equal the date of last update. Yes, there is a bug in that the |
Beta Was this translation helpful? Give feedback.
-
I can't answer that. It should have updated as normal just after midnight, but going back in the HA logs (now viewable via the UI not in a txt file) is impossible because one of my smart plugs has gone 403 and HA is spamming its own logfile trying to connect to it repeatedly: And it does that over and over again, retrying the connection every second. The previous HA log shows activity from 19/11/25 to 20/11/25 So the bit inbetween which might have shown any problem is in the ether. Oh well, not a critical issue. I've already spent too long trying to find the log |
Beta Was this translation helpful? Give feedback.
-
v4.4.9 What's Changed?
Full Changelog: v4.4.8...v4.4.9 See the advanced options documentation for details about new options. Thanks for these additions, @Nilogax. And thanks for the new example chart, @gcoan, where dampened and undampened forcasts are drawn together. Several messages are now translated, most notably for exceptions to normal startup. Some fixes for minor bugs are also included. |
Beta Was this translation helpful? Give feedback.
-
|
@rcode6, you now have a median automated dampening model, thanks to @Nilogax implementing options for the advanced option |
Beta Was this translation helpful? Give feedback.
-
|
Gotta be quick... 
|
Beta Was this translation helpful? Give feedback.
-
|
🎅🏼🦌 🥳🎊 🕎✡️ Happy v4.4.10 What's Changed?
Zero length This catches situations where a cache file on reload is found to be zero length. These files are now deleted automatically, and the integration should complete startup successfully, but probably using more API calls than normal (which will almost certainly cause API quota exhaustion issues if a zero length cache is encountered). If the file noted is Restore this file from backup (if you have it) then reload, or decide to move on as is, with history lost. Report instances of this occuring in a discussion (we would like to hear about it happening, and explore the reason why), but please do not raise a code issue if it occurs. It was an issue for your install, which now automatically gets fixed; the integration cannot read a zero-length cache. Add granular dampening delta adjustment If doing roll-your-own granular dampening, then the same log/exp dampening adjustments can be applied to your factors too. You need to be acquiring estimated actuals for this to work. Advanced option rename, deprecation, error situations Some advanced options have been renamed, and these are flagged in issues raised in HA. When format/option issues occurred in the past the logs needed to be viewed to work out what had gone wrong. These issues are now called out instantly using Home Assistant issues raised in the GUI. Full Changelog: v4.4.9...v4.4.10 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Warning⚠️ 👀
If you are upgrading from a version earlier than v4.4.3, an issue will be raised in the Home Assistant interface on upgrade, saying that future forecast data is not available, yet should be. This is because the integration now fetches up to 14 days of forecast data.
Ignore this issue. Just click on the big "X" in the corner.
If you are prompted to turn on Automatic updates, but have your own automations running, just close the issue using the "X" in the corner.
The forecast will be updated in the near future on your next automation run, or the integration's own automatic update. When it updates, either on schedule or automatically that warning will disappear... You won't need to do anything in the UI. Just wait.
v4.4.1 What's changed?
Full Changelog: v4.4.0...v4.4.1
There were a couple of eye-twitches with auto-dampening. Most notably the selection of a single generation match for multiple "best" case intervals. This is now a majority, and I think it much more in keeping with the original design spec.
Generation sensors occasionally "go away", and this is now handled.
It's better.
There are automatic unit-of-measure adjustments. There are documentation improvements. There is a shiny new example thanks to @Nilogax.
Any and all feedback is most welcome.
Beta Was this translation helpful? Give feedback.
All reactions