As said by Robert just a few documentation and Sonnen is not very collaborative on this.
This is what I’m planning to do (moving a bit slowly and still to fully test the commands, but I was able to switch from automatic to manual mode and viceversa)
In configuration.yaml:
## Shell commands
shell_command:
# Definition of shell commands to invoke API endpoints for Sonnen batteries
set_operating_mode_sonnen_battery: curl -X PUT -d EM_OperatingMode={{ operating_mode }} --header 'Auth-Token{{':'}} {{ token }}' {{ api_endpoint }}
dis_charge_sonnen_battery: curl -d -H -X POST --header 'Auth-Token{{':'}} {{ token }}' {{ api_endpoint }}/{{dis_charge_command}}/{{ dis_charge_value }}
And then in an automation.yaml file (keep in mind this would not work if you create the automation through the UI - the !secrets are replaced when the automation gets loaded by HA)
- id: 'sonnen_8_manual_operating_mode'
alias: "Sonnen 8 manual operating mode"
description: "Imposta la Sonnen 8 in modalità manuale così che la carica/scarica possa comandata via API"
trigger: []
condition: []
action:
- service: shell_command.set_operating_mode_sonnen_battery
data:
operating_mode: 1
token: !secret sonnen_8_api_token
api_endpoint: !secret sonnen_8_configurations_api_endpoint
mode: single
These two pieces of code together build the final command (I tested via PC terminal), for example to put the battery into Manual mode:
curl -X PUT -d EM_OperatingMode=1 --header 'Auth-Token: xxxxxxxxxxxx' http://192.xxx.xxx.xxx/api/v2/configurations
Thanks for sharing the EMHASS project, I’ll have a look.
At the moment I’m thinking to switch to manual mode and charge during the off-peak time with cheapest rates when the remaining capacity plus the forecasted production can’t cover tomorrow’s forecasted energy needs (median over the past 8 days) and then stop when I reach this equivalence.
The fact is that I should be able to dynamically adapt the charge power depending on the consumption (heating may start at night in winter and I don’t want to exceed the max allowed contractual power) and on how close I am to the end of the off-peak time-window.
I know, quite complex (probably I have to accept compromises), but maybe this project will give some ideas!
The benefit of EMHASS is that it makes available several methods for analysing all the forecasts and history (sun, supply costs, feed-in tariff, load history, current battery charge etc) and come up with a plan or schedule for charging and discharging, switching deferrable loads on and off (hot water, pool pumps, car chargers etc) to take advantage of the crests and troughs of supply cost and FiT profit.
The most accurate and most difficult to configure is Model Predictive Control MPC, a control model that continuously reanalyses the data to adjust the schedules (every 5 minutes or 1 min or 30 sec whatever you want). EMHASS has other models as well such as linier, that are more rudimentary and simpler to implement.
Graphic representation of today’s schedule (which still isn’t right as I haven’t got the PV data working correclty):
So I use the Batt Forecast (green) to charge and discharge the battery. I use the amplitude of the curve (in Watts) in the POST to the sonnen API to drive the battery.
Negative Batt Forecast or say -3300W means charge the battery at 3300 Watts, positive discharge.
The Pool (purple) is used to switch the pool pump on and off (simple switch on and off no control over wattage as it’s a constant 1500W pump). Yet to add the car charger but it would be a variable load.
Rob
This looks really promising. Thanks for your time in putting it together.
Now I have no excuses for not diving in deep. I’ll no doubt be in touch when I stuff something up.
Pat
I would like to have the configuration for the 5 buttons for controlling the solar battery. Unfortunately I can’t read what I need to do to implement this. I currently have the addon from GitHub - weltmeyer/ha_sonnenbatterie: Homeassistant integration to show many stats of Sonnenbatterie Weltmeyer in HA and the Sonnenbatterie with APIv2 / Webhook in the configuration.yaml from the first post. I don’t have Node-Red, my HA runs on Raspi, but I would like to automate battery charging depending on the expected solar output.
Kind Regards
These are the elements in the Node-Red Function Node for REST API call for manual mode. Translate them into a rest_command in yaml.
rest_command:
sonnen_manual_mode:
url: http://YOUR BATTERY IP ADDRESS:80/api/v2/configurations
method: PUT
headers:
authorization: your sonnen API Token
content_type: 'application/x-www-form-urlencoded'
payload: 'EM_OperatingMode=1'
If I set to manual mode and charge rate 7000 (sb performance 10) with start charging via rest command, the SB stop charging after 30 - 45 sec? and go back to automatic? do you have a glue why?
Do you also see an OperatingMode switch, as reported by Uwe?
Can you maybe add this to the previous chart?
Maybe the Sonnen service needs some time to check with the HQ as they are off in Germany right now. I may also try to investigate with the Italian support team… maybe I’m luckier than you, even if not easy as I’m not experiencing this behavior (so far I’ve never charged at max power).
While replying to Uwe I noticed that the inverter, for a SB 10, has max 95% efficiency. Maybe you could check for your model, do not exceed the resulting value and see if this happens again.
EM_OperatingMode=1 puts the battery into manual mode that allows POST commands to charge and discharge.
EM_OperatingMode=2 puts the battery into automatic (self consumption) mode