Have a similar algorithm based on the work of @GrantK among others. But since i am on dynamic tariff i find that price is a very decent proxy for CO2 saving as its generally wind and solar which push prices down. So as long as we have net metering in the Netherlands that works well.
Off topic: I have seen examples of people using Emhass in Australia saving hundreds of dollars per month - the spreads there are gigantic and with the right optimization you can seriously benefit. Max I have seen here in NL is +64c for a kWh vs. -50 in summer, both perhaps 2-3 hours in a year. Mostly the spreads are 7 - 15 cents between peak and through, just enough to justify cycle costs for the battery.
Differences between regions and countries is sometimes massive.
For me (Flanders) there is a monthly tariff, itās the same price/kWh day and night for the month.
There is a tariff for consumption and we get payed for injected excess solar energy to the grid.
But we do have an extra cost for peak consumption to force the consumer to keep their energy peak consumption as low as possible at any given time.
Even though Iām on the other side of the world in New Zealand, the structure of my electricity charges is quite similar to @Krivatri in Flanders. There are 4 components to our monthly bill:
Daily charge 68c whether we use any electricity or not
34c per kWh on main meter (available 24/7)
27c per kWh on ripple-controlled meter (almost always available except for short periods on the coldest winter days (22 hours minimum per day)
-17c per kWh for any power exported to the grid (net metering is not allowed in NZ)
So for me, it makes no difference when I use the energy unless itās on a very few days per year in the middle of winter. All the energy in our House Battery is used every night, so anything taken from it needs to be replaced @ 34c per kWh. Therefore, it never makes any sense for me to use House Battery energy to charge my EV. Much better to wait until the sun is shining (if possible), or if I canāt wait that long, use grid energy at night through the ripple-controlled meter.
My point being that each of us have different use cases and I love the flexibility afforded by HA where we can so easily tailor our controls to match our individual circumstances. I donāt use any HA automations at all, just a couple of templates. All my programming is done in Node-RED which is a visual programming environment I find very intuitive and easy to maintain.
I have a request regarding the availability of the mqtt bridge.
yesterday I disconnected the ethernet connection between my switch and the wallbox to do some testing on the ping integration in HA I have setup to check the availability of the wallbox.
after reconnecting the cable, the connection was restored and HA reported the wallbox as online.
but today when I wanted to charge the car, I noticed the bridge had stopped working,
although the network connection was still alive and the micro2wallbox topic was also active, the bridge was not, probably due to my disconnecting/reconnecting the day before.
so I would like to be notified when the bridge has stopped working or isnāt reachable/alive anymore.
I guess this has to be done through an availability topic or last will?
Iām trying to figure out how to implement this but I donāt have the know-how nor the coding skills to achieve this unfortunately.
Was the disconnection issue ever fixed on this? Iām just setting up HA and noticed that my Wallbox Pulsar Plus is reporting a status of āDisconnectedā, then āReadyā repeatedly.
Well thatās a first. The disconnection issue was from the bridge to the MQTT broker. This is your charger saying disconnected in relation to the car.
Its with the cloud integration. When I saw @jagheterfredrik 's response I did wonder if this thread was just for the MQTT version. Apologies if it is.
Whilst the MQTT option intrigues me, Iām a little nervous about pwning my wallbox in case I screw it up and brick it. Hence going with the cloud option.
The disconnected state is because of the cloud server, nothing you can do about it.
You donāt have to be afraid for trying mqtt, you canāt brick your wallbox this way, if you do it wrong, mqtt wonāt work, but it does not affect the workings of your box.
Iām just in the process of setting up my homelab on a new server which will be running an MQTT broker (with Zigbee2MQTT) so once Iāve got all that working I might look at it.
For now - Iāll leave as is and accept the disconns.
How did you use $SYS/broker/connection/bridge-ha/state? This could be helpful for the micro2wallbox sensors but the state remains as 1 even while restarting the Wallbox so not sure if and when it changes to 0. If it does we could add:
I made a sensor in wallbox.yaml for the micro2wallbox connection and one for the bridge connection
# status connection micro2wallbox
- name: "status_m2w"
state_topic: "$SYS/broker/connection/bridge-ha/state"
# status connection bridge
- name: "status_bridge"
state_topic: "wallbox_xxxxxx/availability" #xxxxxx = the ID number of your wallbox
the first sensor gives a value of ā0ā or ā1ā
the 2nd a value āonlineā or āofflineā
when I reboot my wallbox, I get state = 0
the $SYS/broker/connection/bridge-ha/state topic is already present by default, no need to change anything in mosquitto.conf or so.
But I also had state always = 1 at first, because I had for my 2 wallboxes the same remote_clientid in both mosquitto.conf, therefore when I rebooted only 1 wallbox at a time, the state was always 1.
changing the remote_clientid to a unique name for each wallbox fixed this issue.
I now have a state for each wallbox
one in $SYS/broker/connection/bridge-ha-1/state and one in $SYS/broker/connection/bridge-ha-2/state
if you only have 1 wallbox and your clientid is unique it should work.
if not, you can try to use ānotifications trueā and specify a ānotification_topicā in mosquitto.conf instead.
for the bridge there was no such mechanism, but by adding an availability topic to bridge.py, thatās fixed. (not yet tested tho)
Tested a reboot of the wallbox just now.
Connection micro2wallbox drops to 0 and connection bridge goes offline.
Also all bridge sensors go to state unavailable during reboot (before all states were retained).
After some time micro2wallbox = 1 and 30 seconds later the bridge is also online again, all sensors show their state again after reboot.
Now I have all sensors and controls working locally with my Wallbox. Itās so easy with the latest version MQTT Bridge writtten in Go. All self-contained with no need to worry about using SCP.
Just to be sure, I used the command systemctl enable mqtt-bridge to make sure MQTT Bridge will auto start when my Wallbox reboots.
Finally, a warning to others reading this threadā¦
DONāT install the latest Wallbox 6.1.xx firmware versions, or you will lose the ability to use Wallbox-pwn and possibly MQTT Bridge.
