OCPP EN+ AC7000-AE-45 unstable #15552
Labels
question
Rather clarification than issue
Comments
|
As any other information than ocpp is missing in the log, so I can not see what is the operational state is. The only thing visible is meaning that the transaction is closed (evcc will never do this) and you have to plug out the vehicle. No further operation is possible until the vehicle is disconnected. If you want any help please provide usefull logfiles showing the issues (including context) you describe. |
|
So before with the config in the initial part on 0.129.0 was working really well stable didn't need to power cycle the evse. now with 0.130.2 I have to to get things going The car was plugged in and that was myself unplugging the car, but the car was ready to accept charge but the evse wasn't in an enabled state until after the evse was turned on off and evcc restarted. Between the start 8:17:38 and 8:18:50 the car should have been charging and it wasn't evcc was just saying waiting for vehicle. Even after that point the car was plugged back in and nothing was happening. |
|
Unfortunately your report is missing a detailed log file. Without log, we don‘t have the information for diagnosing the issue described. See https://docs.evcc.io/docs/faq#wie-kann-ich-ein-logfile-zur-fehleranalyse-erstellen. |
|
@jeffborg we'll need a logfile, OCPP: trace and the rest on debug. |
|
@andig logs with levels set to debug for all and trace for ocpp now. prior to 0.130.0 this was never an issue #15552 (comment) evcc would restart the transaction on it's own even if this isn't strictly part of the ocpp spec. yes physically unplugging the car and plugging it back in again gets things going but that makes no sense for home charging. |
|
On start-up of the log your charger is in "finishing" state. The meter messages are because it is a one phase charger. |
|
@premultiply I can't use free charge mode as this will disable the ocpp connection. |
|
Also the evse just disconnected around 10:22:42 , and I need to power cycle it. Before on 0.129.2 with the config set to There was far less chatter on the ocpp websocket and only the meter values and ping messages and the evse stayed online much much much longer. log of no more ocpp messages - not much to see here they just stop at 10:22:42am |
|
@premultiply I just power cycled the evse but didn't restart evcc it still ended up in the finishing state It seems to stop the evcc transaction with a softreset at 10:41:53, goes into Preparing then jumps to finishing, I haven't touched the car it was plugged in the entire time. I'll physically unplug the car and plug back in and post the log in another comment (I suspect it will jump out of finishing state) |
|
@premultiply as suspected after physically unplugging and plugging back in here is the logs covering that time period. evse seems to go from
|
|
What's missing here? Looks like the box is 1p and we don't handle that yet for currents? |
@andig yes my box is 1p. It does appear the en+ firmware supports 3p boxes also |
|
@andig the bug report was not about currents, it was about the state Finishing and needing to physically unplug and replug the car back in after the evse has a power failure. |
|
We have added a new indication in UI for finishing status. #15659 If the charger ends a transaction the vehicle needs to be reconnected or the charger needs to be setup to continue the running transaction. |
|
@premultiply so you are saying if there is a power failure we can't just start the charger? I know it's not part of the spec but we should just attempt to start from the finishing status, see the logs in #15691 which show how this particular evse always jumps to finishing after a power failure. Prior to 0.130.0 this was a non issue. |
|
@premultiply here is the same log from 0.129.0 as I needed to downgrade due to the issues in 0.130.4 note the charger is far more stable when we don't do get configuration and ignoring boot notification config log |
|
Anything left to do here? If yes, what is the specific issue and where is it visible in the logs?
What exactly is the issue? |
|
@andig issue is prior to 0.130.0 evse would stay online for days at a time 0.129.0 config Now with the above config and 0.129.0 the only messages sent on a regular basis were the meter values, I had the same issue with the evse disconnecting with I had getconfiguration enabled which is why it's disabled, it was even more stable if you don't request the metervalues! Now in 0.130.0 the regular messages also include this DataTransfer message below config for 0.130+ regular messages The extra messages make the evse more unstable in keeping the network connection going and it will disconnect within less than 24 hours, before it would stay working for weeks. I can only put it down to the volume of traffic on the websocket and I'm guessing there is some sort of memory leak in the evse. |
You can still have
That sounds both horrible and like a charger issue more than an evcc issue. Did you open a ticket with vendor support?
It's unclear where those are coming from. evcc doesn't do anything to trigger specific messages. If these are cause of instability that would be another question to vendor. Sorry for not having better news- but there is no issue with evcc that we can see here. |
|
@andig without a flag now to consider finished state the same as preparing 0.130.0 is almost unusable. I have spent far too much time in trying to get a charge happening where this was no where near the issue this is in 0.129.0 |
@jeffborg sorry for the bad experience. Our old implementation was quirky and punished spec-compliant chargers. We've fixed that. Seems non-compliant chargers may have different issues now due to these changes. That are of course fixable since we know they worked before. We just need to figure out how. However, I'm entirely unclear how we could help since there is no obvious problem with evcc. I've asked a couple of questions above, especially regarding
You're making assumptions. We don't need a flag since it is already implemented that way and hasn't changed: It should be possible from logfile to see if and that evcc will again enable the charger in this state. That said I'm happy to help but right now there's nothing to do for me. Sorry. |
|
@andig seems somehow mine got stuck in a state with 0.129.0 where it would only ever charge at 32amps and never lower. I have forked evcc and first change I did to avoid having to unplug the car, Just assume finishing is the same as preparing. It's not where you pointed out above. I think it's still going to be too chatty but I can deal with going to the garage and turning on/off the evse, The entire unplug the car thing was crazy and is totally unnecessary I know it's a hack but you still get this icon, but the evse is functional and FYI here is the log showing my broken evse is quite happy to be sent a |
|
Starting a new transaction in the "Finishing" state would never allow the cable to be unplugged again. @andig needsTransaction() should be moved from the Status() API to the StatusNotification callback on the connector so that it can be called immediately before the charger's internal connection timeout expires. |
|
@premultiply that should work by starting the transaction without waiting after Getting the first status message, note if you make a change to nightly I can't test due to #15852 but that looks like it's fixed now 👍 |
Could you explain a little more? What ist "charger's internal connection timeout" (what connection?)? Which status would be notified in the callback to react on? Apparently not |
|
The missleeding ConnectionTimeOut of OCPP already mentioned here: It is just moving the condition calling needsTransaction() from charger Status() into the StatusNotification-Callback/Handler of the connector. |
|
Ich verstehe nicht, was der Link mit |
|
Got a firmware update for the the unit overnight, I'm hoping 🤞 the network stability issues are resolved. I power cycled it and it still does the Preparing -> Finishing thing but it took 15 seconds as before it took 6 so the proposed change #15552 (comment) is still required. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Since upgrade from 0.129.0 to 0.130.2 occp has been unstable, I removed all custom ocpp config to allow the new ocpp code to do it's thing.
new issues on 0.130.2
previous config for 0.129 below
The only way to get it working is to power cycle the wallbox and restart evcc at the same time.
Steps to reproduce
Configuration details
Log details
What type of operating system are you running?
Linux
Version
0.130.2
The text was updated successfully, but these errors were encountered: