Hourly damping factor not work?

[erepeo]

Hello, I want to report that after the update, I’m no longer able to enable the hourly damping factor :-( Is this happening only to me?

[BJReplay]

@erepeo, Yes.

Well, actually, I don't know.

I had 1/2 hourly granular dampening factors set up in a file, mainly for testing purposes, and I just cleared them, and then I just set hourly dampening factors using the configuration flow.

So you are going to have to provide a lot more information if anyone is going to be able to help you.

Debugging logs as per #38.

Screen shots of any errors that you see.

A description of the problem that you have.

If you do all that, raise an issue, please.

[autoSteve]

I cleared granular dampening, opened config in the UI, modified the midnight to 0.5, saved. Opened options, damp for that hour set to 0.5. Opened config again, set it back to 1.0. All worked.

I opened dev. tools, actions. This:

action: solcast_solar.set_dampening
data:
  damp_factor: 0.5,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1

Executed and saw the green tick. Went into options and saw that the 0.5 had been set.

🤷‍♂️ @erepeo.

From which original version to v4.2.4? Environment? What does "no longer able" actually mean? (Morally able? 😂) Do the values appear to be changed, yet do not get applied to forecast data? Have you transitioned from v4.1.x to v4.2.x? (A change was made to historical data where dampening would appear to reset to no dampening, with future dampened values eventually getting recorded as the history. This is in the readme and was in the release note when that change happened.)

[erepeo]

I have version 4.2.4.
I'm trying to set up dumping factor in the GUI (not in the configuration.yaml file). I check the box to "yes," then I enter the parameters and click "submit." When I go back to check if the changes were saved, the checkbox is unchecked.
I'm not very proficient with these things. I’m happy to provide any information you ask for, but I would need to know exactly what I should check. At the moment, dumping factor is not working, but it was working before. I also don’t see the option for dumping factor every 0.5 hours anymore.

[BJReplay]

I have version 4.2.4.

Thanks

I'm trying to set up dumping factor in the GUI (not in the configuration.yaml file).

So you would have set some factors something like this - but presumably not zero in the middle of the day:

I check the box to "yes," then I enter the parameters and click "submit."

You should have seen a success dialog:

When I go back to check if the changes were saved, the checkbox is unchecked.

That is expected behaviour - the check box is only checked by you if you want to update them again

I'm not very proficient with these things. I’m happy to provide any information you ask for, but I would need to know exactly what I should check. At the moment, dumping factor is not working, but it was working before.

How do you know? Are you saying that the forecast is undamped, or based on what you wrote above?

The forecast is only dampened for future forecasts: this is the result of the dampening above - but for tomorrow's forecast:

What version did you upgrade from?

Due to a bug in the HA front end, @autoSteve had to change the configuration dialogs some time ago, but if you were running an old version, it looks different, but that does not mean that it is not working.

I also don’t see the option for dumping factor every 0.5 hours anymore.

You never have been able to set that up through the configuration dialog - please read the readme.

[erepeo]

Ah, so after "finish" appears and I leave, and then come back, the checkbox is unchecked again? Previously, it was always checked, and based on that I concluded that something was broken. If that's the case, I apologize.

I did read the readme. My English isn't good, and translators don't always translate accurately. I wasn't claiming that setting every 0.5h has to be available in the GUI, I was just wondering if it might be available, but something was wrong on my side. The translation probably messed up what I meant ;)

Anyway, in my opinion, changes to the dumping factor should take effect today, not tomorrow. They may not affect yesterday, but they should affect today. Why? Because it's easier to adjust the values while observing the situation during the day. Based on what’s currently being produced, you can adjust the forecast, and there's a chance it will be more accurate in the future. When you set it for tomorrow, you can't see anything. You're doing it blindly, and the whole process may take many days before you find the right setting. In the previous version, this was better.

Thank you very much for your help, and I hope you understand that my English is very weak. I don't have bad intentions; it's just that the translation might sometimes miss the mark.

[autoSteve]

factor should take effect today, not tomorrow

1. What I hope you mean, and you probably mean...

If by this you mean that dampening of future values from now should be re-applied at exactly the moment that dampening values are set, then I completely agree with you.

I believe that these are only applied on forecast fetch, so there will be a (potentially great) lag to see the influence.

I am going to take it that this is what you really meant, because it is something that really should be fixed. Thanks for pointing it out.

translation

On translations, you don't do Urdu do you?

factor should take effect today, not tomorrow

2. What I hope you do not mean...

A contentious point, "today" versus "tomorrow", and this may be a mis-translation induced response to that, so if this all sounds weird ignore it.

The change to dampening in v4.2.0 means that the integration only applies it to future values received from Solcast, and not for values before "now". We do not re-write history from this version on. Nor should we. (The integration used to, which greatly skewed the historical view when factors changed, and annoyed me and others.)

The word "should" is an interesting one to use, as people will have differring opinions about re-writing history. For example, @BJReplay may disagree with me on this (but probably not) I am not a fan of re-writing any history.

It could be argued that "today" is different from "history", and that we should re-write recent history. But I am not a fan of that either.

Those with automations to determine the level of dampening to apply for a period will almost certainly be getting un-dampened history via an HA action (or they should be), and comparing that to actual outcomes in the past to influence the future. Any dampening set will not impact that decision making because using the un-dampened data.

[autoSteve]

Oh, and on 30-minute periods in the GUI I would say that would not be implemented. Having hourly in configuration is of limited use.

Some, like @BJReplay apply manual dampening of zero in the GUI for hours when the sun is not shining to avoid weird issues. (He should really be using a dampen to zero automation based on sunrise/sunset to call the dampening action, though, shouldn't you, BJ? 😂)

[autoSteve]

Why do you do that, mate? (Reactions: 🤣)

[BJReplay]

Well, I sort of agree 👍, but, then thinking about it, I would have to add time to sunset and subtract from sunrise to make sure that I didn't dampen when the sun was up so 👎, and that made me smile, so 😀, and since I had been drinking🍻, well, one thing led to another.

[autoSteve]

Gotta get the eyes in... It's thing now.

[BJReplay]

For example, @BJReplay may disagree with me on this (but probably not) I am not a fan of re-writing any history.

Not. I am, in general a fan of George Orwell's writing, if not the rest of his lived experience.

[BJReplay]

Previously, it was always checked

I don't think so, but as we say in Australia "No Worries" and hopefully that translates.

[erepeo]

In my opinion, the forecast should change immediately when I set the dumping factor, not only when data is fetched from the Solcast server. It should change for "today" and the future. It should not change "yesterday" and the past. Why? Because the dumping factor can change throughout the year, especially if someone has panels set at an unfavorable angle, and changing this in September would affect what happened in May.

[BJReplay]

In my opinion, the forecast should change immediately when I set the dumping factor, not only when data is fetched from the Solcast server.

It doesn't happen immediately, unfortunately, only for the next forecast fetch.

It might be possible to change the most recently fetched forecast so that what you see is updated, but that's more work, that a developer has to do. It is beyond my current skills.

But most people who use dampening use it by either:

• setting it programmatically so it is set automatically based on an algorithm, or
• setting it up once

Now that we've answered your original query, I'm going to close this conversation.

[BJReplay]

@autoSteve has already noted that it would be great if the new factors were applied once set, and if he has time and inclination, he might decide to do it. Thanks for the suggestion.

[erepeo]

Of course. Taking this opportunity, I want to thank you for your responses now as well as for the work on this solution. I really appreciate that the Author and his colleagues dedicate their time to such a great cause. Wishing you all the best!

[autoSteve]

Immediate application of dampening from "now" onwards has been the subject of this evening. It is almost baked. I'm ironing out the kinks in testing as I write...

[autoSteve]

Correction. Fully baked. Committed. Awaiting daylight hours real-life scenario testing...

[BJReplay]

Created issue to track fix about to be released in v4.2.5

[autoSteve]

@erepeo, of which language do you speak, out of interest?

I may regret this question, because Urdu, but a load of integration strings can be translated into any language as is set in Home Assistant...

A translation could be added for your native tongue. (You could add it via a pull request, or if unable I could give it a go...)

[erepeo]

Szanowny Kolego - jestem z Polski ;-)
Nie mam problemu z tłumaczeniem dodatku Solcast. Miałem na myśli naszą rozmowę xD

[autoSteve]

W takim razie dla Ciebie mamy już przetłumaczoną integrację!

Informacje zwrotne dotyczące błędów będą mile widziane.

[erepeo]

I'd be happy to help. Can you show me step by step how I can submit translation corrections?

[BJReplay]

If you're familiar with Github, you'd submit a pull request, but looking at your github history, I don't think you are which is why you're asking- but if this is a new ID, and you're already familiar, then fork this repo, make your edits, and submit a pull request.

To make a fork, click on the Fork button at the top of the page when you're viewing the repository (mine is greyed out as I can't fork my own repository)

Once you've forked it, you can start editing your own changes in your own copy.

Edit away, and when you're ready, click on Commit Changes

It will ask you if you want to save directly, or create a new branch and start a pull request - this is what you want to do:

Once you're ready, you should have a pull request which you can submit, which will submit the changes back to this repository - and you'll be a contributor for the next release and a most valued user!

If you'd prefer to avoid all of that, simply make a copy of https://github.com/BJReplay/ha-solcast-solar/blob/main/custom_components/solcast_solar/translations/pl.json, edit the incorrect translations in your favourite text editor, and attach the corrected version to a new issue or a new discussion, and we will pick it up, check that it is correctly formatted, and release it.

[BJReplay]

Nie mam problemu z tłumaczeniem dodatku Solcast. Miałem na myśli naszą rozmowę xD

If you're using Microsoft Edge (and probably other browsers), there's a right click option to translate:

Yours should show Polish (in Polish, of course 🤣)

Once you've translated, there's an icon in the address bar, and you can revert to the original, if you want:

[autoSteve]

Once the branch is created, switch your repo to that branch to continue making more commits for the same PR. The PR will update automagically with subsequent commits. (Thanks @BJReplay.)

[erepeo]

This made me laugh: "Yours should show Polish (in Polish, of course 🤣)"
;)
Below I am posting the file with minor corrections.

pl.json

[BJReplay]

This made me laugh: "Yours should show Polish (in Polish, of course 🤣)"

I could have attempted to machine-translate it - and got it wrong, or chosen to just use english.

Je parle un peu francais.

Parlo solo un po' di italiano.

@autoSteve do you want to grab this and roll this into the current PR, or are you happy for me to merge this straight into the current release?

Which will cause you less grief?

[BJReplay]

Note @autoSteve there are some quote escaping issues in the file provided by @erepeo which I've just spotted - I'm working through and will re-attach here once I've checked through the rest of the file.

[autoSteve]

GitHub scared you off, did it @erepeo? 😂 It can be a bit of a learning curve to ensure you don't mess up. I still do occasionally!

Pulling it in to the v4.2.5 proposal would be my preference @BJReplay, crediting @erepeo of course.

[BJReplay]

See attached.

pl.json

Just one change:

From (which VS Code handily red-squiggle-underlined for me - note the embedded quotes in the string)

"config_damp": "Zmodyfikuj godzinowe współczynniki tłumienia (po kliknięciu przycisku "ZATWIERDŹ")",

Which I first edited to

"config_damp": "Zmodyfikuj godzinowe współczynniki tłumienia (po kliknięciu przycisku \"ZATWIERDŹ\")",

But then, while reviewing the rest of the file, found some other quoted strings, so changed it to.

"config_damp": "Zmodyfikuj godzinowe współczynniki tłumienia (po kliknięciu przycisku „ZATWIERDŹ”)",

Google seems to thing it is OK.

[erepeo]

Oh yes, GitHub is beyond me, but if I managed to help, I'm very happy.
I only used quotes once - I didn't know they weren't allowed.

[autoSteve]

Looks like Polish to me.

Merged with the changes for v4.2.5 (which you would approve of, @erepeo) and committed. The changes were to specify the units for twardy limit as kilowaty, and add an additional twardy limit translation key.

            "hard_limit": {"name": "Ustawiony twardy limit"},
            "hard_limit_api": {"name": "Ustawiony twardy limit {api_key}"}

I cannot imagine what some kind soul could do for my Urdu...

[erepeo]

Glad to help with the Polish twist! 😄 As for Urdu… let's just say I'll leave that to a truly kind soul. Thanks for merging – looks great!