Workaround for 28 day network cutoff

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.

1 Like