Moved to using the unique_id on the main branch now, feel free to test it out @yavinmaster
I replaced bridge.py in my wallbox, have not tested yet, but there is now a -0.0 kWh value for the added energy.
value of 0.0 is normal due to my testing yesterday, but there is a minus before the value.
no car connected or anything, only replaced bridge.py and restarted the service.
Can you use https://github.com/jagheterfredrik/wallbox-tooling/blob/c2e925c335eefc174814634f8f589feac5b1fdb4/mycli.sh to run
SELECT * FROM `session` ORDER BY `id` DESC LIMIT 1;
Ok.
without the car plugged in yet, I got nothing in return for the moment.
I forgot to add the â;â at the end
car not plugged in:
MariaDB [wallbox]> SELECT * FROM `session` ORDER BY `id` DESC LIMIT 1;
+----+-----------+--------+------------+--------------+---------------+---------------+---------------------+---------+--------+---------------------+------------+-----------+------------+--------------------+------------------+--------------+----------------------------+
| id | unique_id | energy | energy_mid | energy_total | charging_time | charged_range | end_time | user_id | car_id | start_time | total_cost | energy_id | payment_id | discharging_energy | discharging_time | green_energy | ulid |
+----+-----------+--------+------------+--------------+---------------+---------------+---------------------+---------+--------+---------------------+------------+-----------+------------+--------------------+------------------+--------------+----------------------------+
| 41 | 0 | 0 | 0 | 0 | 89 | 0 | 2023-12-11 18:21:24 | 1 | 1 | 2023-12-11 18:19:39 | 0 | 1 | 0 | 0 | 0 |
0 | 01HHCY8FTG8TT5YES41EE148NV |
+----+-----------+--------+------------+--------------+---------------+---------------+---------------------+---------+--------+---------------------+------------+-----------+------------+--------------------+------------------+--------------+----------------------------+
do you need me to do a plugged in unplugged test or charging test?
wait, I just noticed cable connected returns plugged in, but the car is unplugged.
Can you run SELECT * FROM active_session; twice, once while the car is unplugged and once plugged? I think for you the unique_id is 0 and the user_id is 1 even when there is an active session so we have to change the condition in the code to:
`active_session`.`unique_id` != 0 OR `active_session`.`was_connected`
to detect there is an active session.
Me and @Krivatri did some testing over PM and it seems his Copper SB also has a unique id when plugged in (and 0 when unplugged), not sure what the problem is/was
brief summary of my tests:
tested with https://github.com/jagheterfredrik/wallbox-mqtt-bridge/tree/quick_added_energy
car plugged in = cable connected: plugged in
car unplugged = cable connected: unplugged
when plugging the car in => added energy and range = 0
when done charging and unplugging the car => added energy and range are retained
charging power is correct when charging and drops to 0 when paused or done charging.
pause/resume switch is working well.
I have no issues so far.
discordance plugged in / unplugged seems to be resolved by itself after 1 complete start / stop charging cycle.
Just done a very quick test of the latest version ( #15). On the surface the main functionality looks good and certainly appears useable. The only minor issue Iâve noticed that needs further investigation (by me first to confirm my suspicions) is the lock function. I have auto-lock enabled which means that about 5 minutes after disconnecting the car, the lock automatically turns on. What I noticed today was when I returned home, the lock was still disabled. This can easily be overcome by adding an automation to turn the lock on when required but I suspect the way the lock is currently being implemented in the bridge is overriding the normal auto-lock behaviour.
It looks like Iâve decided to try the bridge out just at the right time - so many improvements in such a short time. The crazy thing is, if Wallbox provided this functionality out of the box, it would encourage more people to buy it.
3 Likes
Would recommend to automate the lock functionality through HA either way. Opens up a host of options also to unlock the wallbox.
In my case it also unlocks automatically as follows:
- wallbox connected triggers automation
- condition: car at home (directly through car GPS or via android auto/ phone GPS)
- condition 2: car API confirms connection to wallbox
- action unlock
This is still cloud based but it works quite well. I also programmed a safety feature, if the wall box starts to charge it checks if the car is at home and connected. If not the charger pauses. Maybe a bit over the top but who knows what people are up tođ
@RT1080 I already have very similar unlock automations which I will change to using the bridge. It was just nice having the built-in timed auto-lock but as mentioned, it is far from being an issue. The only reason I mentioned it is in case this behaviour is masking an underlying issue.
Very interesting @yavinmaster, nice catch. Iâve noticed that we treat locking differently than original so if our way breaks auto-lock that would be great to know.
OK - I was messing around and accidently updated the firmware on my Wallbox⌠On trying to start a charge it didnât work. Checking the app, the ârandom start delayâ had been activated. Overriding this did allow charging to start. I will want to completely reset the firmware back to the old version to get rid of this but before I do this, is there anything you want me to test which might allow you to override this?
Update on Auto-lock. I unplugged, and locked the charger via the bridge then rebooted the charger (via the web interface). I then plugged the car in, unlocked the charger via the app, started a charge via the app. Stopped charging and unplugged. After the auto-lock timeout, the charger locked itself. I then repeated the process but used the bridge to unlock and start the charge this time. As suspected, when I unplugged the charger it stayed âreadyâ. It does therefore appear that the auto-lock is being disabled by the bridge unlock function.
I have also noticed this morning that the âcable connectedâ doesnât appear to be updating all the time. I need to do some more testing to see under what conditions that it isnât updating.
I donât use the lock function, and havenât tested this yet so I donât have any input for this.
but the âcable connectedâ appears to be working well for me.
I had something else going on yesterday, but I need to investigate further tho, here is what happend.
in my automations for charging the car with excess solar energy, I call upon the service turn_on or turn_off switch.wallbox_charging_enable to pause or resume the charge.
all of these automations have conditions to check before acting on the charging_enable switch, except for one.
I have an input_boolean helper button used as a trigger or as a condition for multiple automations, one being a trigger for an automation to turn on or off the charging_enable switch directly. (itâs a button on my dashboard to stop or resume charging manually, bypassing all the other automations).
now when the solar excess automation pauses the charging, the charging_enable switch is turned off as expected.
but when the helper button is still âonâ and I switch the helper to âoffâ, the charging_enable switch turns back on and charging resumes, although when switching the helper button from on to off calls on the service turn_off switch charging_enable.
when I then turn the helper back on, the charging_enable switch goes to off, although the automation calls then for turn_on the switchâŚ
I solved this by adding a condition in the automations to check the state of the switch before acting on it.
I donât remember having this issue with the cloud integration?
The wallbox is weird in that it always toggles charging so we currently trust that Home Assistant tells us only to resume if weâre already paused. Iâll instead add a check to only move to the desired state.