OCPP Settings für MeterValueSampleInterval und andere Werte
Closed this issue · 18 comments
Originally posted by @foxriver76 in #16 (comment)
Um die Verbrauchswerte erfassen zu können ist es erforderlich, von der Station regelmässig - wenigstens aber beim Starten und Beenden des Ladevorgangs, die Werte abzufragen. Dazu gibt es ein paar Parameter, MeterValueSampleInterval ist einer. Es wäre schön, wenn man die GetConfig-Methode aus dem Admin-Bereich des Adapters aufrufen könnte (Rückgabe als Textbox-output) und vor allem eine Listenversion von Prameter/Value mitgeben könnte beim Verbinden über die ChangeConfig-Methode posten könnte. Damit würden auch gleich "Heart-beat" und andere Dinge einstellbar werden. Diese Liste könnte der User invividuell füllen, vermutlich wird sie als default bei der Installation mit der Zeit mehr und mehr defaults mitbringen ;)
Liste der Parameter:
https://library.e.abb.com/public/0d9afc6917f84901be1d409da42c1fdf/ABB_Terra_AC_Charger_OCPP1.6_ImplementationOverview%20_v1.7.pdf
Suche nach "Standard Configuration keys"
As Said das Problem ist bei den WBS mit denen ich zu tun hatte gibt es keine Antwort auf Config requests obwohl es zum Core des Protokolls gehört. Es wird initial die Config angefordert und geloggt, du kannst ja mal schauen ob bei dir im Log was auftaucht.
2022-10-09 22:02:23.176 - info: host.smarthome1 "system.adapter.ocpp.0" disabled
2022-10-09 22:02:23.179 - info: host.smarthome1 stopInstance system.adapter.ocpp.0 (force=false, process=true)
2022-10-09 22:02:23.185 - info: host.smarthome1 stopInstance system.adapter.ocpp.0 send kill signal
2022-10-09 22:02:23.187 - info: ocpp.0 (17580) Got terminate signal TERMINATE_YOURSELF
2022-10-09 22:02:23.196 - info: ocpp.0 (17580) terminating
2022-10-09 22:02:23.197 - info: ocpp.0 (17580) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason
2022-10-09 22:02:23.837 - info: host.smarthome1 instance system.adapter.ocpp.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION)
2022-10-09 22:02:34.431 - info: host.smarthome1 "system.adapter.ocpp.0" enabled
2022-10-09 22:02:34.690 - info: host.smarthome1 instance system.adapter.ocpp.0 started with pid 18385
2022-10-09 22:02:36.946 - info: ocpp.0 (18385) starting. Version 0.7.0 (non-npm: foxriver76/ioBroker.ocpp) in /opt/iobroker/node_modules/iobroker.ocpp, node: v16.17.1, js-controller: 4.0.23
2022-10-09 22:02:36.985 - info: ocpp.0 (18385) Starting OCPP Server
2022-10-09 22:02:37.028 - info: ocpp.0 (18385) Server listening on port 9220
2022-10-09 22:02:53.267 - info: ocpp.0 (18385) New valid connection from "/ABL-10115184" (http/ocpp1.6)
2022-10-09 22:02:53.361 - info: ocpp.0 (18385) New device connected: "/ABL-10115184"
2022-10-09 22:02:53.362 - info: ocpp.0 (18385) Requesting StatusNotification from "/ABL-10115184"
2022-10-09 22:02:53.394 - info: ocpp.0 (18385) Received boot notification from "/ABL-10115184"
2022-10-09 22:02:53.498 - info: ocpp.0 (18385) Received Status Notification from "/ABL-10115184.1": Available
2022-10-09 22:02:53.578 - info: ocpp.0 (18385) Received Status Notification from "/ABL-10115184.2": Available
2022-10-09 22:02:54.401 - info: ocpp.0 (18385) Requesting MeterValues from "/ABL-10115184"
2022-10-09 22:02:55.425 - info: ocpp.0 (18385) Sending GetConfiguration to "/ABL-10115184"
ich frage mal eben per SteVe ab, da kam aber was soweit ich mich erinnere. kommt gleich, muss ich eben umbasteln..
Kann ich nicht nachvollziehen. Wenn ich mit SteVe auf der gleichen Ladesäule, angebunden mit OCPP 1.6 JSON, ein GetConfig feuere, bekomme ich einie riesige Liste zurück. Hier angehängt ein Ausschnitt. Eventuell ist mit der Abfrage was falsch? Kann ich helfen, zum Beispiel Zugang zu einer Box bereitstellen oder systematisch Teile testen?
Kannst du mir die Response mal raw zeigen? Die von mir genutzte Lib macht da im Hintergrund etwas validierung, evtl verschluckt er sich da ohne sichtbaren Fehler.
Leider komme ich nicht so ohne weitere an die RAW response, SteVe gibt da keinen output zu. Was ich aber beitragen kann..
- Die Response kommt asynchron. Also auf den Call kommt nur ein "gleich", die eigentlichen Ergebnisse gibt es dann als URL
- In der Beschreibung der ABB-Firmware habe ich einen Hinweis gefunden, wonach "bis FW x.y" auf den call GetConfiguration ohne genauere Angabe des gewünschten Rückgabewertes nur mit einer leeren Antwort reagiert wurde. Ab FW x.y wird ein nicht spezifizierter Rückgabewert mit der Liste aller Werte beantwortet. EV ja hilfreich?
- Machen wir EV mal ne session mit nem jump-host für Dich? Da ist eine komplette Config mit Charger, SteVe, iobroker und linux zum testen drin. Teamviewer oder so? PM?
Danke für die Infos, das deckt sich auch genau mit dem wie ich das Protokoll kenne. GetConfiguration gehört zum Core und muss eigentlich funktionieren wenn sich an die Spezifikation gehalten wird. Auch das man die gesamte Konfiguration ohne Angabe von Parametern bekommt (genau so wird es aktuell im Code gemacht).
Meine Pulsar Plus antwortet hierauf dem Adapter nicht und deine scheinbar auch nicht, ich vermute daher nicht mehr zwingend dass es an meiner WB liegt, da ja deine mit dem anderen OCPP Server eine Antwort sendet. Meine Vermutung geht eher dahin, dass die genutzte Library Mist macht, leider ist da nicht auf Support zu hoffen und wenn dann darf ich die Lib übernehmen, worauf ich nicht gehofft hatte.
Die Lib ist aktuell schon ein etwas weiterentwickelter Fork der verwaisten Lib. Leider wohl allerdings eher für interne Zwecke.
Wir können uns gerne mal gemeinsam den Kopf darüber zerbrechen, wie wir das am cleversten lösen können, nur die nächsten Tage sieht es zeitlich schlecht aus,
Gerne. Bin dienstlich auch erst Freitag wieder da - wollen wir am Wochenende mal kontakten?
Nun brauchen wir ja getConfiguration gar nicht unbedingt um Parameter zu setzen - den konkreten Usecase von mir kann man auch mit einem Get der MeterValues zum Beginn und nach dem Ende des Ladevorgangs abbilden. Aber mit der Lib wirst Du / werden wir auf die Dauer nicht glücklich, hab das repo eben mal flüchtig durchgesehen. Da wird uns nix anderes übrig bleiben, als das zu implementieren. Ich schaue mal, ob ich einen guten starting-point finde.
BTW: Hätte hier nicht auch englisch einen gewissen Sinn, um die community zu vergrößern?
Also dein Use Case sollte mit der aktuellen Version gehen, habe es nicht getestet allerdings nehme ich den Meter der mit start gesendet wird und ziehe diesen bei dem Meter bei stop ab und schreibe es in lastTransactionConsumption.
Du meinst unsere Konversation in Englisch? Ja das ist gängig, da du das Issue auf deutsch eröffnet hast, habe ich auf deutsch geantwortet, um Sprachbarrieren zu vermeiden. Wenn englisch auch ok dann gerne englisch. 👍
funny, yes, i started in german as other tickets are german and i tried to avoid language trouble. :)
ups, i did not recognize "lastTransactionConsumption" at all - of cause that will do the job.
but anyway, the connector has a great potential to get famous in iobroker, as many people have the need to charge their company for home-charging. Means, we need a basic customer handling. and a simple report that can be exported. all not a big deal, just some workload - as always..
To be fair, the datapoint is pretty new. I have introduced it with the new version as I saw that these values are also always delivered according to the protocol.
I am totally with you, the config is something I wanted to integrate from the beginning on, but as it is not my own wallbox my intrinsic motivation was not high enough to write my own Lib for that, thus, as you see, I use the best what’s out there for nodejs 😆
So information not gets lost: https://github.com/mikuso/ocpp-rpc does look promising.
I am currently implementing the configuration. Synchronizing should already be possible via the version on GitHub.
@foxriver76 updated to 0.8.2 from GIT, saw the commits + will testrun.
Published 0.9.0 a few minutes ago
0.9.0 (2023-01-13)
(foxriver76) we removed states from main connector which are not allowed there (foxriver76) we now synchronize configuration into adapter (foxriver76) we added ack flag to availability state (foxriver76) we added ack flag for charge limit states (foxriver76) we optimized error logging (foxriver76) we now allow changing charger configuration via adapter (foxriver76) we improved reconnect handlingPlease delete all states of connector 0 once
uii, great stuff! seems re-connect no works, at least breaking connection leads to re-sync after a minute now. will do some further testing tomorrow
much, much better with stability on network availability now. seems, ping / connection reset is doing the job. thanks, @foxriver76
Changing config also works for you?