etecprojekt
commented
1 month ago Anbei noch die volle Logdatei
Closed etecprojekt closed 1 month ago
etecprojekt
commented
1 month ago Anbei noch die volle Logdatei
premultiply
commented
1 month ago [ABL_3W226305065-1] WARN 2024/08/21 08:52:10 waiting for local authentication
Die Box wartet auf die lokale Freigabe via RFID oder Free Charge-Mode.
premultiply
commented
1 month ago [ocpp ] ERROR 2024/08/21 08:56:10 ocpp message (140010820): OccurrenceConstraintViolation - Field CallResult.Payload.ChargingSchedule.ChargingRateUnit required but not found for feature GetCompositeSchedule ([3, "140010820" ,{"status":"Accepted","connectorId":2,"scheduleStart":"2024-08-21T06:56:09.340+00:00","chargingSchedule":{"duration":60,"startSchedule":"2024-08-21T06:56:09.340+00:00","chargingSchedulePeriod":[{"startPeriod":0,"limit":16.0}]}}])
Das ist ein Fehler in der OCPP-Implementierung der Box. Verletzung des Standards. Bitte damit an den Hersteller wenden.
etecprojekt
commented
1 month ago Hallo,
vielen Dank für die Info. Da wird seitens ABL wohl nichts mehr kommen, da die eMH3 aus dem Programm genommen wurde. Also heißt das, dauerhaft die Version 0.129.0 nutzen?
Vielen Dank.
premultiply
commented
1 month ago Erstmal Problem 1 bei dir lösen, der Error ist zweitrangig und nur ein Hinweis.
etecprojekt
commented
1 month ago Die ID für freies Laden wird doch in der Konfiguration (idtag: 10101010101010) mit übergeben, wieso sollte die Box dann auf eine Authentifizierung waren? Es hat so bislang immer funktioniert, und es wurde nichts geändert oder neugestartet. Ich werde nochmal auf die neuste Version gehen und es nochmal beobachten.
premultiply
commented
1 month ago RFID-Karte vorhalten oder Wallbox in deren OCPP-Setup auf "Free charge", "Autostart", "Free vending" o.ä. konfigurieren. Ref https://github.com/evcc-io/evcc/pull/14888 und https://docs.evcc.io/blog/2024/08/17/highlights-14a-enwg-ocpp-loadmanagement-elli#rfid-und-autorisierung
etecprojekt
commented
1 month ago Nochmal kurz getestet, Konfiguration auf Freies Laden funktioniert, allerdings sind die Funktionen nicht gewünscht. Wieso wird das idTag nicht weiterhin mit übergeben? So ist eine Sperre des Ladeports möglich, wenn dieser über EVCC ausgeschaltet wird. Ist der Modus auf Freies Laden, wird erst ein Ladevorgang gestartet.
Was auch nicht geht, ist die Regelung. EVCC bekommt die Ladeleistung nicht mit, weshalb immer wieder ein und ausgeschaltet wird, obwohl diese im 10 Sekunden Takt übermittelt wird.
premultiply
commented
1 month ago Nochmal kurz getestet, Konfiguration auf Freies Laden funktioniert,
Prima. Wie erwartet. Dann genau so lassen.
allerdings sind die Funktionen nicht gewünscht.
Die Alternative lautet RFID-Authentifizierung.
Wieso wird das idTag nicht weiterhin mit übergeben?
Das idTag heisst per default "evcc" und wird grundsätzlich nur bei RemoteStartTransaction benötigt. Nur extrem selten besteht die Notwendigkeit hierfür ein anderes, vorgegebenes manuelles idTag zu verwenden. Wird hier nicht gebraucht und daher ist diese Konfig-Option überflüssig.
So ist eine Sperre des Ladeports möglich, wenn dieser über EVCC ausgeschaltet wird.
Das ist richtig. Der Default-Modus "off" in evcc sperrt den Ladepunkt für fremde Nutzer, die Fahrzeugerkennung ermöglicht es nur berechtigte Fahrzeuge automatisch zu laden (Default-Lademodus des jeweiligen Fahrzeugs). Über die UI lassen sich auch Gastfahrzeuge freigeben.
Ist der Modus auf Freies Laden, wird erst ein Ladevorgang gestartet.
Das ist nicht richtig. Das verhindert evcc über das gesendete ChargingProfile mit Stromvorgabe 0. Es wird lediglich von der Box eine Transaktion gestartet. Ohne laufende Transaktion ist keinerlei Steuerung der Box durch evcc möglich. Die eigentliche Ladefreigabe obliegt dennnoch durch das ChargingProfile in letzter Instanz evcc. Das sind Feinheiten die man aber zum Verständnis genau differenzieren muss.
Was auch nicht geht, ist die Regelung. EVCC bekommt die Ladeleistung nicht mit, weshalb immer wieder ein und ausgeschaltet wird, obwohl diese im 10 Sekunden Takt übermittelt wird.
Das wäre ein anderes Problem was sich hoffentlich im Log erkennen lässt.
premultiply
commented
1 month ago Bitte die Konfig der beiden OCPP-Ladepunkte mal auf
- type: template
template: ocpp
stationid: ABL_3W226305065
connector: 1
name: wb_re_1
- type: template
template: ocpp
stationid: ABL_3W226305065
connector: 2
name: wb_re_2reduzieren und den FreeCharge Mode aktivieren.
Schau auch mal bitte ob du in der Konfiguration der Box irgendwo das Meter Sample Interval Box auf 10s reduzieren kannst.
Dann mal bitte den Output von evcc charger --log trace --diagnose
premultiply
commented
1 month ago Also, ich habe jetzt dein Log mal durchgesehen.
[ocpp ] DEBUG 2024/08/22 12:30:40 charge point connected: ABL_3W226305065
Ab hier funktioniert es wie es soll. Auf Grund der Logeinträge gehe ich davon aus, dass das der Zeitpunkt war nachdem du den FreeChargeMode aktiviert hast und die Box neugestartet hat/wurde.
Bitte auch noch beachten, da du insgesamt 4 Ladepunkte hast, dass pro Intervall immer nur ein LP bearbeitet wird und es daher zu längeren Verzögerungen zwischen Aktion in der UI und tatsächlicher Änderung am Charger kommen kann. Daher ist es vielleicht hilfreich das evcc interval in der Konfig ggf. etwas zu reduzieren. Probier mal 10s ggf. auch noch weniger. Das sollte das System schon deutlich responsiver machen.
Das einzige was etwas irritierend ist, ist dass die Meteringdaten von evcc in dem Log nicht erkannt wurden und daher vermutlich keine sinnvolle Anzeige in der UI kam. Das kann aber mit der Neuverbindung durch die Änderung auf FreeChargeMode zusammenhängen. Oder auch mit dem sehr langen intervall durch die 4 LPs.
Das würde ich gerne mit einem aktuellen Log nochmal genauer ansehen.
Hier also bitte nochmal mit dem aktuellen Nightly Build testen. Dazu bitte FreeChargeMode anschalten bzw. angeschaltet lassen, dann die Box vollständig neustarten und dann erst evcc (neu)starten.
etecprojekt
commented
1 month ago Werde ich morgen nochmal testen. Etwas schwierig mit 1-4 Fahrzeugen und Sonne die mal da ist und mal nicht 😁 Das Blöde an Mercedes ist noch, wenn innerhalb von 30 Minute - 3 mal ausgeschaltet wird, geht das Fahrzeug auf Ladestörung.
Ich habe die Box schon mal umgestellt und auf nightly geswitcht. Interval habe ich auf 10s gestellt, mir war nicht bewusst, dass immer nur eine in einem Durchlauf bearbeitet wird.
Lokale Vorauthorisierung habe ich auch mal ausgeschaltet.
Nachfolgend noch ein Log, nach dem EVCC start, ohne Fahrzeuge. evcc-20240822-211328-trace.log
etecprojekt
commented
1 month ago Fahrzeug wurde angesteckt, erst mit 6A geladen, dann mit 16A und dann gestoppt, obwohl kein Überschuss verfügbar war, idTag ist in der Config nicht mehr drin.
Trace:
evcc-20240823-065208-trace.log
W
Wallbox:
etecprojekt
commented
1 month ago Eine manuelle Ansteuerung über Min+PV funktioniert, Zählerwerte werden gesendet, allerdings wird die Ladeleistung in EVCC nicht erkannt, somit wird die Überschussregelung nicht funktionieren, da so kein Überschuss erkennen wird.
premultiply
commented
1 month ago Die Anzeige der Leistung des Ladepunkts hat nicht mit der Überschussregelung zu tun. Diese basiert ausschließlich auf den Daten des Netzanschlusses (grid).
premultiply
commented
1 month ago Abgesehen von den diversen Fehlermeldungen auf Grund von Fehlern in der Firmware funktioniert es nach dem erstem Blick in das Log aber nun eigentlich wie es soll.
Bei der Ausgabe der nicht kritischen Fehler werden wir sicherlich noch nachjustieren.
Die Sache mit den Meteringdaten stellt mich aber gerade noch vor ein Rätsel.
/cc @andig Ich stehe auf dem Schlauch. Weshalb werden hier die Ladeleistungen und Energie mit NotAvailable abgelehnt? Hast du eine Idee?
Und wir haben mit Blick auf den Screenshot offensichtlich das Problem, dass wir die interne Constraint-Fehlerausgabe via OCPP an den Charger zurückwerfen, was dieser sicherlich nicht verstehen wird.
etecprojekt
commented
1 month ago Ich glaube du hast recht, er merkt also das die Box Strom zieht (Leistung fehlt), zeigt es glaube ich nur nicht an. Würde er es nicht merken, würde er ja immer wieder an und ausschalten, da er nicht weiß, wieviel Anteil Ladeleistung in Grid steckt. Anbei ein Log mit einem Fahrzeug dran, welches 1p läd und geregelt wird.
[lp-3 ] ERROR 2024/08/23 10:59:22 charge power: not available [lp-3 ] DEBUG 2024/08/23 10:59:22 charge currents: [6.6 0.1 0.1]A [lp-4 ] DEBUG 2024/08/23 10:59:22 charge power: 0W [lp-4 ] DEBUG 2024/08/23 10:59:22 charge currents: [0 0 0]A
Was ich aber als Fehler sehe, dass die Box beim Einstecken sofort mit 6A, dann mit 16A läd und dann abgeschaltet wird. Diese Freigabe darf doch garnicht erst erteilt werden über das Backend oder?
Zudem scheint es noch ein Problem mit dem Timer zu geben, dieser resettet sich immer bei neuladen der Seite auf 2:59.
mfuchs1984
commented
1 month ago @premultiply die MeterValues messages ist auf den ersten Blick anders als bswp. bei meinem Bender Charger, es handelt sich hier um ein Array mit 2 Objekten, das erste enthält die erfolgreich geparsten Currents, das zweite den Rest und nochmals die Currents. Evtl. ist das die Ursache? Die Fehlermeldungen korrespondieren mit den sampledValues, die im ersten Objekt nicht drin sind.
[
2,
"39118670",
"MeterValues",
{
"connectorId": 1,
"transactionId": 1,
"meterValue": [
{
"timestamp": "2024-08-23T06:02:45.311+00:00",
"sampledValue": [
{
"value": "6.0",
"context": "Sample.Periodic",
"format": "Raw",
"measurand": "Current.Import",
"phase": "L1",
"location": "Body",
"unit": "A"
},
{
"value": "6.0",
"context": "Sample.Periodic",
"format": "Raw",
"measurand": "Current.Import",
"phase": "L2",
"location": "Body",
"unit": "A"
},
{
"value": "5.9",
"context": "Sample.Periodic",
"format": "Raw",
"measurand": "Current.Import",
"phase": "L3",
"location": "Body",
"unit": "A"
}
]
},
{
"timestamp": "2024-08-23T06:02:45.337+00:00",
"sampledValue": [
{
"value": "10280.792",
"context": "Sample.Periodic",
"format": "Raw",
"measurand": "Energy.Active.Import.Register",
"location": "Outlet",
"unit": "kWh"
},
{
"value": "4185.3",
"context": "Sample.Periodic",
"format": "Raw",
"measurand": "Power.Active.Import",
"location": "Outlet",
"unit": "W"
},
{
"value": "5.957",
"context": "Sample.Periodic",
"format": "Raw",
"measurand": "Current.Import",
"phase": "L1",
"location": "Outlet",
"unit": "A"
},
{
"value": "6.027",
"context": "Sample.Periodic",
"format": "Raw",
"measurand": "Current.Import",
"phase": "L2",
"location": "Outlet",
"unit": "A"
},
{
"value": "5.983",
"context": "Sample.Periodic",
"format": "Raw",
"measurand": "Current.Import",
"phase": "L3",
"location": "Outlet",
"unit": "A"
},
{
"value": "236.3",
"context": "Sample.Periodic",
"format": "Raw",
"measurand": "Voltage",
"phase": "L1-N",
"location": "Outlet",
"unit": "V"
},
{
"value": "234.8",
"context": "Sample.Periodic",
"format": "Raw",
"measurand": "Voltage",
"phase": "L2-N",
"location": "Outlet",
"unit": "V"
},
{
"value": "235.8",
"context": "Sample.Periodic",
"format": "Raw",
"measurand": "Voltage",
"phase": "L3-N",
"location": "Outlet",
"unit": "V"
},
{
"value": "6.0",
"context": "Sample.Periodic",
"format": "Raw",
"measurand": "Current.Offered",
"location": "Outlet",
"unit": "A"
},
{
"value": "0.0",
"context": "Sample.Periodic",
"format": "Raw",
"measurand": "Power.Offered",
"location": "Outlet",
"unit": "kW"
}
]
}
]
}
]Ist das die Stelle, wo das verarbeitet wird?
func (conn *Connector) MeterValues(request *core.MeterValuesRequest) (*core.MeterValuesConfirmation, error) {
conn.mu.Lock()
defer conn.mu.Unlock()
if request.TransactionId != nil && conn.txnId == 0 && conn.status != nil &&
(conn.status.Status == core.ChargePointStatusCharging ||
conn.status.Status == core.ChargePointStatusSuspendedEV ||
conn.status.Status == core.ChargePointStatusSuspendedEVSE) {
conn.log.DEBUG.Printf("hijacking transaction: %d", *request.TransactionId)
conn.txnId = *request.TransactionId
}
for _, meterValue := range request.MeterValue {
// ignore old meter value requests
if meterValue.Timestamp.Time.After(conn.meterUpdated) {
for _, sample := range meterValue.SampledValue {
sample.Value = strings.TrimSpace(sample.Value)
conn.measurements[getSampleKey(sample)] = sample
conn.meterUpdated = conn.clock.Now()
}
}
}
select {
case conn.meterC <- conn.measurements:
default:
}
return new(core.MeterValuesConfirmation), nil
}Ohne jetzt der go Experte zu sein würde ich sagen, die for-Schleife nimmt das erste Objekt, schaut sich den Timestamp (2024-08-23T06:02:45.311+00:00) an und wenn er neuer ist als conn.meterUpdated, werden die Werte verarbeitet -> die currents werden gespeichert und conn.meterUpdated auf die aktuelle Zeit conn.clock.Now() gesetzt. Nun wird das zweite Objekt mit dem Timestamp 2024-08-23T06:02:45.337+00:00 verarbeitet. Da aber conn.clock.Now() bei Verarbeitung des ersten Objekts schon später als der Timestamp des zweiten Objekts ist, wird der Inhalt ignoriert.
premultiply
commented
1 month ago Autsch, ja!! Super! Hier gibt es zwei Objekte: Einmal von der Messposition Body (für uns eigentlich eher irrelevant) und einmal Outlet.
Da muss ich erstmal überlegen wie wir damit sinnvoll umgehen.
/cc @andig
andig
commented
1 month ago Da aber conn.clock.Now() bei Verarbeitung des ersten Objekts schon später als der Timestamp des zweiten Objekts ist, wird der Inhalt ignoriert.
Dann sollten wir das einfach nach Timestamps sortieren (anstatt mit location rumzufrickeln)? Vorschlag kommt.
premultiply
commented
1 month ago Die Location ist hier schon auch relevant, da das hier eine Box mit zwei LPs ist und der Ladestrom beider LPs auf den Body-Werten auftaucht, wir uns hier aber nur für die Outlets (Connector) interessieren. Die Body-Werte verwirren hier nur - kann aber bei anderen Boxen wieder anders sein.
mfuchs1984
commented
1 month ago Je nach Verhalten der Wallboxen ggf. over engineered, aber wäre es nicht am robustesten, mit dem neuesten timestamp anzufangen und dann bis zum ältesten Objekt weiterzumachen und measurands, die noch nicht gefunden wurden, daraus zu ergänzen? Dabei Outlet vor Body priorisieren?
andig
commented
1 month ago Dabei Outlet vor Body priorisieren?
Sind die irgendwo definiert?
mit dem neuesten timestamp anzufangen und dann bis zum ältesten Objekt weiterzumachen und measurands
Umgekehrt und dann wird einfach überschrieben.
premultiply
commented
1 month ago Das würde hier vielleicht funktionieren aber in anderen Fällen (andere Boxen) ist die Reihenfolge ggf. eine andere? Ist ja leider nicht näher definiert. Und wie wir wissen macht da jeder Hersteller irgendwas anderes (wie man hier ja auch sieht). Theoretisch können die auch alle mit unterschiedlichen Locations unter einem Timestamp stehen.
Aktuell sehe ich noch keine elegante Möglichkeit das möglichst universell zu lösen. Doch irgendwie eine Priorität nach der Location machen?
mfuchs1984
commented
1 month ago Ocpp 1.6 Specs chapter 7.30
Body Measurement inside body of Charge Point (e.g. Temperature)
Cable Measurement taken from cable between EV and Charge Point
EV Measurement taken by EV
Inlet Measurement at network (“grid”) inlet connection
Outlet Measurement at a Connector. Default value
andig
commented
1 month ago Ich sehe hier gar kein Problem. Oder wollen wir Spannungsabfall über das Kabel messen???
premultiply
commented
1 month ago Nein, aber wir wollen auch nicht zufällige Sprünge in den Currents sehen?
andig
commented
1 month ago ...dann könnte man in anderer Logik nach Zeit und Location sortieren. Dafür müssten die verschachtelten Listen erst gemerged werden?
premultiply
commented
1 month ago Das geht aus meiner Sicht in die richtige Richtung.
mfuchs1984
commented
1 month ago Mit dem PR bleibt das Grundroblem doch bestehen, oder? Da conn.meterUpdated auf conn.clock.Now() gesetzt wird, was definitiv später als die Timestamps ist, wird alles nach dem ersten Objekt in der nun sortierten Liste nicht verarbeitet. Steht zufällig das Benötigte im ersten Objekt der sortierte Liste, ist alles gut, wenn nicht, fehlt was. Oder übersehe ich was?
for _, meterValue := range sortByAge(request.MeterValue) {
// ignore old meter value requests
if meterValue.Timestamp.Time.After(conn.meterUpdated) {
for _, sample := range meterValue.SampledValue {
sample.Value = strings.TrimSpace(sample.Value)
conn.measurements[getSampleKey(sample)] = sample
conn.meterUpdated = conn.clock.Now()
}
}
}Man müsste meines Erachtens nur einen der Timestamp im request für die Prüfung meterValue.Timestamp.Time.After(conn.meterUpdated) heranziehen, danach alle Objekte verarbeiten und anschließend erst conn.meterUpdated = conn.clock.Now() aufrufen.
andig
commented
1 month ago Das geht aus meiner Sicht in die richtige Richtung.
Dann brauchts bitte eine Precedence eincshl. "leer". Welche Werte "stechen"?
premultiply
commented
1 month ago Das ist gar nicht so einfach, da es für diverse Messwerte unterschiedlich ist.
Voltage: Inlet, Body, Outlet, "" Currents/Power/Energy: "", Outlet, Body, Inlet Current.Offered/Power.Offered/SoC: egal?
kschwar
commented
1 month ago Wie kann ich den pr #15623 testen?
andig
commented
1 month ago da es für diverse Messwerte unterschiedlich ist.
Ist das so? Muss uns das wirklich interessieren? Ich sehe nichtmal in den Beispielmesswerten hier ein echtes Problem da die disjunkt sein?
That said: der aktuelle PR sollte schon reichen. Kein Grund für Overengineering.
premultiply
commented
1 month ago Ja, ist schon so. Irgendwo wird es uns sehr bald wieder auf die Füße fallen. ;) Aber gut, fürs Erste hier erstmal dann hoffentlich gefixt.
Ich lass hier aber mal auf, da das Problem mit den Error-Ausgaben auf die OCPP-Schnittstelle noch eines Fixes bedarf. Komme ich aber erst heute Abend dazu.
mfuchs1984
commented
1 month ago Mit dem PR bleibt das Grundroblem doch bestehen, oder? Da conn.meterUpdated auf conn.clock.Now() gesetzt wird, was definitiv später als die Timestamps ist, wird alles nach dem ersten Objekt in der nun sortierten Liste nicht verarbeitet. Steht zufällig das Benötigte im ersten Objekt der sortierte Liste, ist alles gut, wenn nicht, fehlt was. Oder übersehe ich was?
for _, meterValue := range sortByAge(request.MeterValue) { // ignore old meter value requests if meterValue.Timestamp.Time.After(conn.meterUpdated) { for _, sample := range meterValue.SampledValue { sample.Value = strings.TrimSpace(sample.Value) conn.measurements[getSampleKey(sample)] = sample conn.meterUpdated = conn.clock.Now() } } }Man müsste meines Erachtens nur einen der Timestamp im request für die Prüfung meterValue.Timestamp.Time.After(conn.meterUpdated) heranziehen, danach alle Objekte verarbeiten und anschließend erst conn.meterUpdated = conn.clock.Now() aufrufen.
@andig @premultiply Sorry falls ich es nicht ganz verstehe, aber ich bin nach wie vor der Meinung, dass der PR nicht hilft. In dem Fall hier sind sie Objekte ja schon nach timestamp sortiert, aber das zweite wird nicht verarbeitet aufgrund des Vergleichs mit conn.meterupdated, welches nach Verarbeitung des ersten Objekt auf conn.clock.Now() steht, was wohl der aktuellen Systemzeit entspricht und somit neuer als der timestamp des zweiten Objekts ist. Will man das verhindern, müsste man es auf den timestamp des zuletzt verarbeiteten Objekt setzen (ggf. problematisch wenn der hinterher hinkt) oder wie oben vorgeschlagen nur einen timestamp vergleichen.
andig
commented
1 month ago Good catch. Siehe PR- der Vergleich ist umzudrehen.
In dem Fall hier sind sie Objekte ja schon nach timestamp sortiert
Check- aber darauf kann man sich vmtl. auch nicht verlassen, daher der andere PR...
etecprojekt
commented
1 month ago Good catch. Siehe PR- der Vergleich ist umzudrehen.
In dem Fall hier sind sie Objekte ja schon nach timestamp sortiert
Check- aber darauf kann man sich vmtl. auch nicht verlassen, daher der andere PR...
Wann erscheint das ganze im Docker nightly Build? Würde es dann einmal testen und logs bereitstellen.
etecprojekt
commented
1 month ago Mit der aktuellen nightly, kann der Ladepunkt nicht mehr erstellt werden. Nachfolgend der Log: evcc-20240825-103747-trace.log evcc_logs (1).txt
andig
commented
1 month ago @premultiply ich verstehe nicht was hier los ist. Die Kommunikation funktioniert, aber es gibt einen Timeout und alle Meßwerte werden hier einzeln konfiguriert?
[ocpp ] TRACE 2024/08/25 10:31:09 send ABL_3W226305065: [2,"2656132676","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Power.Active.Import"}]
[ocpp ] TRACE 2024/08/25 10:31:09 send ABL_3W226305065: [2,"2489658164","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Energy.Active.Import.Register"}]
[ocpp ] TRACE 2024/08/25 10:31:09 send ABL_3W226305065: [2,"1788724089","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Current.Import"}]
[ocpp ] TRACE 2024/08/25 10:31:09 send ABL_3W226305065: [2,"553884136","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Voltage"}]
[ocpp ] TRACE 2024/08/25 10:31:09 send ABL_3W226305065: [2,"3257290741","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Current.Offered"}]
[ocpp ] TRACE 2024/08/25 10:31:09 send ABL_3W226305065: [2,"3995821291","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Power.Offered"}]
[ocpp ] TRACE 2024/08/25 10:31:09 send ABL_3W226305065: [2,"2798628732","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"SoC"}]
[ocpp ] TRACE 2024/08/25 10:31:09 send ABL_3W226305065: [2,"1399715684","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Power.Active.Import,Energy.Active.Import.Register,Current.Import,Voltage,Current.Offered,Power.Offered,SoC"}]
[ocpp ] TRACE 2024/08/25 10:31:09 send ABL_3W226305065: [2,"145743017","ChangeConfiguration",{"key":"MeterValueSampleInterval","value":"10"}]Auffällig ist an der Stelle des timeouts, dass der erste der beiden timestamps in den empfangenen MeterValues stark veraltet ist, evtl. ein Seiteneffekt des PR #15643? Da der zweite timestamp aber ok ist, sollte das eigentlich passen.
[ocpp ] TRACE 2024/08/25 10:35:05 recv ABL_3W226305065: [2, "20839185", "MeterValues" ,{"connectorId":1,"transactionId":1,"meterValue":[{"timestamp":"2024-08-25T08:34:44.584+00:00","sampledValue":[{"value":"15.9","context":"Sample.Periodic","format":"Raw","measurand":"Current.Import","phase":"L1","location":"Body","unit":"A"},{"value":"15.9","context":"Sample.Periodic","format":"Raw","measurand":"Current.Import","phase":"L2","location":"Body","unit":"A"},{"value":"15.8","context":"Sample.Periodic","format":"Raw","measurand":"Current.Import","phase":"L3","location":"Body","unit":"A"}]},{"timestamp":"2024-08-25T08:35:04.062+00:00","sampledValue":[{"value":"10286.317","context":"Sample.Periodic","format":"Raw","measurand":"Energy.Active.Import.Register","location":"Outlet","unit":"kWh"},{"value":"11274.0","context":"Sample.Periodic","format":"Raw","measurand":"Power.Active.Import","location":"Outlet","unit":"W"},{"value":"15.896","context":"Sample.Periodic","format":"Raw","measurand":"Current.Import","phase":"L1","location":"Outlet","unit":"A"},{"value":"15.934","context":"Sample.Periodic","format":"Raw","measurand":"Current.Import","phase":"L2","location":"Outlet","unit":"A"},{"value":"15.983","context":"Sample.Periodic","format":"Raw","measurand":"Current.Import","phase":"L3","location":"Outlet","unit":"A"},{"value":"237.0","context":"Sample.Periodic","format":"Raw","measurand":"Voltage","phase":"L1-N","location":"Outlet","unit":"V"},{"value":"236.4","context":"Sample.Periodic","format":"Raw","measurand":"Voltage","phase":"L2-N","location":"Outlet","unit":"V"},{"value":"236.5","context":"Sample.Periodic","format":"Raw","measurand":"Voltage","phase":"L3-N","location":"Outlet","unit":"V"},{"value":"16.0","context":"Sample.Periodic","format":"Raw","measurand":"Current.Offered","location":"Outlet","unit":"A"},{"value":"0.0","context":"Sample.Periodic","format":"Raw","measurand":"Power.Offered","location":"Outlet","unit":"kW"}]}]}]
[ocpp ] TRACE 2024/08/25 10:35:05 send ABL_3W226305065: [3,"20839185",{}]
[main ] FATAL 2024/08/25 10:35:09 cannot create charger 'wb_re_1': cannot create charger type 'template': cannot create charger type 'ocpp': timeoutalle Meßwerte werden hier einzeln konfiguriert?
Das ist die normale Autokonfiguration die die einzelnen Measurands auf Gültigkeit durchprobiert und anschließend alle gültigen konfuguriert.
andig
commented
1 month ago Ahhh, danke :). Hast Du eine Idee, woher jetzt der Timeout kommt? Ich habe https://github.com/evcc-io/evcc/pull/15644 im Verdacht, sehe aber nicht warum?
andig
commented
1 month ago @mfuchs1984 kannst Du selbst kompilieren? Falls ja probier mal bitte
git revert e622e67 && makeIch kann kompilieren, habe aber nicht die betroffene Wallbox, sondern eine Bender
andig
commented
1 month ago @etecprojekt siehe https://github.com/evcc-io/evcc/issues/15559#issuecomment-2308750931. Kannst Du compilieren oder alternativ Deine Box mal auf meinen Rechner als OCPP Server umbiegen? In dem Fall bitte bei info@evcc.io melden- vielen Dank!
kschwar
commented
1 month ago Habe dir eine E-Mail geschrieben, danke 😉
etecprojekt
commented
1 month ago Startet wieder und verbindet. Werde es ggf. heute Nachmittag nochmal mit einem Ladevorgang testen. Nachfolgen ein Log ohne verbundene Fahrzeuge: evcc-20240825-132443-trace (1).log evcc-20240825-132701-trace.log
etecprojekt
commented
1 month ago Nachfolgend ein Log von einem kurzen Ladevorgang: evcc-20240825-151251-trace.log
etecprojekt
commented
1 month ago Wenn ein Fahrzeug eingesteckt ist, kein Überschuss verfügbar ist, laufen die charge abfragen alle auf timeout und werden in der UI als Fehler angezeigt.
Describe the bug
Hallo zusammen,
nach dem Update von Version 0.129.0 auf 0.130.2 funktioniert die Ansteuerung der ABL eMH3 (3W2263) nicht mehr. Nachfolgende Fehlermeldungen aus dem Log:
[ocpp ] ERROR 2024/08/21 07:04:20 ocpp message (2383823729): OccurrenceConstraintViolation - Field CallResult.Payload.ChargingSchedule.ChargingRateUnit required but not found for feature GetCompositeSchedule ([3, "2383823729" ,{"status":"Accepted","connectorId":1,"scheduleStart":"2024-08-21T05:04:19.385+00:00","chargingSchedule":{"duration":60,"startSchedule":"2024-08-21T05:04:19.385+00:00","chargingSchedulePeriod":[{"startPeriod":0,"limit":-1.0}]}}])Die Ladung wird laut Log wohl freigegeben aber es erfolgt keine Ladung. Haben jetzt erstmal wieder auf Version 0.129.0 zurück.Steps to reproduce
PV-Überschussladen, Min+PV ohne Funktion.
Configuration details
Log details
What type of operating system are you running?
Linux
Version
0.130.2