Just looking for some clarification or explanation and maybe some examples of the different load types.
What does the “- treat_deferrable_load_as_semi_cont:” do, and what does it expect the load behaviour to be?
I thought semi-continuous might be like a washing machine, which has high and low power use phases during its usage cycle, but I feel like I might be wrong here . . .
Also any help in providing example to classify the following loads would be appreciated:
Reverse-Cycle Air-Conditioner - with variable loads during cycle
Dishwasher - load varies during the cycle
Washing Machine - load varies during the cycle
Heat Pump Hot water - load does not vary (but tricky to turn on and off due to compressor)
Resistive electric hot water - load does not vary
Zappi EV car charger - load can be variable and can be controlled dynamically
treat_def_as_semi_cont: Define if we should treat each deferrable load as a semi-continuous variable. Semi-continuous variables are variables that must take a value between their minimum and maximum or zero.
The semi continuous load is one that you can set a value for, from you list the best example would be the Zappi, where you can tell zappi exactly how much power to consume.
The other examples where power consumption may change over an normal operating cycle would not be considered semi continuous as you have no control.
However my air conditioner has a demand response input that can limit power to fixed values of maximum power consumption; 0%, 50%, 75% and 100%. So in that case I treat my air conditioner as semi continuous and I switch demand response modes to match the EMHASS forecast.
Is it correct that I only see the variable figures in the output table if I set this to false?
If I set it to true, it only populates the table if the the value is above the load Wattage with the loads setting ie. 2200W.
But you are saying you set the load as semi-continuous (TRUE) and then get data like 768W 900W etc etc .in order to fire the RCAC at certain thresholds.
Sorry for a long winded response, but I have been going around in circles with this and are finally seeing the data produces, but is opposite to what you had said. . .
Also, if it is semi continuous, then what Wattage do you use for your DRED RCAC in the:
So with the RCAC set as semi-continuous TRUE, then EMHASS is only publishing the load if it reaches the threshold of the set load for the RCAC at say 2200W. (There is no 960W or 1150W published).
So how are you triggering the different DRED Wattage levels if you are only getting a trigger from EMHASS at the full Watts of the RCAC?
Okay,
I think this is where my confusion is coming from as you said:
“However my air conditioner has a demand response input that can limit power to fixed values of maximum power consumption; 0%, 50%, 75% and 100%. So in that case I treat my air conditioner as semi continuous and I switch demand response modes to match the EMHASS forecast.”
So for my own information and clarity, is the AC set to false continuous or semi-continuous?
No worries, it is complex to setup but once it is working it is worth the effort.
See my AC forecasts here (in red) how it tracks down towards as the solar production reduces this afternoon and the the red forecast tracks back up tomorrow morning when my solar production increases.
I stole your Apex chart settings and have this interesting result.
Deferrable0 will be my RCAC.
I am set for self-consumption.
So the big spike in load power forecast in blue tomorrow - is that a base load prediction based on data from the last couple of days?
Also seeing the stepping of the RCAC tomorrow, as you noted. . . Thanks
Excellent, I can see you AC stepping down this afternoon and then stepping back up again tomorrow morning. I would recommend the use of notifications/ logging in your deferrable automation so you can understand in real time what it is doing.
The spike in your blue line would be something you ran today (maybe your AC), so EMHASS just assumes you will run the same amount and time tomorrow. The smarts is there you can see your AC drop to zero for that 30 minutes because it is expecting something else to be consuming at that time.
This naive model, just assuming base load will be the same pattern the following days is actually one of the limitations of Amber SmartShift (assume tomorrow will be the same pattern.) If your charge your EV one day because price is cheap that forecast load gets carried over to tomorrow. This gives reasonable results.
EMHASS can do better, you should take your deferrable loads out of the sensor recording no_var_loads, so your AC load from today shouldn’t be appearing in the blue spike, so check if you need to remove it. So the blue line baseload should never reflect the deferrable loads from the day before.
EMHASS also let’s you specify more that one days history so it can average out those spikes. Or you can also inject your own forecasts. I know @davidusb has also been working on an AI model for load forecasts.
Got it!!
I think the blue spike must have been the dryer, as that is no in my no_var_loads, whereas the aircon and dishwasher are. . …
I am happy with where I have made it to with the base settings of EMHASS, next is to look at automations to use the data.
I will also keep my eye on any AI or other predictive developments of the system.
I was with Amber but could not keep up with the variability of the pricing in what is the most volatile time in our energy history, not that I disagree with a little volatility in these times of change. . .
Thanks Again, I feel like I got somewhere today … . .
I will hopefully resume my work on AI based load forecast very soon and then release a version of the add-on with smarter forecasts. Maybe before the end of this year
Due to bad weather in Ballarat (it is supposed to be summer) I have seen an interesting plot today:
I have noticed today that my p_deferrable1 (Dishwasher) (purple line) is split in two start times.
This is set as 2000W for 1 Hour
I think I am correct in reading my graph as two half hour allocations with a 2.5hr gap in-between.
treat_deferrable_load_as_semi_cont: true
How would I set this to be a single continuous time period required?
set_def_constant: Define if we should set each deferrable load as a constant fixed value variable with just one startup for each optimization task.
You can see from your graphic that splitting would be useful for something like a water heater that could start/ stop during the day.
The set_def_constant is for something that should only startup once a day. Which would find the optimal 60 minute block to run your device.
Of course your dishwasher is unlikely to utilise the full 2000W for the full 60 minutes. Mine has two power spikes during it’s cycle when it’s heater is operating.
Is there any value in having system/mechanism that could “record” the exact load profile of the dishwasher, as per your example. As I know mine does the same, likewise with the washing machine on a hot wash?
I assume set_def_constant is only available from the command line. I am still working with the GUI at the moment. I will take a look . …
I would think you would hit diminishing returns in trying to model it too finely. There are other variables like PV and your household baseload that will also vary, so I view EMHASS as always getting a pretty good, but not perfect optimisation.
I assume set_def_constant is only available from the command line. I am still working with the GUI at the moment. I will take a look . …
I haven’t actually used it, but you maybe able to set from the GUI if you edit in YAML mode?
