SmartEVSE-3
SmartEVSE-3 copied to clipboard
SmartEVSE
Configuration help with slave device configuration, also maybe feature request
Hi, I'm trying to get my head around a particular configuration which is not obvious, but I also think I need to achieve something that's not currently supported.
This is how I want the device to behave:
- Device is pre-configured with a maximum circuit current, configured to represent the charging circuit (ie, 32A).
- Device should ALSO be configured with a default operating current (ie, 10A, or even 0A (waiting for command)).
- When device is powered on, use the specified default charge current (not necessarily the maximum, because household load it not yet known at power-on).
- Operate device strictly in slave-mode; it should wait for modbus commands to adjust charge current away from the 10A default (up to the maximum allowed by the circuit current setting).
- If communication is interrupted and external controller stops communicating for any reason, it must revert to default after some timeout as a precaution to avoid overloading the circuit because household load is unknown.
This describes the EVSE configured as a pure slave device to another smart controller (my own software). I'm sure this can already be configured (like the secondary devices in a load-balance group), but the special sauce is that I want to set a default charge rate which is lower than the circuit's maximum current, and an external controller may override this to set the charge current based on energy usage conditions. If communication with the external controller is lost (doesn't receive a set-current instruction for some timeout period), it must revert itself to the default current as a precaution.
I browsed the code, I didn't see a way to achieve this, but it's hard to understand the complete device configuration capabilities by browsing through the code.
If this isn't already supported, I think it's an important safety precaution, even for regular load-balancing slave devices in the event their master stops communicating with them for any reason; they should revert to some speficied default state (ie, low-power, or off/waiting).
It'd be great of the modbus protocol between the master and the load-balance slaves could be documented somewhere, so we can refer to it directly without sifting through code and hoping we understood it right.
Cheers!
If you want to communicate directly with a controller that is configured as Slave/node, then you'll have to behave like a Master. Here some of the communication is documented: https://github.com/SmartEVSE/SmartEVSE-3/issues/1#issuecomment-1073299256
The Master will poll all the nodes, and check charge requests, and set the charging current,
The Node will timeout and stop charging if it does not receive any data from the Master in 10 seconds.
That's very helpful, thank you. Is there a complete modbus reference kicking around anywhere?
This leaves one item from my issue; you said it will timeout with a communication error and stop charging, this is great, I didn't expect this. It means the logic I need is already implemented, but it's not quite right. In the event of a communication loss, I don't think it's reasonable to leave all chargers in a non-working state; that's basically a guarantee to leave people stranded until a tech shows up. Everyone knows a broken charging station that refuses to charge, which they made plans to rely on, is the most frustrating and terrifying think for an EV owner.
I need to be able to configure a default charge current; perhaps some lower current which I know won't overload any circuits even if all chargers are in use. The charger should just revert to self-control with the default operating current until communication is restored. I think it's extremely important to not leave people stranded in the event of communication loss.
" I think it's extremely important to not leave people stranded in the event of communication loss."
The problem with a "fall back" charge current is that you are operating in Smart Mode, which means you want your Mains guarded by the MainsMeter / MaxCircuit currents. It is permitted to use this as a "software regulated" safety feature, which means people are allowed to depend on it. A "fall back" charge current interferes with this.
If your communications are so unreliable, and safety is not an issue because your mains have enough capacity, why don't you just run on Normal Mode?
It is permitted to use this as a "software regulated" safety feature, which means people are allowed to depend on it. A "fall back" charge current interferes with this.
Can you explain what you mean by this exactly? Are you saying there's a regulation on this? Is that internationally relevant?
If your communications are so unreliable, and safety is not an issue because your mains have enough capacity, why don't you just run on Normal Mode?
Because in practical reality, normal mode configured conservatively implements the worst-possible case at all times, and wasted potential energy (and money). My recent example site (my wife's small office) is like this: Mains breaker: 64A 20kW solar generation: ~80A 3x EV chargers each with circuits suitable for 32A
This site is still in construction; the chargers aren't selected, but I'd rather use your hardware if I can find a good solution to this issue. I also have other similar sites, including my own home which also has 3 EV chargers and less solar, but that's more like a lab for now with different chargers.
Maximum solar export allowance is 5kW, so any energy that is not self-consumed is wasted energy (and money), and several staff have EV's. The large solar installation is specifically to anticipate EV chargers, and we intend to make use of it to recover that investment.
From solar, with supplement from the mains, it is almost always possible for all cars using the chargers to operate at 32A during the day. If I put it in normal mode, I must assume it's night time and there is no solar generation. Reserve some allocation for the building, and the most I could do is assign each charger ~10-12A max. This is not a sufficient car charging rate for an office where people are coming and going; some staff are mobile.
Naturally, the most frequent case is that 0-1 car chargers are in use, which means that one charger can always securely have 32A with no problems straight from the mains. Offices are daytime things, there's a heap of solar energy, and the EMS can happily ramp up/down the car chargers to consume the available energy. Basically, this site can comfortably support 3 cars almost all the time it's in use, but without any smarts, conservative configuration allows the chargers only ~10-12A max. The smarts make the site "work".
The EMS infrastructure is relatively complex; I'm not saying it's "so unreliable", but there are a lot of parts; solar inverters, several meters at different locations, the EMS computer itself, modbus repeaters and some wifi links (because the site is large) and associated networking equipment. Any of these things could fail in a way that requires a support person to attend the site, but leaving people stranded is a hard-no; absolutely unacceptable. Instead, their car may charge at the 1/3rd conservative rate in the event of equipment failure; worst case, they might run a little late, but they're not stranded. I consider this expectation of reliability essential for EV drivers to have security and confidence in their transport.
It feels like the most simple and direct safety mechanism here with respect to the chargers is, in the event of loss of communication, revert to conservative current setting. Your charger currently has logic where it reverts to 0 (turns off) when it's being controlled and loses the control signals; I just want to change the number 0, to a configurable value which I can determine to be within the spec of the circuit breaker minus other potential building loads to avoid tripping the main breaker. It feels like a very low impact change? It's no more unsafe than the main option to set the max current in Normal mode; the user must specify a max working current that's within the circuit's limits, nothing more complicated than that.
Lets not repeat this discussion again:
https://github.com/dingo35/SmartEVSE-3.5/issues/34
Sure. I felt like you brought it up again.
I still don't understand the concern. Can you possibly direct me to where in the code I might look to make a change to effect what I'm discussing? This is a pretty critical piece of code, and I'm just not super comfortable 'hacking' on this sort of thing. Do you see it being possible as a small/simple patch?
Also, you said "why don't you just run on Normal Mode?", what do you have in mind? Are you imagining some arrangement I haven't thought of?
It is a non trivial, difficult change in a critical part of the code, with very few use cases (there is you and one other guy who brought this up years ago), and it has many opponents (as you can read in the thread).
The Normal mode suggestion was just meant to help you out....
Is it the difficulty of the change that motivated the resistance? I've really tried very hard to understand your perspective, but I still feel not a single bit illuminated as to why you say it's a safety concern. It has never been successfully explained or communicated how the feature would be unsafe, and that's why I'm so confused and stuck on this.
If it's just hard as you say and nobody wants to do it, and you're making a reasonable sounding excuse not to, then I can finally understand and this whole conversation makes sense. (I truly mean this not in a disparaging way, but just in a literal and factual way with no judgement; I'm just trying to find a way for this whole conversation to make sense in my mind)
If not that, and there is some real safety concern, I haven't understood it, and I genuinely do want to understand it; because if it's real, then I am at risk of creating an arrangement that exhibits a safety hazard I haven't recognised.
Do you have a dev guide, or is it written somewhere how to do a windows/linux build and simulate the control signals?