steve-community/steve

Steve communication with Alfen Eve Charger broken

Closed this issue · 14 comments

Checklist

  • [ x] I checked other issues already, but found no answer/solution
  • [ x] I checked the documentation and wiki, but found no answer/solution
  • [ x] I am running the latest version and the issue still occurs
  • I am sure that this issue is about SteVe (and not about the charging station software or something unrelated to SteVe)

Specifications

SteVe Version     : 3.6.0
Operating system  : Raspbian bullseye
JDK               : openjdk 11.0.21
Database          : Mariadb ver 15.1..

Expected Behavior

Untill the last firmware update Steve worked flawlessly with the Alfen Eve Charger

Actual Behavior

After the last firmware update of the Alfen Eve Charger to version 6.5.0-4217, the communication stops with the following problem in the Steve logfile:

[INFO ] 2023-12-29 12:14:04,509 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=TRAFFIC_0175, sessionId=23ff971b-3f54-cc00-ad75-0ecce5d909f9] Sending: [4,"7","FormationViolation","The payload for action could not be deserialized",{"errorMsg":"Unrecognized field "values" (class ocpp.cs._2012._06.MeterValue), not marked as ignorable (2 known p..."}]

Steps to Reproduce the Problem

  1. Connect Steve to the Alfen with the latest firmware.

Additional context

I have down graded Steve to 3.5 and 3.4 to no avail. Downgrading of the Alfen firmware is not possible.

The receiving payload is missing. Could you add it?

Not sure what you mean by that, but I have the Steve log and the Alfen Eve log available.
In the Alfen Eve log I find the following:
2023-12-31T14:53:12.289Z:USER:comConnect.c:328:wired connect
2023-12-31T14:53:12.621Z:INFO:websockets.c:445:Connected to Socket 192.168.1.214:8080
2023-12-31T14:53:12.632Z:INFO:websockets.c:2202:WS timeout: 10000 ms
2023-12-31T14:53:13.050Z:INFO:websockets.c:813:WebSocket upgrade successful
2023-12-31T14:53:13.070Z:USER:taskOCPP.c:477:Back office connection available
2023-12-31T14:53:18.082Z:COM:ocpp_rpc.c:681:-> [2,"1","BootNotification",{"chargePointVendor":"Alfen BV","chargePointModel":
2023-12-31T14:53:18.082Z:COM:ocpp_rpc.c:681:"NG910-60023","chargePointSerialNumber":"ACE0177305","chargeBoxSerialNumber":"TR
2023-12-31T14:53:18.082Z:COM:ocpp_rpc.c:681:AFFIC_0175","firmwareVersion":"6.5.0-4217"}]
2023-12-31T14:53:18.531Z:COM:ocpp_rpc.c:1127:<- [3,"1",{"status":"Accepted","currentTime":"2023-12-31T14:53:19.472Z","heartbe
2023-12-31T14:53:18.531Z:COM:ocpp_rpc.c:1127:atInterval":60}]
2023-12-31T14:53:28.578Z:COM:ocpp_rpc.c:681:-> [2,"2","StartTransaction",{"timestamp":"2023-12-31T11:47:54Z","connectorId":1
2023-12-31T14:53:28.578Z:COM:ocpp_rpc.c:681:,"meterStart":2145278,"idTag":"ACE0177305"}]
2023-12-31T14:53:29.265Z:COM:ocpp_rpc.c:1127:<- [3,"2",{"transactionId":2,"idTagInfo":{"status":"Blocked"}}]
2023-12-31T14:53:29.277Z:INFO:db_transaction.c:16:Updated TransactionStart for socket 1 at 0x000009ae (ts: 2023-12-31 11:47:54)
2023-12-31T14:53:29.289Z:INFO:taskMaster.c:2374:Socket #1: tag marked invalid
2023-12-31T14:53:29.300Z:INFO:db_transaction.c:16:Updated TransactionStop for socket 1 at 0x00000a0c (ts: 2023-12-31 11:50:33)
2023-12-31T14:53:29.316Z:COM:ocpp_rpc.c:681:-> [2,"3","StatusNotification",{"connectorId":0,"errorCode":"NoError","status":"
2023-12-31T14:53:29.316Z:COM:ocpp_rpc.c:681:Available"}]
2023-12-31T14:53:29.457Z:COM:ocpp_rpc.c:1127:<- [3,"3",{}]
2023-12-31T14:53:29.464Z:COM:ocpp_rpc.c:681:-> [2,"4","StatusNotification",{"connectorId":1,"errorCode":"NoError","status":"
2023-12-31T14:53:29.464Z:COM:ocpp_rpc.c:681:Available"}]
2023-12-31T14:53:29.554Z:COM:ocpp_rpc.c:1127:<- [3,"4",{}]
2023-12-31T14:53:30.328Z:COM:ocpp_rpc.c:681:-> [2,"5","MeterValues",{"connectorId":1,"transactionId":2,"values":[{"timestamp
2023-12-31T14:53:30.328Z:COM:ocpp_rpc.c:681:":"2023-12-31T11:47:54Z","values":[{"value":"2145.278","context":"Transaction.Be
2023-12-31T14:53:30.328Z:COM:ocpp_rpc.c:681:gin","unit":"kWh"}]}]}]
2023-12-31T14:53:30.597Z:COM:ocpp_rpc.c:1127:<- [3,"5",{}]
2023-12-31T14:53:31.632Z:COM:ocpp_rpc.c:681:-> [2,"6","MeterValues",{"connectorId":1,"transactionId":2,"values":[{"timestamp
2023-12-31T14:53:31.632Z:COM:ocpp_rpc.c:681:":"2023-12-31T11:50:33Z","values":[{"value":"2145.539","context":"Transaction.En
2023-12-31T14:53:31.632Z:COM:ocpp_rpc.c:681:d","unit":"kWh"}]}]}]
2023-12-31T14:53:31.746Z:COM:ocpp_rpc.c:1127:<- [3,"6",{}]
2023-12-31T14:53:32.765Z:COM:ocpp_rpc.c:681:-> [2,"7","StopTransaction",{"timestamp":"2023-12-31T11:50:33Z","transactionId":
2023-12-31T14:53:32.765Z:COM:ocpp_rpc.c:681:2,"meterStop":2145539,"idTag":"ACE0177305","transactionData":[{"values":[{"times
2023-12-31T14:53:32.765Z:COM:ocpp_rpc.c:681:tamp":"2023-12-31T11:47:54Z","values":[{"value":"2145.278","context":"Transactio
2023-12-31T14:53:32.765Z:COM:ocpp_rpc.c:681:n.Begin","unit":"kWh"}]},{"timestamp":"2023-12-31T11:50:33Z","values":[{"value":
2023-12-31T14:53:32.765Z:COM:ocpp_rpc.c:681:"2145.539","context":"Transaction.End","unit":"kWh"}]}]}]}]
2023-12-31T14:53:32.902Z:COM:ocpp_rpc.c:1127:<- [4,"7","FormationViolation","The payload for action could not be deserialized
2023-12-31T14:53:32.902Z:COM:ocpp_rpc.c:1127:",{"errorMsg":"Unrecognized field "values" (class ocpp.cs._2012._06.MeterValue
2023-12-31T14:53:32.902Z:COM:ocpp_rpc.c:1127:), not marked as ignorable (2 known p..."}]
2023-12-31T14:53:32.945Z:ERROR:ocpp_json.c:462:WAMP_ERROR on (FormationViolation) Desc: The payload for action could not be des
2023-12-31T14:53:32.945Z:ERROR:ocpp_json.c:462:erialized
2023-12-31T14:53:32.964Z:ERROR:ocpp_rpc.c:438:reply error REPLY ERROR
2023-12-31T14:54:32.988Z:COM:ocpp_rpc.c:681:-> [2,"8","StopTransaction",{"timestamp":"2023-12-31T11:50:33Z","transactionId":
2023-12-31T14:54:32.988Z:COM:ocpp_rpc.c:681:2,"meterStop":2145539,"idTag":"ACE0177305","transactionData":[{"values":[{"times
2023-12-31T14:54:32.988Z:COM:ocpp_rpc.c:681:tamp":"2023-12-31T11:47:54Z","values":[{"value":"2145.278","context":"Transactio
2023-12-31T14:54:32.988Z:COM:ocpp_rpc.c:681:n.Begin","unit":"kWh"}]},{"timestamp":"2023-12-31T11:50:33Z","values":[{"value":
2023-12-31T14:54:32.988Z:COM:ocpp_rpc.c:681:"2145.539","context":"Transaction.End","unit":"kWh"}]}]}]}]
2023-12-31T14:54:33.113Z:COM:ocpp_rpc.c:1127:<- [4,"8","FormationViolation","The payload for action could not be deserialized
2023-12-31T14:54:33.113Z:COM:ocpp_rpc.c:1127:",{"errorMsg":"Unrecognized field "values" (class ocpp.cs._2012._06.MeterValue
2023-12-31T14:54:33.113Z:COM:ocpp_rpc.c:1127:), not marked as ignorable (2 known p..."}]
2023-12-31T14:54:33.152Z:ERROR:ocpp_json.c:462:WAMP_ERROR on (FormationViolation) Desc: The payload for action could not be des
2023-12-31T14:54:33.152Z:ERROR:ocpp_json.c:462:erialized
2023-12-31T14:54:33.171Z:ERROR:ocpp_rpc.c:438:reply error REPLY ERROR

The failing request is:

 [2,"7","StopTransaction",{"timestamp":"2023-12-31T11:50:33Z","transactionId":2,"meterStop":2145539,"idTag":"ACE0177305","transactionData":[{"values":[{"timestamp":"2023-12-31T11:47:54Z","values":[{"value":"2145.278","context":"Transaction.Begin","unit":"kWh"}]},{"timestamp":"2023-12-31T11:50:33Z","values":[{"value":"2145.539","context":"Transaction.End","unit":"kWh"}]}]}]}]

Need to check if the payload is legit.

I do not have more information now. But I can easily replicate if that helps and send you the logs of that. Strange thing is that Steve communicated fine with Alfen Eve before the firmware update on Alfen.

the first occurrence of values should have been sampledValue. this is according to spec.

edit: sorry, got confused because of differences between ocpp versions. you seem to have an ocpp 1.5 station. the innermost occurrence of values (with a sibling field timestamp) should have been just value.

how can I resolve that on my side?

you can go back to an earlier firmware, or contact the manufacturer about this regression.

Create an issue on alfen helpdesk. They are reactive and often provide early access firmware with fix.

... I am probably forced to say goodbye to Steve, to my great regret, because I have fallen in love with it.

thanks for the kind words.

Is there nothing that can be done on the Steve side?

of course there is. this is software code at the end of the day. i can "bend" the implementation to add some flexibility. i did some similar things in the past for some weird manufacturer decisions and mistakes. but, i dont know how i feel about this after 10 years. i'd rather prefer them doing the right thing, instead of me creating a workaround for their regression.

I succeeded in acquiring a backlevel firmware for my Alfen Eve. I could install it and now Steve communicates again with the charger as before. Although this is an acceptable workaround, of course it is not a solution. For now I am good, but in the future it will be difficult to maintain.
Anyway all: thanks for your support and have a very good year!