Pause doesn't work

[tronikos]

There are reports in the community that they don't work via the MQTT Bridge, see https://community.home-assistant.io/t/wallbox-pulsar-plus-integration/200339/839. I assume they don't work via local-rest.py either. It seems that changing the db table wallbox_config isn't sufficient.

[jagheterfredrik]

@tronikos have you tested?

[tronikos]

No I haven't. I can test next week.

[tronikos]

I was able to test today. Locking and setting max charging current seem to work fine. It's only pause that doesn't quite work. It does pause charging but within a couple of seconds it resumes on its own.

[tronikos]

Diffing all the tables in the database before and after pausing from the app, the only meaningful change is in the charging_enable field in the wallbox_config exactly what we do. It seems it's just that there is another process that overrides the db change.

As a potential workaround we could use the max_charging_current field. Any value below 6 causes charging to pause.

[jagheterfredrik]

Thanks @tronikos I’ll try to reverse relevant parts maybe tomorrow

[jagheterfredrik]

did you save the diff for the active_session table btw?

[tronikos]

Yes I exported all the tables using DBeaver. There was no change in the active_session table. The only changes were in: myinfo: config_sync_timestamp and last_state_values_id_uploaded on_time_track: timestamp power_outage_values: charged_energy wallbox_config: charging_enable and timestamp

[jagheterfredrik]

Ok, so it seems the Wallbox statemachine is the star of the show and to pause/resume one has to use POSIX message queues. I couldn't be bothered getting cffi installed so here's some super janky hack to pause/resume:

import ctypes
libc = ctypes.CDLL(None)
syscall = libc.syscall
# 274 => mq_open
# 276 => mq_timedsend
mq = syscall(274, b'WALLBOX_MYWALLBOX_WALLBOX_STATEMACHINE', 0x2, 0x1c7)
# Resume
syscall(276, mq, b'EVENT_REQUEST_USER_ACTION#1.000000'.ljust(1024, b'\x00'), 1024, 0, None)
# Pause
syscall(276, mq, b'EVENT_REQUEST_USER_ACTION#2.000000'.ljust(1024, b'\x00'), 1024, 0, None)

Locking is also supposed to be done through message queues (message EVENT_REQUEST_LOCK) so I'm not sure the DB-way of locking actually does all the locking that is supposed to happen.

For setting the max current that is actually done through the DB the way we do it today.

[jagheterfredrik]

Weird, it seems both 1 and 2 toggles the pause/resume, investigating..

Edit: Ok, it seems the cloud sends a 1 to resume if the box is paused and 2 to pause if the wallbox is not paused but both toggle 🤷‍♂️

[GrantKeymer]

I wonder if the Wallbox State Machine is the key to unravelling the current charger status?

The following states would be most useful for typical HA users...

READY(0), CHARGING(1), CONNECTED_WAITING_CAR(2), PAUSED(4), LOCKED(6),

[jagheterfredrik]

The state machine state is available in redis on the wallbox MGET wallbox:wallboxsmachine::state, note that these states are different from the ones you mention, e.g. paused is "B6"

[jagheterfredrik]

The charger status belong to micro2wallbox and is also available in redis: HGET m2w tms.charger_status, returns 4 for paused and 1 for charging etc.

[GrantKeymer]

The second one using HGET looks perfect. Is it possible to make this into a sensor for use in HA?

[jagheterfredrik]

I've incorporated the changes and moved the code to its own repo, https://github.com/jagheterfredrik/wallbox-mqtt-bridge. Thanks for all your hard work @tronikos