I’m no specialist, but does that not indicate that the Wallbox cloud actively refuses the connection?
I see this happen after precisely 15 minutes every time, which also makes me believe the disconnect is purposely. Can anybody confirm they see the 15 minute timing?
I’m afraid this behavior is implemented on purpose by Wallbox. The idea was for your Wallbox phone app to request data from the cloud rarely for short periods of time. The HA Wallbox integration requests data from the cloud every 30 seconds 24/7. Remember that this is not an officially supported API. I expect the reload workaround to be blocked soon.
Same problem as with many other home automation hardware; the manufacturer wants everything to go through their servers rather than allowing a local connection.
It is a pity if Wallbox spends resources blocking access, rather than providing a better solution. If f.i. the Wallbox ‘eco’ mode implementation wasn’t crippled by the fact it can only be managed through BT while standing next to the charger, I would use it.
I agree it’s on purpose and I am also sure this new 15 minutes “timeout” it’s actually a newly implemented “feature” from Wallbox to reduce traffic to their servers.
At the same time I think though, that this behaviour doesn’t favour them the slightest (we don’t pay for cloud access anyway) and simply implementing a local api (bluetooth, wifi) in the firmware of the wallbox would make their product more user friendly. It would also reduce the load on their infrastructure, as the app would contact the wifi address first and go through cloud only when unsuccessful. BT access would then only be used for setup.
Yes, to the second. Agree with your assessment. @Oriol_FP , if maintaining a proper cloud service is too expensive [which I can fully understand in current market], why not allow us to self host?
If this is due to a simple change, rather than intentional, that would be good news 
.
And Kudos to @hesselonline for being right on top of this!
So now what do we do ? Diligently wait untill the fix is implemented into core, where the Wallbox integration is now part of, or is there a way to add te “/1000” somewhere ourselves ?
I set up an automation to reload the Wallbox integration every 12 minutes.
Hi
Then, the optimal is to wait until we see if this change fix it.
Sorry I cannot get very involved on this, at least this week. If you have further complaints I recommend you to:
A) Open a customer support ticket explaining the issue <here>. Please, add how many of you are being affected by the issue so this helps customer service prioritize this as the impact assessment will result higher.
B) If you send me a google docs with the issue and number of impacted users I can also open the ticket myself in the system.
Sorry, I cannot get more involved and I should let customer service do their work. Regarding product insight I have blocked the research where some of you participated so I may not keep involved that much any more until priorities change.
Best regards
@Deedzy Well, so did I, as a temporary measure, but the fix seems to be real easy, to be done in the Home Assistant integration:
Change
if self.jwtToken != "" and self.jwtTokenTtl > datetime.timestamp(datetime.now()):
into
if self.jwtToken != "" and (self.jwtTokenTtl/1000) > datetime.timestamp(datetime.now()):
But where ???
If you run ha os the only option you have is to override the core integration by installing this as a custom component where you update the reference (presumably in manifest) to the latest package.
I intend to wait though, hopefully this will be solved in the .4 or .5 patch release of HA
Just installed the fix which was released as part of 2022.10.4
@hesselonline it still loses connection albeit at a lower frequency (exactly 30 minutes vs. 15 minutes previously).
For me it works; sometimes it looses connection but it restores it again without any intervention. I think it looses connection because in this file: wallbox/wallbox.py at d94ef73fe72bf276e1764548f528d925ecc6e7c6 · cliviu74/wallbox · GitHub it only refreshes the token when the TimeToLive has fully expired.
Due to the async nature of Home Assistent I have noticed sometimes a diff of up to 35sec between checking the token and getting the data. This allows the token to expire in the time passed.
I believe further improvements on this should be made in the Wallbox Pypi package, I have already pushed a fix to it for the milisecond issue, but maybe we shouldn’t be using TTL at all. In an earlier version, the token was refreshed with every call. I believe that this change was suggested by the wallbox team: Use new auth endpoint and TTL by victor-falcon · Pull Request #16 · cliviu74/wallbox · GitHub
Same here, it becomes anavailable and I need to manually reload it.
On 2022.10.4 it still disconnects exactly every 15 minutes, stays disconnected for 30 seconds and then connects again automatically.
I keep watching this page…
But in regard to an ETA, good luck with that 
Hi
Regarding this, what I see is that the original ticket (VBUG-2293) has been closed and a new one has been created (VBUG-3538) with this name: [iOS] When user is inactive for more than 7 minutes during a charge, session information disappears. So I understand that the calculation of energy and power should be consistent and reasonably accurate across HMI (problem 1) but the lose of energy & power reporting may persist (problem 2), at least, in iOS and connected via cloud. Please contact customer support and refer to this ticket if you want to get more info. Please, bear in mind that you should complain about features that are shown and expected from our products and HMIs (charger, App, portal). We cannot take responsibility for defects that appear in Home Assistant HMI. If you always report an issue, refer to our app-charger experience please :). Our customer support specialist will really appreciate it.
So this is the error I see now:
Logger: homeassistant.components.wallbox
Source: components/wallbox/__init__.py:132
Integration: Wallbox (documentation, issues)
First occurred: 26 oktober 2022 om 23:02:09 (13121 occurrences)
Last logged: 11:43:14
Unexpected error fetching wallbox data:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/wallbox/__init__.py", line 118, in _get_data
data: dict[str, Any] = self._wallbox.getChargerStatus(self._station)
File "/usr/local/lib/python3.10/site-packages/wallbox/wallbox.py", line 73, in getChargerStatus
raise (err)
File "/usr/local/lib/python3.10/site-packages/wallbox/wallbox.py", line 71, in getChargerStatus
response.raise_for_status()
File "/usr/local/lib/python3.10/site-packages/requests/models.py", line 1021, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 401 Client Error: Unauthorized for url: https://api.wall-box.com/chargers/status/385644
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 205, in _async_refresh
self.data = await self._async_update_data()
File "/usr/src/homeassistant/homeassistant/components/wallbox/__init__.py", line 136, in _async_update_data
return await self.hass.async_add_executor_job(self._get_data)
File "/usr/local/lib/python3.10/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
File "/usr/src/homeassistant/homeassistant/components/wallbox/__init__.py", line 132, in _get_data
raise ConnectionError from wallbox_connection_error
ConnectionError
I updated HA to the lastest version and now it seems to be solved
Finally got around to installing a Shelly EM on the EVSE connection. Now have current for the charger, voltage closest to the charger and thus a reliable power reading (for what is supplied to the EVSE).
Was not lucky with the Shelly I received. It was violently sparking between the Neutral connector and the PCB due to a poor connection. I was impatient so I fixed it rather than returning it.