Time of Use functionality?

[whistlebare]

Time of Use functionality?

[atimgraves]

There are some example tests that show how to use it, but these are only the "driver" part of the code. I'm also working on some updates for ha_sonnenbatterie that will bring some of these (battery mode, you schedule and reserve) in as ha entities and ultimately will make them controllable from within the home assistant UI. As I'm not that familiar with the way HA operates (and this is my first python programming experience) however that's not ready yet.

…

On Fri, 21 Jul 2023 at 11:17, whistlebare ***@***.***> wrote: That's brilliant news...Are there any guides that can help with setting this up @atimgraves <https://github.com/atimgraves>? I'm a little new to this stuff — Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG4VUTES4WNJWRIAP73SYQTXRJJMPANCNFSM6AAAAAAVRCBVTM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[weltmeyer]

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.

[weltmeyer]

Just check the tests. OperationMode for example: https://github.com/weltmeyer/python_sonnenbatterie/blob/master/test/test_operating_mode.py

[alsFC]

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.

[RustyDust]

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:

[atimgraves]

>> 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: ***@***.***>

[xlibbyx]

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

[whistlebare]

Thanks for the info, I'm in the process of getting my dashboard all set up and then I'll tinker with this.

…

On Mon, 6 Mar 2023, 19:25 xlibbyx, ***@***.***> wrote: 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 — Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A6IZTTEBZ5KI6KRCT4EYSW3W2Y2ZTANCNFSM6AAAAAAVRCBVTM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[RustyDust]

I'll have a look, sounds interesting ;)

[RustyDust]

@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.

[whistlebare]

Brilliant thank you...I'm not in a position to test this for a few weeks but will give it a shot. I might come back to you if I get stuck 😅

…

On Sun, 26 Mar 2023, 14:10 stefan, ***@***.***> 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": "<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. — Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A6IZTTHD66ELWAMXKFNUPTLW6BE5NANCNFSM6AAAAAAVRCBVTM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[whistlebare]

That's brilliant news...Are there any guides that can help with setting this up @atimgraves? I'm a little new to this stuff

[whistlebare]

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.

[alsFC]

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

[atimgraves]

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: ***@***.***>

[whistlebare]

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...

[whistlebare]

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 😂

[atimgraves]

OK the current implementation is focused on the configuration settings (currently operating mode, tou, reserve), but I can add the setting charge / discharge quite easily I think. I'll have to then figure out how to implement these as services (my current task)

…

On Fri, 21 Jul 2023 at 13:23, Alexander Strotmann ***@***.***> wrote: 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 — Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG4VUTFXR5FBNUA4WO2DXBLXRJYCNANCNFSM6AAAAAAVRCBVTM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[rcruikshank]

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

[rcruikshank]

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

[whistlebare]

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.

[atimgraves]

So I've tested that settings (taking the deviceInfo frpm the main coordinator) and ensured that when creating my "special" entities for battery reserve, you schedule and operating mode that are using the same content. I can't see what I'm doing differently between these, can you have a look - it seems to be the battery reserve that is consistently putting itself as a different device, whereas the operating more and you schedule are (at least now) both showing up correctly as being under the "main" device. Yet they all have the same settings for device info passed in by the code that creates them (this is in the special settings code as I was tryign ot minimize changes to your code as much as possible). I suspect I'm doing something that's obviously wrong but I just can;t see it. This is the last thing that needs to be fixed, I have been running the other items (operating mode, tou schedule, setting and retrieving on schedules and so on) in my test setup successfully for the last 3 weeks. My repo / branch is at https://github.com/atimgraves/ha_sonnenbatterie/tree/extended-services Thanks, Tim

…

On Fri, 21 Jul 2023 at 14:00, Alexander Strotmann ***@***.***> wrote: 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. — Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG4VUTAP6MQ4JG2DTZZWWZDXRJ4NFANCNFSM6AAAAAAVRCBVTM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[weltmeyer]

@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...

[whistlebare]

@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.

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....

[RustyDust]

@whistlebare

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?

Correct.

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" ?

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.

[atimgraves]

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": "<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. 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: ***@***.***>

[whistlebare]

@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

[whistlebare]

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

[RustyDust]

@whistlebare

@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.

[whistlebare]

@whistlebare

@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 👍🏼

[RustyDust]

@atimgraves

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.

[atimgraves]

I've put a gate check in my code to ensure that the core sonnen code has done a full initialization before my main code starts configuring things

…

On Sat, 2 Dec 2023 at 17:07, stefan ***@***.***> wrote: @atimgraves <https://github.com/atimgraves> 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. — Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG4VUTCDDNS3FVTDXNNMMG3YHNN5NAVCNFSM6AAAAAAVRCBVTOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZXGIYDINRTGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[whistlebare]

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?

[whistlebare]

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.

[whistlebare]

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:

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 :-)

[whistlebare]

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:

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

[whistlebare]

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...

[RustyDust]

@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?

[whistlebare]

@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?

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

[whistlebare]

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.

[RustyDust]

@whistlebare

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 ;)).

[RustyDust]

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".

[atimgraves]

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. IFor my battery (Hybrid 9.53) if it's in TOUmode then it will automatically charge from the panels that are connected directly to it if there is any excess at the house level. However ... I have a second set of solar panels that were installed prior to the battery going in and in TOU mode it does not take account of those when deciding to charge (i.e. it will only charge fomo the directly connected ones) in TOU mode. In Automatic mode however it will charge if there is any excess at the house level across all of the panels. I personally think this is a bug in the sonnen software as this behaviour only started after an upgrade earlier in the year, prior to that upgrade TOU mode would also charge if both sets of panels were producing an excess at the house level. I raised this with sonnen support and they said that I should have an additional sensor on the other panels, though why it did work properly in TOU mode and then stopped working they didn't answer. My main reason for updating the HA sonnen battery mode is to automatically switch from TOU and Automatic mode so as to maximise the storage of generation from both sets of panels, then I'm going to figure out optimised charge levels, but you can also handle some of that using the minimum battery reserve (going to a higher battery reserve then the current stored charge causes my battery to automatically start charging until the battery reserve is reached)

…

On Mon, 4 Dec 2023 at 13:49, stefan ***@***.***> wrote: 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". — Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG4VUTENS7DGK42FX5JDMKTYHXIFDAVCNFSM6AAAAAAVRCBVTOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZYGY3TSNZWHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>