Workaround for 28 day network cutoff

[arkonis]

TLDR: The 28 day cut off if network connection is not achieved is an extremely poor design and I am desperate for this to be disabled. If I could return the charger I would over this design.

Feature request: Ability to disable this function.

I recently had to decide on a smart or dumb charger. I went with the Evnex smart charger on the guidance of the sparky who said it would be a better choice in the long term.

The garage has no internet connection and at some point fairly recently, the telcoms did something that has completely black spotted our entire building.

The plan was to eventually wire wifi into the garage but that is going to take some time given the difficulty of managing common spaces and in the mean time I was going to just use my hotspot.

However, the more I’ve been thinking about it, the more disgruntled and upset I am that this device has 28 days of run time before it bricks itself.

I know it can operate as a dumb charger because that’s what it does for 28 days at a time with the ‘smart’ features primarily being the reporting. However the fact that technology is simply not really reliable over a given amount of time really upsets me that over any 28 day period, my car charger may just become a wall mounted plastic box with a flashing blue LED.

I have owned the charger for just over a month and once the 28 days arrived and it disabled itself, I tried to connect and through one bug or another I could not get it to communicate online.

Everything turned out okay in the end as it was actually a couple of app bugs and a reporting bug. The device itself did connect but I was none the wiser as the app continued to fail or report a failure to connect.

This is not really a rare occurrence either. The fact is that apps, APIs and server based services fail all the time and I find it really disorienting that I am depending on the continuation of the company and all services continuing on an ongoing basis in order for my car charger to work at all.

I read somewhere on this forum that the philosophy here is to fail in favour of charging but this is quite the opposite.

I spoke to support and they reassured me that if something were to happen (for example the company becoming insolvent) that things would be organised to find another provider but we all know from experience that this is simply not guaranteed or even the priority for a company going under and could simply be resolved by the defacto state returning to a dumb charger of some kind.

I am frankly desperate for there a way to disable the 28 day bricking as otherwise I feel like I’m sitting on a rather expensive wall hanging that will continue to charge my car only if several things go right. I have already had this experience this last day as, while it did work out, I spent a 1-2 day cycle with the (albeit incorrect) understanding that my charger was now bricked until I could both contact evnex support and also have a resolution organised.

[Randm]

I agree wholeheartedly. The commercial concept of you bought it but we control it is ethically bankrupt.

If your company is shut down by liquidators tomorrow you don’t get to undo the damage of a timeout. All purchased products should continue operating indefinitely without internet access.

[arkonis]

Absolutely. I called up support and was informed of two things.

The first is that the 28 day timeout is hardwired because it has ‘rom enough for 28 days’. I keep mine switched off at the power for most of those days so that’s not it either. It’s clearly just datestamped for an elapsed time with the onboard RTC.

Meanwhile i was also ‘reassured’ that if evnex went under another company would take over their server host obligations. That’s historically and logically nonsense as I seriously doubt keeping servers online indefinitely would be the priority. Meanwhile, every one of these would have a 28 day retainer before shutting down for ever.

There is literal precedent of this too. When the 3G network shutdown they reverted them to dumb chargers. Why isn’t this built in? Instead they said that they never anticipated that an outdated network modality and their single point of failure would shutdown.

“Unfortunately when we designed these products we weren’t aware when support for the 3G network would run out.”

I wondered if this was the norm across the board and, therefore, had a good reason but when I reached out to Signenergy they confirmed that their car chargers need network access for smart features only and will otherwise revert to being a dumb charger INDEFINITELY. They were even surprised I was asking which I think highlights the insanity of this design.

I am so upset by this practice, I seriously wish I had grounds to get this removed and my money refunded. Right now instead I’m trying to find out if this is actually a legal practice and if I do now that I’ve already been told there is no way to remove this ‘feature’.

[edharvey]

Hi @arkonis

I’m the founder & CEO of Evnex, sorry that there’s been a bit of a delay in response over the break while the team have been away. Our support team will chip in soon, but I just wanted to acknowledge the frustration and clarify a few points.

Firstly, some of the design decisions mentioned are a function of the underlying OCPP standard used in the communication layer between the charger and the cloud. OCPP was really designed for public charging applications first and foremost, but in some states in Australia, OCPP is a requirement for chargers installed in homes, and this may become the case in other states, and New Zealand in the future.

We’ve traditionally taken a view that this is not the right direction for the industry to go. I’ve written a bit about it here: Evnex Blog | EECA’s smart charger approved list explained — and why it won’t achieve EECA’s stated objectives

Until the regulatory environment becomes a bit clearer, we’re torn between trying to build the best UX for our home customers, but also being conscious that one day our hand may be forced to fully adopt and commit to an OCPP roadmap with all of its nuances.

One of these nuances is that chargers compliant with the OCPP standard require regular “pings” with a central server to synchronise their clocks, along with clearing their transaction backlog. While I’m aware that these requirements may seem frustrating and irrelevant to your use case, that’s the reason the system was designed in such a way.

Notwithstanding all of the above, I want to apologise that you’ve had this experience and reiterate that I acknowledge the frustration around the product requiring a network connection. We do state this requirement in our product descriptions but I do accept not everyone will see this.

What I’m going to do is check in with our team to see what it would look like to add an “offline mode” to our development backlog, or a similar way of addressing your issue. I’ll check in again soon.