Wattpilot wird nicht mehr verbunden nachdem die Verbindungen verloren geht

[kad49007]

Describe the bug

Die Verbindung zum Wattpilot wird nicht mehr verbunden nachdem die Verbindungen verloren gegangen ist. Der Verbindung wird erst nach einem Restart von evcc neu aufgebaut.
Passiert relativ schnell, der letzte Neustart war gegen 7:00 Uhr

Steps to reproduce

...

Configuration details

# open evcc at http://evcc.local:7070
network:
  schema: http
  host: evcc.local # .local suffix announces the hostname on MDNS
  port: 7070

log: info
levels:
  cache: error
  mini: debug
  site: debug
  lp-1: trace
  eMini: debug
  charger: debug

# unique installation id
plant: c3e77ab967105b1ccae8945ecccde2e3987556b17683360aa09957f8cdd84b27

interval: 10s # control cycle interval

meters:
- type: template
  template: fronius-solarapi-v1 
  usage: grid  
  host: 192.168.X.67  
  name: grid1
- type: template
  template: fronius-solarapi-v1
  usage: pv
  host: 192.168.X.15
  name: pv
- type: template
  template: fronius-solarapi-v1 
  usage: pv  
  host: 192.168.X.67  
  name: pv2
- type: template
  template: fronius-solarapi-v1 
  usage: battery  
  host: 192.168.X.67  
  name: battery3
  capacity: 19.3
- type:  custom
  name: Heizstab
  power: 
    source: http
    uri: http://192.168.X.67/solar_api/v1/GetOhmPilotRealtimeData.cgi?Scope=Device&DeviceId=0
    method: GET # default HTTP method
    headers:
      - content-type: application/json
    auth:
    insecure: false # set to true to trust self-signed certificates
    jq: .Body.Data.PowerReal_PAC_Sum # parse response json
    timeout: 10s # timeout in golang duration format, see https://golang.org/pkg/time/#ParseDuration
  
  
chargers:
- type: template
  template: fronius-wattpilot 
  host: 192.168.X.101  
  password: XXXX  
  name: wallbox2
- type: template
  template: fronius-wattpilot 
  host: 192.168.X.61  
  password: XXXX  
  name: wallbox1

vehicles:
- type: template
  template: mini 
  title: eMini  
  user: XXXX 
  password: XXXX  
  vin: XXXX 
  capacity: 29  
  phases: 3  
  icon: car  
  cache: 15m  
  mode: PV  
  minSoc: 30  
  targetSoc: 80  
  minCurrent: 6  
  maxCurrent: 16  
  name: emini

loadpoints:
- title: Wattpilot 2
  charger: wallbox2
  vehicle: emini
  mode: pv
  phases: 0
  mincurrent: 6
  maxcurrent: 16
  resetOnDisconnect: false
  soc:
    poll:
      mode: connected
      interval: 15m
    estimate: true
- title: Wattpilot 1
  charger: wallbox1
  mode: off
  phases: 3
  mincurrent: 6
  maxcurrent: 16
  resetOnDisconnect: false

site:
  title: Neufahrn
  meters:
    grid: grid1
    pvs:
    - pv
    - pv2
    batteries:
    - battery3
    aux:
    - Heizstab
  bufferSoc: 80
  prioritySoc: 75
  residualPower: -50

tariffs:
  currency: EUR # (default EUR)
  grid:
    # static grid price
    type: fixed
    price: 0.3652 # [currency]/kWh
   # type: awattar
   # cheap: 0.2 # [currency]/kWh
   # region: de

  feedin:
    # rate for feeding excess (pv) energy to the grid
    type: fixed
    price: 0.0606 # [currency]/kWh
  planner:
    type: grünstromindex
    zip: XXX 


sponsortoken: XXX

Log details

> Apr 21 09:45:40 openhabian evcc[29254]: [lp-1  ] DEBUG 2023/04/21 09:45:40 charge currents: [6.9 0 0]A
Apr 21 09:45:40 openhabian evcc[29254]: [lp-1  ] DEBUG 2023/04/21 09:45:40 detected active phases: 1p
Apr 21 09:45:40 openhabian evcc[29254]: [lp-1  ] DEBUG 2023/04/21 09:45:40 charger status: C
Apr 21 09:45:40 openhabian evcc[29254]: [lp-1  ] DEBUG 2023/04/21 09:45:40 soc estimated: 36.10% (vehicle: 36.00%)
Apr 21 09:45:40 openhabian evcc[29254]: [lp-1  ] DEBUG 2023/04/21 09:45:40 vehicle soc: 36%
Apr 21 09:45:40 openhabian evcc[29254]: [lp-1  ] DEBUG 2023/04/21 09:45:40 vehicle range: 56km
Apr 21 09:45:40 openhabian evcc[29254]: [lp-1  ] DEBUG 2023/04/21 09:45:40 pv charge current: 7.17A = 7A + 0.169A (-39W @ 1p)
Apr 21 09:45:46 openhabian evcc[29254]: bye bye
Apr 21 09:45:46 openhabian evcc[29254]: Reconnect
Apr 21 09:45:46 openhabian evcc[29254]: bye bye
Apr 21 09:45:46 openhabian evcc[29254]: Reconnect
Apr 21 09:45:50 openhabian evcc[29254]: [site  ] DEBUG 2023/04/21 09:45:50 ----
Apr 21 09:45:51 openhabian evcc[29254]: [lp-1  ] ERROR 2023/04/21 09:45:51 charge meter: connection is not valid
Apr 21 09:45:51 openhabian evcc[29254]: [lp-2  ] ERROR 2023/04/21 09:45:51 charge meter: connection is not valid
Apr 21 09:45:51 openhabian evcc[29254]: [site  ] DEBUG 2023/04/21 09:45:51 pv power: 4084W
Apr 21 09:45:51 openhabian evcc[29254]: [site  ] DEBUG 2023/04/21 09:45:51 battery soc: 20%
Apr 21 09:45:51 openhabian evcc[29254]: [site  ] DEBUG 2023/04/21 09:45:51 battery power: -2105W
Apr 21 09:45:51 openhabian evcc[29254]: [site  ] DEBUG 2023/04/21 09:45:51 grid power: -2W
Apr 21 09:45:51 openhabian evcc[29254]: [site  ] DEBUG 2023/04/21 09:45:51 giving priority to battery charging at soc: 20%
Apr 21 09:45:51 openhabian evcc[29254]: [site  ] DEBUG 2023/04/21 09:45:51 aux power 1: 0W
Apr 21 09:45:51 openhabian evcc[29254]: [site  ] DEBUG 2023/04/21 09:45:51 aux power: 0W
Apr 21 09:45:51 openhabian evcc[29254]: [site  ] DEBUG 2023/04/21 09:45:51 site power: -52W
Apr 21 09:45:51 openhabian evcc[29254]: [lp-2  ] ERROR 2023/04/21 09:45:51 charge meter: connection is not valid
Apr 21 09:45:51 openhabian evcc[29254]: [lp-2  ] ERROR 2023/04/21 09:45:51 charge rater: connection is not valid
Apr 21 09:45:51 openhabian evcc[29254]: [lp-2  ] ERROR 2023/04/21 09:45:51 charger: connection is not valid
Apr 21 09:45:51 openhabian evcc[29254]: [site  ] DEBUG 2023/04/21 09:45:51 telemetry: charge: Δ14/14Wh @ 1620W
Apr 21 09:46:00 openhabian evcc[29254]: [site  ] DEBUG 2023/04/21 09:46:00 ----

What type of operating system are you running?

Linux

Version

evcc version 0.116.3

[andig]

@mabunixda

[mabunixda]

Seltsam ist dabei, dass er sich ja Reconnected

Apr 21 09:45:46 openhabian evcc[29254]: Reconnect

eventuell doppelter Reconnect call?

@andig Wie am besten Logging in der Library fuer so einen Zweck reinbekommen, damit man sowas sichtbar machen kann?

[andig]

Du hast doch schon Logging auf die Konsole? Das ist nicht schön aber kommt auch an. Alternative ist ein Logger Interface oder ein Errors() (chan <-error) Api über das man sich auf einen Fehlerkanal subscriben kann.

[kad49007]

Heute Nachmittag war der Fehler verschwunden, aber leider haben meine Einstellungen zur Vergrösserung der Logfiles nicht gefruchtet . Daher habe ich kein Log über den interessanten Zeitraum, es fehlen 2 Stunden. Ich kann also nicht sagen, was das passiert ist.
Bin leider kein Linux-Spezialist, habe in journald.conf die Einstellung SystemMaxUse von 50MB auf 250MB. Ist das die richtige Stelle?

[m-milinovsky]

Genau dieses Verhalten beobachte ich auch sehr häufig: geht die Verbindung zum Wattpilot mal verloren hilft nur mehr ein Neustart von evcc. Alle anderen Methoden (Fahrzeug abstecken, Wattpilot neu starten bzw. vom Strom nehmen etc.) fruchten nicht.

[andig]

Ich verschieb das Thema mal in die Discussions- als evcc Team können wir nichts beitragen.

[m-milinovsky]

eventuell doppelter Reconnect call?

Ich denke kein doppelter Call- es sind ja 2 Wallboxen (sehe ich auch erst jetzt). Bleibt die Frage ob Du da am fehlenden reconnect noch was machen kannst/willst? Sonst würde ich hier zu machen. Danke!

Ich habe nur eine Wallbox, trotzdem ist im Log gelegentlich ein doppelte Reconnect zu lesen:
evcc.log

[andig]

Im Issue oben sind es zwei

[kad49007]

Es ist ein Change in Arbeit der sich dem widmet. Nachdem bei mir aber andere Hardware für Wlan verbaut ist, kann ich das nicht testen ausser den Wattpilot neuzustarten. ich werde aber noch ein anderes logging einarbeiten

Helfe gerne beim Testen!

[m-milinovsky]

Im Issue oben sind es zwei

Ja, korrekt; bei mir ist es eine; wollte nur bei der Fehlersuche helfen ¯\(ツ)/¯ ...

[mabunixda]

pull request #7634 fügt nun ein kontrolliertes reconnect hinzu und zudem logging, dass per evcc-konfiguration auch gesteuert werden kann

[m-milinovsky]

Hier noch ein "kuratiertes" Logfile der letzten drei Tage inkl. Versionswechsel von 0.116.3 auf 0.116.4. Man sieht, dass die Reconnects manchmal gut gehen, meistens aber nicht und zu einem dauerhaften "connection is not valid" Zustand führen. Abgesehen von generellen Problemen mit der Internetanbindung (oder der Netzwerkanbindung des Raspi?) zwischen 00:43 und 03:04 am 25.4. sind aber auch andere Fehler zu sehen:

Apr 26 08:50:44 openhab evcc[1264639]: [site  ] DEBUG 2023/04/26 08:50:44 ----
Apr 26 08:50:44 openhab evcc[1264639]: [lp-1  ] DEBUG 2023/04/26 08:50:44 charge power: 0W
Apr 26 08:50:44 openhab evcc[1264639]: [site  ] DEBUG 2023/04/26 08:50:44 pv power: 2820W
Apr 26 08:50:44 openhab evcc[1264639]: [site  ] DEBUG 2023/04/26 08:50:44 grid power: -1771W
Apr 26 08:50:44 openhab evcc[1264639]: [site  ] DEBUG 2023/04/26 08:50:44 site power: -1771W
Apr 26 08:50:44 openhab evcc[1264639]: [lp-1  ] DEBUG 2023/04/26 08:50:44 charge currents: [0 0 0]A
Apr 26 08:50:44 openhab evcc[1264639]: [lp-1  ] DEBUG 2023/04/26 08:50:44 charger status: B
Apr 26 08:50:44 openhab evcc[1264639]: [lp-1  ] WARN 2023/04/26 08:50:44 charger out of sync: expected enabled, got disabled
Apr 26 08:50:44 openhab evcc[1264639]: [lp-1  ] ERROR 2023/04/26 08:50:44 charger: failed to write msg: WebSocket closed: failed to read frame payload: read tcp 192.168.10.32:34346->192.168.178.12:80: read: connection reset by peer
Apr 26 08:50:44 openhab evcc[1264639]: [lp-1  ] DEBUG 2023/04/26 08:50:44 pv charge current: 7.7A = 0A + 7.7A (-1771W @ 1p)
Apr 26 08:50:44 openhab evcc[1264639]: [lp-1  ] ERROR 2023/04/26 08:50:44 max charge current 7A: failed to write msg: WebSocket closed: failed to read frame payload: read tcp 192.168.10.32:34346->192.168.178.12:80: read: connection reset by peer
Apr 26 08:51:14 openhab evcc[1264639]: [site  ] DEBUG 2023/04/26 08:51:14 ----
Apr 26 08:51:14 openhab evcc[1264639]: [lp-1  ] DEBUG 2023/04/26 08:51:14 charge power: 0W
Apr 26 08:51:14 openhab evcc[1264639]: [site  ] DEBUG 2023/04/26 08:51:14 pv power: 2779W
Apr 26 08:51:14 openhab evcc[1264639]: [site  ] DEBUG 2023/04/26 08:51:14 grid power: -1715W
Apr 26 08:51:14 openhab evcc[1264639]: [site  ] DEBUG 2023/04/26 08:51:14 site power: -1715W
Apr 26 08:51:14 openhab evcc[1264639]: [lp-1  ] DEBUG 2023/04/26 08:51:14 charge currents: [0 0 0]A
Apr 26 08:51:14 openhab evcc[1264639]: [lp-1  ] DEBUG 2023/04/26 08:51:14 charger status: B
Apr 26 08:51:14 openhab evcc[1264639]: [lp-1  ] WARN 2023/04/26 08:51:14 charger out of sync: expected enabled, got disabled
Apr 26 08:51:14 openhab evcc[1264639]: [lp-1  ] ERROR 2023/04/26 08:51:14 charger: failed to write msg: failed to acquire lock: context canceled
Apr 26 08:51:14 openhab evcc[1264639]: [lp-1  ] DEBUG 2023/04/26 08:51:14 pv charge current: 7.45A = 0A + 7.45A (-1715W @ 1p)
Apr 26 08:51:14 openhab evcc[1264639]: [lp-1  ] ERROR 2023/04/26 08:51:14 max charge current 7A: failed to write msg: failed to acquire lock: context canceled

Nachfolgend die derzeit verwendete Config:

[main  ] INFO 2023/04/26 10:42:12 evcc 0.116.4
[main  ] INFO 2023/04/26 10:42:12 using config file: /etc/evcc.yaml
[db    ] INFO 2023/04/26 10:42:22 using sqlite database: /home/martin/.evcc/evcc.db

Konfiguration (/etc/evcc.yaml):

# open evcc at http://evcc.local:7070
network:
  schema: http
  host: evcc.local # .local suffix announces the hostname on MDNS
  port: 7070

log: debug
levels:
  site: debug
  lp-1: debug
  fiat: debug
  cache: debug
  charger: debug
  meter: debug
  vehicle: debug

# unique installation id
plant: *****

#interval: 10s # control cycle interval
interval: 30s # control cycle interval

meters:
  - name: pv1
    type: template
    template: fronius-solarapi-v1
    usage: pv
    host: 192.168.178.8
  - name: my_grid
    type: template
    template: fronius-solarapi-v1
    usage: grid
    host: 192.168.178.8

chargers:
  - type: template
    template: fronius-wattpilot
    host: 192.168.178.12
    password: *****
    name: wallbox3

vehicles:
  - name: fiat500e
    type: template
    template: fiat
    title: Fiat 500e
    user: *****
    password: *****
    capacity: 42
    mode: pv
    targetSoc: 90

tariffs:
  currency: EUR # (default EUR)
  grid:
#    type: awattar
#    region: at # optional, choose at for Austria
    type: fixed
    price: 0.44
  feedin:
    type: fixed
    price: 0.11

loadpoints:
  - title: Wallbox links
    charger: wallbox3
    mode: pv
    phases: 0
    mincurrent: 6
    maxcurrent: 16
    resetOnDisconnect: true
    vehicle: fiat500e # Referenz auf Standardfahrzeug

site:
  - title: MiliHome
    meters:
      grid: my_grid
      pv:
      - pv1

# push messages
#messaging:
#  events:
#    start: # charge start event
#      title: Charge started
#      msg: Started charging ${vehicleTitle} in "${mode}" mode
#    stop: # charge stop event
#      title: Charge finished
#      msg: Finished charging ${vehicleTitle} ${chargedEnergy:%.1fk}kWh in ${chargeDuration}.
#    connect: # vehicle connect event
#      title: Car connected
#      msg: "Car ${vehicleTitle} connected at ${pvPower:%.1fk}kW PV"
#    disconnect: # vehicle connected event
#      title: Car ${vehicleTitle} disconnected
#      msg: Car disconnected after ${connectedDuration}
#    soc: # vehicle soc update event
#      title: Soc updated
#      msg: Battery of ${vehicleTitle} charged to ${vehicleSoc:%.0f}%
#    guest: # vehicle could not be identified
#      title: Unknown vehicle
#      msg: Unknown vehicle, guest connected?
#  services:
#   - type: ntfy
#     uri: https://ntfy.sh/mili_load_info
#     priority: low
#     tags: fiat500

sponsortoken: *****

Version: `0.116.4`

Was kann ich noch zur Fehlersuche beitragen?

Hier das Logfile:
syslog_evcc.txt

[m-milinovsky]

Anbei erneut ein Logfile von den Fehlern, erstellt mit der Version 0.116.5 und folgenden Loglevels:

log: debug
levels:
  site: trace
  lp-1: trace
  fiat: trace
  cache: debug
  charger: trace
  meter: trace
  vehicle: trace

Falls ich die Loglevels anders einstellen soll, bitte um Info.

syslog_evcc_trace.txt

[mabunixda]

Die Verbindung wird hier abgebrochen während die Verbindung neu aufgebaut wird, weil der Status noch nicht komplett übertragen wurde ... spannend

[micw]

Ich habe hier ähnliche Probleme. Aufgrund von Umbauarbeiten haben wir gerade die Waschmaschine an der gleichen Leitung wie die Autos, so dass manchmal die Sicherung kommt. EVCC denkt dann dauerhaft, dass das Auto noch lädt, auch wenn die Sicherung wieder drin und die Wallbox erreichbar ist.
Wird noch Info zum Debuggen benötigt?

[mabunixda]

Aber was hat evcc gemeldet in dem Sinne vom wattpilot? Hat er sich neu verbunden und dann wieder Daten gemeldet/gelesen?

[kad49007]

Bei mir kommt den in dem Fall immer die Meldung "charge meter: connection is not valid". Habe jetzt versucht es mit den richtigen Logeinstellungen zu reproduzieren. Leider sehe ich mit lp-1 bzw. charger auf trace noch nicht mehr. Soll ich noch andere Logs einschalten (Bin auf 0.116.7)?
Beim Testen habe ich auch noch eine interessante Beobachtung gemacht, obwohl die WLAN-Verbindung definitiv weg war (Mesh-Repeater dazwischen war aus), hat evcc über mehrere Minuten nicht erkannt und versucht den Loadpoint weiter zu steuern. Siehe das angehängte Log zwischen 13:09:30 und 13:19:55. Erst als die Verbindung wieder da war, hat evcc bemerkt, dass da was nicht stimmt (charger out of sync: expected disabled, got enabled):
evcc_lost_conn1.log
Vielleicht hilft das ja, dem Problem auf die Spur zu kommen?

[micw]

selbe Meldung bei mir hier, eben wieder.

[micw]

Update: hatte da noch eine ältere Version laufen, ich beobachte mal weiter mit der aktuellen (1.117.2)

[m-milinovsky]

Hallo,
nach mehreren Wochen Tests ist mein Resumee, dass für mich evcc mit der Fronius Wattpilot Wallbox (momentan) nicht verwendbar ist. Ja, ich weiß, dass wir momentan bei Version 0.116.7 stehen, also noch weit vor einer Version 1.0 und ich bewundere, was für ein tolles Produkt evcc trotzdem schon ist! Aber für den täglichen Betrieb mit der Aufgabe das Fahrzeug bis zu 80 oder 90 % zu laden und das möglichst ausschließlich mit PV-Strom ist die Kombination evcc - Wattpilot für mich nicht zu benutzen: gerade bei wechselnden Stromlieferungen der PV und somit notwendigem Wechseln der Ladeleistung und Wechseln zwischen 1- und 3-phasig dauert es keine hable Stunde, bis regelmäßig "charge meter: connection is not valid" oder andere Fehler bei der Kommunikation mit der Wallbox auftreten und somit das PV-gesteuerte Laden unmöglich ist. Falls ich noch etwas zur Fehlersuche beitragen kann, lasst es mich bitte wissen, ich helfe gerne weiterhin mit; ansonsten bin ich hier mal raus und verwende sehr schweren Herzens wieder die unselige Hersteller App Solar.wattpilot :-(

Da die Probleme - so wie ich das einschätze - zu einem Großteil auf der Seite des Fronius Wattpilot und der Verbindug zu diesem zu suchen sind, überlege ich ernsthaft eine andere Wallbox zu kaufen (wir haben einen zweiten Anschluss an einer anderen Stelle im Haus vorgesehen). Es gibt in Discussions schon eine Diskussion über die "optimale" Wallbox in Verbindung mit evcc ( #7172 ), der werde ich mich anschließen, für Empfehlungen bin ich dankbar:

• Ladestrom regelbar
• Phasenumschaltung möglich
• Anschluss per LAN
• möglichst "offen", Open Source?
• wenn möglich deutsches oder österr. Produkt
• unabhängig von einer Hersteller-Cloud zu betreiben
• kein Go-E Charger, da der meines Wissens technisch die gleiche Basis wie der Wattpilot hat und ich befürchte da vom "Regen in die Traufe" zu kommen
• arbeitet problemlos mit evcc zusammen :-)

[wiggal]

kann man auf 100% stellen, gehe davon aus, dass dies bereits so eingestellt ist

[m-milinovsky]

kann man auf 100% stellen, gehe davon aus, dass dies bereits so eingestellt ist

Ja.

[wiggal]

es gibt so wetterfeste Boxen in die man die Fritzbox einschließen kann, damit hat ein Kumpel von mir ne Fritzbox im Garten positioniert. Eine Fritzbox 4040 gibts schon ab 75€ 😉

[m-milinovsky]

Könnte man versuchen: die würde dann aber quasi im Freien hängen und sollte auch im Winter bei minus 20 Grad funktionieren! Finde dazu leider nix in den technischen Daten bei AVM.

[wiggal]

oder sowas
https://www.reichelt.de/wlan-access-point-2-4-ghz-300-mbit-s-outdoor-tplink-cpe210-p150844.html?&nbc=1&SID=95acdbfd002d56824cc92cc68fa15729c12a7a03d4c65a41619b1&LANGUAGE=de&trstct=magaz_artlink
geht angeblich von Minus 30 bis plus 70 Grad.
Wird halt nicht im Mesh der Fritzbox zu integrieren sein.

[micw]

Leider scheint das Problem weiterhin mit Version 0.117 zu bestehen:

Nach Neustart von EVCC (Über Hilfe -> Neu starten)

[micw]

Das Problem ist 20 Minuten nach dem Neustart wieder aufgetreten, obwohl der Wattpilot zwischenzeitlich nicht aus war.

Beim zweiten Wattpilot scheint dieses Problem nicht aufzutreten

[micw]

Im Debug-Log steht alle paar Sekunden:

[site  ] DEBUG 2023/05/14 11:41:45 ----
[lp-1  ] DEBUG 2023/05/14 11:41:45 charge power: 0W
[lp-2  ] ERROR 2023/05/14 11:41:45 charge meter: connection is not valid
[site  ] DEBUG 2023/05/14 11:41:45 pv power: 362W
[site  ] DEBUG 2023/05/14 11:41:45 grid power: 10483W
[site  ] DEBUG 2023/05/14 11:41:45 site power: 10483W
[lp-1  ] DEBUG 2023/05/14 11:41:45 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/05/14 11:41:45 charger status: A
[site  ] DEBUG 2023/05/14 11:41:55 ----
[lp-1  ] DEBUG 2023/05/14 11:41:55 charge power: 0W
[lp-2  ] ERROR 2023/05/14 11:41:55 charge meter: connection is not valid
[site  ] DEBUG 2023/05/14 11:41:55 pv power: 360W
[site  ] DEBUG 2023/05/14 11:41:55 grid power: 11604W
[site  ] DEBUG 2023/05/14 11:41:55 site power: 11604W
[lp-2  ] ERROR 2023/05/14 11:41:55 charge meter: connection is not valid
[lp-2  ] ERROR 2023/05/14 11:41:55 charge rater: connection is not valid
[lp-2  ] ERROR 2023/05/14 11:41:55 charger: connection is not valid
[site  ] DEBUG 2023/05/14 11:42:05 ----

Das Laden hat trotzdem pünktlich begonnen, in der UI schaut es so aus:

Mir ist gerade nicht klar, ob ich hier aktuelle Daten sehe oder nur den letzten Stand, bevor die Verbindung weg war. Einen Reconnect, wie der Merge von #7634 suggeriert, kann ich nicht sehen.

@mabunixda Benötigst Du noch weitere Infos zum Debuggen? Ich kann das hier lokal zu 100% reproduzieren, indem ich den Wattpilot kurz vom Strom trenne (passiert hier aktuell 3x die Woche, sobald Auto lädt und Waschmaschine wäscht, da beides temporär an der 16A Außensicherung hängt).

[mabunixda]

Ja die Logmeldung sind per Default auf Warning nur. Du kannst eine Umgegungsvariable WATTPILOT_LOG setzen und da den Wert auf Debug zb setzen. Dann kommt lehr Info zur Wattpilot Kommunikation

du hast aber auch ein sehr spezielles Setup 🫣🤔

[micw]

Was genau ist da speziell?

[micw]

@mabunixda Leider nichts verwertbares im Debug-Log:

{"level":"debug","msg":"Get Property alw","time":"2023-05-14T21:18:02+02:00","wattpilot":"192.168.1.164"}
{"level":"debug","msg":"Get Property power","time":"2023-05-14T21:18:11+02:00","wattpilot":"192.168.1.164"}
{"level":"debug","msg":"Get Property power","time":"2023-05-14T21:18:11+02:00","wattpilot":"192.168.1.165"}
{"level":"debug","msg":"Get Property power","time":"2023-05-14T21:18:11+02:00","wattpilot":"192.168.1.165"}
{"level":"debug","msg":"Get Property power","time":"2023-05-14T21:18:12+02:00","wattpilot":"192.168.1.165"}
[lp-2  ] ERROR 2023/05/14 21:18:12 charge meter: connection is not valid
[site  ] ERROR 2023/05/14 21:18:12 pv 1 power: solar/116182009632/0/power outdated: 11m45s
[site  ] ERROR 2023/05/14 21:18:12 pv 2 power: solar/114183090265/0/power outdated: 17m35s
[lp-2  ] ERROR 2023/05/14 21:18:12 charge meter: connection is not valid
{"level":"debug","msg":"Get Property amps1","time":"2023-05-14T21:18:12+02:00","wattpilot":"192.168.1.165"}
{"level":"debug","msg":"Get Property wh","time":"2023-05-14T21:18:12+02:00","wattpilot":"192.168.1.165"}
{"level":"debug","msg":"Get Property car","time":"2023-05-14T21:18:12+02:00","wattpilot":"192.168.1.165"}
[lp-2  ] ERROR 2023/05/14 21:18:12 charge rater: connection is not valid
[lp-2  ] ERROR 2023/05/14 21:18:12 charger: connection is not valid
{"level":"debug","msg":"Get Property power","time":"2023-05-14T21:18:21+02:00","wattpilot":"192.168.1.164"}
{"level":"debug","msg":"Get Property power","time":"2023-05-14T21:18:21+02:00","wattpilot":"192.168.1.165"}
{"level":"debug","msg":"Get Property power","time":"2023-05-14T21:18:21+02:00","wattpilot":"192.168.1.165"}
{"level":"debug","msg":"Get Property power","time":"2023-05-14T21:18:22+02:00","wattpilot":"192.168.1.165"}
[lp-2  ] ERROR 2023/05/14 21:18:22 charge meter: connection is not valid
[site  ] ERROR 2023/05/14 21:18:22 pv 1 power: solar/116182009632/0/power outdated: 11m55s
[site  ] ERROR 2023/05/14 21:18:22 pv 2 power: solar/114183090265/0/power outdated: 17m45s
{"level":"debug","msg":"Get Property amps1","time":"2023-05-14T21:18:22+02:00","wattpilot":"192.168.1.164"}
{"level":"debug","msg":"Get Property amps2","time":"2023-05-14T21:18:22+02:00","wattpilot":"192.168.1.164"}
{"level":"debug","msg":"Get Property amps3","time":"2023-05-14T21:18:22+02:00","wattpilot":"192.168.1.164"}
{"level":"debug","msg":"Get Property wh","time":"2023-05-14T21:18:22+02:00","wattpilot":"192.168.1.164"}
{"level":"debug","msg":"Get Property car","time":"2023-05-14T21:18:22+02:00","wattpilot":"192.168.1.164"}
{"level":"debug","msg":"Get Property alw","time":"2023-05-14T21:18:22+02:00","wattpilot":"192.168.1.164"}
{"level":"debug","msg":"Get Property power","time":"2023-05-14T21:18:31+02:00","wattpilot":"192.168.1.164"}
{"level":"debug","msg":"Get Property power","time":"2023-05-14T21:18:31+02:00","wattpilot":"192.168.1.165"}
{"level":"debug","msg":"Get Property power","time":"2023-05-14T21:18:31+02:00","wattpilot":"192.168.1.165"}
[lp-2  ] ERROR 2023/05/14 21:18:32 charge meter: connection is not valid
{"level":"debug","msg":"Get Property power","time":"2023-05-14T21:18:32+02:00","wattpilot":"192.168.1.165"}
[site  ] ERROR 2023/05/14 21:18:32 pv 1 power: solar/116182009632/0/power outdated: 12m4s
[site  ] ERROR 2023/05/14 21:18:32 pv 2 power: solar/114183090265/0/power outdated: 17m55s
[lp-2  ] ERROR 2023/05/14 21:18:32 charge meter: connection is not valid
[lp-2  ] ERROR 2023/05/14 21:18:32 charge rater: connection is not valid
{"level":"debug","msg":"Get Property amps1","time":"2023-05-14T21:18:32+02:00","wattpilot":"192.168.1.165"}
{"level":"debug","msg":"Get Property wh","time":"2023-05-14T21:18:32+02:00","wattpilot":"192.168.1.165"}
{"level":"debug","msg":"Get Property car","time":"2023-05-14T21:18:32+02:00","wattpilot":"192.168.1.165"}

[m-milinovsky]

Ich habe jetzt seit rund einer Woche einen Outdoor Access Point in 2m Entfernung vom Wattpilot positioniert und seitdem tritt das Verbindungsproblem deutlich seltener auf: zweimal in den letzten sieben Tagen anstatt zig-mal pro Tag. Nichts desto trotz verliert der Wattpilot trotz 100% WLAN Empfang lt. der Wattpilot App öfter mal die Internet Anbindung!

[wiggal]

Hast du schon mal nachgesehen ob nicht ein WLAN aus der Nachbarschaft stören könnte?
Es gibt dazu verschiedene Apps, bei den man das schön sieht
In der Wattpilotapp siehst im Menü Internet die Qualität des WLAN, was hast du da?
Da sind auch alle erreichbaren WLANs aufgeführt, da kannst du auch die Qualität nachsehen, über das "i" Symbol

[premultiply]

WLAN ist NIE störungsfrei. Schon aus Prinzip nicht. Es verwndet Funkkanäle in denen zahlreiche andere Dienste beliebig funken und zudem durch ständige Neustarts von Routern und sonstigen APs durch Updates, diversen Firmwarebugs, automatische Kanalwechsel, sonstigen Störungen, Fehlkonfigurationen, Mehrfachbelegung, selbststörenden Repeatern, regulatorischen Vorgaben und sich stets verändernden Wetterbedingungen usw. eigentlich nie von einer störungsfreien Datenübertragung zu reden ist.

Eigentlich ist das mehr ein Wunder der Technik dass es für den unbedarften Anwender meist so aussieht als ob da manchmal was funktionieren würde.

[m-milinovsky]

Ja, @premultiply, das ist mir bewusst. Umso unverständlicher, ja geradezu absurd finde ich die Entscheidung der meisten Wallbox Hersteller, keinen LAN Anschluss zu verbauen! Eine (Strom-) Leitung muss ich ja sowieso zur Wallbox legen, der Aufwand auch ein LAN-Kabel mit zu verlegen ist also vernachlässigbar. Die zusätzlichen Kosten auf Wallbox Seite für den LAN-Port können bei Preisen von mehreren hundert Euro für eine Wallbox nicht ins Gewicht fallen.

[elha]

Servus zusammen,
bei mir tritt der identische Fehler regelmäßig nach einigen Tagen auf.
Nach einigen Tests:
Es hilft nur evcc-Restart um das Problem zu beheben.
(Ubuntu auf i5 NUC, 2x Wattpilot)

Abhilfe: cron script

harald@b3:~$ cat /etc/cron.hourly/evcc_disconnect
#!/bin/sh

# restart evcc if connection to wattpilot is lost
if service evcc status | grep -E "charge(r|r status| power| currents| rater): connection is not valid"; then
    sudo service evcc stop
    sleep 60
    sudo service evcc start
fi

(update 14.05.2024: nach update auf 0.126 hat sich die Fehlermeldung geändert)

VG, Harry

[m-milinovsky]

Danke für den Tip; ich bin inzwischen auf eine Tinkerforge Warp2 mit LAN Anschluß umgestiegen.

[mabunixda]

Diese Verbindungsprobleme fielen mir nun mit der letzten Firmware Version von Wattpilot auch vermehrt auf.
Ich werde mir das ansehen...

[otti175]

Gibt es Hier schon eine Fehlerbehebung mit kleiner Anleitung??
Ich bin Blutiger Anfänger was das Programmieren angeht.

[mabunixda]

Noch nicht - das bin ich noch schuldig ... Das Thema ist aktuell ein wenig eingeschlafen bei mir.
Ich werde mir das aber anschauen

[otti175]

In der App vom Wattpilot steht dass er keine Verbindung zum Wechselrichter hat. In EVCC ist er aber angemeldet und kommuniziert.
Die Frage die sich mir jetzt stellt muss ich den Wattpilot noch anders konfigurieren? Bekomme ich überhaupt eine Verbindung zu meinem Kostal Plenticore Plus hin?
Vielleicht hat hier ja jemand erfahrungen...

Vielen Dank schonmal!

[premultiply]

Wozu sollte die Box eine Verbindung zum WR benötigen?
evcc kommuniziert mit der Box zur Steuerung und evcc kommuniziert mit dem WR für die Meteringdaten.

[mabunixda]

Wattpilot kann nur mit Fronius Wechselrichtern direkt reden. Aber wie @premultiply auch schon sagt - evcc steuert das Laden und diese Verbindung ist gar nicht nötig

[otti175]

Okay, danke für die schnelle Antwort... !

[micw]

Das Problem tritt bei mir in letzter Zeit wieder gehäuft auf, keine Ahnung wieso :-(

@mabunixda, hättest Du die Möglichkeit, da einen Reconnect einzubauen? Vielen Dank!

[mabunixda]

Also bei mir lokal funktioniert die Version nun einwandfrei. Egal ob ich den Wattpilot neustarte, im WLAN blockiere, den AP Neustarte oder Wattpilot ein Reconnect auslöse, bis dato kam immer die Verbindung sauber wieder.

[elha]

Vielen Dank für eure Problemlösung!
Bei mir ist ebenfalls alles sehr stabil bisher.

[kad49007]

Leider gab es bei mir heute Nacht wieder ein Problem und ich musste evcc neu starten. Sieht noch nach einem Deadlock-Problem aus, wenn während der Initialisierung der Receive-Handler gestoppt wird. Das sollte aber nur bei sehr langsamen und schlechten Verbindungen passieren. Bei mir passiert das sobald sich der Wattpilot mit dem falschen WLAN-Repeater verbindet. Vermutlich würde sich bei mir die Situation verbessern, wenn ich ein dediziertes WLAN für die Wattpilots ohne Mesh machen würde. Aber dann ist das auch kein Chaos Engineering mehr ;-)

[andig]

Es sollte möglich sein, deadlock-freien Code zu schreiben. Pprof bietet das Werkzeug die Ursache von Deadlocks zu erkennen.

[kad49007]

Da gebe ich Dir vollkommen recht. Nur sind diese nicht immer so leicht zu finden, wenn sie selten auftreten. Für pprof müsste ich erst mal go auf meinem raspberry installieren, da ich meinen Rechner mit der Entwicklungsumgebung nicht tagelang durchlaufen lassen kann. Daher versuche ich mal den Deadlock in der Entwicklungsumgebung zu reproduzieren und dann mit pprof zu analysieren.

[kad49007]

Mit Chaos Engineering hab ich es ja reproduziert 😉
Die Version mit den Sleeps dient nur dazu, dass ich mir die Restarts des Repeaters spare…

[micw]

Moin @mabunixda,
weißt du schon, wann der Patch ins offizielle EVCC übernommen wird? Ich bin hier gerade auf der neuesten Nightly, weil sonst die Akku-Abfrage von Skoda nicht mehr geht, daher kann ich nicht auf Deinen Branch für den Fix gehen.

[mabunixda]

Der letzte PR wurde schon in master gemerged #13912

[micw]

Danke für die Info. Hatte heute früh wieder einen disconnect mit der nightly von gestern..

[mabunixda]

Ja das ist auch meine Testversion - die hat einen ganz anderen Zustand momentan..

[micw]

Ich meinte mit der "offiziellen" evcc nightly.