Releases: marq24/ha-goecharger-api2
WebSocket FTW! - This integration now support 'local/cloud push' [+rollback fix]
'Rollback fix': Charger/Controller PWD can be removed now
In the initial release there was no way back from the websocket to the polling version. I have to admit, that I don't see any reason why somebody want to go back from the WebSocket to the polling the REST-API, but at least this should work.
So when you are just got sick of the slick and instant updated of the WebSocket implementation: open the configuration of your integration entry and remove the password and press the 'submit' button.
Support for WebSocket communication
TL/DL; Open the integration Configuration, specify your go-eCharger Password and wait till the integration is restarted. You are now using WebSocket communication.
At the weekend I have realized, that beside the very vell documented HTTP v2 API the go-eCharger is able to communicated via a WebSocket connection (unfortunately this great feature is not documented).
Using WebSockets make polling/requesting data from the Wallbox obsolete, since the wallbox will actively provide any new values/data via the WebSocket communication channel as soon as the data changes. So the integration does not have to ask for possible new data (and guess what might have changed) - by using the WebSocket the integration will be be instantly notified. This simplify plenty of things.
As initially mentioned, there is no official documentation available - so there might be some surprises coming in the future. In any case there is always the option to fall back to the initial implemented data-polling procedure.
In order to be able to use the new communication method, you must specify the go-eCharger password in the integration configuration (a new optional input field have been added). Why? I order to establish a WebSocket connection (local or cloud), your specified password, your device serial number (and two additional tokens received during the initial handshake) will be used to calculate a final authorisation-hash. This hash will be send to the device and once it's accepted the WebSocket can be used to exchange data. So the actual password you specify in the integration configuration will not been send anywhere.
I am looking forward to your feedback! You don't have a single clue, what's your current wallbox password? Well changing it, is quite simple- you can do it via the go-eApp -> Settings -> Security -> Password.
What is the difference between pull (http get) vs. push (WebSocket)?
A WebSocket connection provides a persistent, two-way communication channel between a client and a server, whereas an HTTP GET is a one-time request that typically ends after the server responds. The primary advantages of using WebSockets over traditional HTTP GET requests include:
- Full-Duplex Communication: Both the client and server can send data simultaneously and independently. In contrast, HTTP is half-duplex, meaning data flows in only one direction at a time.
- Reduced Overhead: After the initial handshake, WebSocket messages (frames) are sent with very small headers (as little as 2 bytes). HTTP GET requests must include full headers (e.g., cookies, user-agent) with every request, which can be hundreds of bytes.
- Lower Latency: Since the connection remains open, there is no need for the "handshake" process (TCP three-way handshake and TLS setup) for every interaction. This makes data exchange nearly instantaneous, which is critical for real-time apps.
- Server Push Capabilities: In a WebSocket connection, the server can proactively push data to the client as soon as it is available. With HTTP GET, the client must usually "poll" the server periodically to see if there is new data, which is inefficient and creates delays.
- Persistent State (not relevant for this integration): WebSockets are inherently stateful, meaning the server can easily track the client's session over the single, long-lived connection. HTTP is stateless, requiring extra mechanisms like cookies or tokens to maintain context between separate GET requests.
Other stuff
As reported in #111 the Integration device did not show up in the autogenerated dashboards that have recently been introduced by HA. It would not be a surprise, that I am not a fan of these new kind of dashboards that should make it easier for new HA-users - I totally disagree with this approach - but that's a different story. Of course CONFIG or DIAGNOSTIC Entities will not show up in this autogenerated Dashboards. sigh
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.
WebSocket FTW! - This integration now support 'local/cloud push'
Support for WebSocket communication
TL/DL; Open the integration Configuration, specify your go-eCharger Password and wait till the integration is restarted. You are now using WebSocket communication.
At the weekend I have realized, that beside the very vell documented HTTP v2 API the go-eCharger is able to communicated via a WebSocket connection (unfortunately this great feature is not documented).
Using WebSockets make polling/requesting data from the Wallbox obsolete, since the wallbox will actively provide any new values/data via the WebSocket communication channel as soon as the data changes. So the integration does not have to ask for possible new data (and guess what might have changed) - by using the WebSocket the integration will be be instantly notified. This simplify plenty of things.
As initially mentioned, there is no official documentation available - so there might be some surprises coming in the future. In any case there is always the option to fall back to the initial implemented data-polling procedure.
In order to be able to use the new communication method, you must specify the go-eCharger password in the integration configuration (a new optional input field have been added). Why? I order to establish a WebSocket connection (local or cloud), your specified password, your device serial number (and two additional tokens received during the initial handshake) will be used to calculate a final authorisation-hash. This hash will be send to the device and once it's accepted the WebSocket can be used to exchange data. So the actual password you specify in the integration configuration will not been send anywhere.
I am looking forward to your feedback! You don't have a single clue, what's your current wallbox password? Well changing it, is quite simple- you can do it via the go-eApp -> Settings -> Security -> Password.
What is the difference between pull (http get) vs. push (WebSocket)?
A WebSocket connection provides a persistent, two-way communication channel between a client and a server, whereas an HTTP GET is a one-time request that typically ends after the server responds. The primary advantages of using WebSockets over traditional HTTP GET requests include:
- Full-Duplex Communication: Both the client and server can send data simultaneously and independently. In contrast, HTTP is half-duplex, meaning data flows in only one direction at a time.
- Reduced Overhead: After the initial handshake, WebSocket messages (frames) are sent with very small headers (as little as 2 bytes). HTTP GET requests must include full headers (e.g., cookies, user-agent) with every request, which can be hundreds of bytes.
- Lower Latency: Since the connection remains open, there is no need for the "handshake" process (TCP three-way handshake and TLS setup) for every interaction. This makes data exchange nearly instantaneous, which is critical for real-time apps.
- Server Push Capabilities: In a WebSocket connection, the server can proactively push data to the client as soon as it is available. With HTTP GET, the client must usually "poll" the server periodically to see if there is new data, which is inefficient and creates delays.
- Persistent State (not relevant for this integration): WebSockets are inherently stateful, meaning the server can easily track the client's session over the single, long-lived connection. HTTP is stateless, requiring extra mechanisms like cookies or tokens to maintain context between separate GET requests.
Other stuff
As reported in #111 the Integration device did not show up in the autogenerated dashboards that have recently been introduced by HA. It would not be a surprise, that I am not a fan of these new kind of dashboards that should make it easier for new HA-users - I totally disagree with this approach - but that's a different story. Of course CONFIG or DIAGNOSTIC Entities will not show up in this autogenerated Dashboards. sigh
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
Data Refresh on User Request
Added Request Data Refresh Button
In order to support #108 a separate button have been added
Force data refresh after values written
removed the 10 sec delayed auto refresh
Other stuff
Make sure that service (PV surplus) date send procedure will use the same client error handling as the data refresh part (that was introduced in 2026.2.3)
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
LOT.DYN & auto refresh cycle
LOT.DYN key
As requested in #109 the LOT.DYN Sensor should not be affected by the optional 16k limit
Force data refresh after values written
With this new release the integration will force a complete data refresh cycle (update of all sensors/configs) after 10 second. So if there are any additional changes in the wallbox data, you should get the latest information. Please note, that this of course only work, when you set the values via this integration. [I hope this will help for #108]
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
Revised handling of 'ClientConnectionError' / HA 2026.2 adjustments
Revised handling of 'ClientConnectionError'
Since a couple of weeks there are different reports about instable wallbox connections (started with the release of the 60.x beta firmware). Looks like that all previous adjustments attempts have not been successful.
With this release most of the changes of the past weeks have been rolled back and an alternative approach (restarting the integration via code) has been implemented - Thanks @markahon for your input.
HA 2026.2 adjustments
The upcoming release of HA 2026.2 requires an update of this integration. That's why it's so important, that an integration will be actively maintained.
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
Contributors
Assets 3
HA 2026.2 adjustments (patched)
HA 2026.2 adjustments
The upcoming release of HA 2026.2 requires an update of this integration. That's why it's so important, that an integration will be actively maintained.
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
HA 2026.2 adjustments
HA 2026.2 adjustments
The upcoming release of HA 2026.2 requires an update of this integration. That's why it's so important, that an integration will be actively maintained.
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
HA 2026.2 adjustments
HA 2026.2 adjustments
The upcoming release of HA 2026.2 requires an update of this integration. That's why it's so important, that an integration will be actively maintained.
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
I am a bad developer
Fix
Fixing issue #103
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
Basic support for Schedules (Ladezeiten)
Schedules (Weekdays, Saturdays, Sundays)
With the new release you can select the Mode of the three existing Schedule objects as requested in #102
- 0: Deactivated
- 1: Loading
- 2: Blocked
- 3: Loading (Surplus active)
- 4: Blocked (Surplus active)
Yes you still can not set the start & end times (yet) via this Integration - but having at least the option to activate/deactivate them is the right step to do.
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