text:
bufferSoc: PV modus startet Laden des E-Autos, wenn die Batterie nicht mehr geladen wird

Describe the bug
Wenn ein E-Auto angesteckt ist und der Modus auf "pv" im evcc steht, wird das Auto in dem Moment geladen, wenn die Haus-Batterie nicht mehr geladen wird - was meist abends der Fall ist, wenn die PV-Leistung eh nicht mehr ausreichend ist - aber die Haus-Batterie über bufferSoC geladen ist:

hier im Bild zu sehen ab 16:36 wurde geladen, bei Haus-SoC 75% wurde gestoppt.
expected behavior
Das Auto wird weiterhin nicht geladen, weil die PV-Leistung bei weitem nicht ausreicht, das Auto zu laden:

Grundlast: ~ 600Watt
residualPower: 600Watt
PV-Leistung: ~700Watt

=> d.h. rein rechnerisch stünden im Bild ca. 700Watt zur Verfügung, die nichtmal 1p Ladeleistung erlaubten.
Steps to reproduce

E-Auto anstecken
Warten, bis die Haus-Batterie nicht mehr geladen wird
zusehen, wie der Lade-Befehl an den Ladepunkt geht, an dem das Auto angesteckt ist
trotz nicht ausreichender PV-Leistung

Configuration details
network:
  # schema is the HTTP schema
  # setting to `https` does not enable https, it only changes the way URLs are generated
  schema: http

  # host is the hostname or IP address
  # if the host name contains a `.local` suffix, the name will be announced on MDNS
  # docker: MDNS announcements don't work. Host must be set to the docker host's name
  #host: evcc.local
  host: 0.0.0.0

  # port is the listening port for UI and api
  # evcc will listen on all available interfaces
  port: 7070

  # per default, evcc should be available at http://evcc.local:7070

interval: 10s # control cycle interval
log: info

meters:
# meter definitions
# name can be freely chosen and is used as reference when assigning meters to site and loadpoints
# for examples see https://github.com/evcc-io/config#meters
- type: custom
  name: PVErzeugung
  power:
    source: http
    uri: http://192.168.78.10:8080/rest/items/KOS_PVPower
    method: GET
    headers:
    - content-type: application/json
    jq: .state|split(" ")[0]|split(".")[0]
- type: custom
  name: Netzbezug
  power:
    source: http
    uri: http://192.168.78.10:8080/rest/items/KOS_HomeConsumptionGrid
    method: GET
    headers:
    - content-type: application/json
    jq: .state|split(" ")[0]|split(".")[0]
    scale: 1
- type: custom
  name: BYD10
  power:
    source: http
    uri: http://192.168.78.10:8080/rest/items/KOS_BatteryChargeDischarge
    method: GET
    headers:
    - content-type: application/json
    jq: .state|split(" ")[0]|split(".")[0]
    scale: 1
  soc:
    source: http
    uri: http://192.168.78.10:8080/rest/items/KOS_BatterySoC
    method: GET
    headers:
    - content-type: application/json
    jq: .state|split(" ")[0]|split(".")[0]

chargers:
# charger definitions
# name can be freely chosen and is used as reference when assigning charger to vehicle
# for examples see https://github.com/evcc-io/config#chargers
- type: template
  template: tinkerforge-warp
  fw2: true
  host: 192.168.78.18
  port: 1883
  topic: devices/Warp2
  timeout: 30s
  name: WarpWallbox

vehicles:
# vehicle definitions
# name can be freely chosen and is used as reference when assigning vehicle to loadpoint
# for examples see https://github.com/evcc-io/config#vehicles
- name: 500e
  type: template
  template: offline
  title: Fiat 500e
  capacity: 22
- name: EV6
  type: custom
  title: Kia EV6 # display name for UI
  capacity: 77 # byttery capacity (kWh)
  soc: # battery soc (%)
    source: http
    uri: http://192.168.78.10:8080/rest/items/EV6_batteryStatus
    method: GET
    headers:
    - content-type: application/json
    jq: .state|split(" ")[0]|split(".")[0]
  range: # optional electric range (km)
    source: http
    uri: http://192.168.78.10:8080/rest/items/EV6_availableRange
    method: GET
    headers:
    - content-type: application/json
    jq: .state|split(" ")[0]|split(".")[0]
  status: # FahrzeugStatus (%)
    source: http
    uri: http://192.168.78.10:8080/rest/items/EV6_vehicleStatus
    method: GET
    headers:
    - content-type: application/json
    jq: .state|split(" ")[0]|split(".")[0]
  onIdentify: # set defaults when vehicle is identified
    mode: pv
    minSoC: 25
    targetSoC: 80

tariffs:
# tariffs are the fixed or variable tariffs
# cheap (tibber/awattar) can be used to define a tariff rate considered cheap enough for charging
  currency: EUR # (default EUR)
  grid:
    #type: fixed
    #price: 0.319 # [currency]/kWh
    type: tibber
    cheap: 0.25
    token: "xxx"
    homeid: "yyy"
  feedin:
    type: fixed
    price: 0.065 # [currency]/kWh

loadpoints:
# loadpoint describes the charger, charge meter and connected vehicle
- title: Warp
  charger: WarpWallbox
  mode: pv
  phases: 3
  mincurrent: 6
  maxcurrent: 16
  resetOnDisconnect: true
  vehicle: 500e

site:
# site describes the EVU connection, PV and home battery
  title: Zuhause
  meters:
    grid: Netzbezug
    pvs:
    - PVErzeugung
    batteries:
    - BYD10
  prioritySoC: 66
  bufferSoC: 75
  residualPower: 600

mqtt:
  broker: 192.168.78.18:1883
  topic: servers/evcc

# sponsor token enables optional features (request at https://cloud.evcc.io)
sponsortoken: xxxx
plant: yyyy

Log details
zum Zeitpunkt leider kein DEBUG-Log vorhanden, Verhalten kann aber immer nachvollzogen werden, wenn:

* der aktuelle Haus-SoC > bufferSoC ist
* die Haus-Batterie nicht mehr geladen wird
* auch wenn PV-Leistung nicht mehr ausreichend ist

What type of operating system are you running?
Docker container
Version
0.112.5

Durch mehrere Diskussionen und einen Selbstversuch habe ich folgendes herausgefunden:
Ausgangssituation: Auto ist angesteckt, Modus PV, es wird nicht geladen, BatterySoc > bufferSoc
Solange die Hausbatterie geladen wird, startet die Fahrzeugladung nicht.
Wird die Hausbatterie nicht mehr geladen bzw. entladen (Kipppunkt konnte ich nicht testen), dann startet die Fahrzeugladung sofort, ohne Timer.
Offensichtlich hat bufferSoc keine Wirkung, solange die Batterie geladen wird.

Siehe https://github.com/evcc-io/evcc/discussions/1361

Solange die Hausbatterie geladen wird, startet die Fahrzeugladung nicht.

Das ergibt wenig Sinn, da Batterieladung immer als verfügbare Leistung gewertet wird. Sollte das so sein wärs ein Bug, ist aber wirklich schwer zu glauben.
Mangels Logfile mache ich hier zu. Gerne weiter wenn es etwas Nachvollziehbares gibt.

Im Eingangspost (anderes Thema!) startet die Ladung nicht weil einfach nicht genug Leistung dafür vorhanden ist. Die Batterie zählt nicht weil nicht bekannt ist, welche Leistung sie beisteuern könnte. Würde einmal geladen (Min+PV) so würde die Ladung bis bufferSoc fortgesetzt sofern die Batterie ausreichend Leistung liefert.

Im Eingangspost (anderes Thema!) startet die Ladung nicht weil einfach nicht genug Leistung dafür vorhanden ist. Die Batterie zählt nicht weil nicht bekannt ist, welche Leistung sie beisteuern könnte.

Problem ist ja eben, dass exakt dann der Ladevorgang beginnt, wenn die Haus-Batterie nicht mehr geladen wird und (und das sehe ich als Fehler) die PV-Leistung weiterhin nicht ausreicht, selbst mit residualPower nicht.
Kanns morgen abend gern nochmal nachstellen, morgen sollte das Auto bewegt werden und <100% haben.

Ja, das wäre falsch.

Gestern diesen Test gemacht.
PV Modus, nur wenig PV Power, Hausbatterie wurde leicht geladen. bufferSoc auf 10% gestellt.
Erstmal ist nix passiert, Dann habe ich die Herdplatte eingeschaltet,
Batterie ging in die Entladung und das Auto fing sofort an zu laden.
Feb 12 12:20:24 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:24 ----
Feb 12 12:20:24 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:20:24 charge power: 0W
Feb 12 12:20:24 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:24 pv power: 839W
Feb 12 12:20:24 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:24 battery soc: 20%
Feb 12 12:20:24 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:24 battery power: -232W
Feb 12 12:20:25 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:25 grid power: -10W
Feb 12 12:20:25 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:25 grid powers: [-12 21 -19]W
Feb 12 12:20:25 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:25 grid currents: [-1.14 0.86 -1.03]A
Feb 12 12:20:25 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:25 site power: -143W
Feb 12 12:20:25 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:20:25 charge currents: [0 0 0]A
Feb 12 12:20:25 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:20:25 charger status: B
Feb 12 12:20:25 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:20:25 next soc poll remaining time: 47m14s
Feb 12 12:20:25 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:20:25 pv charge current: 0.62A = 0A + 0.62A (-143W @ 1p)
Feb 12 12:20:39 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:39 ----
Feb 12 12:20:39 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:20:39 charge power: 0W
Feb 12 12:20:39 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:39 pv power: 836W
Feb 12 12:20:40 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:40 battery soc: 21%
Feb 12 12:20:40 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:40 battery power: 14W
Feb 12 12:20:40 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:40 grid power: 1720W
Feb 12 12:20:40 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:40 grid powers: [1769 4 -52]W
Feb 12 12:20:40 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:40 grid currents: [7.75 0.86 -1.02]A
Feb 12 12:20:40 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:40 site power: 1834W
Feb 12 12:20:40 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:20:40 charge currents: [0 0 0]A
Feb 12 12:20:40 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:20:40 charger status: B
Feb 12 12:20:40 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:20:40 next soc poll remaining time: 46m59s
Feb 12 12:20:40 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:20:40 pv charge current: 0A = 0A + -7.97A (1834W @ 1p)
Feb 12 12:20:40 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:20:40 max charge current: 6A
Feb 12 12:20:40 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:20:40 charger enable
Feb 12 12:20:40 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:20:40 wake-up timer: start
Feb 12 12:20:54 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:54 ----
Feb 12 12:20:54 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:20:54 charge power: 400W
Feb 12 12:20:54 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:54 pv power: 837W
Feb 12 12:20:54 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:54 battery soc: 21%
Feb 12 12:20:54 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:54 battery power: 1059W
Feb 12 12:20:55 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:55 grid power: 1955W
Feb 12 12:20:55 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:55 grid powers: [722 4 1230]W
Feb 12 12:20:55 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:55 grid currents: [3.19 0.88 5.66]A
Feb 12 12:20:55 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:55 site power: 3114W
Feb 12 12:20:55 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:20:55 charge currents: [2.6 0 0]A
Feb 12 12:20:55 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:20:55 charger status: C
Feb 12 12:20:55 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:20:55 charge start energy: 99.3kWh
Feb 12 12:20:55 raspberrypi evcc[10762]: [lp-1  ] INFO 2023/02/12 12:20:55 start charging ->
Feb 12 12:21:11 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:11 soc estimated: 59.00% (vehicle: 59.00%)
Feb 12 12:21:11 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:11 vehicle soc: 59%
Feb 12 12:21:11 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:11 vehicle soc limit: 100%
Feb 12 12:21:11 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:11 vehicle range: 218km
Feb 12 12:21:11 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:11 pv charge current: 0A = 4.6A + -13.5A (3114W @ 1p)
Feb 12 12:21:11 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:11 ----
Feb 12 12:21:11 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:11 telemetry: charge: Δ2/3Wh @ 400W
Feb 12 12:21:11 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:11 charge power: 1200W

Problem ist ja eben, dass exakt dann der Ladevorgang beginnt, wenn die Haus-Batterie nicht mehr geladen wird und (und das sehe ich als Fehler) die PV-Leistung weiterhin nicht ausreicht, selbst mit residualPower nicht.

@VolkerK62 also gleiche Fehlerbeschreibung?

Ich habe dann kurz nach dem Einschalten bufferSoc wieder hochgesetzt, dann fing der disable Timer an
Feb 12 12:20:55 raspberrypi evcc[10762]: [lp-1  ] INFO 2023/02/12 12:20:55 start charging ->
Feb 12 12:21:11 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:11 soc estimated: 59.00% (vehicle: 59.00%)
Feb 12 12:21:11 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:11 vehicle soc: 59%
Feb 12 12:21:11 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:11 vehicle soc limit: 100%
Feb 12 12:21:11 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:11 vehicle range: 218km
Feb 12 12:21:11 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:11 pv charge current: 0A = 4.6A + -13.5A (3114W @ 1p)
Feb 12 12:21:11 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:11 ----
Feb 12 12:21:11 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:11 telemetry: charge: Δ2/3Wh @ 400W
Feb 12 12:21:11 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:11 charge power: 1200W
Feb 12 12:21:11 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:11 pv power: 835W
Feb 12 12:21:11 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:11 battery soc: 21%
Feb 12 12:21:11 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:11 battery power: 1015W
Feb 12 12:21:11 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:11 grid power: -69W
Feb 12 12:21:12 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:12 grid powers: [-1271 9 1176]W
Feb 12 12:21:12 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:12 grid currents: [-5.54 0.9 5.48]A
Feb 12 12:21:12 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:12 site power: 1047W
Feb 12 12:21:12 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:12 charge currents: [5.5 0 0]A
Feb 12 12:21:12 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:12 detected active phases: 1p
Feb 12 12:21:12 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:12 charger status: C
Feb 12 12:21:12 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:12 next soc poll remaining time: 3h59m43s
Feb 12 12:21:12 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:12 soc estimated: 59.00% (vehicle: 59.00%)
Feb 12 12:21:12 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:12 vehicle soc: 59%
Feb 12 12:21:12 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:12 vehicle soc limit: 100%
Feb 12 12:21:12 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:12 vehicle range: 218km
Feb 12 12:21:12 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:12 pv charge current: 1.45A = 6A + -4.55A (1047W @ 1p)
Feb 12 12:21:24 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:24 ----
Feb 12 12:21:24 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:24 charge power: 1200W
Feb 12 12:21:24 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:24 pv power: 843W
Feb 12 12:21:24 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:24 battery soc: 21%
Feb 12 12:21:24 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:24 battery power: 1073W
Feb 12 12:21:25 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:25 grid power: -54W
Feb 12 12:21:25 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:25 grid powers: [-1287 19 1214]W
Feb 12 12:21:25 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:25 grid currents: [-5.59 0.89 5.69]A
Feb 12 12:21:25 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:25 site power: 1119W
Feb 12 12:21:25 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:25 charge currents: [5.5 0 0]A
Feb 12 12:21:25 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:25 detected active phases: 1p
Feb 12 12:21:25 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:25 charger status: C
Feb 12 12:21:25 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:25 next soc poll remaining time: 3h59m46s
Feb 12 12:21:25 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:25 soc estimated: 59.00% (vehicle: 59.00%)
Feb 12 12:21:25 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:25 vehicle soc: 59%
Feb 12 12:21:25 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:25 vehicle soc limit: 100%
Feb 12 12:21:25 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:25 vehicle range: 218km
Feb 12 12:21:25 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:25 pv charge current: 1.13A = 6A + -4.87A (1119W @ 1p)
Feb 12 12:21:39 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:39 ----
Feb 12 12:21:39 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:39 charge power: 1200W
Feb 12 12:21:39 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:39 pv power: 841W
Feb 12 12:21:40 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:40 battery soc: 21%
Feb 12 12:21:40 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:40 battery power: 1117W
Feb 12 12:21:40 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:40 grid power: -67W
Feb 12 12:21:40 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:40 grid powers: [-1278 0 1212]W
Feb 12 12:21:40 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:40 grid currents: [-5.55 0.91 5.69]A
Feb 12 12:21:40 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:40 site power: 1151W
Feb 12 12:21:40 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:40 charge currents: [5.5 0 0]A
Feb 12 12:21:40 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:40 detected active phases: 1p
Feb 12 12:21:40 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:40 charger status: C
Feb 12 12:21:40 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:40 next soc poll remaining time: 3h59m44s
Feb 12 12:21:40 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:40 soc estimated: 59.00% (vehicle: 59.00%)
Feb 12 12:21:40 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:40 vehicle soc: 59%
Feb 12 12:21:40 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:40 vehicle soc limit: 100%
Feb 12 12:21:40 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:40 vehicle range: 218km
Feb 12 12:21:40 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:40 pv charge current: 0.996A = 6A + -5A (1151W @ 1p)
Feb 12 12:21:40 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:40 site power 1151W >= 0W disable threshold
Feb 12 12:21:40 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:40 pv disable timer start: 3m0s
Feb 12 12:21:40 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:40 pv disable in 3m0s
Feb 12 12:21:49 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:49 set charge mode: off
Feb 12 12:21:49 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:49 pv timer reset
Feb 12 12:21:49 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:49 pv timer inactive
Feb 12 12:21:49 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:49 ----
Feb 12 12:21:49 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:49 charge power: 1200W
Feb 12 12:21:49 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:49 pv power: 843W
Feb 12 12:21:49 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:49 battery soc: 21%
Feb 12 12:21:49 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:49 battery power: 1071W
Feb 12 12:21:49 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:49 grid power: -51W
Feb 12 12:21:49 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:49 grid powers: [-1281 16 1213]W
Feb 12 12:21:49 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:49 grid currents: [-5.55 0.87 5.68]A
Feb 12 12:21:49 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:49 site power: 1119W
Feb 12 12:21:49 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:49 charge currents: [5.5 0 0]A
Feb 12 12:21:49 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:49 detected active phases: 1p
Feb 12 12:21:50 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:50 charger status: C
Feb 12 12:21:50 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:50 next soc poll remaining time: 3h59m50s
Feb 12 12:21:50 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:50 soc estimated: 59.00% (vehicle: 59.00%)
Feb 12 12:21:50 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:50 vehicle soc: 59%
Feb 12 12:21:50 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:50 vehicle soc limit: 100%
Feb 12 12:21:50 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:50 vehicle range: 218km
Feb 12 12:21:50 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:50 charger disable
Feb 12 12:21:50 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:50 wake-up timer: stop
Feb 12 12:21:50 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:50 telemetry: charge: Δ13/13Wh @ 1200W
Feb 12 12:21:54 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:54 ----
Feb 12 12:21:54 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:54 charge power: 1200W
Feb 12 12:21:54 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:54 pv power: 843W
Feb 12 12:21:54 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:54 battery soc: 21%
Feb 12 12:21:54 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:54 battery power: 1008W
Feb 12 12:21:55 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:55 grid power: -1214W
Feb 12 12:21:55 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:55 grid powers: [-1198 7 -22]W
Feb 12 12:21:55 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:55 grid currents: [-5.21 0.88 -1.02]A
Feb 12 12:21:55 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:21:55 site power: -106W
Feb 12 12:21:55 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:55 charge currents: [5.5 0 0]A
Feb 12 12:21:55 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:55 detected active phases: 1p
Feb 12 12:21:55 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:55 charger status: C
Feb 12 12:21:55 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:55 next soc poll remaining time: 3h59m54s
Feb 12 12:21:55 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:55 soc estimated: 59.00% (vehicle: 59.00%)
Feb 12 12:21:55 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:55 vehicle soc: 59%
Feb 12 12:21:55 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:55 vehicle soc limit: 100%
Feb 12 12:21:55 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:21:55 vehicle range: 218km
Feb 12 12:22:09 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:22:09 ----
Feb 12 12:22:09 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:22:09 charge power: 0W
Feb 12 12:22:09 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:22:09 pv power: 847W
Feb 12 12:22:09 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:22:09 battery soc: 21%
Feb 12 12:22:09 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:22:09 battery power: 186W
Feb 12 12:22:10 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:22:10 grid power: -147W
Feb 12 12:22:10 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:22:10 grid powers: [-139 15 -23]W
Feb 12 12:22:10 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:22:10 grid currents: [-0.93 0.86 -1.03]A
Feb 12 12:22:10 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:22:10 site power: 139W
Feb 12 12:22:10 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:22:10 charge currents: [0 0 0]A
Feb 12 12:22:10 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:22:10 charger status: B
Feb 12 12:22:10 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:22:10 final charge energy: 0kWh
Feb 12 12:22:10 raspberrypi evcc[10762]: [lp-1  ] INFO 2023/02/12 12:22:10 stop charging <-
Feb 12 12:22:10 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:22:10 soc estimated: 59.00% (vehicle: 59.00%)
Feb 12 12:22:10 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:22:10 vehicle soc: 59%
Feb 12 12:22:10 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:22:10 vehicle soc limit: 100%
Feb 12 12:22:10 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:22:10 vehicle range: 218km
Feb 12 12:22:24 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:22:24 ----
Feb 12 12:22:24 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:22:24 charge power: 0W
Feb 12 12:22:24 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:22:24 pv power: 851W
Feb 12 12:22:24 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:22:24 battery soc: 21%
Feb 12 12:22:24 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:22:24 battery power: -355W
Feb 12 12:22:25 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:22:25 grid power: 103W
Feb 12 12:22:25 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:22:25 grid powers: [112 16 -25]W
Feb 12 12:22:25 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:22:25 grid currents: [1.36 0.86 -1.04]A
Feb 12 12:22:25 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:22:25 site power: -152W
Feb 12 12:22:25 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:22:25 charge currents: [0 0 0]A
Feb 12 12:22:25 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:22:25 charger status: B
Feb 12 12:22:25 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:22:25 next soc poll remaining time: 3h59m44s
Feb 12 12:22:38 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:22:38 set charge mode: pv
Feb 12 12:22:38 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:22:38 ----

@VolkerK62 also gleiche Fehlerbeschreibung?

Ja?

Sorry, das hab ich überlesen. Ja.
Residualpower steht auf +100.
Ich glaube, das "Problem" ist https://github.com/evcc-io/evcc/discussions/1361#discussioncomment-1274270
BufferSoc wird als "Schalter" genommen um so eine Art "Min+PV" einzuschalten.
Das ist mMn okay, wenn es um das AUSschaltverhalten geht.
Aber ich denke, es ist falsch, wenn es um das EINschaltverhalten geht.
Ich werde den obigen Test heute Abend mal wiederholen, wenn keine PV-Erzeugung mehr da ist.
Ich vermute stark, dass auch dann eingeschaltet wird. (gegen dich wetten würde ich aber nicht ;-)

Also die Werte stimmen:
Feb 12 12:20:39 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:20:39 charge power: 0W
Feb 12 12:20:39 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:39 pv power: 836W
Feb 12 12:20:40 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:40 battery power: 14W
Feb 12 12:20:40 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:40 grid power: 1720W
Feb 12 12:20:40 raspberrypi evcc[10762]: [site  ] DEBUG 2023/02/12 12:20:40 site power: 1834W

Was nicht passt ist:
Feb 12 12:20:40 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:20:40 pv charge current: 0A = 0A + -7.97A (1834W @ 1p)
Feb 12 12:20:40 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:20:40 max charge current: 6A
Feb 12 12:20:40 raspberrypi evcc[10762]: [lp-1  ] DEBUG 2023/02/12 12:20:40 charger enable

Warum passiert das?
case mode == api.ModeMinPV || mode == api.ModePV:
	targetCurrent := lp.pvMaxCurrent(mode, sitePower, batteryBuffered)

	var required bool // false
	if targetCurrent == 0 && lp.climateActive() {
		targetCurrent = lp.GetMinCurrent()
		required = true
	}

	// Sunny Home Manager
	if lp.remoteControlled(loadpoint.RemoteSoftDisable) {
		remoteDisabled = loadpoint.RemoteSoftDisable
		targetCurrent = 0
		required = true
	}

	err = lp.setLimit(targetCurrent, required)
}

Kann es sein, dass beim Auto Klimatisierung detektiert wurde? Sonst fällt mir kein guter Grund ein warum die 0 wieder auf 6 korrigiert werden sollte???

Kann es sein, dass beim Auto Klimatisierung detektiert wurde?

Nein. Wird bei Bluelink nicht unterstützt.

Letzte Idee: bitte nochmal trace log davon, oder wie müssen eine Debugsession machen. Da ist ja sonst nix :/

ok, ich starte meinen Docker grad mal mit TRACE neu und warte ab. könnte bissle größer werden das logfile dann! ;)

Ich hab in lp.pvMaxCurrent() noch was gefunden, aber noch nicht versucht, die Logik zu verstehen:
// in MinPV mode or under special conditions return at least minCurrent
if (mode == api.ModeMinPV || batteryBuffered || lp.climateActive()) && targetCurrent < minCurrent {
	return minCurrent
}

Im Prinzip: falls abgeschaltet würde und MinPV, dann minimaler Strom. Analog machen wir das aber auch falls Batteriepuffer vorhanden ist. Das sieht erstmal unklar aus.
@binderth denke Log hat sich damit erledigt, Ursache gefunden.

ok. alles klar. hab eh gerade rausgefunden, dass meine Batterie über Tags nicht über 10% kam. Habs grad noch simulieren können mit 5% bufferSoC, hat aber bei Start von evcc gleich bei 6% zu laden begonnen.
Falls noch Notwendigkeit besteht - kurz anstupsen, das trace-log ist eben fertig.

das ging also noch nie richtig.

ist dir Frage, was "richtig" ist. Wenn man sich das Issue #1361 anschaut, ist es works as designed.

Hallo,
eigentlich sollte bei Überschreiten von buffersoc in den Modus Min+PV geschaltet werden. Beim Unterschreiten zurück nach PV.
Ob der Hausakku geladen wird ist nicht ist völlig relevant.
Usecase für das Verhalten:

Umladen des Hausakkus, damit dieser nivht bei 100% steht und am Folgetag wieder Platz hat.
Starten des Ladevorgangs wenn Hausakku voll und Fahrzeug angesteckt wird. Wichtig für ZeroExport und Inseln.
Verhindern von Ladeunterbrechungen bei Wolken usw.

Ich hatte es so verstanden dass der Hausbatterie Speicher die Ladung unterstützt um kurzzeitige Unterbrechungen (Wolke z.b. damit kleiner Mindestleistung) zu verhindern.
Ein entladen der Hausbatterie über dies Hinaus halte ich für wenig sinnvoll (auch auf Basis der gängigen Batteriespeichergrößen)

Kannst du ja einstellen, wie dein buffersoc sein soll.

Der normale Use Case sind sicherlich 10kWh Speicher und 40-70kWh E-Auto. Und nein, wenn evcc automatisch den Lademodus wechselt empfinde ich das nicht sinnvoll.
Die Haus-Batterie zur Überbrückung von Wolken zu verwenden ist ein sinnvoller UseCase, aber es macht in der überwiegenden Mehrheit keinen Sinn, "teureren" Haus-Speicher-Strom über zweimal Wandeln in E-Auto Speicher zu laden.
Wer im Sommer verhindern will, mit voller Batterie aus der Nacht zu kommen, kann ja Ziel-Laden oder per Schalter/API den Lademodus am Morgen entsprechend auf MinPV ändern.
Aus User-Sicht ist ein Lademodus-Wechsel nur sinnvoll, wenn man das vorab so plant und drauf hingewiesen wird. Auch das ein Edge-Case: Start des Ladevorgangs mit "pv" und Ziel-Laden bis 8h morgen. Mit nicht ausreichend PV-Leistung stoppt "PV" nach eingestellten Intervall wie konfiguriert (3min sind glaub Standard). Wenn noch nicht fertig geladen, wird rechtzeitig nachgeladen.
Das ist netzdienlich und gibt die Chance, mit genügend grosser Batterie dann doch den UseCase "ich möchte im Sommer möglichst viele Zyklen erreichen" dadurch zu lösen. Aber aus meiner Sicht sollte evcc dabei helfen, möglichst viel PV-Strom direkt zu verwenden.
Wer mag und eine entsprechend riesig dimensionierte Anlage hat, kann sich ja per API selbst einen "Battery"-Modus basteln. Ist aber nicht die Regelgröße, leider.

Dann stellst du halt buffersoc auf 100 und hast was du möchtest. Ist ja auch der Default.
Anlagen mit ZeroExport oder Inseln sind aber auf das Feature angewiesen.

Alle Usecase sind sicherlich sinnvoll, aber auch sehr individuell.
Es sollte die Möglichkeit geben, das man zusätzlich zu "nicht beenden" auch noch "neu starten" auswählen kann.
Z.B. ein bufferStart: true/false.
Ja, es wäre ein neuer Parameter, aber aufgrund der immer wieder aufkommenden Diskussionen rund um bufferSoc und der großen Unterschiede zwischen den Usecase halte ich den für durchaus nützlich.

Dann stellst du halt buffersoc auf 100 und hast was du möchtest. Ist ja auch der Default.

Dann sind allerdings 90% der Anlagen außen vor, weil keine Inseln. 100 bufferSoC ist halt meist sinnfrei.

Nachtrag: Die Doku spricht von "Ladung nicht unterbrechen".

Darauf beziehe ich mich und das sollte auch so bleiben. Ansonsten sehe

Ich ziehe aus der ganzen Diskussion nur folgendes Fazit:
Gewünscht ist, dass die Fahrzeugladung oberhalb bufferSoc zuverlässig und eindeutig (wie bei Min+PV) startet.
Das ist bisher nur unter auf den ersten Blick nicht ganz nachvollziehbaren Bedingungen der Fall.
Mir war das vorher nicht bewusst dass dies derzeit nicht immer so funktioniert wie dokumentiert.

Gewünscht ist, dass die Fahrzeugladung oberhalb bufferSoc zuverlässig und eindeutig (wie bei Min+PV) startet.

Im Modus 'pv' ist ein Start rein aus Batterie allerdings entgegen des Sinnes des Modus. Weil dann isses eben nicht mehr 'pv', sondern 'minpv'. Daher finde ich den von Volker ins Spiel gebrachten Schalter eine gute Idee.
Weil, wenn ich 'pv' gewählt habe, möchte ich mit PV-Überschuss laden, nicht mit Batterie-Überschuss. In der Regel können handelsübliche Akkus 5kW, das reicht zwar erstmal für 3p Laden, aber gerade wenn abends z.B. gekocht wird, eben nicht mehr.
Oder es gibt einen "Batterie" Modus, der explizit Nutzung der Batterie erlaubt. Dann aber mit Angabe der maximalen Batterieentladung. Und das wiederum führt zu nix.
Ergo: 'pv' sollte PV-Laden bleiben, mit 'bufferSoc' für Wolken o.ä. wie in der Doku beschrieben. Das sollte der Standardfall bei den meisten Anlagen sein.
Nächtliches Entladen der Batterie bei mega-Akkus kann durch Zielladen ja jederzeit erfolgen.

Ich ziehe aus der ganzen Diskussion nur folgendes Fazit:
Gewünscht ist, dass die Fahrzeugladung oberhalb bufferSoc zuverlässig und eindeutig (wie bei Min+PV) startet. Das ist bisher nur unter auf den ersten Blick nicht ganz nachvollziehbaren Bedingungen der Fall.
Mir war das vorher nicht bewusst dass dies derzeit nicht immer so funktioniert wie dokumentiert.

Genau. Danke.
Und bis BufferSoc die Hausbatterie als Puffer nutzt.

Ergo: 'pv' sollte PV-Laden bleiben, mit 'bufferSoc' für Wolken o.ä. wie in der Doku beschrieben. Das sollte der Standardfall bei den meisten Anlagen sein. Nächtliches Entladen der Batterie bei mega-Akkus kann durch Zielladen ja jederzeit erfolgen.

Exakt.

Das bedeutet im Klartext aber auch, dass PV sich >bufferSoc wie MinPV verhält sobald die Ladung gestartet ist.

Jeder hat eben ein individuelles Setup.

Da haben wir tatsächlich eine absolute Sonderlösung für Dich gebaut.

Gewünscht ist, dass die Fahrzeugladung oberhalb bufferSoc zuverlässig und eindeutig (wie bei Min+PV) startet.

Das mag sein, ist aber einfach nicht möglich da (heute) keine Aussage über die Leistung der Batterie getroffen werden kann, es also nicht klar ist ob minCurrent erreichbar ist. Weitere "mal probieren ob" Logik ist zu vermeiden.
Was wir aber machen könnten wäre, dass die Ladung bufferSoc aufrecht erhalten wird wenn sie einmal läuft. Es gäbe also keinen automatischen Start, wohl aber Ladeerhaltung bis bufferSoc. Aus Anwendersicht brauchts also einen Schubs über minPV, dann würde PV die Ladung halten und abschalten.
Alternativ (und ich möchte das nur sehr ungern) bräuchte es noch einen batteryDischargePower Parameter mit dem sich berechnen liesse, ob ein weiteres Fahrzeug innerhalb dieser geladen werden könnte. Dann:

würde das Limit aber auch voll ausgeschöpft
weitere Verbraucher würden genau analog PV zur Unterbrechung führen
es bräuchte einen weiteren Parameter

Das würde allerdings die Modi nicht weiter verwirren.

Was wir aber machen könnten wäre, dass die Ladung bufferSoc aufrecht erhalten wird wenn sie einmal läuft. Es gäbe also keinen automatischen Start, wohl aber Ladeerhaltung bis bufferSoc. Aus Anwendersicht brauchts also einen Schubs über minPV, dann würde PV die Ladung halten und abschalten.

und das ist soweit ich die Doku lese auch der entsprechende Use-Case:

zu geringe PV-Erzeugung bei Überschreitung des bufferSoc: pv bleibt auch aus (weil ja eben die dafür eigtl. nötigen Umgebungsvariablen fehlen)
Ladevorgang ist vor Überschreitung des bufferSoc zu gering: pv lädt weiterhin - bis threshold erreicht ist.

Auch:
Wenn jemand überhalb bufferSoc auch ohne PV-Zutun laden möchte, kann er minPV nutzen, residualPower einstellen oder direkt Ziel-Laden nutzen.

Alternativ (und ich möchte das nur sehr ungern) bräuchte es noch einen batteryDischargePower Parameter mit dem sich berechnen liesse, ob ein weiteres Fahrzeug innerhalb dieser geladen werden könnte.

Dann wüsste evcc, ob und wieviel die Batterie beitragen könnte - und in diesem Fall, das käme, plädierte ich dann für einen extra PVplusBattery Modus (oder Schalter), der dann den PV-Überschuss-kW mit der maximalen Entladungs-kW addiert und dann in einem "selbstgemachter verfügbarer Strom" zusammenfasst. Abgesehen von den von Andi erwähnten Schwierigkeiten könnte evcc dann den "PVplusBattery"-Strom so behandeln wie bisher den PV-Überschuss - und entsprechend des sonstigen Hausverbrauches dann im pv-Lademodus abriegeln - mit der Ausnahme, dass bufferSoc dann natürlich nicht mehr geht, weil die Batterie ja zu 100% in den verfügbaren eigenen Ladestrom einfliesst.

plädierte ich dann für einen extra PVplusBattery Modus

Weitere Modi wirds noch weniger geben als weitere Parameter ;)

und das ist soweit ich die Doku lese auch der entsprechende Use-Case:

zu geringe PV-Erzeugung bei Überschreitung des bufferSoc: pv bleibt auch aus (weil ja eben die dafür eigtl. nötigen Umgebungsvariablen fehlen)
Ladevorgang ist vor Überschreitung des bufferSoc zu gering: pv lädt weiterhin - bis threshold erreicht ist.

Auch: Wenn jemand überhalb bufferSoc auch ohne PV-Zutun laden möchte, kann er minPV nutzen, residualPower einstellen oder direkt Ziel-Laden nutzen.

Exakt so lese ich es auch aus der Doku

Alternativ (und ich möchte das nur sehr ungern) bräuchte es noch einen batteryDischargePower Parameter mit dem sich berechnen liesse, ob ein weiteres Fahrzeug innerhalb dieser geladen werden könnte

Ich denke, auch in Bezug auf "Redesign PV Modus" wäre dieser Parameter nützlich. Da gab es auch immer wieder Wünsche nach Batterieunterstützung.

Dann bliebe die Frage, was der tun soll:

nur den Start ermöglichen?
oder voll als "verfügbare" Leistung am Netzpunkt ausgeschöpft werden?

Ersteres würde am Loadpoint passieren, letzteres wäre analog der aux Zähler.

Zweiteres.
Batterie kann mit spezifizierter Leistung entladen werden, wenn SoC > buffersoc.

Batterie kann mit spezifizierter Leistung entladen werden, wenn SoC > buffersoc.

mir fehlt weiterhin eine schlüssige Erläuterung, warum im Modus pv eine reine Batterieentladung ohne PV-Erzeugung gestartet werden sollte. PV = PV-Überschuss ist ausreichend vorhanden!?

Dann bliebe die Frage, was der tun soll:

nur den Start ermöglichen?
oder voll als "verfügbare" Leistung am Netzpunkt ausgeschöpft werden?

Ersteres würde am Loadpoint passieren, letzteres wäre analog der aux Zähler, aber eben nur >bufferSoc.

Den Start ermöglichen und puffern.

PV = PV-Überschuss

Aufgrund der Entwicklung (Zielladen, Tarif, CO2, Planner) sollte man sich nicht mehr so sehr an PV´ festhalten.
Der PV-Modus ist mittlerweile zu einem "Automatik" Modus gewachsen.

Der PV-Modus ist mittlerweile zu einem "Automatik" Modus gewachsen.

Dann brauchts aber einen "Automatik"-Modus. Ich sehe evcc wirklich in erster Linie als PV-Überschuss-Tool. Automatik-Modus geht Richtung EMS und sollte daher im parallel diskutierten "Profi-Modus" münden.
und ganz ehrlich: Wenn pv nicht so konfiguriert werden kann, dass es PV-Überschuss verwendet und Wolken puffert -> dann brauch ich persönlich kein evcc, weil es am Thema vorbei geht.

Batterie kann mit spezifizierter Leistung entladen werden, wenn SoC > buffersoc.

Nur mal als Gedankenspiel:
batteryDischargePower: 1000 und Soc > buffersoc ; Mindestladeleistung 1,4 kW

Fall 1: Dann würde bei 300 W Überschuss nix passieren und bei 500 W Überschuss würde das Laden gestartet.
Fall 2: Ladung läuft, Erzeugung geht zurück, Batterie wird mit mehr als 1000 W entladen, dann geht es in die Abschaltung, auch wenn Soc immer noch > bufferSoc.

buffersoc auf z.B. 95%: Batterie dient als Puffer, bis diese auf buffersoc entladen wurde. Dabei wird allerdings nicht geprüft, ob die Batterie überhaupt die Min-Leistung hergibt. Ggf. wird der Rest aus dem Netz geholt.

Widespruch! Ich möchte nicht erst einen Puffer haben, wenn die Batterie voll ist.
Nochmal: pv heißt erstmal PV und nicht Battery. und nur weil eine PV-Ladung mal Wolken überdauern soll, kann man nicht auf 95% warten. weil dann kann man den Puffer außer für 4 Monate kicken.... und täglich per yaml oder API den bufferSoc anzupassen kann nicht der Sinn von evcc sein.

So ist das aber heute mit dem buffersoc.
Wie möchtest du es denn genau haben? Wie weit darf der Speicher geleert werden, wenn während des Ladevorgangs die Sonne untergeht?

Wie möchtest du es denn genau haben? Wie weit darf der Speicher geleert werden, wenn während des Ladevorgangs die Sonne untergeht?

bis der threshold erreicht ist. So wie es heute ist. 3min. im Standard.

bis der threshold erreicht ist. So wie es heute ist. 3min. im Standard.

das hat doch aber gar nix mit buffersoc zu tun, bzw. entspricht buffersoc: 100

Ich rede davon, was ich mir wünsche (und wie pv funktioniert, wenn Auto während Überschuss vollständig geladen wird):

Wähle Modus pv
gehe davon aus, pv wird nicht geändert
warte auf PV-Ladung
Ladung wird ab Haus-batterie > bufferSoc nicht unterbrochen
Wenn threshold erreicht ist, stoppt die Ladung bei unzureichen PV-Erzeugung

ich rede nicht davon

wähle Modus pv
irgendwann entscheidet evcc (intransparent) auf minPV zu wechseln
...

oder auch nicht von

wähle Modus pv
stelle zusätzlich Ziel-Laden im Planner ein
...

Entweder: beschränken wir uns jetzt hier darauf, konkrete Vorschläge mit konkreten Ergänzungen oder Gegenvorschlägen zu beantworten, oder ich mache das Issue zu. bufferSoc funktioniert heute genau wie er designed wurde, ob das gut oder schlecht ist. Mein Vorschlag das zu ändern steht oben. Ansonsten führt die Diskussion für mich in keine erkennbare Richtung.
Anders gesagt: wenn kein Konsens dann dieses Issue zu, ist allenfalls ein Dokumentationsthema. Konkrete neue Featurerequests bei Bedarf.
Oder: wir kommen wieder auf die Vorschläge zurück.

+1 für deinen Vorschlag.
Start ermöglichen und puffern (bei Wolke z.b)

Ladung wird ab Haus-batterie > bufferSoc nicht unterbrochen

Die Ladung wird also fortgesetzt, bis der soc den buffersoc unterschritten hat? Unabhängig vom threshold?

Wenn threshold erreicht ist, stoppt die Ladung bei unzureichend PV-Erzeugung
(weil es evcc nur interessiert, DASS eine Batterie zur Unterstützung ab deren Ladestand verwendet weren kann, aber nich wieviel von der Batterie in kW beigetragen werden kann: sprich evcc nimmt bei einer Puffer-Ladung in Kauf, dass Netzbezug zustande kommt, wenn die Batterie nicht vollständig die Mindestladung erreichen kann)

Angenommen die Hausbatterie bringt die notwendige Leistung nicht und PV ist auch mau, dann wird aus dem Netz gezogen. Logisch. Dann wird der threshold überschritten und nach delay wird die Ladung unterbrochen.

Das widerspricht der Aussage von oben:

Ladung wird ab Haus-batterie > bufferSoc nicht unterbrochen

Sorry, aber ich versteh' es echt nicht.
Bei der aktuellen Implementierung ist es so, dass der Hausakku bis buffersoc zum Laden des Autos verwendet werden darf. Dabei wird die Ladeleistung heruntergefahren. Auf Min - in der Regel 6 A. Wo ist hier der Unterschied zu deinem 2. Absatz.

+1 für den Vorschlag.
Start ermöglichen und puffern (bei Wolke z.b)
Sollte der Start erst erfolgen, wenn die Hausbatterie nicht mehr geladen wird, so würde ich das als Bug einordnen.

+1 für den Vorschlag:
nur puffern (bei Wolke z.b)
+1 für den Vorschlag:
Start aus Batterie durch Schalter ermöglichen (bufferStart: true/false)

@Webwanze

Sollte der Start erst erfolgen, wenn die Hausbatterie nicht mehr geladen wird, so würde ich das als Bug einordnen.

Bist du dir da sicher? Dann passiert doch folgendes:
Batterie < buffersoc und wird geladen. In dem Moment, wo buffersoc überschritten wird, startet die Ladung um dann kurz danach zu stoppen, weil bis buffersoc entladen wurde.

@VolkerK62
Die Alternative wäre wie oben beschrieben: Die PV quält sich noch ewig und lädt den Hausakku stundenlang mit ein paar Watt. Wenn dann garnichts mehr geht, startet der Ladevorgang aus der Hausbatterie bis buffersoc unterschritten wurde.
Da finde ich die andere Variante besser/logischer.

Mit den Parametern 'disable', 'threshold', 'delay' kann man doch eigentlich den UseCase der Wolken ganz gut abbilden. Es wird für eine gewisse Zeit weitergeladen, auch wenn PV gerade nicht reicht. Ist ein Hausakku vorhanden, dann kommt's halt (teilweise) von dort. Das Wolkenthema kann man doch eigentlich unabhängig von 'buffersoc' sehen, finde ich.
'buffersoc' zusammen mit 'maxbatterydischargepower' würde ich einfach unter 'aux' anrechnen. Fertig.

'buffersoc' zusammen mit 'maxbatterydischargepower' würde ich einfach unter 'aux' anrechnen.

den "Trick" mit auxfinde ich gut.

Am Ende geht es ja um die Berechnung der site. Da ist die Hausbatterie sowieso ein Sonderfall, weil diese gleichzeitig Verbraucher als auch Quelle ist.
soc < prioritysoc: Hausakku wird nicht eingerechnet in site
prioritysoc < soc < buffersoc: aktuelle Ladeleistung Hausakku wird unter site einbezogen.
soc > buffersoc: sowohl Ladeleistung als auch mögliche Entladeleistung wird angerechnet.

Und mit der Möglichkeit die Entladeleistung festzulegen kann man das Verhalten beeinflussen. Gefällt mir.

Am Ende geht es ja um die Berechnung der site. Da ist die Hausbatterie sowieso ein Sonderfall, weil diese gleichzeitig Verbraucher als auch Quelle ist.
soc < prioritysoc: Hausakku wird nicht eingerechnet in site prioritysoc < soc < buffersoc: aktuelle Ladeleistung Hausakku wird unter site einbezogen. soc > buffersoc: sowohl Ladeleistung als auch mögliche Entladeleistung wird angerechnet.

Mit der Möglichkeit die Entladeleistung der Hausbatterie zu definieren. Top

Start ermöglichen und puffern (bei Wolke z.b)

Also: es bleibt wie heute, der Ladevorgang wir aber nicht mehr automatisch gestartet. Läuft er einmal, so wir die Batterie bis Puffer genutzt. Mit batteryDischargePower gingen noch mehr und andere Szenarien; dazu bitte neues Issue mit konkretem Vorschlag.

Closed in https://github.com/evcc-io/evcc/commit/99595b72cdae97f64526052c69e7008d1cb3ff9e
/cc @VolkerK62

authors: VolkerK62 Webwanze andig binderth premultiply thebrainkafka


text:
Is this repository stale/unmaintained?

Hey there,
I see there haven't been any changes for quite some time now and PRs are open and not merged.
Is this repository not maintained anymore?
If not, I forked it and started to merge open Pull-Requests, so feel free to contribute on my fork and I'll happily accept changes.
For v1.9.1 I'll replace TouchableHighlight with TouchableOpacity for iOS/Windows and TouchableNativeFeedback for Android (1.9.0 is the one with all open PRs merged).

Nice idea, shame yet another repository gets abandoned. What happened to your fork? Or is there another preferable fork?

Oh no. Where's your Form @creambyemute  :)
Is there an alternative Module?

For anyone else looking, I did another fork, any PR welcome
yarn add git+https://github.com/pjamrozowicz/react-native-settings-list.git
or
npm install git+https://github.com/pjamrozowicz/react-native-settings-list.git

This looks dead to me, will use @pjamrozowicz 's repo from now on - thanks :)

I've been using this repo for several years and on a few different projects. I originally forked to one of my businesses but have since forked to my personal account. I have made many updates to the feature set - though the readme has not reflected any of those changes :-( I'm happy to update it if others find the repo useful (I'll accept PR's ;-) Feel free to troll the commits for updates.
https://github.com/ajp8164/react-native-settings-list/

@ajp8164 I'm going to be trying your repo this week. If you could give a tldr of the added functionalities it'd be great :)

@ajp8164 I'm going to be trying your repo this week. If you could give a tldr of the added functionalities it'd be great :)

I’ll update the doc. I’m rewriting one of my apps and I need to bring my fork up to date.  I may rewrite my copy into ts/fc as well.

Just fyi - I've moved over to RNE as my base plus some core items from RNUI. The UX is much better. I still use my picker fork though - not getting much attention on my PR over there.

@ajp8164 RNE?

@ajp8164 RNE?

React Native Elements

source: gharchive/issue

authors: X-Tender ajp8164 antgel creambyemute glesperance philhudson91 pjamrozowicz

repo: evetstech/react-native-settings-list

license: mit

license_type: permissive

license_source: bigquery


text:
Build sample docs site using Starlight TypeDoc

There is a solution that seems to be close to what we want:
https://starlight-typedoc-example.vercel.app/
I need to check how it works, and is there any possibility that we could improve this one to get what we want.

TODO:

[ ] Run without any modifications on the sample TS project
[ ] Check if it's possible to adjust the design -- adding tables, links

Starlight seems to be unsuitable for custom-designed docs like PostCSS doc or Logux.
However, it can be enough for standard-looking docs for smaller projects.

repo: evilmartians/astro-typedoc

license: MIT

license_source: github-api


text:
:package: chore: Init new viem-effect package

Description

Init new EVMts-viem package

Testing
Explain the quality checks that have been done on the code changes
Additional Information

[ ] I read the contributing docs (if this is your first contribution)

Your ENS/address:

Current dependencies on/for this PR:

main

PR #557   👈

This comment was auto-generated by Graphite.

source: gharchive/pull-request

repo: evmts/evmts-monorepo


text:
Add requests package

Requests package should export type of every valid EVMts request

Moving to linear

repo: evmts/tevm-monorepo


text:
:bug: Fix(api): Replace enum with string type for EvmError

Description
Concise description of proposed changes
Testing
Explain the quality checks that have been done on the code changes
Additional Information

[ ] I read the contributing docs (if this is your first contribution)

Your ENS/address:

Current dependencies on/for this PR:

main

PR #811   👈

PR #812

This stack of pull requests is managed by Graphite.


text:
OSError: togethercomputer/evo-1-131k-base does not appear to have a file named pytorch_model.bin, tf_model.h5, model.ckpt or flax_model.msgpack.

Hi,
I just run the example command:
from evo import Evo
import torch

device = 'cuda:1'

evo_model = Evo('evo-1-131k-base')
model, tokenizer = evo_model.model, evo_model.tokenizer
model.to(device)
model.eval()

sequence = 'ACGT'
input_ids = torch.tensor(
    tokenizer.tokenize(sequence),
    dtype=torch.int,
).to(device).unsqueeze(0)
logits, _ = model(input_ids) # (batch, length, vocab)

print('Logits: ', logits)
print('Shape (batch, length, vocab): ', logits.shape)

But it show the error as below, even if I directly the huggingface version. Does anyone know what's the problem?
OSError: togethercomputer/evo-1-131k-base does not appear to have a file named pytorch_model.bin, tf_model.h5, model.ckpt or flax_model.msgpack.
Thanks,
Jinglie

I had this issue and updating to latest version of transformers fixed it for me

I had this issue and updating to latest version of transformers fixed it for me

Thank you!

authors: davidkell jingliezhou

repo: evo-design/evo


text:
Update http4s-core to 0.23.18

Updates org.http4s:http4s-core from 0.23.7 to 0.23.18.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.http4s", artifactId = "http4s-core" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.http4s", artifactId = "http4s-core" }
}]

labels: library-update, early-semver-minor, semver-spec-patch, version-scheme:early-semver, commit-count:1

Superseded by #254.

repo: evolution-gaming/smetrics


text:
Add example apps to Beta 2

Add the example apps we didn't have time for in Beta 1

Amazon AWS, example
New MediaTek MediaTek Linkit Connect 7681
ESP 8266
Ionic?
Facebook, Parse IoT cloud x 2

We do only New MediaTek MediaTek Linkit Connect 7681 and ESP 8266 for beta 2.

Done.
Documentation added in this commit: https://github.com/mikaelkindborg/evothings-doc/commit/2ad16984b31fca8cd933b0657239343b878d7807
Examples added to Workbench in this commit: https://github.com/mikaelkindborg/evothings-studio/commit/9e3879dfd96b827756e8db8c34ea64f56520446f

authors: gokr mikaelkindborg

repo: evothings/evothings-examples


text:
🛑 My Site is down

In 9236d75, My Site ($SECRET_SITE) was down:

HTTP code: 0
Response time: 0 ms

Resolved: My Site is back up in c16066f.

repo: exand/upptime


text:
🛑 My Site is down

In dae671d, My Site ($SECRET_SITE) was down:

HTTP code: 0
Response time: 0 ms

Resolved: My Site is back up in ef1403b.


text:
🛑 Portfolio is down

In d8cb649, Portfolio ($SECRET_P_SITE) was down:

HTTP code: 404
Response time: 654 ms

Resolved: Portfolio is back up in 1dbb0dc.


text:
🛑 Portfolio is down

In 9948d95, Portfolio ($SECRET_P_SITE) was down:

HTTP code: 404
Response time: 574 ms

Resolved: Portfolio is back up in a0cada6.


text:
Hyperlink 404 not found

The shield icon on the bottom right corner shows 404 error on clicking. This is the link of the button it points to

Fixed, thanks for the report!

authors: AdityaPGit dwelle

repo: excalidraw/excalidraw


text:
Feature: Align elements

This pull request implements the alignment feature suggested in #772
In order to allow for a sensible integration with the existing context menu items it also adds a contextMenuOrder property to z-index actions.

Nice, thanks for the PR!
Few notes

The aligning doesn't work well with rotated elements. I can't seem to be able to upload images to GH right now, so can't illustrate. Try rotating to rectangles and top-aligning them. It should align by their bounding boxes.
Any reason why some of the icons have dotted lines while the others don't?

Thanks for the quick feedback. I guess we'll have to give aligning rotated shapes some more thought.

Any reason why some of the icons have dotted lines while the others don't?

The idea behind this is that for the centering actions the reference line crosses through the elements which it doesn't for the other four. I actually tried having a solid line both in front of and behind the blocks. Neither we're as clear as the one with the dashed line I decided on at such small scale in the application.

Besides the rotated elements is awesome!

Working great.
Final thing, are we fine with the button order? Traditionally, vertical and horizontal buttons are grouped together. Ours:

I can see benefits of our solution, but it's non-standard, and it makes it harder to realize (if you're not already familiar with the behavior) that you can align by two different axes at the same time.

I changed the order of the actions in the respective component but anywhere else in the code.
For some reason the tests suddenly fail in a spot we didn't touch and I can't see any connection either. Is that just a random hickup that was there before? Also, it appears I can't rerun the check without making another push...

For some reason the tests suddenly fail in a spot we didn't touch and I can't see any connection either. Is that just a random hickup that was there before?

Checking the run, yes, it's failing on __cokieJar which is an unrelated flake fixed in my recent PR. Will merge it soon and then merge it into this one.

Shipping! Superb job @IllTemperedMax @SvenKube :tada:

authors: IllTemperedMax SvenKube dwelle lipis


text:
Add and deploy docs!

Should have some interactive demos in it as well. :)

This will be coming in the new version of mystjs.
Includes interactive demos of syntax, showing the AST, and the rendered HTML.

repo: executablebooks/mystjs


text:
[v3] Add prerequisites to Practice Exercises

This issue is part of the migration to v3. You can read full details about the various changes here.
Exercism v3 introduces a new type of exercise: Concept Exercises. All existing (V2) exercises will become Practice Exercises.
Concept Exercises and Practice Exercises are linked to each other via Concepts. Concepts are taught by Concept Exercises and practiced in Practice Exercises. Each Exercise (Concept or Practice) has prerequisites, which must be met to unlock an Exercise - once all the prerequisite Concepts have been "taught" by a Concept Exercise, the exercise itself becomes unlocked.
For example, in some languages completing the Concept Exercises that teach the "String Interpolation" and "Optional Parameters" concepts might then unlock the two-fer Practice Exercise.
Each Practice Exercise has two fields containing concepts: a practices field and a prerequisites field.
Practices
The practices key should list the slugs of Concepts that this Practice Exercise actively allows a student to practice.

These show up in the UI as "Practice this Concept in: TwoFer, Leap, etc"
Try and choose 3 - 8 Exercises that practice each Concept.
Try and choose at least two Exercises that allow someone to practice the basics of a Concept.
Some Concepts are very common (for example strings). In those cases we recommend choosing a few good exercises that make people think about those Concepts in interesting ways. For example, exercises that require UTF-8, string concatenation, char enumeration, etc, would all be good examples.
There should be one or more Concepts to practice per exercise.

Prerequisites
The prerequisites key lists the Concept Exercises that a student must have completed in order to access this Practice Exercise.

These show up in the UI as "Learn Strings to unlock TwoFer"
It should include all Concepts that a student needs to have covered to be able to complete the exercise in at least one idiomatic way. For example, for the TwoFer exercise in Ruby, prerequisites might include strings, optional-params, implicit-return.
For Exercises that can be completed using alternative Concepts (e.g. an Exercise solvable by loops or recursion), the maintainer should choose the one approach that they would like to unlock the Exercise, considering the student's journey through the track. For example, the loops/recursion example, they might think this exercise is a good early practice of loops or that they might like to leave it later to teach recursion. They can also make use of an analyzer to prompt the student to try an alternative approach: "Nice work on solving this via loops. You might also like to try solving this using Recursion."
There should be one or more prerequisites Concepts per exercise.

Although ideally all Concepts should be taught by Concept Exercises, we recognise that it will take time for tracks to achieve that. Any Practice Exercises that have prerequisites which are not taught by Concept Exercises, will become unlocked once the final Concept Exercise has been completed.
Goal
Practices
The "practices" field of each element in the "exercises.practice" field in the config.json file should be updated to contain the practice concepts. See the spec.
To help with identifying the practice concepts, the "topics" field can be used (if it has any contents). Once prerequisites have been defined for a Practice Exercise, the "topics" field should be removed.
Each practice concept should have its own entry in the top-level "concepts" array. See the spec.
Prerequisites
The "prerequisites" field of each element in the "exercises.practice" field in the config.json file should be updated to contain the prerequisite concepts. See the spec.
To help with identifying the prerequisites, the "topics" field can be used (if it has any contents). Once prerequisites have been defined for a Practice Exercise, the "topics" field should be removed.
Each prerequisite concept should have its own entry in the top-level "concepts" array. See the spec.
Example
{
  "exercises": {
    "practice": [
      {
        "uuid": "8ba15933-29a2-49b1-a9ce-70474bad3007",
        "slug": "leap",
        "name": "Leap",
        "practices": ["if-statements", "numbers", "operator-precedence"],
        "prerequisites": ["if-statements", "numbers"],
        "difficulty": 1
      }
    ]
  }
}

Tracking
https://github.com/exercism/v3-launch/issues/6

⚠ The spec for Practice Exercises has changed. Besides having a prerequisites field, each Practice Exercise should now also have a practices field, which should list the slugs of Concepts that this Practice Exercise actively allows a student to practice. See the spec for more information.
The issue's text has been updated to reflect the updated spec.

repo: exercism/babashka


text:
[v3] Pass linting checks

This issue is part of the migration to v3. You can read full details about the various changes here.
The configlet tool has a lint command that checks if a track's configuration files are properly structured - both syntactically and semantically. Misconfigured tracks may not sync correctly, may look wrong on the website, or may present a suboptimal user experience, so configlet's guards play an important part in maintaining the integrity of Exercism.
We're updating configlet to work with v3 tracks, which have a different set of requirements than v2 tracks.
The full list of rules that will be checked by the linter can be found in this spec.
⚠ Note that only a subset of the linting rules has been implemented at this moment. This means that while your track may be passing the checks at this moment, it might fail later. We thus strongly suggest you keep this issue open until we let you know otherwise.
Goal
Ensure that the track passes all the (v3 track) checks defined in configlet lint.
To help verify that the track passes all the linting rules, the v3 preparation PR has added a GitHub Actions workflow that automatically runs configlet lint.
It is also possible to run configlet lint locally by running the ./bin/fetch-configlet (or ./bin/fetch-configlet.ps1) script to download a local copy of the configlet binary. Once downloaded, you can then do ./bin/configlet lint to run the linting on your own machine.
Tracking
https://github.com/exercism/v3-launch/issues/3

⚠ The original issue did not explain that currently only a subset of the linting rules have been implemented. This means that while your track may be passing the checks at this moment, it might fail later. We (the Exercism team) thus strongly suggest you keep this issue open until we let you know otherwise. The issue's text has been updated to reflect this.

repo: exercism/crystal


text:
Fortran fixed format

Fortran77 only supported fixed format. This course is focused on Fortran90 and free format.
We should add somewhere that fixed format is still in use for older legacy systems.
Ref:
https://en.wikibooks.org/wiki/Fortran/Beginning_Fortran#Free_Form_and_Fixed_Form

We should probably avoid "legacy" as well, older systems is descriptive enough, legacy has a not-well-defined use, usually.  Used, but sloppily to mean quite a few things, when it comes to systems and coding.  Specifically we can say "before Fortran90" if there is nothing before that that used free format.

authors: kotp pclausen

repo: exercism/fortran


text:
Correct grammar as per Issue #1524

Hello!
This PR is to address the issue I raised in Issue #1524 .
As per June's advice, I changed "old" to "mature" so as to be friendly to non-native speakers of English.
Cheers!

Thanks @junedev! I just familiarized myself with the test tool and have corrected the error I left in the exemplar solution. Instructions.md has also been updated.

repo: exercism/javascript


text:
update for perfect-numbers

The perfect-numbers exercise for Racket seems to be outdated when compared to other programming languages. I took example on the Go version.
Note that contrary to the Go Version, this one doesn't ask for an error/exception to be throw if the passed argument is negative or zero.

👋 @benreyn it looks like you've been the most active on the track recently. Would you have time to take a look at this one?

authors: codingbum kytrinyx

repo: exercism/racket


text:
Remove fetch-canonical-data-syncer scripts

The fetch-canonical-data-syncer script is obsolete as canonical data syncing is now built into configlet.
See See https://github.com/exercism/configlet/issues/124

@ErikSchierboom let's just merge this one?

@ee7 Done

repo: exercism/solidity


text:
rna-transcription: Improve error-handling behavior

As part of #275, we'd like to more closely follow idiomatic Go behavior in the face of errors.
If the rna-transcription exercise does not have error handling, then this ticket can be closed immediately.
If it does, then follow the below steps:
Ensure err return value is of type error
It's idiomatic for the error return value to be of type error.
Most tests simply check whether err == nil or not. If we don't verify the type of err, it could be any type that has nils.
To lean on the type system, add the following line after assigning err:
var _ error = err

See the hamming tests for an example.
Ignore the normal return value when an error expected
The contract in Go is "if there's an error, assume nothing about the normal return value". Thus, we should only check the non-error return value when there is no error.
In some exercises we found that we were checking the normal return value, even when there was an error.
See the binary tests for an example of the behavior that we want.
Increment the test version
These changes break backwards compatibility. Bump the test version to let reviewers know that the exercise has changed.
This requires changing two constants:

targetTestVersion in the test file (*_test.go)

testVersion in the reference solution (example.go)

If the exercise does not have a test version, then add one, setting the value to 1.
See the version test in leap for an example.

No error here.

repo: exercism/xgo


text:
Ensures designers ruby at version 2.1.2 or higher

#371 discussion about helping ensure we are reporting on older versions of Ruby for exercise developers.

I think the string is being interpreted literally, as in, ruby is now looking for a ruby version called >= 2.1.2 instead of a ruby version that is greater than or equal to 2.1.2
Is there a reason for 2.1.2 over say, 2.1.0?

Seems like Travis CI is set to 2.1.x these two should match, so I am lowering the minimum Ruby version to match that rather than what is required for repository exercism-io.
Strange, the specification is failing in Travis CI, though Bundle version specification in Gemfile is correctly formatted.  A Travis bug?  Checking for that possibility.

The version string is technically correct for Gemfile, it seems Travis is comparing it in a manner than doesn't account for that in the Gemfile.  I think I asked Travis team the same thing, it appears to check it 'stringally' rather than 'versionally'.

And I would say "Yes, there is some reason."  But I do not know what the reason is.  Could be an end of life point, would likely have to check the commit history for that file, if it was annotated for the change, or it was a 'convenience' change at that point.

Closing due to lack of interest, and it is possible to do this locally, away from the repository.

Thanks, @kotp, I think that was the right choice.

authors: Cohen-Carlisle kotp kytrinyx

repo: exercism/xruby


text:
cannot build (make dev) project

identified error:
error: Relative import path "global.d.ts" not prefixed with / or ./ or ../ and not in import map from "https://cdn.esm.sh/@types/react@17.0.20/index.d.ts"

complete steps/log
deno --version
deno 1.13.1 (release, x86_64-unknown-linux-gnu)
v8 9.3.345.11
typescript 4.3.5
  20:32  ~/Develop/testing
git clone https://github.com/exhibitionist-digital/ultra deno_ultra
Cloning into 'deno_ultra'...
remote: Enumerating objects: 659, done.
remote: Counting objects: 100% (515/515), done.
remote: Compressing objects: 100% (327/327), done.
remote: Total 659 (delta 323), reused 330 (delta 182), pack-reused 144
Receiving objects: 100% (659/659), 209.40 KiB | 3.95 MiB/s, done.
Resolving deltas: 100% (372/372), done.
  20:32  ~/Develop/testing
cd deno
deno-tutorials1/ deno_ultra/
  20:32  ~/Develop/testing
cd deno_ultra/examples/react18/
  20:34  ~/.../examples/react18
make dev
mode=dev deno run --no-check --allow-net --allow-read --allow-env --allow-run --allow-write --import-map=importmap.json --unstable server.js
Download https://deno.land/x/ultra@v0.5/mod.ts
Download https://deno.land/x/ultra@v0.5/src/ultra.ts
Download https://deno.land/x/ultra@v0.5/src/types.ts
Download https://deno.land/x/oak@v9.0.0/mod.ts
Download https://deno.land/x/ultra@v0.5/src/render.ts
Download https://deno.land/std@0.106.0/path/mod.ts
Download https://deno.land/std@0.106.0/fs/mod.ts
Download https://deno.land/x/lru@1.0.2/mod.ts
Download https://deno.land/x/ultra@v0.5/src/transform.ts
Download https://deno.land/x/oak@v9.0.0/deps.ts
Download https://deno.land/x/oak@v9.0.0/http_server_std.ts
Download https://deno.land/x/oak@v9.0.0/middleware/proxy.ts
Download https://deno.land/x/oak@v9.0.0/request.ts
Download https://deno.land/x/oak@v9.0.0/application.ts
Download https://deno.land/x/oak@v9.0.0/response.ts
Download https://deno.land/x/oak@v9.0.0/send.ts
Download https://deno.land/x/oak@v9.0.0/middleware.ts
Download https://deno.land/x/oak@v9.0.0/context.ts
Download https://deno.land/x/oak@v9.0.0/body.ts
Download https://deno.land/x/oak@v9.0.0/range.ts
Download https://deno.land/x/oak@v9.0.0/server_sent_event.ts
Download https://deno.land/x/oak@v9.0.0/httpError.ts
Download https://deno.land/x/oak@v9.0.0/cookies.ts
Download https://deno.land/x/oak@v9.0.0/etag.ts
Download https://deno.land/x/oak@v9.0.0/router.ts
Download https://deno.land/x/oak@v9.0.0/testing.ts
Download https://deno.land/x/oak@v9.0.0/http_server_native.ts
Download https://deno.land/x/oak@v9.0.0/multipart.ts
Download https://deno.land/x/oak@v9.0.0/types.d.ts
Download https://deno.land/x/oak@v9.0.0/util.ts
Download https://deno.land/x/oak@v9.0.0/helpers.ts
Download https://x.nest.land/swc@0.1.4/mod.ts
Download https://deno.land/x/esbuild@v0.12.24/mod.js
Download https://deno.land/x/swc@0.1.4/types/options.ts
Download https://deno.land/std@0.106.0/fs/exists.ts
Download https://deno.land/std@0.106.0/fs/empty_dir.ts
Download https://deno.land/std@0.106.0/fs/ensure_file.ts
Download https://deno.land/std@0.106.0/fs/move.ts
Download https://deno.land/std@0.106.0/fs/copy.ts
Download https://deno.land/std@0.106.0/fs/ensure_dir.ts
Download https://deno.land/std@0.106.0/fs/ensure_symlink.ts
Download https://deno.land/std@0.106.0/fs/eol.ts
Download https://deno.land/std@0.106.0/fs/walk.ts
Download https://deno.land/std@0.106.0/fs/ensure_link.ts
Download https://deno.land/std@0.106.0/fs/expand_glob.ts
Download https://esm.sh/wouter?deps=react@18.0.0-alpha-67f38366a-20210830&bundle
Download https://esm.sh/react@18.0.0-alpha-67f38366a-20210830
Download https://esm.sh/react-helmet-async?deps=react@18.0.0-alpha-67f38366a-20210830&bundle
Download https://esm.sh/react-dom@18.0.0-alpha-67f38366a-20210830/server
Download https://deno.land/std@0.106.0/path/common.ts
Download https://deno.land/std@0.106.0/path/win32.ts
Download https://deno.land/std@0.106.0/path/separator.ts
Download https://deno.land/std@0.106.0/_util/os.ts
Download https://deno.land/std@0.106.0/path/_interface.ts
Download https://deno.land/std@0.106.0/path/glob.ts
Download https://deno.land/std@0.106.0/path/posix.ts
Download https://deno.land/x/oak@v9.0.0/async_iterable_reader.ts
Download https://deno.land/x/oak@v9.0.0/negotiation/mediaType.ts
Download https://deno.land/x/oak@v9.0.0/negotiation/language.ts
Download https://deno.land/x/oak@v9.0.0/negotiation/encoding.ts
Download https://deno.land/x/oak@v9.0.0/negotiation/charset.ts
Download https://deno.land/x/path_to_regexp@v6.2.0/index.ts
Download https://deno.land/std@0.105.0/bytes/mod.ts
Download https://deno.land/std@0.105.0/io/buffer.ts
Download https://deno.land/std@0.105.0/io/streams.ts
Download https://deno.land/std@0.105.0/http/server.ts
Download https://deno.land/std@0.105.0/io/util.ts
Download https://deno.land/std@0.105.0/path/mod.ts
Download https://deno.land/std@0.105.0/io/readers.ts
Download https://deno.land/std@0.105.0/testing/asserts.ts
Download https://deno.land/std@0.105.0/io/bufio.ts
Download https://deno.land/std@0.105.0/ws/mod.ts
Download https://deno.land/x/media_types@v2.10.1/mod.ts
Download https://deno.land/std@0.105.0/http/http_status.ts
Download https://deno.land/std@0.105.0/encoding/base64.ts
Download https://deno.land/x/oak@v9.0.0/keyStack.ts
Download https://deno.land/x/oak@v9.0.0/structured_clone.ts
Download https://deno.land/x/oak@v9.0.0/websocket.ts
Download https://deno.land/std@0.106.0/fs/_util.ts
Download https://deno.land/x/oak@v9.0.0/isMediaType.ts
Download https://deno.land/x/oak@v9.0.0/headers.ts
Download https://deno.land/x/oak@v9.0.0/content_disposition.ts
Download https://deno.land/x/oak@v9.0.0/buf_reader.ts
Download https://deno.land/std@0.106.0/_util/assert.ts
Download https://deno.land/x/oak@v9.0.0/negotiation/common.ts
Download https://deno.land/std@0.105.0/http/_io.ts
Download https://deno.land/std@0.105.0/_util/assert.ts
Download https://deno.land/std@0.105.0/async/mod.ts
Download https://deno.land/std@0.105.0/path/glob.ts
Download https://deno.land/std@0.105.0/path/separator.ts
Download https://deno.land/std@0.105.0/path/common.ts
Download https://deno.land/std@0.105.0/path/_interface.ts
Download https://deno.land/std@0.105.0/path/win32.ts
Download https://deno.land/std@0.105.0/_util/os.ts
Download https://deno.land/std@0.105.0/path/posix.ts
Download https://deno.land/x/media_types@v2.10.1/db.ts
Download https://deno.land/x/media_types@v2.10.1/deps.ts
Download https://deno.land/std@0.105.0/_util/has_own_property.ts
Download https://deno.land/std@0.105.0/async/deferred.ts
Download https://deno.land/std@0.105.0/textproto/mod.ts
Download https://deno.land/std@0.105.0/io/ioutil.ts
Download https://deno.land/std@0.105.0/crypto/mod.ts
Download https://deno.land/std@0.106.0/path/_util.ts
Download https://deno.land/std@0.106.0/path/_constants.ts
Download https://deno.land/std@0.105.0/io/types.d.ts
Download https://deno.land/x/oak@v9.0.0/tssCompare.ts
Download https://deno.land/x/oak@v9.0.0/mediaTyper.ts
Download https://deno.land/std@0.105.0/testing/_diff.ts
Download https://deno.land/std@0.105.0/fmt/colors.ts
Download https://deno.land/std@0.105.0/bytes/bytes_list.ts
Download https://deno.land/x/denoflate@1.2.1/mod.ts
Download https://deno.land/x/esbuild@v0.12.24/mod.d.ts
Download https://cdn.esm.sh/v49/react-dom@18.0.0-alpha-67f38366a-20210830/deno/server.js
Download https://cdn.esm.sh/@types/react-dom@18.0.0-alpha-67f38366a-20210830/server.d.ts
Download https://cdn.esm.sh/v49/react@18.0.0-alpha-67f38366a-20210830/deno/react.js
Download https://cdn.esm.sh/@types/react@17.0.20/index.d.ts
Download https://deno.land/std@0.105.0/async/debounce.ts
Download https://deno.land/std@0.105.0/async/delay.ts
Download https://deno.land/std@0.105.0/async/mux_async_iterator.ts
Download https://deno.land/std@0.105.0/async/pool.ts
Download https://deno.land/std@0.105.0/async/tee.ts
Download https://deno.land/std@0.105.0/async/deadline.ts
Download https://deno.land/std@0.105.0/path/_util.ts
Download https://deno.land/std@0.105.0/path/_constants.ts
Download https://deno.land/std@0.105.0/_wasm_crypto/mod.ts
Download https://arweave.net/V1fQ06LQBlZRczbAOoQQBsfCgbP00TTXGQ2VUUbWS7w/mod.ts
Download https://cdn.esm.sh/v49/object-assign@4.1.1/deno/object-assign.js
Download https://deno.land/x/denoflate@1.2.1/pkg/denoflate_bg.wasm.js
Download https://deno.land/x/denoflate@1.2.1/pkg/denoflate.js
Download https://k5l5bu5c2adfmultg3advbaqa3d4fant6titjvyzbwkvcrwwjo6a.arweave.net/V1fQ06LQBlZRczbAOoQQBsfCgbP00TTXGQ2VUUbWS7w/mod.ts
Download https://deno.land/std@0.105.0/_wasm_crypto/crypto.js
Download https://deno.land/std@0.105.0/_wasm_crypto/crypto.wasm.js
Download https://k5l5bu5c2adfmultg3advbaqa3d4fant6titjvyzbwkvcrwwjo6a.arweave.net/V1fQ06LQBlZRczbAOoQQBsfCgbP00TTXGQ2VUUbWS7w/types/options.ts
Download https://k5l5bu5c2adfmultg3advbaqa3d4fant6titjvyzbwkvcrwwjo6a.arweave.net/V1fQ06LQBlZRczbAOoQQBsfCgbP00TTXGQ2VUUbWS7w/swc_wasm/wasm.js
Download https://deno.land/x/lz4@v0.1.2/mod.ts
Download https://cdn.esm.sh/v49/wouter@2.7.4/X-ZGVwczpyZWFjdEAxOC4wLjAtYWxwaGEtNjdmMzgzNjZhLTIwMjEwODMw/deno/wouter.bundle.js
Download https://cdn.esm.sh/X-ZGVwczpyZWFjdEAxOC4wLjAtYWxwaGEtNjdmMzgzNjZhLTIwMjEwODMw/wouter@2.7.4/index.d.ts
Download https://cdn.esm.sh/v49/react-helmet-async@1.1.2/X-ZGVwczpyZWFjdEAxOC4wLjAtYWxwaGEtNjdmMzgzNjZhLTIwMjEwODMw/deno/react-helmet-async.bundle.js
Download https://cdn.esm.sh/X-ZGVwczpyZWFjdEAxOC4wLjAtYWxwaGEtNjdmMzgzNjZhLTIwMjEwODMw/react-helmet-async@1.1.2/index.d.ts
Download https://deno.land/x/lz4@v0.1.2/wasm.js
error: Relative import path "global.d.ts" not prefixed with / or ./ or ../ and not in import map from "https://cdn.esm.sh/@types/react@17.0.20/index.d.ts"
make: *** [makefile:2: dev] Error 1

since im new with deno -> this is a show stopper for me

As a temporary workaround, you can add the path to manually to the import map by adding the line
"global.d.ts": "https://cdn.esm.sh/@types/react@17.0.20/global.d.ts" to the file ultra/examples/react18/importmap.json.

I think @SebastianZimmer's suggestion would fix this. Any bare imports will need to be added to your importmap, or else you can use the fully qualified CDN url.
I will update the docs for this type of usage, apologies its not very clear atm.

repo: exhibitionist-digital/ultra


text:
A documentation example for C++ API

Please, can you add a C++ example to the documentation? celerite C++ doc's example looks helpful but I'm not sure if it is applicable here. Thank you!

Yeah - that would be useful and the interface is very different from celerite. I'm not sure when I'll be able to get to this, but some combination of the API docs and the C++ unit tests might get you started?

authors: dfm hombit


text:
Support for multiple CESTER_OPTIONS, and like block

Support for multiple functions for a single macro function below:
CESTER_OPTIONS
CESTER_BEFORE_ALL
CESTER_BEFORE_EACH
CESTER_AFTER_ALL
CESTER_AFTER_ALL

# and in future

CESTER_SETUP
CESTER_TEARDOWN

The method is to concatenate the line number with the name of the function like:
#define CESTER_OPTIONS(x) void cester_options_before_main_##__LINE__();

unnecessary complexity

repo: exoticlibraries/libcester


text:
small or tiny object detection

Hi,experiencor,
I want to detect some objects that is very small compared to the whole image.
eg: image size 2000    2500  object size: 20   25
Do you think if the YOLOV2 model can handle this? Which parameters should I change for this task?
Should I set the anchors  smaller?
Or if the Yolov2 is not good at tiny object detection? DO you know is there any other models good at it ?
Thank you for your time.

Yes. You should adjust the size of the anchors to work best with your dataset. The rule is that the sizes of the anchors should be the prevalent sizes of the bounding boxes in your dataset. After that, I think YOLOv2 will work fine with your dataset.

thank  you, I will try.

Hi @Isabelliu Have you tried small object? How is that going after setting the anchors?

@jjjjohnson Sorry for the late reply as I was on vacation. You can now try gen_anchors.py to generate the custom anchor sizes to suit your dataset (small objects).

@experiencor Thanks. Yes I tried that. It generated some suggested anchors but YOLO still performed poorly. Maybe I need better quality training data...

authors: Isabelliu experiencor jjjjohnson

repo: experiencor/basic-yolo-keras


text:
Feature/aspen benchmark

Aspen_benchmark class added, that creates a connection to a Aspen Plus simulation as a benchmark problem.
Autosafe functionality integrated into benchmark.single_run() that saves benchmark function results including candidates and hypervolume in a .json file every 10 iterations.

Thanks JD ;)
I added a few comments into the first file, on which you can start working. A few more notes:

the paths should be for me something of type Dict[str,str], where the key of the dictionary is actually the feature key in the domain. Then you can also easily check them for consistency. Via the domain, you also know which key is an input, and which an output key.
please add pytests for the init of your benchmark module in which we check that the error checking for the paths, filename etc. works. This can be tested also without having aspen installed. For this reason put also the import for win32 inside the start_aspen method so that one can run the tests also on machines without win32.
Finally, I think we need a categorical mapper, which can be provided at init. This can map for a categorical feature the actual value that is proposed by the strategy (which is in case of categoricals always a string) to the actual value which is then passed to Aspen.

Best,
Johannes

authors: evo-jdridder jduerholt

repo: experimental-design/bofire


text:
Adding Tonic Validate integration notebook

Adds a jupyter notebook on how to use Tonic Validate to visualize Ragas metrics.

Hmm, the PR doc environment is not properly rendering my embedded images+gifs.  I'll get that fixed and drop a note here when its resolved.

Awesome, things look good from my end now!

thanks @akamor for the merge :)

authors: akamor jjmachan

repo: explodinggradients/ragas


text:
source attribute could be undefined

TypeError: Cannot convert undefined or null to object
        at Function.keys (<anonymous>)

      at Function.getClosestHighQualitySource (node_modules/@expo/react-native-responsive-image/ResponsiveImage.js:83:136)
      at ResponsiveImage.render (node_modules/@expo/react-native-responsive-image/ResponsiveImage.js:59:35)
      at node_modules/react-test-renderer/lib/ReactCompositeComponent.js:796:21
      at measureLifeCyclePerf (node_modules/react-test-renderer/lib/ReactCompositeComponent.js:75:12)
      at ReactCompositeComponentWrapper._renderValidatedComponentWithoutOwnerOrContext (node_modules/react-test-renderer/lib/ReactCompositeComponent.js:795:25)
      at ReactCompositeComponentWrapper._renderValidatedComponent (node_modules/react-test-renderer/lib/ReactCompositeComponent.js:822:32)
      at ReactCompositeComponentWrapper.performInitialMount (node_modules/react-test-renderer/lib/ReactCompositeComponent.js:362:30)
      at ReactCompositeComponentWrapper.mountComponent (node_modules/react-test-renderer/lib/ReactCompositeComponent.js:258:21)
      at Object.mountComponent (node_modules/react-test-renderer/lib/ReactReconciler.js:46:35)

You have to pass in valid image sources, otherwise there is nothing to display.

I think, this is a bug. Should be checked for undefined in the code.

authors: ide iegik

repo: expo/react-native-responsive-image


text:
When clicked on Thumbnail and dots Carousel is not moving to next slider.

When i click on the thumbnails Carousel should change the images, and even left and right button is also not working.

All I can say is, the carousel works.  I don't doubt you are having problems though.  There must be something must be misconfigured on your end.  Can you show me your code so that I can better understand the issue?

repo: express-labs/pure-react-carousel


text:
Unable to find a way to properly remove or override a route after it has already been created

Basically I can't find a way properly remove a route after it has already been created. or redefine it to add a middleware if needed.
This is really causing a slight setback for a project I'm working on right now that needs to be able to create, remove or alter a route on demand.

Hi @VaasKahnGrim yes, in Express you can only add routes; there is no method to remove or change them. There have been PRs to add this functionality, but they never worked right so far. Currently, we recommend creating a router with the routes you may need to "refresh" at some point and then create a middleware that directs requests to the current version of the router you need.
If you would like help, you're welcome to post here in head on over to our Gitter or StackOverflow with specific details about what you are trying to accomplish and we can help show how to accomplish that in Express if the above generic explanation was not enough.

Hi @VaasKahnGrim yes, in Express you can only add routes; there is no method to remove or change them. There have been PRs to add this functionality, but they never worked right so far. Currently, we recommend creating a router with the routes you may need to "refresh" at some point and then create a middleware that directs requests to the current version of the router you need.
If you would like help, you're welcome to post here in head on over to our Gitter or StackOverflow with specific details about what you are trying to accomplish and we can help show how to accomplish that in Express if the above generic explanation was not enough.

Hi @dougwilson, what kind of issues did you guys have with removing routes?
Can you give me please a reference to the PR that closed to add this functionality?
Thanks, Moisei 😄

Hi @Moisei-Shkil I'm sorry I don't remember exactly. If you are looking to contribute a method to remove routes, you are welcome to do so if you believe it works correctly. We can review from there 👍

authors: Moisei-Shkil VaasKahnGrim dougwilson

repo: expressjs/express


text:
Allow a path before /favicon.ico

This is to allow a path such as /some-path/favicon.ico. This is for use cases where an express server might be behind a proxy or CDN that transforms the URL path.

Just mount the middleware on your path prefix:
app.use('/some-path', favicon(...))

That will respond now to GET /some-path/favicon.ico

authors: dougwilson drewmoore

repo: expressjs/serve-favicon


text:
max-age is always 2592000 for images (.png, .jpg etc.)

I've set the max-age value to 1 year in my tiny connect server:
var connect = require('connect');
var serveStatic = require('serve-static');

connect()
    .use(serveStatic(__dirname, {
        cacheControl: true,
        maxAge: '1 year'
    }))
    .listen(process.env.PORT);

This generally works great, giving me Cache-Control: public, max-age=31536000. But some resources, such as .png files, are delivered with the value 2592000 instead of 31536000. Is there something I'm doing wrong?

Weird. Using the exact code you posed, everything, even .png and .jpg are coming back as  Cache-Control: public, max-age=31536000  for me. Is the above code exactly what you're running to see the issue as well? If you change the max age to like 1 day do the .png and stuff change to be a day, or stay at  2592000 ?

Case closed. I was a victim of my own client cache... disabled cache in Chrome DevTools earlier but somehow the value stuck around a bit. So sorry for stealing your time!

authors: dougwilson storafrid

repo: expressjs/serve-static


text:
PushSecret: option to add additional tags\labels

Describe the solution you'd like
I would like to be able to manage the tags that are set on the external secret when using PushSecret.
What is the added value?
Tags can be used for governance, compliance, and billing purposes and in a lot of organizations it is mandatory to add certain tags to resources.
Currently, only the 'managed-by: external-secrets' is set to (AWS Secrets Manager in our case).

For us , this functionality is a blocker to actually start using the push secret functionality.
In fact, i know from other companies in the past, that tagging AWS resources is mandatory.

Agree, this is widely used. Tho to make that work we need to support multiple "dimensions". E.g. in GCP Secret Manager we can define both annotations and labels. The same is true for the Kubernetes provider.
I'd be happy to review a PR if someone takes this on :pray:.

I've started thinking about this feature. Let me create a PR to discuss the possible design!

Hi, I've created a PR to discuss the potential API design! Any feedback will be much appreciated 🙂
https://github.com/external-secrets/external-secrets/pull/2600

@shuheiktgw perhaps this should also be a SecretsStore matter i.e. where provider specific concerns are usually addressed?
Maybe a 'template' and 'templateParameters' subsections, for SecretStore and PushSecret, respectively?
To keep PushSecret decoupled from the SecretStore-provider, the SecretStore-template could feature placeholders in-line e.g. in annotations and/or labels; the PushSecret-templateParameters then just gives values for those placeholders.

authors: DarrenBishop dvbthijsvnuland moolen shuheiktgw tabnul

repo: external-secrets/external-secrets


text:
Can't get data from /pets and position is null in /households/{household_id}/pets/{pet_id}

I'm not sure what changed, but sometime overnight my monitoring of the cat flap stopped working. I'm not sure what changed - whether it's something my hardware, with the api? I'm running the latest version of the docker installation.
It had been working for quite some time, and to get the location of my cat, I was relying on calling:
/households/{household_id}/pets/location
Noticing that things had stopped working this morning, I read in the documentation that use of 'location' had been deprecated, and sotried calling:
/pets/{pet_id}/position
This results in error:
{     "detail": "Not Found" }
As does just calling:
 /pets
But calling:
/households/{household_id}/pets/{pet_id}
works, and does give details of my cat, but unfortunately the position field always seems to remain set to 'null'. Redacted output is as follows:
{
    "comments": null,
    "created_at": "2024-05-17T09:04:30Z",
    "gender": 0.0,
    "household_id": XXXXXX.0,
    "id": XXXXXX.0,
    "name": "XXXXXXXX",
    "photo": {
        "created_at": "2024-05-17T09:04:54Z",
        "id": XXXXXXX.0,
        "location": "https://userimages.production.surehub.io/thm/XXXXXXXXXX/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.jpg",
        "updated_at": null,
        "uploading_user_id": XXXXXXXXXX.0,
        "version": 0.0
    },
    "photo_id": XXXXXX.0,
    "position": null,
    "species_id": 1.0,
    "tag_id": XXXXXXX.0,
    "updated_at": "2024-12-04T09:38:03Z",
    "version": 2.0
}

Anybody have any idea what's going on? What's changed?

Hi!
I'm also experiencing this. I guess they deployed something.
Worst part is that the application still works so they're probably using a different API.
I hope they're not discontinuing this API. Sob.

I will have a look at this tomorrow.

After further investigation I suspect that Sure PetCare made a mistake on their end. I have two pets in my household. For one of them i get the correct position payload from their API, while for the other one the position payload is missing entirely. Take a look at the following payload from /households/{household_id}/pets:
[
  {
    "id": "XXXXXX",
    "name": "Leo",
    "gender": 1,
    "date_of_birth": "1970-01-01T00:00:00Z",
    "weight": "4800",
    "comments": "",
    "breed_id": 382,
    "food_type_id": 3,
    "household_id": "XXXXX",
    "photo_id": "XXXXXX",
    "species_id": 1,
    "spayed": 1,
    "tag_id": "XXXXXX",
    "version": 11,
    "created_at": "2020-11-24T10:44:35Z",
    "updated_at": "2024-11-17T19:31:43Z",,
    "conditions": [],
    "tag": {
      "id": "XXXXXX",
      "tag": "XXX.XXXXXXX",
      "supported_product_ids": [
        3,
        4,
        6,
        8,
        32
      ],
      "version": 310,
      "created_at": "2020-11-24T10:44:35Z",
      "updated_at": "2022-11-09T01:57:20Z"
    },
    "status": {
      "activity": {
        "id": "XXXXXXXXX",
        "pet_id": "XXXXXX",
        "tag_id": "XXXXXX",
        "device_id": "XXXXXX",
        "where": 2,
        "since": "2024-12-04T16:39:47Z"
      }
    },
    "position": {
      "id": "XXXXXXXX",
      "pet_id": "XXXXXX",
      "tag_id": "XXXXXX",
      "device_id": "XXXXXX",
      "where": 2,
      "since": "2024-12-04T16:39:47Z"
    }
  },
  {
    "id": "XXXXXX",
    "name": "Sammy",
    "gender": 1,
    "date_of_birth": "1970-01-01T00:00:00Z",
    "weight": "4800",
    "comments": "",
    "breed_id": 382,
    "food_type_id": 3,
    "household_id": "XXXXX",
    "photo_id": "XXXXXX",
    "species_id": 1,
    "spayed": 1,
    "tag_id": "XXXXXX",
    "version": 11,
    "created_at": "2020-11-24T10:48:44Z",
    "updated_at": "2024-11-17T19:30:17Z",
    "conditions": [],
    "tag": {
      "id": "XXXXXX",
      "tag": "XXX.XXXXXXXXX",
      "supported_product_ids": [
        3,
        4,
        6,
        8,
        32
      ],
      "version": 218,
      "created_at": "2020-11-24T10:48:44Z",
      "updated_at": "2022-11-09T06:03:06Z"
    },
    "status": {}
  }
]

Note: IDs where obfuscated for privacy reasons

Notice that "Leo" has a status and position attribute, while "Sammy" has an empty status and no position attribute. Since I am querying the SureHub API directly, there is not additional manipulation involved.
The only thing you can do is to wait until this issue gets fixed by the Sure Petcare developers.
Kind regards
Fabian

Thanks for investigating. How odd and slightly frustrating! I wonder if deleting and re-adding a pet is worthwhile? I might give it a try, if things don't start working in a few days time.
Thanks,
Richard

Same or similiar problem here - getting a "Internal Server Error" on calling requesting a get from "http://x.x.x.x:8080/pets/position"

Same or similiar problem here - getting a "Internal Server Error" on calling requesting a get from "http://x.x.x.x:8080/pets/position"

Thats due to the missing position attribute. I could improve the error handling here, that at least the valid pets are getting returned.

Thats due to the missing position attribute. I could improve the error handling here, that at least the valid pets are getting returned.

Thanks for your answer. Was "position" removed or is it also just a current bug/error by SurePet?

Since the official Sure Petcare App (https://surepetcare.io) also has problems displaying the position (see the screenshot below) I believe it is a temporary problem.

I also improved the error handling for missing pet positions. From now on the API will throw a HTTP 500 status code with a detailed error message, when no pet position is found.

Just to let you know, things have started working for me sometime over the last 24 hours.
Not sure if it's related to me contacting Sure Petcare regarding the issue you mentioned on the https://surepetcare.io/ dashboard, which has also now started working for me.
Anyway, thanks for looking into this.

I can confirm, that for me the API is now behaving as expected again. Maybe they did not realize their API was broken until you messaged them :D

I can confirm that the problem is also solved on my side - my "MagicMirror" display / dashboard is correctly returning my pets location as well as the time, since when they went out or in the house.
Many thanks again for your efforts on this.

authors: ShogunPanda alphatrianguli fabieu rleeden

repo: fabieu/sureflap-api


text:
Mixed styles

Hello, it seems it’s impossible to mix like done todo entry and bold content.

This app is now deprecated, you should use Notable instead, which is a much better note-taking app overall, its zen mode can replace Noty's UI pretty effectively and it is very actively developed.
Notable fixes this problem as well.

authors: Li-An fabiospampinato

repo: fabiospampinato/noty


text:
Fix package tests

Package renamed: https://github.com/FusionAuth/fusionauth-jwt/commit/8a24e6b4cb0c8af3c32a560ebe867064e8152d3d

Note: This does not fix tests/test_feature_hooks.py:76: AssertionError

[test]

@CermakM Your image is available in the registry: docker pull MISSING_REGISTRY_NAME/MISSING_IMAGE_NAME:SNAPSHOT-PR-34

[test]

@CermakM Your image is available in the registry: docker pull MISSING_REGISTRY_NAME/MISSING_IMAGE_NAME:SNAPSHOT-PR-34

authors: CermakM centos-ci tisnik


text:
feat(openshift): Add SOURCE_REPOSITORY_PROVIDER parameter

Fixes #603

Ike Plugins (test-keeper)
Thank you @gastaldi for this contribution!

It appears that no tests have been added or updated in this PR.
Automated tests give us confidence in shipping reliable software. Please add some as part of this change.
If you are an admin or the reviewer of this PR and you are sure that no test is needed then you can use the command /ok-without-tests as a comment to make the status green.
For more information please head over to official documentation. You can find there how to configure the plugin.

authors: alien-ike gastaldi