Support Sessy battery

[Tazzios]

The Sessy is a Dutch home battery that was launched through a successful crowdfunding campaign in 2022. It has an active community, and the developers are highly engaged, listening closely to user feedback and continuously improving the product.

For Home Assistant integration, the community recommends the following custom integration:
https://github.com/PimDoos/ha-sessy

Examples of automating and controlling the battery can be found here:
https://github.com/PimDoos/ha-sessy-examples/tree/main/blueprints/automation/sessy

[github-actions[bot]]

Thanks for the suggestion! 🙌

Here's how this works:

• Vote by clicking 👍 on the original post — not in the comments
• The more votes an idea gets, the higher it moves in the priority queue
• I review feature ideas periodically and implement the ones that benefit the most users

If your idea is very specific to your setup, it may not make it into the core integration — I'll try to suggest a workaround in that case.

Feel free to discuss details or alternatives below.

[ffunes]

I am having trouble finding official documentation on how to develop software for this brand, Can you please point me to the official documentation?

Best regards

[Tazzios]

Controlling it with the integration from Pimdoos is pretty straight forward select.sessy_XXXX_power_strategy on API and number.sessy_XXXX_power_setpoint a power value negative for charging and positive for discharging

If you want to skip the integration and control it directly then i think you are looking for this:
Battery: https://www.sessy.nl/wp-content/uploads/2026/01/api_docs_dongle.txt
P1 meter: https://www.sessy.nl/wp-content/uploads/2026/01/api_docs_p1.txt
(rename to .yaml for syntax highlighting)
You maybe also can check the github code from Pimdoos to see how he has done it.

[ffunes]

#167

[Tazzios]

Wow,That is fast!

[ffunes]

Hi,

1.2.0b1 is out. Please test it and provide feedback on the new functionality.

Best regards

[Tazzios]

I would expect to see Sessy in this list, right?

[ffunes]

My bad! The configuration is only possible in the config flow. I will release a b2 version today with the options flow fixed.

[ffunes]

Hi, 1.2.0b2 is out.

[Tazzios]

First test results.

For the configuration
max charge is 2,2 kW
max discharge is 1,7 kW
minimal SOC is set to 12% needs to be 0 / 1%
Laadhysterese is minimal 2% could be 0 for sessy i think?

In the dashboard
device info is empty maybe the firmware version or something cloud be mentioned? or wifi strenght if connect with wifi.

Control
When enable control it mentions Noresponse. When trie to enable it manual 'force mode' switches back to none.

edit:
both batteries has sometimes not responding (but also responding 😄 )

[ffunes]

Hi,

New beta:

[1.2.0b3] - 2026-07-28

Fixed

• Sessy control authentication and device information: local API calls now use the username and password printed on the Sessy dongle, with credential fields available during setup, options and reconfiguration. This prevents control writes from being rejected and subsequently reported as “No response”. The dashboard now exposes the Sessy model, dongle firmware and Wi-Fi RSSI when available, links to the local device UI, and keeps a manually selected force direction visible while its power is still 0 W.
• Sessy SOC limits: setup and options now accept a 0–30% software minimum with a conservative 5% default instead of inheriting Marstek's 12% floor. The software maximum remains 80–100% with a 100% default and ceiling, matching Sessy's full visible SOC range.

The hysteresis is enforced by the integration, it is a minimum of 2% for all the batteries, this prevents pingponing at max soc.

[ffunes]

Hi,

Can you please provide feedback after the latest changes? I need to publish the 1.2.0 release.

[Tazzios]

It seems I am struggling with the basics. Also with only a Marstek on 2 HA installations it is not act how I thing it should work. As example not unloading in the night. So I think I have to figure that out first before I can say something about the Sessy integration. But that will be end of august.

[jenski]

Hi,

Just added the Sessy Batt to Omni but it reports unresponsive.. Tho It seems to have managed to put the Sessy on 'inactive=mode' comming from nom-mode.

[ffunes]

Please provide a debug.

[jenski]

sure,

config_entry-omnibattery-01KXMTXZK39KJ44W8568SH1YHF.json

[ffunes]

Hi,

I was asking for debugs to see what is the system reporting. You need to enable them manually.

I have just released a beta version with one fix for sessy driver:

Sessy could be marked non-responsive during startup: Sessy can take up to 60 seconds to transition from standby to safe running after its first API setpoint. The driver now allows 65 seconds, adding a small polling and network-latency margin so a healthy battery is not excluded while it is starting.

Can you please download 1.3.0b1 and test?

[jenski]

home-assistant_2026-08-03T21-00-34.208Z.log

Wow thats quick man. So, i've updated to ver 1.3.0b1 and turned on logging.

total steps taken;
1- switched off the sessy batt in de sessy integration (so, not deleted it)
2- added sessy batt in omni (already had done that but I ran through the setup so as to re-init omni)
3- updated omni to 1.3.0b1 and restarted HA
4- turned on debug logging and downloaded the log file

[jenski]

So, I've left it on for the night. It looks like Omni managed to use the Sessy batt yet it still reports unresponsive. I've refreshed the log but the log file is 40mb, so i've attached a screengrab.

[ffunes]

I am adding this to the next version: Sessy power writes could fail with Server disconnected: the local HTTP driver now avoids stale keep-alive sockets, consumes write responses and retries a control request once after rebuilding its client session.

[ffunes]

Hi, new betas are out, did you manage to test it?

[jenski]

home-assistant_2026-08-05T19-48-39.153Z.log

at first glance no big changes I'm afraid.

[ffunes]

Hi,

A new beta will be released with a fix:

Fixed

• Sessy authentication failures could look like a healthy connection: the initial probe now validates the protected strategy endpoint instead of relying only on the readable power-status endpoint, and repeated 401 responses are collapsed into one actionable credential warning.

Before releasing this version, can you reconfigure the battery and add the user and password that is shown in the Sessy dongle?

[jenski]

So, done the re-init. I think i forgot to fill in the 5kwh capacity value last time. Also, in the sessy integration changed the scan interval from 7 to 4 sec as I'm using the sessy P1 sensor as the main energy monitor.

So, today I saw the Martek;s being charged not only through net delivery but also by draining the sessy. Only after the Marstek's where full did the Sessy got charged by leftover solar power.

Question, why is Omni not reading 'total charged' etc?
So, below I copypasted the results of checking the API

http://[localip]/api/v1/energy/status
returns
{
"status": "ok",
"energy_phase1": {
"import_wh": 357,
"export_wh": 119
},
"energy_phase2": {
"import_wh": 0,
"export_wh": 0
},
"energy_phase3": {
"import_wh": 0,
"export_wh": 0
},
"sessy_energy": {
"import_wh": 3325596,
"export_wh": 2729452
}
}

[ffunes]

Hi,

Please let's divide this:

1. Is the battery connecting properly to Omnibattery? What are the debugs saying?
2. If the marstek charged by draining the Sessy, then I suspect that the connection was not done properly.
3. First let's have a proper connection and functionality, then we will get into the details.

[jenski]

I think I found out why. In the Sessy app on my phone I saw that the Sessy-batt was still in NOM-mode. That would explain the behaviour of the last couple of day's.

So, I've set it there to API-mode. Normally when I use scripts to control the Sessy I set it to API-mode and then set a value in Power-setpoint (ie. -1000 to charge a 1000Watts). So Omni tries use the sessy batt but it's is not responding, it just sit still. Even when setting Omni in manual-mode it did not respond.

This was yesterday and so for today I did a re-init of Omni but now with just the 2 Marstek's, and saw it left the Sessy devicepage as an empty device in the overview, deleted that empty device. Then re-init and added the Sessy.
This seems to work! The Sessybatt responds to manual-mode and the no-response-error seems to stay away. I even see that Omni reads 'total charged and the diagnostic values

I will follow it through the day to see how it all runs on auto and report back here. But for now it seems to work as it should.