Firs of all the triger you chose is wrong, use the time patern as i advise.
Your trigger will fire only once when the state of your sensor.iammeter_power will go from not above 250 to above 250 (that is the mechanics of your trigger). If it is allready above 250 will not fire at all…You should check instead every x seconds if the power is above 250 then do things…
It is also posible that state of sensor.iammeter_power is not numeric, you should use in that case {{states(‘sensor.iammeter_power’) | int }} instead.
Il y a une petite erreur dans le fichier YAML que tu as partagé. La syntaxe de la valeur value dans la dernière action n’est pas correcte. Voici le fichier YAML corrigé:
value: '{{ states(''sensor.duosida_maxcurrent'') | int + 1 }}'
Hi @anthony.faucogney.
It works like intended, no problems with it so far!
The 6A minimum limit is set by the standard, and is the same for all chargers: any charger must be able to supply minimum 6A. The EV can also draw less, especially at the end of a charge, but the charger cannot be set to lower than 6A.
Yes, it responds really fast, 2-3 seconds, but this also depends on the EV. In my case, it never was an issue, as the automation for surplus calculation runs every 10 seconds.
Any advice to select between duosida or lektrico wallbox ?
lektrico is more expensive, but designed in Europe. (Maybe safer!). The box has no external plug. No need to buy type 2 cable. Seems more robust for outside environment and is smaller.
duosida is cheaper, own a RFID reader. Need to by type2 cable. Display some information on the box.
Is there difference in API capabilities ? Or power capabilities ? Others ?
Quick question - all these chargers seem to be cloud polling / web API’s… (which sucks)… Are there any limits to how often settings can be changed, or is it likely limits will be set in the future?
If we all went ahead and changed the max charge current every minute or so based on some logic, they’d be relaying a lot of settings to devices through their network… Maybe they’d want to avoid that in the future …
Very good question, i would MUCH prefer a charger with an API, that could be called locally by Home Assistant.
I stopped using the dongle that my Solar system came with for the same reason and changed to Solar Assistant. The supplied dongle only updated every 5 minutes, would only transmit the data to a server in China, and the Home Assistant integration had to request the data from there.
Major pain in the behind, not least of all because the Chinese server
Was slow or unresponsive again and again, and they took days to get them to fix their server.
The server was slow because it was WAY to “small” so their solution was to try and eliminate the computers that connected via Home Assistant, and “pretended to be the app”
All in all a really crappy solution. Solar Assistant is a RaspberryPi that is connected directly to the serial port of the system, and send data via MQTT to Home Assistant.
A LOT more reliable, and A WHOLE LOT faster. (Updates every 1-2 seconds, compared to every 5 minutes)
I checked a little and found this thread. It hints that f.ex. the Wallbox has an RS-485 port which seems to be used to chain multiple wallboxes together so that the total draw is less than some value.
I would bet that the RS-485 is able to set the max current at any given time (assuming somebody reverses it)… and I did a search:
Thread on more modbus with ESPHome to communicate. This thread also hints at a Powermeter, an “EM300” that supposedly can do something with the Wallbox.
I’m hopeful. Great thread (I don’t have an EV yet - I’m still planning…)
I went with EV Box which is fitted with autoload balancing features from Smappee.
I read the current draw from Smappee’s api into Home Assistant which allows me to do additional load shedding if needed (switching off two Quookers, when loads are closed to max).
But the EV Box remains a black box, if your pardon the pun, even though I can intercept the mqtt traffic.
My EVBox installation uses modbus. I have not done any research on this, because including my heatmeters into HA were first priority (using a protocol called Mbus, super simple).
The ideal box for me would be one that had wifi, and could be addressed directly via an API, so that the integration would still work, even if internet connectivity was down or the cloud server was unreachable for some reason. (Imagine not being home, and suddenly the weather taking a turn for the worse and the integration just keeps pumping max amps to the car, even if the solar panels stop producing enough watts.)
More ideal, if the manufacturer made a Home Assistant integration, where you could use the workflow setup method, and simply point it to the sensors that it needed, and set max combined current it could draw.
This is not me being lazy, this is me being “I am not nearly good enough to make scripts that did all the fancy math and set the charge states based off of the sensors”.
I find it at bit strange that no manufacturer seems to want to make such a product and integration.
I wonder if you could control a EVSE using tuya
Some of the EVSE I tested use tuya / smart life and adjusting amperage should be easier if you can access the tuya API
