Fix: Detected blocking call to open inside the event loop by custom integration

removed 'local' reading of manifest.json

+fix-it

Maintenance release: addressing 'HomeAssistantType' deprecation warning

This update will fix the warning

HomeAssistantType was used from <integration-name>, this is a deprecated alias which will be removed in HA Core 2025.5. Use homeassistant.core.HomeAssistant instead, please report it to the author of the '<integration-name>' custom integration

when starting HA

WebAPI: Make sure that "auto" will work also in multi-device scenarios

fix for #82

Fix for #80 [WEB-API was not working after recent update]

Thanks to @scottgoo for your report and the provided logs

WebAPI: Usage of APP-APIs - new Sensor's | Wallbox Control adjustments

WebAPI: Usage of APP-APIs

Finalize implementation for #42 - finally mein-senec.de access is only required when you use PeakShaving & SpareCapacity Settings

In this BETA release, the WebAPI Integration has been adjusted to pull data from the API that the SENEC Mobile App is using (instead make use of the mein-senec.de portal). Via the APP-API it's possible to fetch additional information that was previously not available. While SENEC V2 and SENEC V3 users might be not too excited, SENEC V4 users have now the additional Sensor Entities available:

• System State
• Case Temperature
• Battery State Current (A)
• Battery State Voltage (V)
• Battery Inverter State (disabled by default)
• Battery Temperature
• Battery max Tempeature (disabled by default)
• Battery remaining capacity
• Battery Module A-F States (only A enabled by default)
• Battery Module A-F Ø Temperature (only A enabled by default)
• Battery Module A-F min. Temperature (all disabled by default)
• Battery Module A-F max. Temperature (all disabled by default)

It would be cool, if this will work smoothly for all of you - if you want to share any feedback - please just add it the #42 issue - TIA!

The latest release [2024.0.8 + 2024.0.9] persist the APP-API-TOKEN so after a restart the connection should be faster cause a previously fetched access token will be used (instead of requesting a "new" one with each restart) - it must be assumed, that SENEC's TOKEN have no expire time. WEB based API knowledge (or the will to follow best practice) seams to be limited.

With this version [2024.1.1] the logging as been extended (which hopefully help when there are issue reports)

Wallbox Control adjustments

• Supporting two different optimization modes: with/without 'charge interruption'
• Fixing #72 (took me quite a long time to understand the issue)

Other

Fixing issues during integrations reloads (e.g. when adjusting the update interval)

Credits for input

• @iot-sle
• @Schlolle
• @oakdesign
• @bobthebuilder4711

Wallbox Control + Socket Control + BugFix for #68

DISCLAIMER

Use this integration - specially this new wallbox control functionality on your own risk

Control your Wallbox

Before, owners of a SENEC wallbox, must use the SENEC mobile app in order to control the wallbox device. This 'remote-control-functionality' implies, that it takes a certain amount of time till a change in the mobile app will be synced with your local device. I was not aware of this 'delay'-situation (since I do not have a wallbox installed - and probably I will not get one from SENEC). At the end of December (2023) I was contacted by Sigurd L. and was asked, if it would be possible to support wallbox control with this SENEC.Home Integration.

The challenge for the integration is, that on the one hand it has to be ensured that the appropriate values in the local SENEC device will be set and make sure on the other hand that at the same time, that also the corresponding adjustments will be done in the SENEC Backend infrastructure (where the mobile app going to make the adjustments). And of course all that have to be done without any documentation and a really wired mix of parameter names - so please use this functionality on your own risk!.

When the Integration would adjust the wallbox setting in the local SENEC device only, then these changes will be reverted/overwritten after a short while with the data provided by the central SENEC backend. So this Home Assistant integration will set values in your local SENEC device as well as via the APP-API (web based) simultaneously - so that the central SENEC backend and your local SENEC device are in sync.

Please Note: When you're going to adjust the Wallbox setting via the SENEC mobile app, your local SENEC device will still get synced with these adjustments after a short while (typically 5minutes). In such a case the values in the Home Assistant Integration will be also updated to your 'remote' adjustments.

Supported wallbox control features:

• Select the current Wallbox Mode: LOCKED / FASTEST / OPTIMIZED
• When Mode OPTIMIZED is active you can adjust the charging current (IC_MAX)
• When FASTEST is enabled you can switch 'allow intercharge' (use energy from your SENEC battery)

Setup requirements

When you want to control your wallbox via Home Assistant and this integration, you need to configure:

1. the LAN: SENEC.Home V3 hybrid/SENEC.Home V3 hybrid duo or SENEC.Home V2.1 or older and
2. also the WebAPI: mein-senec.de Portal (usable with all SENEC.Home variants)

Only if both components are configured the Wallbox Control can work correctly!

Renamed Wallbox Entities - incompatible change!

Each Senec Device supports up to four wallboxes - in previous versions of this integration all entities of the first wallbox started with just wallbox_, then the second wallbox entities starting with wallbox_2_ - the third with wallbox_3_ and the final one with with wallbox_4_ . With this release the entities for the first wallbox have been renamed to wallbox_1_ and the Names will now also contain the 'Roman numeral' I.

SOCKET Control

As requested in issue #63 this update provide entities for all SOCKETS fields if they are available on your device. Please note that this implementation could not be verified here with my local Senec Hardware (but vars.html showed all adjusted values) - So I am looking for some feedback

Fixes warning at HA start

fix for issue #68

Maintenance

WebAPI Variant

Own/seperate aiohttp sessions per added system Thanks @ml1nk fixing #56

Local-polling-Variant

Added option (simply open Integration Options Dialog) to disable the System Status check for battery charging/discharging sensors - this might tackle #55

WebAPI: PeakShaving fix

Thanks @io-debug for fixing my sloppy snake_case refactoring...
fix for #51

also in this build the logging for "CookieJar purging" by other integrations have been reduced to once every 24h

WebAPI: Control the CookieJar.clear(...) process

In issue #43 it was discovered that some extensions will clear the cookiejar (purge all cookies) - This is fine, when you have control over the web session (to which the cookiejar belongs to) - but in the case of home assistant all Integrations are sharing the web session - and with that the cookiejar - so when integration A purge all cookies the Integration B can be in trouble...

Exactly this has happen to @GregorEstebanCardosoSchiller with the HACS Tapo Controller Integration. Instead of waiting for another developer to fix the root cause in his integration, I have decided to take control over the Cookie JAR and "keep" at least the cookies created by the WebAPI integration when somebody will call 'clear' on the web session cookiejar object...

Fix for #46 - "Emergency Charge" state (=33) is considered as CHARGE state

Thanks @iot-sle for your report - lucky enough my system did not went to state 33 (yet)