Thanks a lot! It works perfectly : ) Now I’ll try to use that future prices to trigger an automation to load my battery from grid. If you’ve done stuff like that I would appreciate a call 
I have some automations to charge my PV battery based on Nordpool data (so essentially the same as this). If you want to exchange some notes let me know.
Hey, I started with north pool also, but I was not in the mood to figure out how to do the tax-math for german prices. This one here has the tax included, but both integrations are fine!
At the moment I’m stuck at the definition of some smart triggers, which switch my sungrow EMS mode like this:
action:
- service: modbus.write_register
data:
address: 13049
slave: !secret sungrow_modbus_slave
value: 2
hub: SungrowSHx
alias: Set EMS mode to 'Forced mode'
- service: modbus.write_register
data:
address: 13050
slave: !secret sungrow_modbus_slave
value: 170
hub: SungrowSHx
alias: Set forced mode to 'Forced Charge'
- delay:
hours: 1
minutes: 0
seconds: 0
milliseconds: 0
- service: modbus.write_register
data:
address: 13049
slave: !secret sungrow_modbus_slave
value: 0
hub: SungrowSHx
alias: Set EMS mode back to 'Self-consumption mode'
- service: modbus.write_register
data:
address: 13050
slave: !secret sungrow_modbus_slave
value: 240
hub: SungrowSHx
alias: Set forced mode back to 'Stop (default)'
The action works like a charm. Thanks to GitHub - mkaiser/Sungrow-SHx-Inverter-Modbus-Home-Assistant: Sungrow SH Integration for Home Assistant for SH3.6RS, SH4.6RS, SH5.0RS, SH5.0RT, SH6.0RS, SH8.0RT, SH6.0RT, SH10RT !
If you wnt to share parts of your work, I would love it!
I am running a Huawei system and that has a pretty good Home Assistant integration, so I can work with force charge to SoC.
What I do is, I define a target SoC based on the battery capacity (10) minus the solar forecast from solcast. That means there is always enough capacity left in the battery for solar charging and the grid charge just tops it off. My solution isn’t very clever yet, because it doesn’t take into account how much electricity will still be used from the time of grid Charge to the beginning of solar yield…but it’s a start and seems to be working OK so far apart from a few occasional glitches due to Solcast “forgetting” the forecast.
It is still very much work in progress though and still needs many optimisations. My threshold for “cheap” electricity is below 80% of the average price and I use a “sliding” scale that looks at all the prices it can “see” for today and tomorrow.
alias: Huawei Autocharge On
description: ""
trigger:
- platform: time_pattern
minutes: "1"
condition:
- condition: template
value_template: |-
{{(states('binary_sensor.strom_billig') ==
"on")}}
enabled: true
- condition: template
value_template: |-
{{(states('sensor.charge_required')|float(0) >
states('sensor.battery_state_of_capacity')|float(0) +10)}}
- condition: time
after: "00:00:00"
- condition: sun
before: sunset
action:
- service: script.grid_charge_on
data: {}
mode: single
alias: Huawei Autocharge Tomorrow
description: ""
trigger:
- platform: time_pattern
minutes: "1"
condition:
- condition: template
value_template: |-
{{(states('binary_sensor.strom_billig') ==
"on")}}
enabled: true
- condition: template
value_template: |-
{{(states('sensor.charge_required_tomorrow')|float(0) >
states('sensor.battery_state_of_capacity')|float(0) +10)}}
- condition: sun
after: sunset
- condition: time
before: "00:00:00"
action:
- service: script.grid_charge_on_tomorrow
data: {}
mode: single
alias: Huawei Autocharge Off
description: ""
trigger:
- platform: state
entity_id:
- binary_sensor.strom_billig
from: "on"
to: "off"
- platform: template
value_template: |-
platform: template
value_template: >-
{{(states('sensor.battery_state_of_capacity')|float(0) >
states('sensor.charge_required')|float(0))}}
enabled: true
enabled: true
condition: []
action:
- delay:
hours: 0
minutes: 3
seconds: 0
milliseconds: 0
- service: script.grid_charge_off
data: {}
mode: single
alias: Grid Charge Off
sequence:
- service: huawei_solar.stop_forcible_charge
data:
device_id: b4ab4f4796f3b4ebc83c4137855528d9
- delay:
hours: 0
minutes: 1
seconds: 0
milliseconds: 0
- type: turn_off
device_id: b4ab4f4796f3b4ebc83c4137855528d9
entity_id: switch.battery_charge_from_grid
domain: switch
mode: single
alias: Grid Charge On
sequence:
- type: turn_on
device_id: b4ab4f4796f3b4ebc83c4137855528d9
entity_id: switch.battery_charge_from_grid
domain: switch
enabled: true
- delay:
hours: 0
minutes: 10
seconds: 30
milliseconds: 0
enabled: false
- service: huawei_solar.forcible_charge_soc
data:
device_id: b4ab4f4796f3b4ebc83c4137855528d9
power: "3000"
target_soc: "{{states('sensor.charge_required')|float(0)|round(0) }}"
mode: single
alias: Grid Charge On Tomorrow
sequence:
- type: turn_on
device_id: b4ab4f4796f3b4ebc83c4137855528d9
entity_id: switch.battery_charge_from_grid
domain: switch
enabled: true
- delay:
hours: 0
minutes: 10
seconds: 30
milliseconds: 0
enabled: false
- service: huawei_solar.forcible_charge_soc
data:
device_id: b4ab4f4796f3b4ebc83c4137855528d9
power: "3000"
target_soc: "{{states('sensor.charge_required_tomorrow')|float(0)|round(0) }}"
mode: single
This is in the Configuration.yaml
Binary Sensors and a regular “sensor” for the required charge
template:
- binary_sensor:
- name: "Strom Teuer"
state: "{{ states('sensor.strompreise') == 'EXPENSIVE' or states('sensor.strompreise') == 'VERY_EXPENSIVE' or states('sensor.strompreise') == 'EXTREMELY_EXPENSIVE' }}"
- name: "Strom Billig"
state: "{{ states('sensor.strompreise') == 'VERY_CHEAP' or states('sensor.strompreise') == 'CHEAP' }}"
- name: "Charge_Required"
state: >-
{{ ([0, 10 * (10 - states("sensor.solcast_forecast_remaining_today")|float(0)), 100]|sort)[1] |round(0) }}
- name: "Charge_Required_Tomorrow"
state: >-
{{ ([0, 10 * (10 - states("sensor.solcast_forecast_tomorrow")|float(0)), 100]|sort)[1] |round(0) }}
1 Like
This looks pretty well designed and it’s more than a start in my opinion. I’ll try to transalte that to my sungrow setup and let you know, if I was able to implement a condition, that takes the expected load into account (at least the big ones like an EV or a heater).
Did you sign up at solcast at the time 50 API requests were standard? I hope that 10 requests / 24 h (what is normal for a new account today) will be enough…how often did the price level switch a day?
Anyway there is a lot to do for the next days 
1 Like
I have the standard Solcast “free” API and no trouble with the limit. It doesn’t refresh that often.
Edit: I found some minor mistakes in my automations that I have now (hopefully) fixed. I will try to edit my post above later with the fixes.
I think I corrected the worst mistake in above automations.
One additional thing I had to do was make a new Automation to force-update Solcast at Midnight so that the switchover from “Today” to “Tomorrow” actually works. Not sure why that is needed, but it wasn’t working on it’s own, so I implemented that. Now I will keep an eye on it again and see how things progress.
The “10:30” Delay I have in my scripts is specific to the Huawei integration since “Grid Charge” On/Off somehow takes a long time to actually swtich, but I have it deactivated at the moment running some tests. Since you are using a different system you should probalb yjust ignore it completely.
1 Like
Happened today for me again, rebooted ha and it was back, i wonder if one could build some “automation” to restart integration, every day, after “bidding time ended”, it seems like it’s at noon, it “drops” tomorrows prices
1 Like
You can create an automation to run every time the entity is unavailable for more than X minutes, or around 13:30…
Just call the service homeassistant.reload_config_entry and that will force the integration to be reloaded.
1 Like
i will look into it, thou the thing is, the sensor is there, and it gets “updated” around midnight, so “tomorrows values”, turns to “today” ( and tomorrows then shows “tomorrow_valid: false” ) … then around 13.30 nothing happens (sometime), even thou i restarted HA few times, first after i Rebooted the ha-host, it “updated” so it gets “new” tomorrow-values" … not sure what reload_config_entry does, but i’ll see whati can figure out
Are you talking about Tibber integration, about NordPool integration or about some other rest sensor?
Tibber Data, custom integration
GitHub - Danielhiversen/home_assistant_tibber_data: Display Tibber data sensors. … as of now i actually got 3 “Tibber integrations” … Tibber-native, tibber_custom and tibber_data … i also wondered whether this could cause some “interference” , thou it shouldn’t in my oppinion.
It’s the “sensor.energy_price_xxxxmyxxxxaddress” — so it’s not the "sensor_electricity_xxx from native tibber, nor "camera_xxxxmyxxxxaddress from tibber-custom 
File “/usr/src/homeassistant/homeassistant/components/homeassistant/init.py”, line 262, in async_handle_reload_config_entry
raise ValueError(“There were no matching config entries to reload”)
ValueError: There were no matching config entries to reload
i went to /dev_tools/services found the service " homeassistant.reload_config_entry " choosed the sensor.energy_xxx_xxx , so apperently it can’t just reload a “sensor” , how do i specify an “integration” ?
It shouldn’t be an issue, although this will probably increase the number of calls to their API which could be an issue if they have a limited number of calls, which I’m not sure if is the case for Tibber.
Anyways, the data changes only once a day, so I wouldn’t expect too many calls from each of those integrations.
Why don’t you report the original problem (sensor becoming unavailable?) on their repository? I got an impression that @Danielhiversen is quite good on responding to issues on the interface).
This is the link for reporting issues:
Well the “topic/issue” just popped up in my head, when i saw Zinken’s issue ( which most likely is not the same ) .
This, for me “experience” only happened twice now, so i really haven’t “investigated” it , atleast not enough to report it as an issue, could be delays in the “tomorrows-price” deliverance, could be other reasons … as mentioned when i rebooted HA, then "tomorrows-price"was there, so it could be something in my installation causing an inconsistent behavior
True, my goal is to eventually skip those integrations i don’t “need” , still can’t decide whether i should buy the “Tibber-Pulse” as i still haven’t got “convinced” about Tibber, in the Mobile-App you have a pretty good “overview”, and statistics etc, BUT that’s on a F… mobile-phone, how funny is that for a household maintenance/budget keeping ? , on their web you basically can’t see a S… , so if Tibber ( Daniel ) wants to “expand/sell more” they should present better descriptions on their website, in regards to how the Web-UI looks like with a Tibber-Pulse, because I and many many others, old people etc. etc. is absolute no fan of mobile apps, and fingering with this little f… invention 
. And from a customer (logged in ) perspective, Tibbers Website sucks , they (support ) direct you to the mobile app … that’s just a big joke, from a customer perspective ( Hope you read this Daniel
I am currently using Nordpool for m Apex Chart 48hour overview…can this also be done using the HA Core Tibber integration directly?
No the core tibber integration doesn’t have future prices. Custom integration tibber_data have them similar to Nordpool
1 Like
I can’t find it in tibber_data , what is that sensor called?
sensor.energy_price_***
ending with my home address. In the attributes of that sensor is both today and tomorrow prices.
But that’s not from Tibber data, that’s from the regular integration. Does it contain future data?