Geräte mit Home Manager koppeln via SEMP (Ethernet)

  • Zitat von Maverick78


    Wenn während einen Ladevorgangs der SAE oder der Raspi neustartet, lädt das Auto weiter, da der SAE den Ausgangszustand nicht wiederherstellt. der Controller bleibt auf Enabled stehen, vermutlich für immer ;) Ich schlage vor, das bei starten der SAE die Ladevorgänge am Controller beendet, um einen definierten Ausgangsstatus zu haben.


    Beim Starten des SAE wird jetzt ein StopCharging (Register 400=0) an den Controller geschickt.


    Zitat von Maverick78


    Hier hat sich jetzt doch noch mal ein Fehler aufgetan. der Überschuss-Timeframe muss 1sek früher enden, sonst plant der SHM das nicht ein. Überlappung um genau 1 sek, es gab keine freigabe vom SHM heute morgen.


    Gefixt.


    Es gibt den neuen Snapshot 1.3.8 mit den o.g. Änderungen:
    https://github.com/camueller/S…3.8-SNAPSHOT.war?raw=true


    Axel

  • Also von meiner Seite gibt es im Moment nichts zu beanstanden. Läuft alles.


    Ich komme am Wochenende nicht weiter zum testen, Montag lasse ich die 1.3.8 mal auf den Produktiven Raspberry los wo die anderen Geräte zusammengefasst sind. Mal schauen ob da noch alles geht.

  • Ich habe noch fix die REST (XML) Schnittstelle getestet. Kann man da eigentlich auch ein EnergyRequest übergeben?
    Jedenfalls habe ich ein normalen Time Schedule getestet. Der wird auch angenommen und der vorhandene gelöscht. Übrig bleibt leider nur die Überschußplanung.


    Code
    curl -s -X POST -d '<Schedules>                                                   
                                          <Schedule minRunningTime="300" maxRunningTime="300">
                                          <DayTimeframe>
                                             <Start hour="9" minute="45" second="0" />
                                             <End hour="9" minute="50" second="0" />
                                            </DayTimeframe>
                                          </Schedule>
                                         </Schedules>' --header 'Content-Type: application/xml' 'http://localhost:8080/sae/schedules?id=F-XX-000000000001-00'


    Code
    018-07-27 09:38:06,316 DEBUG [http-nio-8080-exec-10] d.a.s.w.SaeController [SaeController.java:335] F-XX-000000000001-00: Received request to activate 1 schedule(s)
    2018-07-27 09:38:06,322 DEBUG [http-nio-8080-exec-10] d.a.s.a.RunningTimeMonitor [RunningTimeMonitor.java:80] F-XX-000000000001-00: Using enabled time frame 09:45:00.000-09:50:00.000/
    2018-07-27 09:38:09,046 DEBUG [Timer-0] d.a.s.a.RunningTimeMonitor [RunningTimeMonitor.java:205] F-XX-000000000001-00: activeTimeframeInterval=null
    (...)
    2018-07-27 09:38:55,629 DEBUG [http-nio-8080-exec-1] d.a.s.a.Appliance [Appliance.java:466] F-XX-000000000001-00: requesting optional energy for electric vehicle: 0s-172800s:0Wh-40000Wh
    2018-07-27 09:38:55,634 DEBUG [http-nio-8080-exec-1] d.a.s.s.w.SempController [SempController.java:316] F-XX-000000000001-00: Timeframe created: 0s-172800s:0W/40000W
    2018-07-27 09:38:55,639 DEBUG [http-nio-8080-exec-1] d.a.s.s.w.SempController [SempController.java:269] F-XX-000000000001-00: Timeframe added to PlanningRequest: 0s-172800s:0W/40000W
  • Jetzt ist doch noch ein kleines Problem aufgetaucht. Kein technisches, eher ein Design Problem.


    Auto war am Laden (Überschuß), ich wollte was aus dem Auto holen, aufgesperrt,. Dabei fällt das Auto auf Status B zurück, da der Ladevorgang durch die Entriegelung des Steckers unterbrochen wird. Der SAE meldet sofort:


    Code
    018-07-27 12:18:02,871 DEBUG [Timer-0] d.a.s.c.e.EVModbusControl [EVModbusControl.java:117] F-X-000000000001-00: Vehicle status=B
    2018-07-27 12:18:02,874 DEBUG [Timer-0] d.a.s.c.e.ElectricVehicleCharger [ElectricVehicleCharger.java:159] F-X-000000000001-00: Vehicle state changed: previousState=CHARGING newState=CHARGING_COMPLETED


    Dabei löscht er den kompletten Timeframe. Nach 1min will das Auto den Ladevorgang fortsetzen und der SAE macht folgendes:


    Zitat

    d.a.s.c.e.EVModbusControl [EVModbusControl.java:117] F-x-000000000001-00: Vehicle status=B
    2018-07-27 12:15:02,974 DEBUG [Timer-0] d.a.s.c.e.ElectricVehicleCharger [ElectricVehicleCharger.java:159] F-x-000000000001-00: Vehicle state changed: previousState=CHARGING_COMPLETED newState=VEHICLE_CONNECTED
    2018-07-27 12:15:02,976 DEBUG [Timer-0] d.a.s.a.Appliance [Appliance.java:403] F-x-000000000001-00: Activating schedules


    Dann sind die Schedules wieder da, aber die geladene Energiemenge ist 0.
    beim Überschußladen nicht weiter tragisch, aber bei einen EnergyRequest fängt er wieder von vorne an.


    Ich denke CHARGING_COMPLETED sollte entweder mit Verzögerung gesetzt werden, z.b. 5min oder erst beim Rückfall auf Status A.



    Edit: das gleiche passiert übrigens auch wenn das Auto voll geladen ist. Er macht CHARGING_COMPLETED und kurze Zeit später einen neuen Request.


  • Das ist echt doof, dass der PC statusmäßig keine Unterscheidung zwischen Ladeunterbrechung und Vollgeladen macht.
    Dein Vorschlag mit 5 Minuten oder Rückfall auf A ist meiner Meinung nach nicht praktikabel: Der erstere Fall ist willkürlich, da auch bei Unterbrechung durch den SHM ein Rückfall auf B erfolgt (kann länger als 5 Minuten gehen). Beim zweiten Fall bleibt die Energie-Anforderung bis zum Abstecken des Autos stehen, obwohl das Auto möglicherweis vollgeladen ist.


    Ich habe mir die Anleitung des PC nochmal angesehen. Wenn ich das richtig interpretiere, geht VR auf high, wenn das Auto verbunden wird. Wenn das Auto vollgeladen ist, geht VR auf low. Die Frage ist, ob VR bei einer Ladeunterbrechung (EN=0) auf high bleibt. Falls dem so ist, könnte man anhand von VR das "vollgeladen" von "unterbrochen" unterscheiden. Kannst Du das mal testen?


    Axel

  • Zitat von Maverick78

    Ich habe noch fix die REST (XML) Schnittstelle getestet. Kann man da eigentlich auch ein EnergyRequest übergeben?
    Jedenfalls habe ich ein normalen Time Schedule getestet. Der wird auch angenommen und der vorhandene gelöscht. Übrig bleibt leider nur die Überschußplanung.


    Code
    curl -s -X POST -d '<Schedules>                                                   
                                          <Schedule minRunningTime="300" maxRunningTime="300">
                                          <DayTimeframe>
                                             <Start hour="9" minute="45" second="0" />
                                             <End hour="9" minute="50" second="0" />
                                            </DayTimeframe>
                                          </Schedule>
                                         </Schedules>' --header 'Content-Type: application/xml' 'http://localhost:8080/sae/schedules?id=F-XX-000000000001-00'


    XML entspricht nicht dem aktuellen Schema. Für einen EnergyRequest muss es so aussehen:


    Code
    curl -s -X POST -d '<Schedules>                                                   
                                          <Schedule>
                                           <EnergyRequest min="1380" max="7360" />
                                           <DayTimeframe>
                                             <Start hour="9" minute="45" second="0" />
                                             <End hour="9" minute="50" second="0" />
                                            </DayTimeframe>
                                          </Schedule>
                                         </Schedules>' --header 'Content-Type: application/xml' 'http://localhost:8080/sae/schedules?id=F-XX-000000000001-00'


    ... und für einen RuntimeRequest so:

    Code
    curl -s -X POST -d '<Schedules>                                                   
                                          <Schedule>
                                          <RuntimeRequest min="300" max="300" />
                                          <DayTimeframe>
                                             <Start hour="9" minute="45" second="0" />
                                             <End hour="9" minute="50" second="0" />
                                            </DayTimeframe>
                                          </Schedule>
                                         </Schedules>' --header 'Content-Type: application/xml' 'http://localhost:8080/sae/schedules?id=F-XX-000000000001-00'


    Habe gerade noch einen Unittest für den EneryRequest geschrieben, der das bestätigt :)


    Axel

  • Zitat von camueller


    Ich habe mir die Anleitung des PC nochmal angesehen. Wenn ich das richtig interpretiere, geht VR auf high, wenn das Auto verbunden wird. Wenn das Auto vollgeladen ist, geht VR auf low. Die Frage ist, ob VR bei einer Ladeunterbrechung (EN=0) auf high bleibt. Falls dem so ist, könnte man anhand von VR das "vollgeladen" von "unterbrochen" unterscheiden. Kannst Du das mal testen?


    Im Normalfall ist VR auf "State C and D" konfiguriert, also also high wenn C=läd, low wenn nicht läd. Das läßt sich aber in der PC-Config umstellen (geht auch per Modbus iirc).


    CR und VR lassen sich recht frei konfigurieren - s Bild. Meine Logik reicht ob der Hitze gerade nicht um alles durchzuspielen aber eigentlich sollte alles da sein.

  • Zitat von Nicatron

    Im Normalfall ist VR auf "State C and D" konfiguriert, also also high wenn C=läd, low wenn nicht läd. Das läßt sich aber in der PC-Config umstellen (geht auch per Modbus iirc).


    CR und VR lassen sich recht frei konfigurieren - s Bild. Meine Logik reicht ob der Hitze gerade nicht um alles durchzuspielen aber eigentlich sollte alles da sein.


    Habe nochmals einen Blick in die Anleitung des PC geworfen: In Ladeablauf 8 wird über EN freigegeben und es ist eine Unterbrechung (S4 bis S6) enthalten. Leider wird VR (Vehicle Ready) während der Ladeunterbrechung auch auf low gesetzt. Allerdings scheint CR (Charger Ready) für die Unterscheidung von Ladeunterbrechung und Ladeende geeignet zu sein: Bei einer Ladeunterbrechung geht es auf low (S4 bis S6), aber bei Ladeende (S7) bleibt es auf high.


    Es wäre gut, wenn das mal jemand theroretisch und praktisch prüfen könnte :)


    Ich habe übrigens damit begonnen, das Web-interface anzupassen, nachdem ich zuvor ein Upgrade auf Angular 6 gemacht habe. Die Schaltzeiten können bereits mit Laufzeiten und Energiemengen umgehen. Als nächstes kommt die Unterstützung für den ElectricVehicleCharger und die Anpassungen für Modbus.


    Axel

  • Zitat von camueller

    XML entspricht nicht dem aktuellen Schema. Für einen EnergyRequest muss es so aussehen:


    Code
    curl -s -X POST -d '<Schedules>                                                   
                                          <Schedule>
                                           <EnergyRequest min="1380" max="7360" />
                                           <DayTimeframe>
                                             <Start hour="9" minute="45" second="0" />
                                             <End hour="9" minute="50" second="0" />
                                            </DayTimeframe>
                                          </Schedule>
                                         </Schedules>' --header 'Content-Type: application/xml' 'http://localhost:8080/sae/schedules?id=F-XX-000000000001-00'


    Danke scheint zu gehen.


    Zitat


    ... und für einen RuntimeRequest so:

    Code
    curl -s -X POST -d '<Schedules>                                                   
                                          <Schedule>
                                          <RuntimeRequest min="300" max="300" />
                                          <DayTimeframe>
                                             <Start hour="9" minute="45" second="0" />
                                             <End hour="9" minute="50" second="0" />
                                            </DayTimeframe>
                                          </Schedule>
                                         </Schedules>' --header 'Content-Type: application/xml' 'http://localhost:8080/sae/schedules?id=F-XX-000000000001-00'


    Geht nicht. Wird zwar angenommen vom SAE, aber es wird kein Timeframe reported unter /semp/PlanningRequest



    Befehl war:

    Code
    /usr/bin/curl -s -X POST -d '<Schedules>
                                          <Schedule>
                                            <RunningTimeRequest min="0" max="3939" />
                                            <DayTimeframe>
                                             <Start hour="0" minute="0" second="0" />
                                             <End hour="23" minute="59" second="59" />
                                            </DayTimeframe>
                                          </Schedule>
                                         </Schedules>' --header 'Content-Type: application/xml' 'http://localhost:8080/sae/schedules?id=F-27091978-000000000011-00'