Possible fix for unavailable Sensors

Possible fix for unavailable Sensors

I have found a possible reason that could cause sensors becoming unavailable. We will see, if my assumption was/is correct - I'll keep my fingers crossed.

Please consider supporting me

Thanks to those who have already supported me in the past weeks or month that is highly appreciated! To the other users: I am putting quite an amount of energy and passion into this integration. Perhaps you could give yourself a little push (if you can afford it) and become a sponsor.

If you haven't starred this integration in Github yet - please do so - TIA

Fix for Force Configuration Update Button (when using WebSocket)

Force Configuration Update Button

When using the WebSocket connection, pressing the Force Config Update Button had no effect, since the ws_data container was not updated with the new values. So IF we have the situation, that some data is updating internally in your wallbox (like frc) but for what ever reason this new data does not arrive via the WebSocket, then using now the force update button will show you the new values. When you enable the debug log, you should be able to see, which fields/sensors will be updated by the button action.

Please consider supporting me

Thanks to those who have already supported me in the past weeks or month that is highly appreciated! To the other users: I am putting quite an amount of energy and passion into this integration. Perhaps you could give yourself a little push (if you can afford it) and become a sponsor.

If you haven't starred this integration in Github yet - please do so - TIA

2026.4.4

Reduce data update frequency to at least one second

As mentioned in #135 the WebSocket can create some states to change very frequent (technically every 300ms) and this could overload your HA states db (details can be found in #135). With this new release the integration makes sure, that the minimum data update interval (no matter how fast data arrives via the WebSocket) will be one second.

Additional configuration setting

If you enable the new Apply 'Polling Interval' also to WebSocket updates option, the sensors will only be updated at the configured update interval - even when used the WebSocket connection.

E.g. when you have selected 10sec for the polling-data-from-your-goe-device, then the data in HA will be also updated (just) every 10 seconds, even if the integration has received multiple updates via the established WebSocket connection. Of course only the latest data will be populated to your HA .

Completed migration to CoordinatorEntities

I have fully transitioned the integrations DataUpdateCoordinator to utilize the CoordinatorEntity pattern. As part of this update, all "classic" polling logic—specifically individual async_update methods within each entity—has been completely removed.

Key Improvements:

• State Consistency: All entities update simultaneously as soon as the coordinator receives new data, ensuring a unified state across the dashboard.
• Modern Standards: By removing legacy polling logic from individual sensors, the codebase is now cleaner, more maintainable, and fully aligned with current Home Assistant Best Practices.

Please consider supporting me

Thanks to those who have already supported me in the past weeks or month that is highly appreciated! To the other users: I am putting quite an amount of energy and passion into this integration. Perhaps you could give yourself a little push (if you can afford it) and become a sponsor.

If you haven't starred this integration in Github yet - please do so - TIA

`fst` can now be a negative number [fixed]

This release will implemented the enhancements suggested in #134 - allow negative values for fst (JFYI: sensor is not active by default)

Note for myself - don't do released shortly after 7am!

Please consider supporting me

Thanks to those who have already supported me in the past weeks or month that is highly appreciated! To the other users: I am putting quite an amount of energy and passion into this integration. Perhaps you could give yourself a little push (if you can afford it) and become a sponsor.

If you haven't starred this integration in Github yet - please do so - TIA

`fst` can now be a negative number

This release will implemented the enhancements suggested in #134 - allow negative values for fst (JFYI: sensor is not active by default)

Please consider supporting me

Thanks to those who have already supported me in the past weeks or month that is highly appreciated! To the other users: I am putting quite an amount of energy and passion into this integration. Perhaps you could give yourself a little push (if you can afford it) and become a sponsor.

If you haven't starred this integration in Github yet - please do so - TIA

RoundingMode is writeable & German Translation adjustments

This release will implemented the enhancements suggested in #127 & #128. In order to avoid a breaking change with #128 the previous sensor for the tag frm still exists - so you have the value now twice - once as readonly and a second select.

Please consider supporting me

Thanks to those who have already supported me in the past weeks or month that is highly appreciated! To the other users: I am putting quite an amount of energy and passion into this integration. Perhaps you could give yourself a little push (if you can afford it) and become a sponsor.

If you haven't starred this integration in Github yet - please do so - TIA

Logging enhancement (no functional change)

Logging of WebSocket payloads

I realized yesterday, that when you send data via the websocket that in the case of an error/issue, you don't see any information what content (request) was send to the wallbox. So you just had the information 'something was not processed correctly'. With this release the integration will also log the payload that was send via the WebSocket connection.

Please consider supporting me

Thanks to those who have already supported me in the past weeks or month that is highly appreciated! To the other users: I am putting quite an amount of energy and passion into this integration. Perhaps you could give yourself a little push (if you can afford it) and become a sponsor.

If you haven't starred this integration in Github yet - please do so - TIA

WebSocket implementation fix

A WebSocket fix

Looks like that 'null' must be written different in the WebSocket implementation as reported in #124. With the new release the code will write python 'None' value (instead of the string 'null').

Please consider supporting me

Thanks to those who have already supported me in the past weeks or month that is highly appreciated! To the other users: I am putting quite an amount of energy and passion into this integration. Perhaps you could give yourself a little push (if you can afford it) and become a sponsor.

If you haven't starred this integration in Github yet - please do so - TIA

go-e Charger CORE/CORE PRO support [v2]

go-e Charger CORE

After I have received a test unit from go-e last week, I managed to wire a CORE device to my CEE plug this morning and finally could power it up. It look a little while, till I found the Reset-RFID card with all the credentials printed onto it (I guess for my Gemini it was just the same, but I could not remember). Anyhow... once more thanks that go-e was so kind to provide me with such a temporary test unit, so I am able to adjust the existing integration and so I did some fine tuning for the start.

One of the main differences (to previous go-e models) is that the new go-e Charger CORE series comes with fixed cable. So all options that are dealing with locking/unlocking the cable with the box are obsolete for the CORE units. So these entities should not appear for this new device type [CUS, FFB, LCK, UPO, SDP, BAC, CBL and UST]. On the other Hand, the CORE have already some additional temperature values, which have been integration with this release [Temperature Sensor III - VI].

There are probably more additional things, the CORE device will support in the future (I am really looking forward to ISO-15118 features) - We will see what I can discover in the next couple of weeks.

Once again big kudos @goecharger for making this possible!

Please consider supporting me

Thanks to those who have already supported me in the past weeks or month that is highly appreciated! To the other users: I am putting quite an amount of energy and passion into this integration. Perhaps you could give yourself a little push (if you can afford it) and become a sponsor.

If you haven't starred this integration in Github yet - please do so - TIA

Compatibility enhancements for older HA Versions

bcrypt dependency downgrade

Looks like, that older HA systems can't DL/compile the latest bcrypt python package 5.0.0 (which was declared as required for this integration) With this release the requirement has been downgraded to lib version 4.2.0 (where the binaries hopefully are also available for older HA versions)

Please consider supporting me

Thanks to those who have already supported me in the past weeks or month that is highly appreciated! To the other users: I am putting quite an amount of energy and passion into this integration. Perhaps you could give yourself a little push (if you can afford it) and become a sponsor.

If you haven't starred this integration in Github yet - please do so - TIA