Ok I had already done these steps, and rebooted the wallbox before running the new script.
I now have all the new sensors in MQTT, but locking the wallbox does not work for me.
and what is the m2w_status for? is this the micro2wallbox state?
and what about contol pilot, s2 open and state machine? are these the debug sensors?
@hesselonline has taken us a long way! @jagheterfredrik - amazing to have local control - and thank you for your ideas when I struck a few issues. After running wallbox-pwn.py within an Anaconda environment I was able to ssh from a Windows command prompt to complete the configuration.
@GrantK I am still using node red based on your work from a while ago… Could I ask a few questions of you on the node-red changes for local control?
Are you using mqtt in/out nodes for everything, or a combination with the auto-created HA sensors?
How are you doing pause / resume?
Would you be happy to again share your current node-red flow?
With the Lock control, you won’t see any change in colour of the Halo LEDs if the car is plugged in, but the status shown in Overview should still change when you click it. If the car is unplugged, you will see a change in colour of the Halo LEDs and the status shown in Overview will change also.
The M2W sensor is for debugging. Yes, it shows the Micro2Wallbox state.
Likewise, Control Pilot, S2 Open and State Machine - are all for debugging.
It isn’t clear exactly what ‘S2 Open’ means, but the others are self-explanatory.
OK thx for the info.
I have a copper SB and the lock works a bit differently.
the m2w state shows 0 for me, probably because I’m forwarding my micro2wallbox topic to another topic?
The orange pieces in the ‘Status’ bar are where I locked the charger. Corresponds to 6 on the M2W Status bar. Notice, there is no change to Status if the charger is Locked when Plugged in.
@andypnz - Hello again, and it’s great to see you are still using Node-RED.
For now, I have both integrations running in parallel, while I make sure that all the new sensors are behaving in the way I expect. I realise that I can access MQTT sensors and controls via built-in functions of NR, but I prefer to use the auto-created HA sensors and controls because then I have history and logging available. Maybe that would still work with the NR functions but I’m not sure. So I will stick to using Service Calls from NR and just change the names, one by one.
I’m sure there will be little differences as I convert each sensor and control across from the Wallbox Portal integration to MQTT Bridge, but I don’t expect I’ll need to change too much. Pause/Resume should be renamed to Charging Enable On/Off I think, and turn_on / turn_off / toggle as before. I’ve just tested toggle and that works. I’ve also tested the ‘Charger Status’ and that works - SO much faster
Once I have my flow ported over to MQTT Bridge, I’ll be happy to share it with anyone who is interested.
tried to install the GO version on my second wallbox without deleting the old version, but seems it did not install as expected. bridge.ini is still the old one, bridge.py is replaced with bridge, but there are no debug sensors. only the halo setting is new in my mqtt sensors.
I guess adding debug sensors = true to bridge.ini will fix this all other sensors are working fine.
does work without deleting the old version.
when debug sensors are needed, bridge.ini needs to be adapted manually.
I did a reboot on the wallbox and all seems to be working.
Using cloud control I based my control on these status messages:
Ready, Unavailable, Charging, Disconnected, Paused, Waiting on car demand
I don’t see an ‘unavailable’ message from MQTT? Is that ‘error’? Is there any status message to indicate the charger is unavailable?
I think these are the MQTT status messages:
Ready
Charging
Connected waiting car
Connected waiting schedule
Paused
Schedule end
Locked
Error
Connected waiting current assignation
Unconfigured power sharing
Queue by power boost
Discharging
Connected waiting admin auth for mid
Connected mid safety margin exceeded
OCPP unavailable
OCPP charge finishing
OCPP reserved
Updating
Queue by eco smart
@andypnz - If you stop the Mosquitto Broker then all sensors become unavailable. I’ve tested this just now and it works. If the charger is powered off, all sensors become unavailable after about 30 seconds. If the charger is powered on again, it takes about a minute for the sensors to become available again.
I guess we won’t have the situation of ‘Disconnected’ any more because no cloud connection is involved
P.S. After starting Mosquitto Broker again, you need to restart HA.
Here’s what my EV Charging Dashboard looks like now, with new functions added, courtesy of the MQTT Bridge developed by @jagheterfredrik with help from @tronikos…
I developed this in Node-RED which is a visual programming environment for HA. Main functions are:
Solar-only Mode
Prioritisation of House Battery (or not)
Charging Timer
Target kWh setting with push notification when reached
This screenshot was taken just now, in mid-morning with the house battery recharging quickly after being discharged to 20% overnight. My EV is a 40kWh Nissan Leaf, so the max. charging current is restricted to 16 Amps.
If anyone wants a copy of my Node-RED flow, let me have your email address by Private Message, and I’ll send it to you, stripped of a few private details. I don’t want to post it in a GitHub repo just yet.
The Session Time is calculated by my NR flow. Whenever it sees the word ‘Charging’ appear in the Wallbox Status, it increments a timer. The timer is reset when ‘Ready’ appears.
Now here’s an interesting thing I noticed. The Wallbox app and My Wallbox portal both show a similar timer. Whether they maintain a counter the way I do, I’m not sure. But when I started my journey with HA in early 2022, using the OCPP integration, one of the available sensors was the Session Time. This leads me to suspect it is available somewhere inside the Wallbox, whether in the SQL DB, or elsewhere.
With my Nissan Leaf, there is no app to determine SoC in the way some other manufacturers have. I wish there was, but for now, I make do, knowing that SoC gain = kWh gain x 3.32. Multiply by 10 and divide by 3 is near enough, I can do it in my head. This is how I work out the target kWh if I want to charge to 80%. Or if I want to charge to full, I leave it running, and the Wallbox app notifies me when it’s done.
In a few years time when we replace our Leaf, I expect our next EV will have some way of reading the SoC into HA.
