Supporting spot energy pricing

You can test the binding I linked to in the Sonnen thread - https://smedley.id.au/tmp/org.openhab.binding.sonnen-5.0.0-SNAPSHOT.jar :slight_smile: I have Tesla PW2 here, so can’t test.

Edit: Actually, my memory was hazy - you can set the charging/discharging power using config parameters - I guess this assumes you ALWAYS want to charge/discharge at the same rate. These may be better as actual channels, but I copied the approach of the original binding.

I updated my branch and built a newer snapshot - https://smedley.id.au/tmp/org.openhab.binding.sonnen-5.2.0-SNAPSHOT.jar

Well, so that’s a static definition then we cannot dynamically override that to charge with a power amount case by case, correct?

My first attempt with the 5.1.2-contained binding also shows chargingPower is a mandatory Thing parameter (also it is not a documented parameter so at least the docs should be fixed).

Better though, could you turn this into a channel instead that can be set dynamically so users can adjust charging power in operation?

I can easily make the charge/discharge rate a channel so it can be easily changed, but a) I’m not the binding owner and b) I don’t have a sonnen system to test. Sounds like you may have a user than can test though?

Yes please add it, I have a user at hand that can test and will do for you.
You don’t have to be the binding owner to enhance this. Just put it up as a PR, that then will be confirmed by the author himself (assuming he’s still active else some maintainer will do).

Has the user you have at hand been able to test the force charge functionality? So at least I know that side works?

Edit: I should be able to update this today (Sunday) my time.

not yet but I’ll let you know asap. So I have to set the batteryChargingFromGrid and batteryDischargingToGrid switch items to on for charging/discharging, right?
And is the battery supposed to return to its default state when Ii set it back to off?

A quick first attempt failed, but I only this log output
2026-02-28 22:31:08.155 [DEBUG] [org.openhab.binding.sonnen.internal.SonnenHandler ] - Executing batteryChargingFromGrid command

but no visible effect.Maybe add some helpful debug outputs while you’re at it.

Have to finish for today, will get back to you tomorrow.

Still morning here, so hopefully by the time you wake up, I’ll have investigated. During my morning walk I figured if there’s logging that shows the http call to the sonnen gateway, I should be able to confirm the format/syntax is correct.

And as I understand it, yes the batteryChargingFromGrid and batteryDischargingToGrid switch items to on for charging/discharging, and things shuld revert to normal after.

btw I would expect some logging from openhab-addons/bundles/org.openhab.binding.sonnen/src/main/java/org/openhab/binding/sonnen/internal/communication/SonnenJSONCommunication.java at sonnenforcecharge Ā· psmedley/openhab-addons Ā· GitHub assuming debug logging is enabled.

Edit: https://smedley.id.au/tmp/org.openhab.binding.sonnen-5.2.0-SNAPSHOT.jar is updated and has 2x new channels for charge / discharge rate. Right now, this needs to be set first before the channel is switched on, I need to think on a better way to cache/remember this - or at least set a sensible default. I wonder if the maximum charge/discharge rate is set somewhere in the API and we could default to this?

Hi Paul, I’ve just tested your latest jar but couldn’t get charging/discharging to work.
I’ve linked the batteryChargeRate channel to a Number:Power item and sent 5000W, then issued ON to the switch item for the batteryChargingFromGrid channel.
It remained ON then switched back after some seconds.

I think the following error I’m seeing at times is key. Looks like the binding cannot properly access the battery with a POST because of an issue with the HTTP header.
I’m not seeing this on every command but on quite some. Guess there’s some sort of caching or similar involved resulting in not a full answer to every command.

2026-03-01 20:00:53.606 [DEBUG] [org.openhab.binding.sonnen.internal.SonnenHandler                ] - Executing batteryDischargingToGrid command
2026-03-01 20:00:53.609 [DEBUG] [hab.binding.sonnen.internal.communication.SonnenJSONCommunication] - Error processing Put request http://192.168.170.45/api/v2/configurations:  java.util.concurrent.ExecutionException: org.eclipse.jetty.client.HttpResponseException: HTTP protocol violation: Authentication challenge without WWW-Authenticate header

The command had no visible effect. Logging see below, it does nowhere show the 5000W I commanded.

2026-03-01 20:04:31.642 [DEBUG] [org.openhab.binding.sonnen.internal.SonnenHandler                ] - Update channel batteryChargingFromGrid with state ON
2026-03-01 20:04:31.758 [WARN ] [org.openhab.io.openhabcloud.internal.CloudClient                 ] - Error connecting to the openHAB Cloud instance: not authorized. Reconnecting after 60000 ms.
2026-03-01 20:04:36.116 [DEBUG] [org.openhab.core.model.script.Energiemanagement                  ] - SE-PV-1 errechne PVErzeugungsleistung = 0.0
2026-03-01 20:04:36.117 [DEBUG] [org.openhab.core.model.script.Energiemanagement                  ] - SE-PV-1 errechne PVErzeugungsleistung = 0.0
2026-03-01 20:04:39.736 [DEBUG] [hab.binding.sonnen.internal.communication.SonnenJSONCommunication] - BatteryData = {"Apparent_output":443,"BackupBuffer":"0","BatteryCharging":false,"BatteryDischarging":true,"Consumption_Avg":430,"Consumption_W":474,"Fac":49.95,"FlowConsumptionBattery":true,"FlowConsumptionGrid":true,"FlowConsumptionProduction":false,"FlowGridBattery":false,"FlowProductionBattery":false,"FlowProductionGrid":false,"GridFeedIn_W":-27.0,"IsSystemInstalled":1,"OperatingMode":"2","Pac_total_W":444,"Production_W":0,"RSOC":92,"RemainingCapacity_Wh":19063,"Sac1":443,"Sac2":null,"Sac3":null,"SystemStatus":"OnGrid","Timestamp":"2026-03-01 20:04:39","USOC":91,"Uac":230.0,"Ubat":211.0,"dischargeNotAllowed":false,"generator_autostart":false}
2026-03-01 20:04:39.737 [DEBUG] [org.openhab.binding.sonnen.internal.SonnenHandler                ] - Update channel batteryChargingState with state OFF
2026-03-01 20:04:39.738 [DEBUG] [org.openhab.binding.sonnen.internal.SonnenHandler                ] - Update channel batteryDischargingState with state ON
2026-03-01 20:04:39.739 [DEBUG] [org.openhab.binding.sonnen.internal.SonnenHandler                ] - Update channel batteryCharging with state 0 W
2026-03-01 20:04:39.739 [DEBUG] [org.openhab.binding.sonnen.internal.SonnenHandler                ] - Update channel batteryDischarging with state 444 W
2026-03-01 20:04:39.740 [DEBUG] [org.openhab.binding.sonnen.internal.SonnenHandler                ] - Update channel batteryChargingFromGrid with state OFF
2026-03-01 20:04:39.740 [DEBUG] [org.openhab.binding.sonnen.internal.SonnenHandler                ] - Update channel batteryDischargingToGrid with state OFF
2026-03-01 20:04:39.741 [DEBUG] [org.openhab.binding.sonnen.internal.SonnenHandler                ] - Update channel batteryOperationMode with state Automatic
2026-03-01 20:04:39.741 [DEBUG] [org.openhab.binding.sonnen.internal.SonnenHandler                ] - Update channel consumption with state 474 W
2026-03-01 20:04:39.742 [DEBUG] [org.openhab.binding.sonnen.internal.SonnenHandler                ] - Update channel gridFeedIn with state 0 W
2026-03-01 20:04:39.742 [DEBUG] [org.openhab.binding.sonnen.internal.SonnenHandler                ] - Update channel gridConsumption with state 27 W
2026-03-01 20:04:39.743 [DEBUG] [org.openhab.binding.sonnen.internal.SonnenHandler                ] - Update channel solarProduction with state null
2026-03-01 20:04:39.743 [DEBUG] [org.openhab.binding.sonnen.internal.SonnenHandler                ] - Update channel batteryLevel with state 91 %
2026-03-01 20:04:39.744 [DEBUG] [org.openhab.binding.sonnen.internal.SonnenHandler                ] - Update channel flowConsumptionBatteryState with state null
2026-03-01 20:04:39.744 [DEBUG] [org.openhab.binding.sonnen.internal.SonnenHandler                ] - Update channel flowConsumptionGridState with state null
2026-03-01 20:04:39.744 [DEBUG] [org.openhab.binding.sonnen.internal.SonnenHandler                ] - Update channel flowConsumptionProductionState with state null
2026-03-01 20:04:39.744 [DEBUG] [org.openhab.binding.sonnen.internal.SonnenHandler                ] - Update channel flowGridBatteryState with state null
2026-03-01 20:04:39.745 [DEBUG] [org.openhab.binding.sonnen.internal.SonnenHandler                ] - Update channel flowProductionBatteryState with state null
2026-03-01 20:04:39.745 [DEBUG] [org.openhab.binding.sonnen.internal.SonnenHandler                ] - Update channel flowProductionGridState with state null
2026-03-01 20:04:39.745 [DEBUG] [org.openhab.binding.sonnen.internal.SonnenHandler                ] - Update channel energyImportedStateProduction with state null
2026-03-01 20:04:39.745 [DEBUG] [org.openhab.binding.sonnen.internal.SonnenHandler                ] - Update channel energyExportedStateProduction with state null
2026-03-01 20:04:39.746 [DEBUG] [org.openhab.binding.sonnen.internal.SonnenHandler                ] - Update channel energyImportedStateConsumption with state null
2026-03-01 20:04:39.746 [DEBUG] [org.openhab.binding.sonnen.internal.SonnenHandler                ] - Update channel energyExportedStateConsumption with state null

Can you try something like:

  • curl -X PUT -d EM_OperatingMode=1 --header 'Auth-Token: TOKEN' http://SYSTEM-IP/api/v2/configurations
    

and see what the response is? I’ve read that batteries connected to a VPP cannot be put into manual mode.

Not sure if what I attempted was the right syntax, I tried

curl -X PUT -d EM_OperatingMode=1 --header 'Auth-Token: 49195bf9-xxxx-yyyy-a681-4f1e7e4e9f58' http://192.168.xxx.yyy/api/v2/configurations

and got {"error":"Unauthorized"}

I’m just copying the syntax from sonnenBatterie API so your example looks right to me. In theory, what the binding is calling is similar to the above, so if you’re getting a 401 unauthorised, that sorta makes sense (although the binding could handle it better). You’re sure the token is correct?

Another example of usage at Sonnenbatterie with APIv2 / Webhook - #108 by jesusrop - Share your Projects! - Home Assistant Community

Tried both, double-checked token - no, sorry.
Can we read out if the bat is in a vpp or do I have to ask the owner?

I don’t see anything at sonnenBatterie API that would confirm if the battery is part of a VPP or not - so I gues syou may have to ask the owner.

need to wait for his answer

No he’s not in the VPP

Interesting…. There’s some posts from 2024 at Einbindung Sonnenbatterie - viertueller AusgƤnge (wegen Tibber) - loxforum.com with some things that may help…

There’s 2 things in that post:

  1. the POST we tried is fine should work and should not generate 401, should it?
    We need to find out why it does not work.
    Does it send the combined header field (auth token + content type) mentioned in the posting?
  2. if in (probably default) self consumption mode it takes back control itself after some seconds.
    I know of other that behave similarly. This can be overcome by re-issueing the command any <n> seconds. Usually there’s also a system setting how many seconds a command lasts.
    Else we need to put the bat into manual mode (EM_OperatingMode := 1) and back (EM_OperatingMode := 2) when we’re done charging.
    That would be the preferred solution as I also successfully use that with various other vendor’s devices and you can also use that to prevent that some ev or heat pump drains your bat by ā€œdischargingā€ with 0 W.