update:
I’m getting somewhere now, using WinSCP made it all crystal clear, I was installing everything in the wrong place…
that’s what you get for being a complete noob!
it’s working, all entities have values and max current setting is changeable via mqtt.
next question is what do I need to do or change in the files to get a second charger on the same network in HA.
The code includes the serial number in all the MQTT topics so there should be no collisions. Just repeat the steps on the second charger. You will have two devices both named Wallbox but they shouldn’t collide since they have different unique id. You should be able to rename the device names in Home Assistant. Alternatively modify the device_name in bridge.ini.
OK will try that.
What about the micro2wallbox entities, no need to change the names?
For the micro2wallbox you need to figure out how you need to change the line topic micro2wallbox/# out 0 in /etc/mosquitto/mosquitto.conf so that it forwards it to a different topic name to avoid collisions. And then you need to manually adjust /config/mqtt/wallbox.yaml to correctly get the values.
changing the topic to micro2wallbox1 (as a test) in mosquitto.conf and wallbox.yaml accordingly did not work. values are unknown. is it even possible to change the topic?
OK - finally decided to give the local MQTT control a try. Root and installation worked fine (except for the fact that I had to force the use of python 3 for the rooting process as I had 2.7 on my machine too).
The MQTT device has appeared in Home Assistant. I can unlock the Wallbox and set the charging current. If I try to start charging though, it doesn’t work (and the switch turns itself off after 2 seconds). Also my “cable connected” is reporting “0” - “Unplugged” even though it is connected. Any thoughts?
As a side note which might be relevant, I have my system running an older firmware (5.5.11) as I didn’t like the “random start time” function which is forced in the UK in the newer firmware. This however might not be as much of an issue if I get local control which overrules this function.
OK - some more information. Overnight, I charged the car through the cloud link and on checking this morning, I can see that the “charge enable” switch correctly turned on and off during the charging period. I again tried this morning but if I try to operate the switch, it just turns itself off.
I just happened to see the same issue this morning.
pausing through mqtt turns the switch immediately on again. (charging is briefly stopped tho), pausing through the cloud works as expected.
don’t have the issue with the “cable connected” unplugged when the car is plugged in.
(I have a copper sb with the latest firmware, not UK)
@Krivatri @tronikos - It therefore appears that the charge enable is read only? Could this be a permissions issue with how we did the installation? It is however interesting that lock and max charging work for me. I also noticed that the added energy and added range sensors display something.
It’s not read only, when I tap the switch in mqtt, charging stops but it then switches back on again and charging resumes.
It looks to me that the mqtt is overruled by the cloud?
But I’m not entirely convinced as it switches back on again immediately, could be something else overruling it.
I haven’t tried the pause, lock, or setting the max charging current. I’ve only tested that they update the db table. They were added by @jagheterfredrik. @jagheterfredrik do they work for you? It seems that changing the db state isn’t sufficient. I opened Pause, lock, and setting the max charging current don't work · Issue #4 · jagheterfredrik/wallbox-tooling · GitHub
For me setting current and lock is working fine in mqtt.
Interesting, iirc they worked fine without a car connected so I assumed it was the authoritative source but it seems that’s wrong. I’ll have to reverse engineer some more. I guess m2w is responsible as it handles the TMS and we might have to hook into the posix queues.
Edit: i haven’t tested with car connected. Did you @Krivatri ?
Yes all my tests were done with the car connected.
@jagheterfredrik All my tests were with the car connected too (although it reported that it wasn’t). Like @Krivatri, current level and lock works.
For me, Lock, Max charging current, Cable connected, Added energy, Added range, Cumulative added energy seem to work fine. It’s only Charging enable (the pause/resume) that doesn’t. I got the exact same behavior @Krivatri mentioned above. Charging pauses but within a couple of seconds it resumes again on its own.
OK I managed to figure it out in case of 2 or more chargers.
in /etc/mosquitto/mosquitto.conf you need to republish the topic to another topic as follows:
topic # out 0 micro2wallbox/ micro2wallbox1/
in my case I named the new topic micro2wallbox1/ for the first charger and micro2wallbox2/ for the second charger.
in wallbox.yaml I changed the unique_id, the state_topic and the device variables, this way the two chargers are well separated and appear as two devices in the MQTT integration in HA.
binary_sensor:
- name: "charging enable"
unique_id: "micro2wallbox_state_values_charging_enable_1"
state_topic: "micro2wallbox1/state_values/charging_enable"
value_template: "{{ value_json.samples[0].value }}"
payload_on: "1"
payload_off: "0"
device_class: "running"
device:
identifiers:
- "micro2wallbox1"
name: micro2wallbox1
- name: "charging enable"
unique_id: "micro2wallbox_state_values_charging_enable_2"
state_topic: "micro2wallbox2/state_values/charging_enable"
value_template: "{{ value_json.samples[0].value }}"
payload_on: "1"
payload_off: "0"
device_class: "running"
device:
identifiers:
- "micro2wallbox2"
name: micro2wallbox2
Hello @jagheterfredrik
Thanks for all your work and analysis. May i have a question ?
During all your analysis did you find any clue on setting a ecosmart refresh. I explain actually it seems the wallbox only check each 5 or 10 seconds (i guess 10) the actual solar surplus and adjusts it’s power. I was wondering if we could reduce this timing to minimize the usage of grid during ecosmart full green sessions
I did find some power_management_configuration in the database but didnt seem to take into account any changes i made.
Regards
not sure this would be a good idea. the car itself does not respond as fast to the changing current settings of the charger, so when you increase the current setting too early and the car doesn’t react in time, the current setting will rise again until the car reacts to it but then the current setting will be too high, adjusting itself by decreasing the setting, but too fast again, resulting in a fluctuating current setting.
e.g. I’ve even set a refresh timing of 30 seconds in my excess solar automation to avoid this issue when charging the car.
Like @Krivatri says, the car’s onboard charger will react to changes of the Wallbox’s control signal. The response time is dependent on what car you have.