Jump to content

rtrbt

Administrators
  • Gesamte Inhalte

    1.388
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    127

Posts erstellt von rtrbt

  1. Stimmt, die Variable wird bei Stream-Funktionen in beide Richtungen generiert, aber nur bei Streams vom Bricklet zum PC verwendet. Gefixt: https://github.com/Tinkerforge/generators/commit/aaf854e9

    On 7/31/2023 at 1:04 PM, stefanwe said:

    In der Tat eine Menge Arbeit. Durch ESLint stelle ich auch if/else`s um. Die Evals hab ich auch entfernt.
     

    Knackpunkt ist ESM, ich konnte einfach die JSLib nicht laden für mein Projekt.
    Meine Idee ist noch später Objekte als Zusatz zu schreiben die mit promis die callback daten dann liefern. Die Original-API soll erhalten bleiben, damit die Dokumentation stimmt.

    Das sind alles gute Punkte. Muss ich mit meinem Kollegen mal besprechen ob und wenn ja wie viel davon wir übernehmen können. Wir melden uns dazu nochmal ;)

  2. Das ist in der Tat ein Fehler, danke für den Hinweis!

    Die Fehlerbehandlung, die das streamStateObject zurücksetzt usw. gibt es an mehreren Stellen, alle außer dieser sind aber in Hilfsfunktionen, die device als Parameter übergeben bekommen. Das ist laut git blame seit 2017 niemanden aufgefallen.

    Ich habe das im Generator gefixt: https://github.com/Tinkerforge/generators/commit/fdcc67f1b8f1f210a7aa0d6944f633cab6a9318d und dir neu generierte Bindings angehangen.

    On 7/29/2023 at 11:22 AM, stefanwe said:

    Hallo, wie im Titel schon gesehen, hab ich begonnen mir die JSlib sauber ins TypeScript umzuschreiben.

    Versuchst du auch die Interna zu typisieren, oder nur das Interface nach außen? Eventuell könnten wir das auch generieren. Das für 150 Geräte von Hand zu schreiben stelle ich mir anstrengend vor ;)

    tinkerforge_javascript_bindings_2_1_34.zip

  3. Das ist beabsichtigt.

    Laut Anleitung heißt ein grünes "Atmen" (also langsameres Pulsieren als das Blinken im Fehlerfall), dass alles OK ist und entweder PV-Überschussladen deaktiviert ist, oder gerade Strom ins Netz eingespeist wird.

    Soweit ich das im Code sehe müsste das aber auch schon immer so gewesen sein. Es gibt keinen Standby-Modus o.Ä. der nach einer Weile das "Atmen" stoppt.

  4. Aus dem vollständigen Log sehe ich folgendes:

    • Es dauert nach Start der Wallbox ~ eine Minute, bis die Slave-Box per MDNS aufgelöst wird. Das erklärt
      2023-07-27 16:11:48,661  Received packet from unknown 192.168.1.75. Is the config complete?
      2023-07-27 16:11:49,673  Received packet from unknown 192.168.1.75. Is the config complete?
      2023-07-27 16:11:56,874  Resolved warp-um6-west.local to 192.168.1.75 (via mDNS scan)
    • Es wird zwei Mal Strom umverteilt:
      2023-07-27 16:12:04,203  Redistributing current
      2023-07-27 16:12:04,203      1 charger requests current. 16900 mA available.
      2023-07-27 16:12:04,203      stage 0: Calculated target for warp-ULS-Ost (127.0.0.1) of 6000 mA. 10900 mA left.
      2023-07-27 16:12:04,214      stage 0: 10900 mA still available. Recalculating targets.
      2023-07-27 16:12:04,224      stage 0: Recalculated target for warp-ULS-Ost (127.0.0.1) of 16000 mA. 900 mA left.
      2023-07-27 16:12:04,234      stage 0: 900 mA still available. Attempting to wake up chargers that already charged their vehicle once.
      2023-07-27 16:12:04,245      stage 2: Unthrottled warp-ULS-Ost (127.0.0.1) to 16000 mA.
      2023-07-27 16:12:05,352  Charger state changed from 1 to 2
      2023-07-27 16:12:07,384  Charger state changed from 2 to 3
      2023-07-27 16:13:14,269  Redistributing current
      2023-07-27 16:13:14,270      1 charger requests current. 17500 mA available.
      2023-07-27 16:13:14,270      stage 0: Calculated target for warp-ULS-Ost (127.0.0.1) of 6000 mA. 11500 mA left.
      2023-07-27 16:13:14,280      stage 0: 11500 mA still available. Recalculating targets.
      2023-07-27 16:13:14,291      stage 0: Recalculated target for warp-ULS-Ost (127.0.0.1) of 6000 mA. 11500 mA left.
      2023-07-27 16:13:14,301      stage 0: 11500 mA still available. Attempting to wake up chargers that already charged their vehicle once.
      2023-07-27 16:13:14,311      stage 1: Throttled warp-ULS-Ost (127.0.0.1) to 6000 mA.
      2023-07-27 16:13:14,321      stage 1: Throttled a charger. Skipping stage 2
      2023-07-27 16:13:14,332      Skipping stage 2

    Am Anfang macht der Verteilungsalgorithmus alles richtig, bei der zweiten Verteilung gibt er der Box aber nur 6 Ampere. Ich vermute, dass das mit einer der Lastmanagement-Änderungen in 2.1.3 zusammenhängt. Kannst du testweise in den Experteneinstellungen die Länge der Start­phase auf z.B. 120 Sekunden umstellen? Wenn dann erst nach zwei Minuten der Strom auf 6 Ampere geregelt wird, weiß ich, wo ich suchen muss.

  5. Aktiviere unter Wallbox -> Lastmanagement in den Experteneinstellungen mal das Stromverteilungsprotokoll. Dann schreibt der Lastmanager jedes Mal wenn er Strom verteilt in sein Ereignislog, was er tut. Dann erzeuge das Problem nochmal und zieh einen Debug-Report. Damit sollten wir sehen wo der Strom hin ist.

  6. On 7/22/2023 at 10:14 AM, gustavpaula said:

    Einmal auf 100% geladen: sieht so aus, als ob am Ladeende bei Ladestromsoll = 6A jetzt Ruhe ist. Danke!

    Sehr gut!

    On 7/22/2023 at 10:14 AM, gustavpaula said:

    Werden jetzt Dutzende von WARP1 Besitzern auch diese Fehlfunktion haben und deren WARP eine Rekalibrierung brauchen?

    Vermutlich nicht. Die alte Kalibrierung auf deiner Wallbox war im unteren Bereich ziemlich stark, vermutlich um unabsichtlicherweise die anderen Bugs auszugleichen. Das ursprüngliche Problem, dass das Schütz hin- und herschaltet hatten wir aber bisher meines Wissens nur bei dir und einem anderen Kunden.

  7. Genau richtig.

    Hier die Kalibrierungsdatei. Die kannst du unter Wallbox -> Ladestatus im Low-Levelzustand unter Kalibrierung hochladen. Danach sollte der erste Wert unter "Wider­stands­ka­li­brie­rung 880Ω" -3553 sein und die Zustandswechsel wenn das Auto voll ist (und du 7 Ampere oder weniger vorgibst) sollten nicht mehr auftreten.

    calibration.json

  8. Die Änderungen um das Schützschalten weg zu bekommen haben leicht das Messprinzip geändert. Vermutlich müssen wir jetzt nochmal die Wallbox kalibrieren, weil die alte Kalibrierung bei kleinem erlaubten Ladestrom sehr stark ist. Mach das mal wie hier beschrieben:

    Zusätzlich kannst du das selbe nochmal machen, wenn dein Auto voll (bzw. auf 80% SoC wenn du das Ladeende darauf konfiguriert hast) ist. Dann wird die Kalibrierung besser. Das muss nicht im selben Ladeprotokoll sein, darf es aber.

  9. Oh sorry, ich habe seit Ewigkeiten auf der TODO-Liste stehen, die Dokumentation dafür zu aktualisieren. Mache ich heute noch.

    On 7/11/2023 at 6:28 PM, Frankstar said:

    das Ziel wär das aktuelle "Lade-Log" zu unterbrechen damit ich im Ladelog keine Ladungen von über n-Stunden habe und quasi eine neue Ladung beginnt ohne das ich zum Auto gehen muss aus/einstecken.

    Das wird mit der CP-Unterbrechung nicht funktionieren (siehe hier ;) )

    Im Moment kannst du einen Ladevorgang nur beenden, in dem du entweder das Auto abziehst, oder (falls du die Benutzerfreigabe per NFC-Tag benutzt) das Tag an die Box hältst. Das Tag kannst du aber per API injecten: https://www.warp-charger.com/api.html?v=2#nfc_inject_tag

  10. On 7/8/2023 at 8:25 PM, Little_Company said:

    gibt es schon eine ungefähre Vorstellung, wann die Funktion ein Root Zertifikat hochgeladen werden kann eingeplant ist.

    Ich habe das gerade Proof-of-Concept-artig zusammengeschrieben und es scheint soweit zu funktionieren. Es fehlt noch GUI im Webinterface usw., aber ich würde sagen, das schaffen wir bis zum nächsten Firmware-Release. Also auf jeden Fall deutlich vor den sechs Monaten.

  11. tl;dr: Nach meiner Interpretation der Spec wirkt ein ChargePointMaxProfile, dass als Kind "Absolute", aber keinen scheduleStart-Wert gesetzt hat, nie. Das ist aber streitbar. Wenn du scheduleStart auf einen Zeitpunkt in der Vergangenheit setzt funktionierts.

    Hm das ist ein sehr spezifischer Fall, den du da erzeugst.

    Das ChargingProfile hat als Kind "Absolute". Laut Spec

    Quote

    Absolute
     Schedule periods are relative to a fixed point in time defined in the schedule.

    (Hervorhebung von mir)

    Der ChargingSchedule hat aber keinen startSchedule gesetzt. Wieder laut Spec

    Quote

    startSchedule
     dateTime
     0..1
     Optional. Starting point of an absolute schedule. If absent the schedule will be relative to start of charging.

    Nach meiner Interpretation heißt das, dass du bei einem Absolute-Profile im Schedule den startSchedule weglassen darfst, und wenn du das tust, dann fängt das ganze Profile in dem Moment zu wirken an, wenn ein Ladevorgang (also eine Transaktion) beginnt.

    Ich habe mir dann den Code, der ein Profile evaluiert nochmal angesehen (findest du hier: https://github.com/Tinkerforge/tfocpp/blob/fdf69d6389e803c4b2d06ac3b9ec20c8b816404a/src/ocpp/ChargingProfile.cpp#L47 im Code sind alle /* */-Kommentare Zitate aus der Spec) und mit den Debug-Ausgaben nachvollzogen, warum das Profile nicht wirkt. Sowohl wenn das Profile gesetzt wird, als auch wenn die Transaktion beginnt, bekomme ich folgende Ausgabe:

    2023-07-06 09:25:56,730  Received SetChargingProfile.req stacklevel 0
    2023-07-06 09:25:56,741  Charging profile accepted as ChargePointMaxProfile level 0
    2023-07-06 09:25:56,785  Sending SetChargingProfile.conf.
    2023-07-06 09:25:56,809  Evaluating charging profiles
    2023-07-06 09:25:56,810      ChargePointMaxProfiles[3] not set
    2023-07-06 09:25:56,810      ChargePointMaxProfiles[2] not set
    2023-07-06 09:25:56,820      ChargePointMaxProfiles[1] not set
    2023-07-06 09:25:56,821  Evaluating charging profile 5
    2023-07-06 09:25:56,831      startSchedule not set or kind is relative. Assuming schedule is relative to the start of a transaction.
    2023-07-06 09:25:56,841      No transaction running. Schedule does not apply.
    2023-07-06 09:25:56,852      TODO HIT.
    2023-07-06 09:25:56,852      ChargePointMaxProfiles[0] did not apply
    
    ----------------------------------
    
    2023-07-06 09:26:26,869  Sending StartTransaction.req at connector 1 for tag 0460FC929E3380 at 32.758 kWh.
    2023-07-06 09:26:26,874  Sending StatusNotification.req: Status SuspendedEVSE for connector 1
    2023-07-06 09:26:26,889  Evaluating charging profiles
    2023-07-06 09:26:26,889      ChargePointMaxProfiles[3] not set
    2023-07-06 09:26:26,889      ChargePointMaxProfiles[2] not set
    2023-07-06 09:26:26,899      ChargePointMaxProfiles[1] not set
    2023-07-06 09:26:26,900  Evaluating charging profile 5
    2023-07-06 09:26:26,910      startSchedule not set or kind is relative. Assuming schedule is relative to the start of a transaction.
    2023-07-06 09:26:26,920      No transaction running. Schedule does not apply.
    2023-07-06 09:26:26,931      TODO HIT.
    2023-07-06 09:26:26,931      ChargePointMaxProfiles[0] did not apply

    Im Code sind wir dann hier: https://github.com/Tinkerforge/tfocpp/blob/fdf69d6389e803c4b2d06ac3b9ec20c8b816404a/src/ocpp/ChargingProfile.cpp#L91-L97

    In beiden Fällen wirkt das Profile also nicht, weil (angeblich) keine Transaktion läuft. Das liegt daran, dass die Transaktion, die in der zweiten Ausgabe gestartet wurde, auf dem Connector 1 läuft (also dem einzigen, den die Wallbox hat). Auf Connector 0 (also dem ganzen Charge Point) läuft nie eine Transaktion, die sind immer den spezifischen Connectoren zugeordnet. Deshalb ist im Evaluierungs-Code die startTxnTime nie gesetzt und damit wird der Schedule nicht angewandt.

    Die Interpretation, dass eine Transaktion nicht in die Evaluierung eines Profiles auf Connector 0 eingeht, ist leider etwas wage. Ich finde aber, dass die Spec zumindest Hinweise darauf gibt, dass das so gedacht ist:

    1. Transaktionsspezifische Profiles sind nicht auf Connector 0 erlaubt:

    Quote

    If a transaction-specific profile with purpose TxProfile is present, it SHALL overrule the default charging profile
    with purpose TxDefaultProfile for the duration of the current transaction only. [...] TxProfile SHALL only be set at Charge Point ConnectorId >0.

    und für das transactionId-Feld des ChargingProfiles:

    Quote

    transactionId
     integer
     0..1
     Optional. Only valid if ChargingProfilePurpose is set to TxProfile, the transactionId MAY be used to match the profile to a specific transaction.

    2. ChargePointMaxProfiles sind explizit zur Lastverteilung gedacht. Dabei sollte egal sein, ob gerade eine Transaktion läuft oder nicht:

    Quote

    In load balancing scenarios, the Charge Point has one or more local charging profiles that limit the power or
    current to be shared by all connectors of the Charge Point.

     

    Wenn ich das Profile so ändere, dass es nicht mehr vom Transaktionsstart abhängt, indem ich startSchedule auf z.B. den 6.7.2023 00:00 setze, dann funktionierts wie erwartet:

    2023-07-06 10:23:43,204  Received SetChargingProfile.req stacklevel 0
    2023-07-06 10:23:43,216  Charging profile accepted as ChargePointMaxProfile level 0
    2023-07-06 10:23:43,258  Sending SetChargingProfile.conf.
    2023-07-06 10:23:43,344  Evaluating charging profiles
    [...]
    2023-07-06 10:23:43,355  Evaluating charging profile 5
    2023-07-06 10:23:43,366      startSchedule set and kind is absolute or recurring. Using startSchedule.
    2023-07-06 10:23:43,376      Checking schedule periods.
    2023-07-06 10:23:43,376      Schedule applied.
    2023-07-06 10:23:43,387      Setting number of phases to 3.
    2023-07-06 10:23:43,387      Setting current limit to 9.000.
    2023-07-06 10:23:43,398      ChargePointMaxProfiles[0] applied.
    2023-07-06 10:23:43,398         ConnID  Allowed Phases  MinRate
    2023-07-06 10:23:43,408         0       9.000   3       0.000
    2023-07-06 10:23:43,409         1       32.000  3       0.000
    [...]
    2023-07-06 10:23:43,452      Profile evaluation done. Distributing limit
    2023-07-06 10:23:43,462      Currents distributed:
    2023-07-06 10:23:43,462         ConnID  Allowed Phases  MinRate
    2023-07-06 10:23:43,473         0       9.000   3       0.000
    2023-07-06 10:23:43,473         1       9.000   3       0.000
    2023-07-06 10:23:43,483      Next check: never
    2023-07-06 10:23:43,484  
    2023-07-06 10:23:43,484  Setting connector 1 limit to 9000

     

    • Thanks 1
  12. On 7/4/2023 at 6:17 PM, gustavpaula said:

    Mit welcher Methode kann ich eine Ladung nicht mehr starten/stoppen, wenn "Ladeeinstellungen-Manuelle Ladefreigabe = ON"?

    Mit der Methode "Auto anstecken". Was die manuelle Ladefreigabe im Endeffekt tut ist, dass sie die Ladestromgrenze "Manuelle Lade­freigabe" auf blockiert (bzw. 0 Ampere) setzt und zwar in dem Moment, in dem du ein Auto abziehst. Das heißt im Umkehrschluss, dass wenn du ein Auto ansteckst, immer in der Grenze 0 Ampere steht. Du musst dann also jedes Mal diese Ladestromgrenze wieder freigeben indem du eins der folgenden Dinge tust:

    • im Webinterface auf Start klickst
    • Bei passender Tasterkonfiguration (Ladestart oder Ladestart/Ladestop) den Taster drückst
    • die API evse/start_charging aufrufst

     

    On 7/4/2023 at 6:17 PM, gustavpaula said:

    Das sind einerseits tatsächlich Grenzen für die Höhe des Ladestroms, die nach dem Farbschema in der Anleitung unterschiedliche Zustände haben können. Andererseits gibt es aber noch Bedingungen, die zu einer Ladefreigabe führen oder diese verhindern können.

    Jein. Alle Ladestromgrenzen sind im Endeffekt jeweils eine Zahl, nämlich entweder 0, oder 6000 bis 32000 Milliampere. Das Webinterface zeigt dir statt 0 aber "blockiert" und statt 32000 "freigegeben" an. Außer den Ladestromgrenzen gibt es keine "normalen" (lies: nicht Fehler-) Umstände, die einen Ladevorgang verhindern können.

    On 7/4/2023 at 6:17 PM, gustavpaula said:

    "freigegeben" rechts im Slot bedeutet nicht "die Grenze ist freigegeben" sondern bedeutet "die Ladefreigabe ist durch die Grenze nicht verhindert". Andererseits bedeutet "freigeben" rechts in der Schaltfläche des Slots, dass diese Einschränkung mit Klick darauf deaktiviert wird.

    Genau. Wobei "die Ladefreigabe ist durch die Grenze nicht verhindert" trotzdem bedeuten kann, dass der Ladestrom limitiert wird. Eben dann, wenn nicht "freigegeben" sondern z.B. 10,123 Ampere im Slot steht. Der "Freigeben"-Button tut nichts anderes, als in den Slot wieder 32 Ampere zu schreiben.

    On 7/4/2023 at 6:17 PM, gustavpaula said:

    Z.B. eine 6A Grenze kann manuell auf der Seite Status - erlaubter Ladestrom gesetzt werden, dann kann ich dies aber per "freigeben" bei den Ladestromgrenzen auf 16A ändern. Wer braucht das?

    Da hast du eine interessante Frage aufgeworfen. Zuerst die einfache Antwort: den Freigeben-Button am "Externe Steuerung"-Slot braucht man, wenn die externe Steuerung sich aufgehangen hat, man aber wieder laden möchte. Da das eher ein Spezialfall ist, verstecken wir jetzt den Button, wenn die externe Steuerung deaktiviert ist oder bereits freigibt.

    Den Button am "Konfiguration"-Slot brauchte man früher, wenn man die Schiebeschalter in der Wallbox umgestellt hat. Wir haben aber vor ein paar Monaten geändert, dass wenn du auf der Statusseite zum Beispiel maximal 16 Ampere einstellen kannst (weil das das Minimum aus Lade- und Zuleitungskabel-Slot ist), in Wirklichkeit 32 Ampere (also "Freigegeben") geschickt werden, wenn du 16 Ampere eingibst, bzw. den Button dafür benutzt.

    Das heißt "Wer braucht das?" -> niemand -> Ich habe den Button entfernt. Danke für den Hinweis :D

    On 7/4/2023 at 6:17 PM, gustavpaula said:

    Diese Vorgehensweise sollte als Erklärung in die Anleitung.

    Steht sie in gewisser Weise:

    "Auf dieser Unterseite werden außerdem die aktuellen Ladestromgrenzen angezeigt. Alle Grenzen, die derzeit aktiv sind, werden zur Entscheidung, ob ein Ladevorgang erlaubt ist und zur Berechnung des maximalen Ladestroms einbezogen: Nur wenn alle aktiven Ladestromgrenzen nicht blockieren, wird eine Ladung erlaubt. Der erlaubte Ladestrom ist dann das Minimum aller aktiven Grenzen."

    Fairerweise ist das sehr kompakt beschrieben.

    On 7/4/2023 at 6:17 PM, gustavpaula said:

    Diese Farbtabelle sollte irgendwie auf der Seite mit den Ladestromgrenzen super einfach parallel einsehbar sein:

    Wir haben prinzipiell vor, mehr erklärende Texte ins Webinterface zu bringen. Die Idee ist, dass es bei komplizierteren Einstellungen einen ?-Button gibt, der eine Erklärung aufklappt. Das hat einerseits den Vorteil, dass die Seite übersichtlicher ist, wenn die Erklärungen nicht aufgeklappt sind, andererseits hat man da dann auch mal die Gelegenheit mehr als einen Halbsatz über eine Konfiguration zu verlieren. Das würde ungefähr so aussehen: (Am Layout usw. wird noch gefeilt)

    image.png

     

    Wie üblich danke für's Feedback. Wenn man jeden Tag auf das Webinterface bzw. in die Firmware starrt, sieht man die Komplexität manchmal nicht mehr.

    • Thanks 1
  13. On 7/5/2023 at 7:53 AM, heppth said:

    Wow das ging ja schnell. Super Service!

    Immer gerne :)

     

    On 7/5/2023 at 7:53 AM, heppth said:

    Ist es möglich/angedacht, dass nur eine WARP-Wallbox eine OCPP-Verbindung aufbaut und andere WARP-Wallboxen als zusätzlicher Connector auftauchen? Oder muss jede Wallbox seine eigene OCPP-Verbindung aufbauen?

    Ist im Moment nicht geplant. Was wäre dein Use-Case dafür? (Wenn der gut ist, kann man die Planung ja ändern ;) )

     

    On 7/5/2023 at 7:53 AM, heppth said:

    Werden nun in der MeterValues-Message auch Ströme, Spannung, etc. geschickt?

    In der Standardeinstellung nicht. Du kannst aber per ChangeConfiguration den MeterValuesAlignedData-Wert ändern um mehr Zählermesswerte zu bekommen. Alle Zählerwerte, die OCPP ansich kennt findest du hier: https://github.com/Tinkerforge/tfocpp/blob/master/spec/ocpp-1.6 edition 2.pdf auf Seite 86 und 87 (der Abschnitt 7.31. Measurand)

    Im Moment unterstützen wir folgende, wenn du einen SDM72V2 verbaut hast:

    Energy.Active.Export.Register,Energy.Active.Import.Register,Energy.Reactive.Export.Register,Energy.Reactive.Import.Register,Power.Active.Export,Power.Active.Import,Power.Offered,Power.Reactive.Export,Power.Reactive.Import,Power.Factor,Current.Import,Current.Export,Current.Offered,Voltage,Frequency

    bzw. folgende wenn du einen SDM630 verbaut hast:

    Energy.Active.Export.Register,Energy.Active.Import.Register,Energy.Reactive.Export.Register,Energy.Reactive.Import.Register,Power.Active.Export,Power.Active.Import,Power.Reactive.Export,Power.Reactive.Import,Power.Factor,Current.Offered,Voltage,Frequency

    (das ist direkt die kommaseparierte Liste, die du per ChangeConfiguration schicken kannst)

    Beim SDM630 fehlen Current.Import, Current.Export und Power.Offered. Die sollten eigentlich verfügbar sein, sehe ich nochmal nach: https://github.com/Tinkerforge/esp32-firmware/issues/259

     

    • Like 1
×
×
  • Neu erstellen...