Comments (43)
from ha_sonnenbatterie.
The underlying API =>(https://github.com/weltmeyer/python_sonnenbatterie) now has some new features to SET options to the sonnenbatterie, thanks to @atimgraves , but i currently dont have the time to add these features to ha_sonnenbatterie.
from ha_sonnenbatterie.
Just check the tests. OperationMode for example: https://github.com/weltmeyer/python_sonnenbatterie/blob/master/test/test_operating_mode.py
from ha_sonnenbatterie.
That's really cool when those control features of the API go into the integration!
For the moment I use the above rest_command setup for setting modes and charging values on my Sonnenbatterie. In addition to the examples above note that you can also parametrise a rest_command. This is the way how I can control the amount of loading watts from an automation by setting {{ power }} as parameter from my calculating sensor:start_sonnenbatterie_charging: url: "http://<SONNENBATTERIE_IP>/api/v2/setpoint/charge/{{ power }}" method: post headers: Auth-Token: !secret sonnenbatterie_token
I would love to pick your brains on the various attributes and what they actually do and represent. Eg {{power}} is that the total power you want to put into the battery, or is it the charge rate of the power going in etc...I've never found Sonnens charge settings very easy to grasp...
yep: {{ power }} in this case is the current rate of electrical work in watt and not a total amount of energy in Wh or kWh.
from ha_sonnenbatterie.
The REST integration should be loaded automatically by HomeAssistant once you've put the rest_command:
section either directly in your configuration.yaml
or in a separate file (for example rest_commands.yaml
) that is loaded from configuration.yaml
using the rest_command: !include rest_commands.yaml
statement.
Referencing in automations is done by using the full name which is a combination of rest_command
and the name you gave the command itself. So using my example above it would be rest_command.sonnenbatterie_start_charging
for the command to start charging.
My YAML code for the automation to start charging looks like this:
alias: "[Test] Battery -> Charge"
description: ""
trigger:
- platform: state
entity_id:
- input_boolean.test_batterie_mode
condition:
- condition: state
entity_id: input_boolean.test_batterie_mode
state: "on"
action:
- service: rest_command.sonnenbatterie_set_manual_mode
data: {}
- service: rest_command.sonnenbatterie_start_charging
data: {}
mode: single
Note that you need to set the battery to manual mode before you can start charging.
Likewise, to get back to automatic mode I use:
alias: "[Tst] Battery -> Auto"
description: ""
trigger:
- platform: state
entity_id:
- input_boolean.test_batterie_mode
condition:
- condition: state
entity_id: input_boolean.test_batterie_mode
state: "off"
action:
- service: rest_command.sonnenbatterie_stop_charging
data: {}
- service: rest_command.sonnenbatterie_set_automatic_mode
data: {}
mode: single
Again, the battery has to stop charging before it can be switched back to automatic mode.
Since I don't know whether you're comfortable with creating automations in YAML, here's what they both look like in the visual editor:
![Bildschirmfoto 2023-12-02 um 20 24 41](https://private-user-images.githubusercontent.com/1085162/287470513-57c38924-77f7-4043-a8e3-7a4cc18131be.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQyMTYxOTIsIm5iZiI6MTcyNDIxNTg5MiwicGF0aCI6Ii8xMDg1MTYyLzI4NzQ3MDUxMy01N2MzODkyNC03N2Y3LTQwNDMtYThlMy03YTRjYzE4MTMxYmUucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDgyMSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA4MjFUMDQ1MTMyWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9YjQwODMxZWM0NzNiYzQwOGJlOTNiMWVjYmVkMzllMWRmODljNmE1NDk5NjliZjBhM2Q4Yzk1MjQ3MzU0YTU4OSZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.aara4qSgsD3e3YHZyq1VMwhbmT6s4wxm1eztMjpOPYg)
![Bildschirmfoto 2023-12-02 um 20 24 06](https://private-user-images.githubusercontent.com/1085162/287470490-b4555413-6998-4f54-a4c4-046545ed9daf.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQyMTYxOTIsIm5iZiI6MTcyNDIxNTg5MiwicGF0aCI6Ii8xMDg1MTYyLzI4NzQ3MDQ5MC1iNDU1NTQxMy02OTk4LTRmNTQtYTRjNC0wNDY1NDVlZDlkYWYucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDgyMSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA4MjFUMDQ1MTMyWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9ZmYyYzFlOGJmYmE5M2Q0NzU2NDg0ZDdkOWY2ZmMxNzA0YzYxODBjOTAxNWZiMTZiODM0NTg0NDhiNDk5MjlmMyZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.usv07z_cPBCIxfI-2gBsKEEAHzwTMZqhTV-RNstIqU4)
from ha_sonnenbatterie.
from ha_sonnenbatterie.
Hopefully someone who is better at this sort of stuff can help you, but I cobbled together a limit way of setting ToU with the API and NodeRed. You can find useful information and my hacky work here: https://community.home-assistant.io/t/sonnenbatterie-with-apiv2-webhook/264907/51?u=libby
from ha_sonnenbatterie.
from ha_sonnenbatterie.
I'll have a look, sounds interesting ;)
from ha_sonnenbatterie.
@whistlebare
After checking the API docs I'd say that you could solve your problem using the /api/v2/setpoint/charge/{watt}
API endpoint together with timed automations and the RESTful Command integration in HA.
Untested example:
basic REST commands
rest_command:
set_manual_mode:
url: "http://ip-of-your-sonnenbattery/api/v2/configurations"
method: put
content_type: "application/x-www-form-urlencoded"
payload: "EM_OperatingMode=1"
headers: { "Auth-Token": "<your-auth-token>" }
set_automatic_mode:
url: "http://ip-of-your-sonnenbattery/api/v2/configurations"
method: put
content_type: "application/x-www-form-urlencoded"
payload: "EM_OperatingMode=2"
headers: { "Auth-Token": "<your-auth-token>" }
start_charging:
url: "http://ip-of-your-sonnenbattery/api/v2/setpoint/charge/5000"
method: post
headers: { "Auth-Token": "<your-auth-token>" }
stop_charging:
url: "http://ip-of-your-sonnenbattery/api/v2/setpoint/charge/0"
method: post
headers: { "Auth-Token": "<your-auth-token>" }
simple automation examples
automation:
- alias: "Charge Battery"
trigger:
- platform: time
at: "22:00"
action:
- service: rest_command.set_manual_mode
- service: rest_command.start_charging
- alias: "Stop Battery Charging"
trigger:
- platform: time
at: "02:00"
action:
- service: rest_command.stop_charging
- service: rest_command.set_automatic_mode
Note
As mentioned above this is untested for I'm not using ToU mode but it should give you a pointer on how to solve your problem.
from ha_sonnenbatterie.
from ha_sonnenbatterie.
That's brilliant news...Are there any guides that can help with setting this up @atimgraves? I'm a little new to this stuff
from ha_sonnenbatterie.
Thanks for the info Tim, if you are still working on it then I'll wait for you to finish testing etc...I've been setting TOS etc via the web log in for ages so waiting a little longer isn't going to hurt...I'm using Octopus Agile at the moments so it requires a lot of editing TOS etc to maximise the cheaper periods.
Thanks for your hard work on this.
from ha_sonnenbatterie.
That's really cool when those control features of the API go into the integration!
For the moment I use the above rest_command setup for setting modes and charging values on my Sonnenbatterie. In addition to the examples above note that you can also parametrise a rest_command. This is the way how I can control the amount of loading watts from an automation by setting {{ power }} as parameter from my calculating sensor:
start_sonnenbatterie_charging:
url: "http://<SONNENBATTERIE_IP>/api/v2/setpoint/charge/{{ power }}"
method: post
headers:
Auth-Token: !secret sonnenbatterie_token
from ha_sonnenbatterie.
from ha_sonnenbatterie.
That's really cool when those control features of the API go into the integration!
For the moment I use the above rest_command setup for setting modes and charging values on my Sonnenbatterie. In addition to the examples above note that you can also parametrise a rest_command. This is the way how I can control the amount of loading watts from an automation by setting {{ power }} as parameter from my calculating sensor:
start_sonnenbatterie_charging: url: "http://<SONNENBATTERIE_IP>/api/v2/setpoint/charge/{{ power }}" method: post headers: Auth-Token: !secret sonnenbatterie_token
I would love to pick your brains on the various attributes and what they actually do and represent. Eg {{power}} is that the total power you want to put into the battery, or is it the charge rate of the power going in etc...I've never found Sonnens charge settings very easy to grasp...
from ha_sonnenbatterie.
I guess I'd like to automate it as much as possible, but also I'm happy to manually do it via HA with a simple charge on/off toggle without having to log into the sonnen app each time and set up a TOS.
Is it possible to take the Octopus Agile supplied 24hr prices and feed them into HA with a condition that charges the battery if the price is lower than x.pence? The other spanner in the works is that I have solar, so it doesn't make sense to charge from the grid if the sun is shining etc.
I'm not asking for much am I 😂
from ha_sonnenbatterie.
from ha_sonnenbatterie.
On that front how are you handling the you settings, do you have one for the entire period or do you want to be able to set multiple at the same time ? From a code perspective a single or multiple is not an issue, but the HA ui is my concern - I'm pretty confident I can arrange for a single time of of use slot, but I don't know how easy it would be for the home assistant UI to handle more than one
…
On Fri, 21 Jul 2023 at 13:20, whistlebare @.> wrote: Thanks for the info Tim, if you are still working on it then I'll wait for you to finish testing etc...I've been setting TOS etc via the web log in for ages so waiting a little longer isn't going to hurt...I'm using Octopus Agile at the moments so it requires a lot of editing TOS etc to maximise the cheaper periods. Thanks for your hard work on this. — Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG4VUTD26JNWWXWY2W32OITXRJX2JANCNFSM6AAAAAAVRCBVTM . You are receiving this because you were mentioned.Message ID: @.>
I use EMHASS add-on in Home Assistant to dynamically manage the sonnen battery using forecast data. https://community.home-assistant.io/t/custom-integration-sonnenbatterie/181781/125
from ha_sonnenbatterie.
I guess I'd like to automate it as much as possible, but also I'm happy to manually do it via HA with a simple charge on/off toggle without having to log into the sonnen app each time and set up a TOS. Is it possible to take the Octopus Agile supplied 24hr prices and feed them into HA with a condition that charges the battery if the price is lower than x.pence? The other spanner in the works is that I have solar, so it doesn't make sense to charge from the grid if the sun is shining etc. I'm not asking for much am I 😂
Have a look at EMHASS
I've used EMHASS in home assistant to manage the battery
https://community.home-assistant.io/t/custom-integration-sonnenbatterie/181781/125
from ha_sonnenbatterie.
On that front how are you handling the you settings, do you have one for the entire period or do you want to be able to set multiple at the same time ? From a code perspective a single or multiple is not an issue, but the HA ui is my concern - I'm pretty confident I can arrange for a single time of of use slot, but I don't know how easy it would be for the home assistant UI to handle more than one
…
On Fri, 21 Jul 2023 at 13:20, whistlebare @.> wrote: Thanks for the info Tim, if you are still working on it then I'll wait for you to finish testing etc...I've been setting TOS etc via the web log in for ages so waiting a little longer isn't going to hurt...I'm using Octopus Agile at the moments so it requires a lot of editing TOS etc to maximise the cheaper periods. Thanks for your hard work on this. — Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG4VUTD26JNWWXWY2W32OITXRJX2JANCNFSM6AAAAAAVRCBVTM . You are receiving this because you were mentioned.Message ID: _@**.**_>I use EMHASS add-on in Home Assistant to dynamically manage the sonnen battery using forecast data. https://community.home-assistant.io/t/custom-integration-sonnenbatterie/181781/125
Wow I just looked at your set up...very impressive! My head hurts with all that info and the amount of calculations involved is mind boggling.
from ha_sonnenbatterie.
from ha_sonnenbatterie.
@property
def device_info(self):
return {
"identifiers": {(DOMAIN, self.mainCoordinator.serial)}
}
That is wrong as it results in wrong deviceinfo identifiers... look at the other sensors how this is implemented :)
You have device_info defined 2 times... the 2nd one is overwriting the first one and returns wrong values.
Also Module Count or other sensor should not set to be of type battery.. battery is used to show devices battery%. currently i get always 4% as i have 4 modules...
![image](https://private-user-images.githubusercontent.com/1668465/286379808-c4435b75-e589-4d63-a293-1ed0905663c9.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQyMTYxOTIsIm5iZiI6MTcyNDIxNTg5MiwicGF0aCI6Ii8xNjY4NDY1LzI4NjM3OTgwOC1jNDQzNWI3NS1lNTg5LTRkNjMtYTI5My0xZWQwOTA1NjYzYzkucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDgyMSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA4MjFUMDQ1MTMyWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9ODg3ZjFhMGQwNjBhOTBmMWQwMWM2N2E1YjM5M2RlM2Y0NWYxOWJlYTMwNWMzZDczYTAxNmNhODllYjRhNGFlMCZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.zTKyL5STmJ1x4iT3QKf1nGbZtXPPjEVM_UPEJA9dfc8)
![image](https://private-user-images.githubusercontent.com/1668465/286379873-d71d9280-3e95-483d-b4d4-00bbfd4f1d3c.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQyMTYxOTIsIm5iZiI6MTcyNDIxNTg5MiwicGF0aCI6Ii8xNjY4NDY1LzI4NjM3OTg3My1kNzFkOTI4MC0zZTk1LTQ4M2QtYjRkNC0wMGJiZmQ0ZjFkM2MucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDgyMSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA4MjFUMDQ1MTMyWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9ZTJlN2JlYzRlMTcwMzYwZmQ5YWViMzAzYjQ3MThiZGQ4Y2ZlZWVhOTY3ODllZjU4YzI2NGZiNjZkOGYzNDQ4NCZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.EI1_lqhKC3fsD5OE87Fnocwcm7kn_pVcW2u4L7FD_Cs)
from ha_sonnenbatterie.
@whistlebare After checking the API docs I'd say that you could solve your problem using the
/api/v2/setpoint/charge/{watt}
API endpoint together with timed automations and the RESTful Command integration in HA.Untested example:
basic REST commands
rest_command: set_manual_mode: url: "http://ip-of-your-sonnenbattery/api/v2/configurations" method: put content_type: "application/x-www-form-urlencoded" payload: "EM_OperatingMode=1" headers: { "Auth-Token": "<your-auth-token>" } set_automatic_mode: url: "http://ip-of-your-sonnenbattery/api/v2/configurations" method: put content_type: "application/x-www-form-urlencoded" payload: "EM_OperatingMode=2" headers: { "Auth-Token": "<your-auth-token>" } start_charging: url: "http://ip-of-your-sonnenbattery/api/v2/setpoint/charge/5000" method: post headers: { "Auth-Token": "<your-auth-token>" } stop_charging: url: "http://ip-of-your-sonnenbattery/api/v2/setpoint/charge/0" method: post headers: { "Auth-Token": "<your-auth-token>" }simple automation examples
automation: - alias: "Charge Battery" trigger: - platform: time at: "22:00" action: - service: rest_command.set_manual_mode - service: rest_command.start_charging - alias: "Stop Battery Charging" trigger: - platform: time at: "02:00" action: - service: rest_command.stop_charging - service: rest_command.set_automatic_modeNote
As mentioned above this is untested for I'm not using ToU mode but it should give you a pointer on how to solve your problem.
It's been months but i've finally got to sit down and start playing with this automation in HA for my Sonnenbatterie...I'm not a coder in the slightest, but I can sort of follow the code above... I do have a few questions.
- I put all these Rest commands code into a configuration.yaml file right, I don't need to install 'Rest' in HA, it's part of the OS?
- When you see code like this > headers: { "Auth-Token": "" } Do I remove the { } so it reads headers: "Auth-Token: xxxxxx-xxx-xxxxx-xxxxx-xxxxxxxx" ?
I've been able to send curl commands to do various things using a curl website, for example > curl -d -H -X POST --header 'Auth-Token: xxxxxxxxxxxxxxxxxxxxxxxxxxxxx' http://192.168.x.x:80/api/v2/setpoint/charge/12000
Does the code 'headers' and 'header' do the same thing? I notice code you provided and what Sonnen provide is different. also is things in "xxx" the same as 'xxx' ?
Apologies if these are daft questions....
from ha_sonnenbatterie.
- I put all these Rest commands code into a configuration.yaml file right, I don't need to install 'Rest' in HA, it's part of the OS?
Correct.
- When you see code like this > headers: { "Auth-Token": "" } Do I remove the { } so it reads headers: "Auth-Token: xxxxxx-xxx-xxxxx-xxxxx-xxxxxxxx" ?
No. But there's an easier solution. Instead of using the syntax with curly braces you can do it like this:
rest_command:
sonnenbatterie_set_manual_mode:
url: "http://ip.of.sonnen.battery//api/v2/configurations"
method: put
content_type: "application/x-www-form-urlencoded"
payload: "EM_OperatingMode=1"
headers:
Auth-Token: !secret sonnen_token
sonnenbatterie_set_automatic_mode:
url: "http://ip.of.sonnen.battery//api/v2/configurations"
method: put
content_type: "application/x-www-form-urlencoded"
payload: "EM_OperatingMode=2"
headers:
Auth-Token: !secret sonnen_token
sonnenbatterie_start_charging:
url: "http://ip.of.sonnen.battery//api/v2/setpoint/charge/100"
method: post
headers:
Auth-Token: !secret sonnen_token
sonnenbatterie_stop_charging:
url: "http://ip.of.sonnen.battery/api/v2/setpoint/charge/0"
method: post
headers:
Auth-Token: !secret sonnen_token
Dont' forget to replace ip.of.sonnen.battery
with the actual IP address of your sonnen battery API.
In your HA configuration directory there should be a file named secrets.yaml
there you then add a line like this:
sonnen_token: your_token_goes here
Just use the token as given by sonnenbattery's API, no braces, no apostrophes or anything.
I've been able to send curl commands to do various things using a curl website, for example > curl -d -H -X POST --header 'Auth-Token: xxxxxxxxxxxxxxxxxxxxxxxxxxxxx' http://192.168.x.x:80/api/v2/setpoint/charge/12000
Well, basically yes. It's just that with curl
you're using curl and thus the syntax of curl whereas with HomeAssistant you'd be essentially using the syntax of the python-module. That's why one tool names the headers flag header
and the other names it headers
. In short, it's just a name for a variable, don't let it confuse you. The important part is that Auth-Token
is named Auth-Token
;)
Does the code 'headers' and 'header' do the same thing? I notice code you provided and what Sonnen provide is different. also is things in "xxx" the same as 'xxx' ?
See above. Different tools use different syntax, that's all it is. In the end both, curl and HomeAssistant, will send an HTTP request that in it's header field contains an entry "Auth-Token: whatver-token-you-specified". As long as that requirement is met, everything is fine.
from ha_sonnenbatterie.
from ha_sonnenbatterie.
@RustyDust got it, that make perfect sense now you've spelt it out like you are talking to a minor 😆. Yep I have a secrets.yaml which I have used before...I was putting in the API values etc straight into the code to make sure it worked and I was going to tidy it up after.
Thanks again for your help
from ha_sonnenbatterie.
When I was exploring this I discovered that there are two calls, one for charge and a different one for discharge (both require manual mode) setting a negative charge did not result in a discharge. Look in the 0.2.7 Python sonnen batterie for the details. My code for doing all of this in HA is nearly done, Ii you want to look at what I've been doing updating Jan's HA sonnen code my updates are at https://github.com/atimgraves/ha_sonnenbatterie/tree/extended-services Be warned there is one known outstanding problem which is that sometimes (but not every time) the two out of three of the settings for battery reserve, operating mode or TOu schedule startup under the "Sensor" integration not the sonnenbattrie Integration (With literally the same code this can vary between HA boots - there is clearly a complex race condition happening but I haven't got to the bottom of that. I hope to get time to work on that further this comming week. Cheers, Tim
…
On Sat, 2 Dec 2023 at 15:53, whistlebare @.> wrote: @whistlebare https://github.com/whistlebare After checking the API docs I'd say that you could solve your problem using the /api/v2/setpoint/charge/{watt} API endpoint together with timed automations and the RESTful Command integration https://www.home-assistant.io/integrations/rest_command/ in HA. Untested example: basic REST commands rest_command: set_manual_mode: url: "http://ip-of-your-sonnenbattery/api/v2/configurations" method: put content_type: "application/x-www-form-urlencoded" payload: "EM_OperatingMode=1" headers: { "Auth-Token": "" } set_automatic_mode: url: "http://ip-of-your-sonnenbattery/api/v2/configurations" method: put content_type: "application/x-www-form-urlencoded" payload: "EM_OperatingMode=2" headers: { "Auth-Token": "" } start_charging: url: "http://ip-of-your-sonnenbattery/api/v2/setpoint/charge/5000" method: post headers: { "Auth-Token": "" } stop_charging: url: "http://ip-of-your-sonnenbattery/api/v2/setpoint/charge/0" method: post headers: { "Auth-Token": "" } simple automation examples automation: - alias: "Charge Battery" trigger: - platform: time at: "22:00" action: - service: rest_command.set_manual_mode - service: rest_command.start_charging - alias: "Stop Battery Charging" trigger: - platform: time at: "02:00" action: - service: rest_command.stop_charging - service: rest_command.set_automatic_mode Note As mentioned above this is untested for I'm not using ToU mode but it should give you a pointer on how to solve your problem. It's been months but i've finally got to sit down and start playing with this automation in HA for my Sonnenbatterie...I'm not a coder in the slightest, but I can sort of follow the code above... I do have a few questions. 1. I put all these Rest commands code into a configuration.yaml file right, I don't need to install 'Rest' in HA, it's part of the OS? 2. When you see code like this > headers: { "Auth-Token": "" } Do I remove the { } so it reads headers: "Auth-Token: xxxxxx-xxx-xxxxx-xxxxx-xxxxxxxx" ? I've been able to send curl commands to do various things using a curl website, for example > curl -d -H -X POST --header 'Auth-Token: xxxxxxxxxxxxxxxxxxxxxxxxxxxxx' http://192.168.x.x:80/api/v2/setpoint/charge/12000 Does the code 'headers' and 'header' do the same thing? I notice code you provided and what Sonnen provide is different. also is things in "xxx" the same as 'xxx' ? Apologies if these are daft questions.... — Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG4VUTDWSZUOW3WX7C22QY3YHNFJHAVCNFSM6AAAAAAVRCBVTOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZXGE4DOOJSHE . You are receiving this because you were mentioned.Message ID: @.>
Oh I'll take a look at your new code later when I'm back behind my computer. Ta!
Yes I did try with the curl command the charge option (surprised the sonnen API guide only mentions discharge) and it worked.
So I guess this could be used to do some crude automations with buttons etc
from ha_sonnenbatterie.
@RustyDust got it, that make perfect sense now you've spelt it out like you are talking to a minor 😆.
Oops, not intentionally. It's just that English isn't my native language.
from ha_sonnenbatterie.
@RustyDust got it, that make perfect sense now you've spelt it out like you are talking to a minor 😆.
Oops, not intentionally. It's just that English isn't my native language.
No I meant it in a good way! 😆 It was clear and concise, just how I like it 👍🏼
from ha_sonnenbatterie.
Be warned there is one known outstanding problem which is that sometimes (but not every time) the two out of three of the settings for battery reserve, operating mode or TOu schedule startup under the "Sensor" integration not the sonnenbattrie Integration (With literally the same code this can vary between HA boots - there is clearly a complex race condition happening but I haven't got to the bottom of that. I hope to get time to work on that further this comming week.
From looking at your code (didn't have time to do a proper checkout and some testing) it might just be as simple as that there is no guaranteed order in which the threads for the different integrations are run in HomeAssistant. Since your code (at least at the time I looked at it) seems to do an init routine that is completely separate from the general sonnenbatterie init chances are that sometimes it is just scheduled before the original code. But then again it's just a guess.
from ha_sonnenbatterie.
from ha_sonnenbatterie.
sonnen_token
I've got the code all typed in and the configuration.yaml saved without any errors. Silly question but how do i reference the code? If i try making an automation i can't find it in the 'action' section...looked for 'rest', 'Sonnenbatterie'. Should I have some other python files saved somewhere?
![rest command](https://private-user-images.githubusercontent.com/126982604/287469922-05d31eca-3278-4d5f-8e54-3dbb31c0a6eb.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQyMTYxOTIsIm5iZiI6MTcyNDIxNTg5MiwicGF0aCI6Ii8xMjY5ODI2MDQvMjg3NDY5OTIyLTA1ZDMxZWNhLTMyNzgtNGQ1Zi04ZTU0LTNkYmIzMWMwYTZlYi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwODIxJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDgyMVQwNDUxMzJaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0zYWMxMjIyMjU3M2RlZjJjNjlhNjFlOTgxMzllMDM4YmJhYmU0NzE2YjdlYzY0MjM5NTFkZjgwZDNjNTAzOWNmJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.I6r7POj0x8C6PRV-DIBWCa6Ca2gTjSXVt4UOcRy9Rt0)
from ha_sonnenbatterie.
sonnen_token
I've got the code all typed in and the configuration.yaml saved without any errors. Silly question but how do i reference the code? If i try making an automation i can't find it in the 'action' section...looked for 'rest', 'Sonnenbatterie'. Should I have some other python files saved somewhere?
![]()
Damn it ! Didn't realise i needed to restart HA to get the restful code working...I assumed I only needed to reload the yaml file.
from ha_sonnenbatterie.
The REST integration should be loaded automatically by HomeAssistant once you've put the
rest_command:
section either directly in yourconfiguration.yaml
or in a separate file (for examplerest_commands.yaml
) that is loaded fromconfiguration.yaml
using therest_command: !include rest_commands.yaml
statement.Referencing in automations is done by using the full name which is a combination of
rest_command
and the name you gave the command itself. So using my example above it would berest_command.sonnenbatterie_start_charging
for the command to start charging.My YAML code for the automation to start charging looks like this:
alias: "[Test] Battery -> Charge" description: "" trigger: - platform: state entity_id: - input_boolean.test_batterie_mode condition: - condition: state entity_id: input_boolean.test_batterie_mode state: "on" action: - service: rest_command.sonnenbatterie_set_manual_mode data: {} - service: rest_command.sonnenbatterie_start_charging data: {} mode: singleNote that you need to set the battery to manual mode before you can start charging.
Likewise, to get back to automatic mode I use:
alias: "[Tst] Battery -> Auto" description: "" trigger: - platform: state entity_id: - input_boolean.test_batterie_mode condition: - condition: state entity_id: input_boolean.test_batterie_mode state: "off" action: - service: rest_command.sonnenbatterie_stop_charging data: {} - service: rest_command.sonnenbatterie_set_automatic_mode data: {} mode: singleAgain, the battery has to stop charging before it can be switched back to automatic mode.
Since I don't know whether you're comfortable with creating automations in YAML, here's what they both look like in the visual editor:
Yes after I restarted HA i could see the Rest_commands in the action tab...
As for the making automations, I wouldn't say I'm comfortable, but I learn best by trial and error and if that fails chat GPT ;-)
Thanks for sharing your code :-)
from ha_sonnenbatterie.
The REST integration should be loaded automatically by HomeAssistant once you've put the
rest_command:
section either directly in yourconfiguration.yaml
or in a separate file (for examplerest_commands.yaml
) that is loaded fromconfiguration.yaml
using therest_command: !include rest_commands.yaml
statement.Referencing in automations is done by using the full name which is a combination of
rest_command
and the name you gave the command itself. So using my example above it would berest_command.sonnenbatterie_start_charging
for the command to start charging.My YAML code for the automation to start charging looks like this:
alias: "[Test] Battery -> Charge" description: "" trigger: - platform: state entity_id: - input_boolean.test_batterie_mode condition: - condition: state entity_id: input_boolean.test_batterie_mode state: "on" action: - service: rest_command.sonnenbatterie_set_manual_mode data: {} - service: rest_command.sonnenbatterie_start_charging data: {} mode: singleNote that you need to set the battery to manual mode before you can start charging.
Likewise, to get back to automatic mode I use:
alias: "[Tst] Battery -> Auto" description: "" trigger: - platform: state entity_id: - input_boolean.test_batterie_mode condition: - condition: state entity_id: input_boolean.test_batterie_mode state: "off" action: - service: rest_command.sonnenbatterie_stop_charging data: {} - service: rest_command.sonnenbatterie_set_automatic_mode data: {} mode: singleAgain, the battery has to stop charging before it can be switched back to automatic mode.
Since I don't know whether you're comfortable with creating automations in YAML, here's what they both look like in the visual editor:
In your code you have this >
platform: state
entity_id:
- input_boolean.test_batterie_mode
I don't have an entity for input_boolean and the test_batterie_mode is referenced from what file...configuration.yaml? if so I don't have any of that in my configuration.yaml file...
Sorry for the constant questions
from ha_sonnenbatterie.
I've been tinkering and i've managed to get TOU working with some automations...it's dirty but early testing it looks ok using EM_OperatingMode=10 (10 being TOU...thanks chat GPT :-) )
Here's my config >
#Sonnenbatterie Set mode
rest_command:
sonnenbatterie_set_manual_mode:
url: "http://192.168.1.192:80/api/v2/configurations"
method: put
content_type: "application/x-www-form-urlencoded"
payload: "EM_OperatingMode=1"
headers:
Auth-Token: !secret sonnen_token
sonnenbatterie_set_automatic_mode:
url: "http://192.168.1.192:80/api/v2/configurations"
method: put
content_type: "application/x-www-form-urlencoded"
payload: "EM_OperatingMode=2"
headers:
Auth-Token: !secret sonnen_token
sonnenbatterie_start_charging:
url: "http://192.168.1.192:80/api/v2/setpoint/charge/12000"
method: post
headers:
Auth-Token: !secret sonnen_token
sonnenbatterie_stop_charging:
url: "http://192.168.1.192:80/api/v2/setpoint/charge/0"
method: post
headers:
Auth-Token: !secret sonnen_token
sonnenbatterie_set_tou_mode:
url: "http://192.168.1.192:80/api/v2/configurations"
method: put
content_type: "application/x-www-form-urlencoded"
payload: "EM_OperatingMode=10"
headers:
Auth-Token: !secret sonnen_token
My Automations look like this >
- id: '1701554910867'
alias: IOG - Trigger Battery to Manual
description: Manual Battery Charge when IOG is triggered
trigger:
- platform: state
entity_id:
- binary_sensor.octopus_intelligent_slot_next_2_hours
for:
hours: 0
minutes: 0
seconds: 10
from: 'off'
to: 'on'
condition: []
action:
- service: rest_command.sonnenbatterie_stop_charging
data: {}
- service: rest_command.sonnenbatterie_set_manual_mode
data: {}
- service: rest_command.sonnenbatterie_start_charging
data: {}
mode: single
- id: '1701555225513'
alias: IOG - Trigger Battery to Self Consumption
description: ' Battery Charge set to SelfConsumption when IOG has ended'
trigger:
- platform: state
entity_id:
- binary_sensor.octopus_energy_a_89d6ee15_intelligent_dispatching
for:
hours: 0
minutes: 0
seconds: 10
from: 'on'
to: 'off'
condition: []
action:
- service: rest_command.sonnenbatterie_stop_charging
data: {}
- service: rest_command.sonnenbatterie_set_automatic_mode
data: {}
mode: single
- id: '1701556939715'
alias: IOG - Trigger TOU after 23.30
description: Battery Charge set to TOU when IOG is finished
trigger:
- platform: state
entity_id:
- binary_sensor.octopus_energy_a_89d6ee15_intelligent_dispatching
for:
hours: 0
minutes: 0
seconds: 8
from: 'on'
to: 'off'
condition:
- condition: time
after: '23:30:00'
before: 05:30:00
action:
- service: rest_command.sonnenbatterie_stop_charging
data: {}
- service: rest_command.sonnenbatterie_set_tou_mode
data: {}
mode: single
Please feel free to rip my code apart and point me in the right direction...
from ha_sonnenbatterie.
Please feel free to rip my code apart and point me in the right direction...
Looks good so far but won't help you much unless you also set some time frames with specific ToU instructions for the SonnenBattery. That said I've been playing with the different modes and settings for the last few days. What I found so far is:
- You can always set ToU schedules, no matter what mode the battery is currently in
- However, those schedules come into effect only** when the battery is in ToU mode.
On the one hand this is nice for it allows to test the setting / deleting of schedules without interrupting or otherwise interfering with the actual behavior of the battery. On the other hand it makes it a bit more difficult to activate - and later on de-activate - ToU mode at the right time. In short: some sort of scheduler is needed. With HomeAssistant that'd be the job of an automation that would trigger on times when electricity prices are low. This brings it's own problems because at least to my testing, the schedules have to be defined before ToU mode is activated. My battery simply ignored schedules that were set after switching to ToU mode but would have started in the past.
Which brings me to the next topic: Setting schedules.
This is done using a "PUT" call to the /api/v2/configurations
endpoint, setting the key EM_ToU_Schedule
with a string payload that actually represents an array of JSON objects of this form:
{
"start": "17:00",
"stop": "21:00",
"threshold_p_max": 10000
}
There can be zero to many objects with zero objects obviously clearing the schedule. Every call to the endpoint also clears all existing schedules before setting the new ones. So one can't just add but instead one has to always deliver the full schedule set.
Looking at the parameters, start
and stop
are self-explanatory. But threshold_p_max
is a bit more interesting and a bit confusing as well. When set to "0" it means that the battery will only charge using excess power from the solar panels. If set to anything higher, it means that that battery system will draw up to the given power from the net.
So this is not the amount of power used for charging the battery, but the power to charge plus what's needed by other consumers on the same line. So if you set it to 5000 (W) and your home uses 500 (W) then the battery will charge with 4500 (W) max. This makes calculation of the needed values a bit more complicated but on the other hand it should be safe to simply set it to a higher value than what your battery supports for charging since the battery will never draw more than it supports. Just make sure that the line to your home also supports the value you set ;)
Now the thing that bugs me is:
From an automation's point of view using ToU mode is functionally not much different from setting the battery to "Manual" mode and tell it to charge and reset it back to "Auto" later. Even the steps are pretty much the same.
In ToU one needs to find a matching time window, set it and then using an automation set the battery to ToU mode at the right time to really have it start charging. When the time frame has passed, switch back to "Auto".
With manual mode you just wait for the trigger of the time frame, tell the battery to charge and when the time frame is over set the battery back to normal.
The only advantage of ToU mode would be if HomeAssistant crashes for one or other reasons after it has successfully set a schedule and the battery would then switch to ToU mode automatically. But since that isn't the case (at least it never worked in my tests) this advantage is nullyfied.
Then there's a little difference in the settings. With the manual "charge" command one sets the power the battery should charge with. I found that once the battery is quite full it will stop charging with full power but since we told it to use whatever wattage we gave in the charge command it can't fulfill the request and will simply stop charging, leaving you with a battery that's never filled to 100%. ToU mode will keep on charging until the battery is full or until it is interrupted. That's the main advantage of ToU mode as far as I can tell.
But then, I normally don't want to fully charge the battery (except right now where there's roughly a meter of snow on my panels) but instead I only want to charge what I think the battery can't get from the sun the next day. So most of the times the battery will only be charged to something between 40 and 80 percent I guess. Which makes the better fill-up functionality of ToU mode probably moot.
My current conclusion is that the only scenario that would make the most sense is to let the battery run in ToU mode all the time and just setting different schedules according to electricity prices and sun forecast.
Or did I miss something?
from ha_sonnenbatterie.
Please feel free to rip my code apart and point me in the right direction...
Looks good so far but won't help you much unless you also set some time frames with specific ToU instructions for the SonnenBattery. That said I've been playing with the different modes and settings for the last few days. What I found so far is:
- You can always set ToU schedules, no matter what mode the battery is currently in
- However, those schedules come into effect only** when the battery is in ToU mode.
On the one hand this is nice for it allows to test the setting / deleting of schedules without interrupting or otherwise interfering with the actual behavior of the battery. On the other hand it makes it a bit more difficult to activate - and later on de-activate - ToU mode at the right time. In short: some sort of scheduler is needed. With HomeAssistant that'd be the job of an automation that would trigger on times when electricity prices are low. This brings it's own problems because at least to my testing, the schedules have to be defined before ToU mode is activated. My battery simply ignored schedules that were set after switching to ToU mode but would have started in the past.
Which brings me to the next topic: Setting schedules. This is done using a "PUT" call to the
/api/v2/configurations
endpoint, setting the keyEM_ToU_Schedule
with a string payload that actually represents an array of JSON objects of this form:{ "start": "17:00", "stop": "21:00", "threshold_p_max": 10000 }There can be zero to many objects with zero objects obviously clearing the schedule. Every call to the endpoint also clears all existing schedules before setting the new ones. So one can't just add but instead one has to always deliver the full schedule set.
Looking at the parameters,
start
andstop
are self-explanatory. Butthreshold_p_max
is a bit more interesting and a bit confusing as well. When set to "0" it means that the battery will only charge using excess power from the solar panels. If set to anything higher, it means that that battery system will draw up to the given power from the net. So this is not the amount of power used for charging the battery, but the power to charge plus what's needed by other consumers on the same line. So if you set it to 5000 (W) and your home uses 500 (W) then the battery will charge with 4500 (W) max. This makes calculation of the needed values a bit more complicated but on the other hand it should be safe to simply set it to a higher value than what your battery supports for charging since the battery will never draw more than it supports. Just make sure that the line to your home also supports the value you set ;)Now the thing that bugs me is:
From an automation's point of view using ToU mode is functionally not much different from setting the battery to "Manual" mode and tell it to charge and reset it back to "Auto" later. Even the steps are pretty much the same.
In ToU one needs to find a matching time window, set it and then using an automation set the battery to ToU mode at the right time to really have it start charging. When the time frame has passed, switch back to "Auto". With manual mode you just wait for the trigger of the time frame, tell the battery to charge and when the time frame is over set the battery back to normal.
The only advantage of ToU mode would be if HomeAssistant crashes for one or other reasons after it has successfully set a schedule and the battery would then switch to ToU mode automatically. But since that isn't the case (at least it never worked in my tests) this advantage is nullyfied.
Then there's a little difference in the settings. With the manual "charge" command one sets the power the battery should charge with. I found that once the battery is quite full it will stop charging with full power but since we told it to use whatever wattage we gave in the charge command it can't fulfill the request and will simply stop charging, leaving you with a battery that's never filled to 100%. ToU mode will keep on charging until the battery is full or until it is interrupted. That's the main advantage of ToU mode as far as I can tell.
But then, I normally don't want to fully charge the battery (except right now where there's roughly a meter of snow on my panels) but instead I only want to charge what I think the battery can't get from the sun the next day. So most of the times the battery will only be charged to something between 40 and 80 percent I guess. Which makes the better fill-up functionality of ToU mode probably moot.
My current conclusion is that the only scenario that would make the most sense is to let the battery run in ToU mode all the time and just setting different schedules according to electricity prices and sun forecast.
Or did I miss something?
That's strange that your TOU get cleared...I've just checked my TOU settings that I put in previously (23.30 - 05.30) and after various automations run and it returns to the TOU settings, my times are still set. I'm running sonnen version 1.10.7
from ha_sonnenbatterie.
My current conclusion is that the only scenario that would make the
most sense is to let the battery run in ToU mode all the time and just setting different schedules according to electricity prices and sun forecast. I think this is the best mode for me at least. One factor to consider is that when in the TOU mode it seems to optimize the charging rate so that it gets to 100% in the time window you've provided (but remember that threshold_p_max is the overall max power for the incoming supply). That may put less stress on the battery as it's based on the charge level at the time each TOU window starts, however this only seems to come into play if there is a single slot, if you want to control the actual battery charge rate you'll need to manage it manually. Say you can't fully charge the battery to your desired in the time window the power at the cheapest price, so you need to do a smaller amount of charge in an earlier time window you'll either have to manually set a charge rate or apply a shorter earlier time window.
…
On Sun, 3 Dec 2023 at 20:23, stefan @.> wrote: @whistlebare https://github.com/whistlebare Please feel free to rip my code apart and point me in the right direction... Looks good so far but won't help you much unless you also set some time frames with specific ToU instructions for the SonnenBattery. That said I've been playing with the different modes and settings for the last few days. What I found so far is: - You can always set ToU schedules, no matter what mode the battery is currently in - However, those schedules come into effect only when the battery is in ToU mode. On the one hand this is nice for it allows to test the setting / deleting of schedules without interrupting or otherwise interfering with the actual behavior of the battery. On the other hand it makes it a bit more difficult to activate - and later on de-activate - ToU mode at the right time. In short: some sort of scheduler is needed. With HomeAssistant that'd be the job of an automation that would trigger on times when electricity prices are low. This brings it's own problems because at least to my testing, the schedules have to be defined before ToU mode is activated. My battery simply ignored schedules that were set after switching to ToU mode but would have started in the past. Which brings me to the next topic: Setting schedules. This is done using a "PUT" call to the /api/v2/configurations endpoint, setting the key EM_ToU_Schedule with a string payload that actually represents an array of JSON objects of this form: { "start": "17:00", "stop": "21:00", "threshold_p_max": 10000 } There can be zero to many objects with zero objects obviously clearing the schedule. Every call to the endpoint also clears all existing schedules before setting the new ones. So one can't just add but instead one has to always deliver the full schedule set. Looking at the parameters, start and stop are self-explanatory. But threshold_p_max is a bit more interesting and a bit confusing as well. When set to "0" it means that the battery will only charge using excess power from the solar panels. If set to anything higher, it means that that battery system will draw up to the given power from the net. So this is not the amount of power used for charging the battery, but the power to charge plus what's needed by other consumers on the same line. So if you set it to 5000 (W) and your home uses 500 (W) then the battery will charge with 4500 (W) max. This makes calculation of the needed values a bit more complicated but on the other hand it should be safe to simply set it to a higher value than what your battery supports for charging since the battery will never draw more than it supports. Just make sure that the line to your home also supports the value you set ;) Now the thing that bugs me is: From an automation's point of view using ToU mode is functionally not much different from setting the battery to "Manual" mode and tell it to charge and reset it back to "Auto" later. Even the steps are pretty much the same. In ToU one needs to find a matching time window, set it and then using an automation set the battery to ToU mode at the right time to really have it start charging. When the time frame has passed, switch back to "Auto". With manual mode you just wait for the trigger of the time frame, tell the battery to charge and when the time frame is over set the battery back to normal. The only advantage of ToU mode would be if HomeAssistant crashes for one or other reasons after it has successfully set a schedule and the battery would then switch to ToU mode automatically. But since that isn't the case (at least it never worked in my tests) this advantage is nullyfied. Then there's a little difference in the settings. With the manual "charge" command one sets the power the battery should charge with. I found that once the battery is quite full it will stop charging with full power but since we told it to use whatever wattage we gave in the charge command it can't fulfill the request and will simply stop charging, leaving you with a battery that's never filled to 100%. ToU mode will keep on charging until the battery is full or until it is interrupted. That's the main advantage of ToU mode as far as I can tell. But then, I normally don't want to fully charge the battery (except right now where there's roughly a meter of snow on my panels) but instead I only want to charge what I think the battery can't get from the sun the next day. So most of the times the battery will only be charged to something between 40 and 80 percent I guess. Which makes the better fill-up functionality of ToU mode probably moot. My current conclusion is that the only scenario that would make the most sense is to let the battery run in ToU mode all the time and just setting different schedules according to electricity prices and sun forecast. Or did I miss something? — Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG4VUTAN3NNJDLWDFP4RKL3YHTNSZAVCNFSM6AAAAAAVRCBVTOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZXGU4DSNBVGY . You are receiving this because you were mentioned.Message ID: @.**>
I guess these things are only as smart as the people trying to program them...hence why I'm struggling with basic automations and setting up yaml files. 🤣🤣
I'm going to stick with these automations for now and monitor how I get on before I graduate on to more hard core HA tasks.
from ha_sonnenbatterie.
That's strange that your TOU get cleared...I've just checked my TOU settings that I put in previously (23.30 - 05.30) and after various automations run and it returns to the TOU settings, my times are still set. I'm running sonnen version 1.10.7
It would really help if you could place your comment near the part of my message you're referring to and delete the rest of the original message ;)
Anyway, I guess you misunderstood what I meant: When setting a schedule all formerly set schedules are deleted. It doesn't reset the ToU mode, I never wrote that (hopefully). And also when changing modes the schedules aren't touched (me hoping I didn't write that either ;)).
from ha_sonnenbatterie.
most sense is to let the battery run in ToU mode all the time and just setting different schedules according to electricity prices and sun forecast.
What I'd be interested in is whether I have to set the battery to threshold_p_max=0
to make it charge from excess solar power for times I don't want to charge from the net or whether this is done automatically. Unfortunately I can't test that right now since there's still too much snow on my panels.
I think this is the best mode for me at least. One factor to consider is that when in the TOU mode it seems to optimize the charging rate so that it gets to 100% in the time window you've provided
That's not my general use case. I probably never want the battery to charge to 100%. Depending on the solar forecast I'd be fine with "full enough to last for the day / expensive periods / periods with not enough sun".
from ha_sonnenbatterie.
from ha_sonnenbatterie.
Related Issues (20)
- Error in log: inverter_ststus_fac HOT 3
- Sensor reading total production HOT 8
- I cannot re-install integration HOT 8
- Can't find this integration in the HACS addon HOT 2
- Sonnenbatterie 10: tracking consumption + battery charging HOT 6
- Entities intermittently freeze and get unavailable HOT 9
- Change IP HOT 4
- Sensor Not set HOT 1
- Inverter_ipv2 problem HOT 1
- Fehler HOT 1
- Entities becoming unavailable HOT 2
- Request, not an issue - Show Operating mode HOT 11
- Button to start Manual Loading Process HOT 7
- Representation of the “Systemstatus” sensor HOT 4
- Question :: How to connect to Sonnen unit HOT 1
- Error on 75a3e8c update: "The version 75a3e8c for this integration can not be used with HACS." HOT 6
- https://github.com/weltmeyer/ha_sonnenbatterie.git is not a valid add-on repository
- Sensors Stop waorking and values freeze HOT 1
- Some meters report a value of `undefined` when their actual value is `0` HOT 9
- Internal Max Temp and Charge/Discharge status unavailable HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ha_sonnenbatterie.