Standalone and Add-on merge #334
Conversation
|
|
I am currently unsure how we should approach the parameter naming conventions moving forward. |
|
It would be probably best to change the code to match the options.json, those names are way more explicit |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| @@ -484,8 +363,8 @@ | |||
| # Launch server | |||
| port = int(os.environ.get('PORT', 5000)) | |||
| app.logger.info("Launching the emhass webserver at: http://"+web_ui_url+":"+str(port)) | |||
| app.logger.info("Home Assistant data fetch will be performed using url: "+hass_url) | |||
| app.logger.info("Home Assistant data fetch will be performed using url: "+params_secrets['hass_url']) | |||
Check failure
Code scanning / CodeQL
Clear-text logging of sensitive information High
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
| with emhass_conf['associations_path'].open('r') as data: | ||
| associations = list(csv.reader(data, delimiter=",")) | ||
| else: | ||
| logger.error("Cant find associations file (associations.csv) in: " + str(emhass_conf['associations_path'])) |
Check failure
Code scanning / CodeQL
Clear-text logging of sensitive information High
This comment was marked as outdated.
This comment was marked as outdated.
|
This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation. |
| document.getElementById("config-box").innerHTML = JSON.stringify( | ||
| config, | ||
| null, | ||
| 2 | ||
| ); |
Check warning
Code scanning / CodeQL
DOM text reinterpreted as HTML Medium
|
The hope is to do some testing then create a video tomorrow showing the progress and how this PR works. |
|
Amazing! Let me know if you need any clarification on anything, or need me to fix something. 👍 |
Ok will do 👍 A quick first question: on the add-on repo all github workflows are commented out. So this is normal since all will be dealed here in the main EMHASS code repo right? |
Yep, that is correct. 👍 |
|
Ok, released a new version. |
Copy information for adding a parameter from PR davidusb-geek#334 davidusb-geek#334 (comment)
I seem to be missing the upgrade step. I took my existing 0.10.6 and upgraded to 0.11.0, but wasn't offered an opportunity to bring across my old configuration and then was running 0.11.0 with a 'default' configuration. Rolling back to by backup on 0.10.6 was successful and has restarted with my working config. |
|
I will continue to report my experiences here, but let me know if these would be better to raise as issues. I have now manually taken my YAML config from 0.10.6 and copy/ converted to 0.11.0, which seems to convert correctly. There is a hard coded reference to sensor_power_photovoltaics (in the replace NAN values), but I have changed by sensor entity to sensor.apf_generation_entity, which then causes an error.
When I updated the replace NAN values with my updated entity, I could go to the next stage. |
Yes it is a manual conversion of the configuration file, is not automatic. |
Ah yes, because |
No unfortunately not, I haven't been able to get a stable optimisation. When I call my MPC optimisation the call times out. As does the day ahead optimisation. I'm going to try and simplify my. MPC call to see if I can start with something functional. |
Feel free to send the logs over if you find anything and I'll look Into it. If you could also uninstall the add-on and re-install to see if that changes anything. I'm guessing not but it might be a weird cache issue? |
|
Im looking into this issue now. |
|
Sorry to bug you gain @purcell-lab , while I'm fixing the other bugs, are there any logs I can observe for your issues? |
|
Hi, ive migrated my config across and it runs in the UI. Like @purcell-lab I am using the script to publish my Solcast, price and battery data from HA into EMHASS. My first note is that my battery used to be sent as 51% as "0.51". Its seems to now be expecting "51". So I updated that.. But now its publishing "5105.23" back, so there seems to be a multiplier issue. I am getting very abnormal results elsewhere as well, but i am going to start with Battery SOC. Kel.
I`ll keep digging later, got to get back to "actual work", but the UI is a great step in the right direction. The solar/inverter would be great as a searchable selector/dropdown as people find the underscore stuff confusing. FYI this is my shell command The EMHASS Logs are here: UPDATE: this was on version v0.11.0 |
|
i also fiddled with settings.
Log: |
|
Upgraded to v0.11.1. Still not having joy. The REST post timeouts for me, I have extended timeout to 120 seconds.
Unfortunately the logs don't provide much context: {
"battery_charge_efficiency": 0.95,
"battery_charge_power_max": 11000,
"battery_discharge_efficiency": 0.95,
"battery_discharge_power_max": 15000,
"battery_dynamic_max": 0.9,
"battery_dynamic_min": -0.9,
"battery_maximum_state_of_charge": 1,
"battery_minimum_state_of_charge": 0,
"battery_nominal_energy_capacity": 40500,
"battery_target_state_of_charge": 0.1,
"compute_curtailment": true,
"continual_publish": false,
"costfun": "profit",
"delta_forecast_daily": 2,
"end_timesteps_of_each_deferrable_load": [
0,
0,
0,
0,
0,
0
],
"historic_days_to_retrieve": 2,
"inverter_is_hybrid": false,
"load_cost_forecast_method": "hp_hc_periods",
"load_forecast_method": "naive",
"load_negative": false,
"load_offpeak_hours_cost": 0.09,
"load_peak_hour_periods": {
"period_hp_1": [
{
"start": "02:54"
},
{
"end": "15:24"
}
],
"period_hp_2": [
{
"start": "17:24"
},
{
"end": "20:24"
}
]
},
"load_peak_hours_cost": 0.31,
"logging_level": "INFO",
"lp_solver": "COIN_CMD",
"lp_solver_path": "/usr/bin/cbc",
"maximum_power_from_grid": 50000,
"maximum_power_to_grid": 30000,
"method_ts_round": "first",
"modules_per_string": [
29,
21
],
"nominal_power_of_deferrable_loads": [
1340,
5000,
11500,
4000,
600,
11500
],
"number_of_deferrable_loads": 6,
"operating_hours_of_each_deferrable_load": [
4,
2,
0,
0,
3,
0
],
"optimization_time_step": 30,
"photovoltaic_production_sell_price": 0.05,
"production_price_forecast_method": "constant",
"pv_inverter_model": [
"SolarEdge_Technologies_Ltd___SE7600A_US__208V_",
"SolarEdge_Technologies_Ltd___SE7600A_US__208V_"
],
"pv_module_model": [
"Advance_Power_API_M370",
"Advance_Power_API_M370"
],
"sensor_linear_interp": [
"sensor.apf_generation_entity",
"sensor.power_load_no_var_loads"
],
"sensor_power_load_no_var_loads": "sensor.power_load_no_var_loads",
"sensor_power_photovoltaics": "sensor.apf_generation_entity",
"sensor_replace_zero": [
"sensor.apf_generation_entity",
"sensor.power_load_no_var_loads"
],
"set_battery_dynamic": true,
"set_deferrable_load_single_constant": [
false,
false,
false,
false,
false,
false
],
"set_deferrable_startup_penalty": [
5,
1,
0,
1,
10,
0
],
"set_nocharge_from_grid": false,
"set_nodischarge_to_grid": false,
"set_total_pv_sell": false,
"set_use_battery": true,
"set_zero_min": true,
"start_timesteps_of_each_deferrable_load": [
0,
0,
0,
0,
0,
0
],
"strings_per_inverter": [
1,
1
],
"surface_azimuth": [
90,
270
],
"surface_tilt": [
18,
10
],
"treat_deferrable_load_as_semi_cont": [
true,
true,
false,
false,
true,
false
],
"weather_forecast_method": "scrapper",
"weight_battery_charge": 1,
"weight_battery_discharge": 0.05
} |
|
Thanks @kcoffau & @purcell-lab , I'll have a look at this and see if I can find anything. It may get out of the realm for me to fix (depending on where the issue/s resides). So I may need @davidusb-geek 's help. But I'll let you know after I have a look. |
|
@purcell-lab , It looks like the optimization is being stuck after the last Validated window. I'm not quite sure why. Any ideas @davidusb-geek ? It looks like a battery problem. ( Using Marks config above. P.s. Ill be revisiting the runtime parameters soon from this PR. I believe there are defiantly places I can fix up. |
Unfortunately no idea for now, this will need debugging |
|
Is the documentation for 0.10.6 still available, as a number of the variables are changed I still need access to the previous documentation. On a site with 0.10.6 installed the documentation link goes to the latest version, which of course is now 0.11.1, which isn't relevant. |
It would also be great to get more debugging info as the various states are processed, so we can see where the system need attention. |
|
I'll have a relook at your issue @purcell-lab likely today with 0.11.2 to see if the issue still persists. |
In read the docs, there is a option to select version. So there may be a way for us to set like a 0.10.6 tag/snapshot. For now you can view the GitHub version snapshots: https://github.com/davidusb-geek/emhass/tree/v0.10.6 https://github.com/davidusb-geek/emhass-add-on/tree/v0.10.6 And also the docs page: https://emhass.readthedocs.io/en/latest/differences.html#legacy-parameter-definitions |
|
Looks like the issue still persists with @purcell-lab 's config. I believe its something to do with the battery, I'll do some searching. Unable to find the fault so far. |
|
ive compared our config: I note the following differences (that just arent general settings)
"battery_minimum_state_of_charge": 0,
"set_battery_dynamic": true,"
"weight_battery_charge": 1,"
Ohh, and your SOC_final in your CURL is also 1. Did you want to troubleshoot with a 0.99? Otherwise your config looks within reason the same as mine, +/- inverter/grid/solar settings. |
Thanks @kcoffau this is great. Seems like there are some bugs when it comes to the battery optimization. |
Related to #269