Feature request: no-comms fallback mode

[TurkeyMan]

The default behaviour when comms is lost is for devices to stop charging. It might be a wiring fault that requires attention, or a network environment issue... either way, the user might not be able to fix it promptly. It's never okay for a car charger to be disabled and potentially leave users stranded.

I'd like to be able to configure the device to instead revert to 'standard' operating mode with a specified fall-back current defined when communications is lost. The fall-back current would be specified to be a conservative value that would not cause the circuit to be overloaded if all chargers were in use simultaneously. This way, cars may charge slower than normal, but they will still charge when comms fails.

I think this is really important.

Cheers for the great work!

[Imaginous]

I totally understand, but disagree.

Since 6A is the minimum current, it can add up quickly when using multiple SmartEVSE units.

If a breaker pops it will also need intervention. You don't want to create an unsafe situation. You could pop the main breaker... then the user is stranded and has to wait (in many cases) for the electrical company to fix it.

[TurkeyMan]

I reckon in most cases, 'multiple' will be exactly 2. Many families have 2 cars, and most families don't have more than 2 cars.

In my case, the charge circuit is 32A from a 64A home supply... so it can fail to 16A just fine. Even if I had 3 it would fail to 10A and that's still fine. I can't imagine many car charge circuits less than 32A (especially if there's several chargers on the circuit), and then up to 5 chargers (very unusual) is still 6A each.

And... I'm not saying it should behave this way by default, just an option to make it behave this way. I reckon 99% of charger circuits are 32A, with 1-2 chargers max, I'm pretty confident the feature I describe will be used. Basically, in my case at least (and I predict, the 'common case'), it's perfectly safe, and I can't have users stranded by surprise because of a comms failure; like wifi or router unplugged or broken or the HA device crashing or being serviced.

[devdems]

I think that we first need to be clear on what do you mean when you say "when comms is lost"? The Wi-Fi connection was lost, the connection to the power meter was lost,...?

[TurkeyMan]

I mean, no contact for a timeout period. I think that's exactly how the logic is right now. This will catch all communication failure cases.

[devdems]

Then i don't agree with this as it can present an unsafe situation.

[TurkeyMan]

Can you describe how? ...and what definition for communication loss would you consider more appropriate? Losing comms seems simple to define as any disruption of communications between the device and the controller. How can the device be expected to perform appropriately if the controller has no means to communicate with the devices?

[dingo35]

We are choosing the safety road here.

Apart from that, IMHO if you have stability problems on your infrastructure you should solve that, instead of managing the symptoms.

[TurkeyMan]

You still haven't articulated that claim... I can't see your logic at all. There's nothing safe or unsafe about what we're discussing here. I mean, this device has a maximum current option, it's a critical core configuration element, and it is literally EXACTLY THE SAME as what you are saying here is unsafe. I must have misunderstood you, because I can't fathom your reasoning on this. Either that, or you've totally misunderstood me.

[Imaginous]

I also "disagree" with you. It's a safety issue. In your example it might not be, because you have 40A avaliable and only use 32A.

But in almost every non commercial setting it's dangerous. I have 35A available, but for my whole installation. There are many devices which together could draw 35A, but not above when ruling out my EV.

The EV gets the remainder and has lowest priority. It's not "safe" to say it may use 6A... because at times this 6A is not available.

Furthermore the system relies on power data, so it should be available.

If I take another example in your dual charger solution... Let's say two cars are charging and due to a faulty charging cable the mains breaker is tripped... everything stops. Do you want to remove the mains breaker because the other EV should charge?

The last one is exaggerated off course.

[TurkeyMan]

I honestly can't understand your arguments no matter how I try and contort my mind... you do understand I'm talking about a CONFIGURATION option right? It is always 'unsafe' to misconfigure an EVSE... (if by unsafe, you mean trip a circuit breaker) By the logic you present, you must surely argue against ANY configuration at all. The configuration item that sets the maximum charge current is unacceptable by the exact same logic. If the user has a 20A supply, they could set the charge current to 32A; you'd better remove the option that allows people to set their maximum charge current...

If you can trust people to set the appropriate maximum current, then you can trust people to set the appropriate maximum current.

The term 'safety' used here needs to be examined a little bit too; you do have a circuit breaker on the circuit. If you pull too much, you trip the beaker. Actual hardware safety is a concern for the sparkie.

In the event these devices are communicating, they can divide current better. In the event they are not communicating, then there is simply an array of offline/isolated devices, and if they're configured with a working current for that state, then there is just no conceivable safety concern. If your supply doesn't offer sufficient working current, then don't configure the device this way!

This isn't even a feature request, it already has and does this when the device is singular/isolated... it just needs to go back to its isolated state when comms are lost, because any optimising current management can't be relied on.

I don't feel like you've made any sort of actual case against this; except to say "my supply isn't enough to divide", to which I reply, "obviously, don't configure your device this way! leave your value at the default 0A"...

[TurkeyMan]

Also where you say "non-commercial setting", I very rarely see a residential/home supply in Australia less than 64A, and often 80A. There is a country full of people who don't have the issue you seem to be concerned about, and we drive a lot. I routinely direct 50A to the charge circuit on home installs. Rarely less than 32A, and 2x 16A chargers is still a very useful configuration.

[Imaginous]

But how often does the mains measurement and or seding data fail?

My system runs smoothly and no data failures occurred for the last 3 months.

[TurkeyMan]

You mean communications failures? It has happened. On one large site recently during regional flooding, a communications pit was flooded where an ethernet joint enclosure had failed. It took several days for a contractor to reach the site to perform the repair. Without the chargers configured the way I require, the the software failing over to 0A rather than a safe working current, people would have been stranded.

In another location, another large site, there are some radio links, and that implies a complex arrangement of networking equipment; any of that equipment could fail at any time for whatever reason. The failure of a switch or a WAP is not an acceptable reason to leave people stranded.

I use these devices BECAUSE they are flexible; I can buy any old piece of junk if I want an inflexible EVSE. I use this product specifically because I expect I can configure it to meet the needs of complex sites. I don't bother if I'm installing a single charger in a home; I just get an off-the-shelf charger unit.

Arguing against this feature request is to argue against the entire purpose for the existence of your device as I see it.

[dingo35]

@TurkeyMan Instead of repeating yourself over, and over, and over again, why arent you grateful for what this community built for you FOR FREE?

Why don't you contribute in a more constructive way, either by building the functionality you demand yourself, or by (at least) agreeing that we disagree?

Please dont make me block you from this repo, but we are getting tired of your rants...

[TurkeyMan]

It's just weird, because I just can't make sense if your argument. You haven't really stated a case for rejecting it. You're telling me I need to fork and implement the feature myself? I reckon this is close to a one-line change for someone that is familiar with the project. I have no idea how to configure a build environment for these microcontrollers and test my changes... it's a nothing request.

[TurkeyMan]

Also, you're basically saying that if I put this in a PR, you would reject it... I mean, are you actually telling me to write it myself?