Ocpp: autostart without remotestop #14804
Comments
|
I just have to cry when I read about the plethora of ocpp quirks. What we could do:
|
andig
changed the title
Merged
|
@andig thanks heaps for this. Am I missing something here? I am building from the branch I get the following error on startup: Build is |
|
Ah, I worked it out. I needed to add to templates/definition/charger/ocpp.yaml Unfortunately with the above configuration it will still stop the transaction when charging is set to off: |
Who is "it"? What happens before? |
This comment was marked as resolved.
This comment was marked as resolved.
|
And what's your config? Make sure to test latest commit (or use |
|
Ah, you've added a new commit. I've just rebuilt with b2c8ecd. Unfortunately, same results. Config: |
|
1000 apologies @andig !! It does work! I had neglected to kill the old running binary before running the latest test |
|
I can confirm that with b2c8ecd I am able to stop and start charging again. There is however a bit of a glitch. Using the following sequence:
The display will remain on "Ready. Waiting for vehicle…". If I instead repeat the sequence but change the last step to "Fast", it will once again charge. I can repeat this without unplugging the car and happily switch between "Fast" and "off" successfully. But not Min+Solar |
|
And to clarify, if I switch to |
This comment was marked as resolved.
This comment was marked as resolved.
|
The mental load to interleave different logs is too much for me :(. Can we please look at a single log? |
|
@andig sorry for the delay. The latest version does not start charging. When I switch to min+solar I get this repeatedly in the log: |
|
Do you have a log? Your charger should start the transaction and hence have one? |
This comment was marked as resolved.
This comment was marked as resolved.
|
I've updated PR once more. Also: I need the trace log for OCPP. |
This comment was marked as resolved.
This comment was marked as resolved.
|
Pls once more- our internal testing is happy now :) |
|
Thanks @andig ! This one is nearly working again. It has the same behaviour as before, but I've now realised it's not to do with Eg: Off->Minpv->Off->Minpv fails, Off->Minpv->Off->Fast works. Off->Fast->Off->Fast fails, Off->Fast->Off->Minpv works. Trace log: |
@premultiply could you take a look at the test board? |
|
From the log above it looks like in the cases where it does not start again no |
|
Indeed. Seems something is short-circuited but I don't see what: |
|
Ahhh: found and fixed: 68edb17. Please retry. Also the enable branch needs to switch methods once we have a transaction. |
|
@ross-w would be great if you could test, only cosmetic changes to be done. |
|
@ross-w currently nightly would be great to get another test- thank you! |
|
@andig thanks for that. Testing with latest nightly, I needed to change my config to add Trace logs for ocpp below, with charge mode logs included. |
Is that visible in the logs? /cc @premultiply |
|
@andig you can see in the log above I selected |
|
Hard to say- there's so little logging for the loadpoint? |
|
@andig updated with more detail. I'm trying not to spam you will the full trace log which includes a lot of irrelevant stuff like MQTT, tariff, DB etc |
|
Doesn't charge because there's simply not enough power: |
|
@andig sorry for the alarm. I've tried it again and it seems fine. So in short, latest nightly works! There must have been something strange about my MQTT feed right as I booted evcc (it should not be anywhere near its limit at this time of night) |
|
Latest nightly appears to have an issue and is perpetually stuck on |
|
@andig here's the behaviour on the latest nightly |
|
There is no way to walk into the conditional path where this message is generated if if c.conn.NeedsAuthentication() {
if c.remoteStart {
// lock the cable by starting remote transaction after vehicle connected
if err := c.initTransaction(); err != nil {
c.log.WARN.Printf("failed to start remote transaction: %v", err)
}
} else {
// TODO: bring this status to UI
c.log.WARN.Printf("waiting for local authentication")
}
} |
|
I'm at a loss as to how this is occurring. Looking at the code I don't see how this is possible either. Config for charger is: And yet I'm still seeing "waiting for local authentication". Nightly a2e36a2 |
|
While strictly not the same issue lets reopen here to not lose |
andig
added
bug
Habs gefunden. Das geht wenn das Setting nie ankommt. @premultiply in der |
|
Sieht ganz so aus, dass das beim auseinander ziehen verschütt' gegangen ist. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
There is 40b6d1b. Not sure if that makes sense? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is there any way of having some middle ground between the default behaviour (transaction per charging session) and the
autoStartbehaviour in #14733 ? My EVSE (ZJ Beny) will not auto start, and if an RFID card is used to start the transaction it will then ignore OCPP altogether and charge at full rate. It does need to keep a single transaction, as if one is stopped it will not allow a new one to start until the car is physically disconnected.Originally posted by @ross-w in #12861 (comment)
The text was updated successfully, but these errors were encountered: