Closed BlackandGold1 closed 1 year ago
Das Verhalten ist bei mir nicht nachvollziehbar.
Ich weiß nicht was ich machen soll. Seit heute kann ich nicht länger als 10 Minuten laden dann springt currlim einfach auf "null". Sicherung aus hilft dann nur currlim wieder auf 160 das geht dann 10 Minuten und dann stürzt wieder alles ab.
Schreib mir bitte mal an wbec393@gmail.com
(Steff393 war schneller) Ich kenne diese Probleme nicht. Läuft denn die WB ohne das wbec Modul? Mein erster Schritt wäre dann hier die Wallbox auf "stand-alone" konfigurieren und nur die WB mit den internen Einstellungen durch die Wählschalter und ohne Kommunikation zu wbec zum Laden verwenden. Steigt die dann auch wieder aus, ist mit der WB etwas "faul". Hast du sowas schon probiert?
Nachtrag zu eben: ich habe meiner WB einen "Notfall-Strom" konfiguriert (currFS). Selbst wenn ich die Verbindung zum wbec Modul komplett unterbreche ohne etwas an der Konfig der WB zu ändern lädt die ohne irgendwelche Probleme. Hab's eben schnell ausprobiert: wbec von WB getrennt, EV an WB angeschlossen, lädt mit currFS eingestelltem Strom.
ja habe ich die letzten Tage getestet. Ohne WB und alle Pins auf orginal läuft alles super. Hab die WB jetzt wieder dran und probiere grad die Einträge in der cfg.json auf das minimum zu reduzieren.
mein cfg. sieht grad so aus: {"cfgApSsid":"wbec","cfgApPass":"wbec1234","cfgCntWb":1,"cfgMbCycleTime":3,"cfgMbDelay":100,"cfgMbTimeout":60000,"cfgStandby":0,"cfgMqttIp":"","cfgMqttLp":[]}
ist die soweit korrekt? hab jetzt alle PV Einträge entfernt kann sein das da der Fehler lag.
bei mir sieht's so aus: {"cfgApSsid":"wbec","cfgApPass":"cebw1234","cfgCntWb":1,"cfgMqttIp":"192.168.xxx.xxx","cfgMqttLp":[],"cfgMqttSm":[1],"cfgMqttPv":[1,2]} Bitte ignoriere die beiden letzten Parameter cfgMqttSm und cfgMqttPv; die gibt es nur bei mir in der Form! Haben nichts mit der WB zu tun. Einstellungen für die MBCycleTime oder den delay habe ich nicht gemacht. (aber laß mich mal im code nachsehen)
Edit: CycleTime und Delay sind die default Werte aus dem code. Warum setzt du die da überhaupt?
Man kann alle Einträge aus dem cfg.json entfernen, die identisch zum Default-Wert sind, also z.B. cfgApSsid, cfgCntWb, cfgMbDelay, cfgMbTimeout, cfgMqttIp, cfgMqttLp
Ich würde aber einfach mal den Standby deaktivieren... --> cfgStandby rauslöschen
@hawa-lc4 Diese Werte waren so schon immer. Habe da nie dran rumgespielt.
@steff393 lösche jetzt mal die Standbye. Aktuell stürtzt alles alle 4 Minuten ab.
Korrektur zu meiner letzten Aussage: der Standardwert für die cfgMbCycleTime ist laut wbec master branch 10 und nicht 3! Vielleicht liegt's daran?
@hawa-lc4 :( Asche auf mein Haupt.. Ich weiß nicht mal was der Wert bedeutet.
"alles stürzt ab" ist eine sehr verallgemeinerte Fehlerbeschreibung. cfgMbCycleTime=3s war früher mal der Default-Wert. Für eine einzelne Box geht das auch. Ich hab's später nur auf 10s erhöht um mehr Spielraum bei mehreren Wallboxen zu haben.
cfgMbCycleTime ist das Intervall in dem der Modbus abgefragt wird.
@steff393 "alles stürzt ab" = das weiß/blaue blinken und alle Werte auf "null" also WB nicht erreichbar und neustart erforderlich.
@hawa-lc4 alles klar danke
Schick mir bitte mal die Ausgabe von /json an wbec393@gmail.com (am besten vom Anfang, wenn die Werte noch nicht auf 0 sind).
@BlackandGold1 wie sind denn die blink-codes? Im Handbuch gibt es da 2 Seiten mit Beschreibung wie oft und wie schnell das teil weiß oder blau blinkt. Gibt das einen Hinweis?
@steff393 hab ich dir geschickt weiß aber nicht ob du die siehst.
@hawa-lc4 6*weiß schnell und drei mal blau
laut Anleitung: Sechsmaliges Blinken weiß, Pause, dreimaliges Blin‐ ken blau (90 % an, 10 % aus), Pause Mögliche Störungsursache: Über- oder Unterspan‐ nung der Versorgungsspannung. Beim Betrieb mit einem Lastmanagement bedeutet diese Blinksequenz, dass ein Kommunikationsfehler zwischen externer Steuerung/Master-Wallbox und der entsprechenden Slave-Wallbox besteht. ● Sie müssen nicht eingreifen. Nach einem Selbsttest und behobener Störung leuch‐ tet die Frontbeleuchtung weiß. Das Fahrzeug kann den Ladevorgang anfordern.
habe grad neu gestartet und sehe in der Json Ausgabe "remLock":1 das war doch auch so ein Wert der niemals eingestellt werden sollte oder?
{"wbec":{"version":"v0.4.7","bldDate":"Feb 11 2023 16:02:46","timeNow":"01:22:29"},"box":[{"busId":1,"version":"108","chgStat":7,"currL1":156,"currL2":0,"currL3":0,"pcbTemp":187,"voltL1":239,"voltL2":243,"voltL3":240,"extLock":1,"power":3743,"energyP":0.652,"energyI":945.501,"energyC":0.652,"currMax":16,"currMin":6,"logStr":"00.779.2909/01 2115 005142","wdTmOut":60000,"standby":4,"remLock":1,"currLim":160,"currFs":0,"lmReq":160,"lmLim":255,"resCode":"0"}],"modbus":{"state":{"lastTm":1348992,"millis":1349153}},"rfid":{"enabled":false,"release":false,"lastId":""},"pv":{"mode":0,"watt":0},"wifi":{"mac":"xx:xx:xx:xx:xx","rssi":-75,"signal":50,"channel":13}}
aktuell läuft alles seit 20 Minuten
"remLock":1 bedeutet unlocked. ModBus-Register-Tabelle.pdf
@hawa-lc4 Danke für die Liste
was bedeutet eigentlich diese watchdog??
@BlackandGold1 du meinst den Wert im Register 257 (Modbus-Master Watchdog Timeout)? Kann ich dir nicht genau sagen, dieser Wert entspricht dem wbec Parameter cfgMbTimeout und wird auf 60.000 (60 sec.) gesetzt aber von der wbec Software nicht weiter verarbeitet. Es bleibt offen ob dieser von einer Master- oder Slave-WB ausgewertet wird, auch was der Ablauf der Zeit konkret für Reaktionen hervorruft (oder sollte) kann ich nicht sagen. Darüber habe ich (noch) keine Dokumentationen von Heidelberg gefunden.
okay also einfach in Ruhe lassen.. Also bis jetzt läuft alles, Auto lädt wie es soll. Ich lass dann einfach jetzt alles wie es ist. Dieses grafische Wbec hab ich ja nicht und wenn ich im Wiki so nachlese verstehe ich nur die hälfte. Bleibe einfach bei Iobroker und stelle nur den currlim Wert ein um das laden zu starten oder zu beenden.
Update: Auto hat gestern bis 19 Uhr geladen. Hab es dann abgesteckt und den Wert currlim auf 160 gelassen. Heute um 15 uhr ist sie dann wieder in ihren Lieblings Blinkmodus gegangen WB nicht erreichtbar. Sicherung also wieder aus und ein das ganze zwei mal da beim ersten mal gleich wieder das blinken erschien. Aktuell ist das Auto(Ladeplanung im Auto aktiviert) angeschlossen und lädt nicht da ich erst heut Nacht laden will. Im Moment springt der Status der Wallbox in unregelmäßigen von 5 auf 0 und dann wieder auf 5.
Jetzt wird's schwierig; ich fasse mal zusammen, korrigiere mich bitte wenn ich falsch liege.
Hast du zusätzlich ein dem wbec Modul übergeordnetes Energiemanagement System? Ich benutze openWB und steuere die WB darüber, wbec ist nur ein "Kopplungsglied". Das GUI oder die HTTP Kommandos von wbec sind für mich nur ein Notanker wenn openWB nicht laufen sollte. Wenn ich mich recht entsinne steuerst du die WB ober die HTTP Kommandos von wbec, oder verwechsle ich jetzt da etwas? Alles in allem sollte das aber keinen Einfluß auf die Kommunikation zwischen wbec und der WB über RS485 Schnittstelle haben. Hast du die Ausgaben am seriellen Ausgang mitgelesen? Meldet der dort einen "Comm-Failure" oder einen "Timeout"??
@steff393 bitte schau mal in die mbComm.cpp Zeile 161 der 0.4.7: dort steht "msgCnt > 6 ..." in der 0.4.5 (meine Version!) steht da noch "msgCnt > 7 ..." (Zeile 160); die zugrunde liegende Tabelle dazu hat sich aber nur nach hinten erweitert. Damit wird der Parameter REG_WD_TIME_OUT nicht mehr regelmäßig an die WB gesendet; ist nur so eine Idee.
@hawa-lc4 die WB ganz alleine funktioniert problemlos Ja
die Parameter von wbec die WB betreffend sind auf's wesentliche reduziert und/oder auf Standardwerte gestellt ja
der json Parameter "standby":4 bedeutet das in der WB standby deaktiviert ist und sie sich nicht von alleine ausschalten sollte; tut sie vermutlich auch nicht, oder doch? das weiß ich nicht, weiß auch nicht woran ich das merken soll.
wenn ich mir deine json Datei ansehe kommt mir etwas komisch vor: alle 3 Phasen haben normale Spannung, aber das EV lädt nur auf der Phase L1 mit ca. 16A. Ist das bei deinem Auto normal so? Ist ein Kia Sorento Plugin Hybrid der kann mur einphasig laden. Leider hat der Elektriker einen Sicherungsautomaten verbaut der nur alle drei Phasen gleichzeitig Ein/Ausschalten kann. Hab noch nicht geschafft diesen Stift zu entfernen.
Hast du zusätzlich ein dem wbec Modul übergeordnetes Energiemanagement System? Nein
Ja ich sende nur diesen Befehl"http://xx.xx.xx.xx/json?currLim=160" zum einschalten und diesen"http://xx.xx.xx.xx/json?currLim=0" zum ausschalten
Zum Thema
Wie ich schon sagte, jetzt wird's langsam schwierig mit der Fehlersuche. Was mir als erstes noch einfällt ist die Verkabelung des RS485 Bus. Ich gehe davon aus das du ein geschirmtes Kabel verwendet hast; ein CAT.6 Kabel muß es nicht unbedingt sein aber ein einfacher Klingeldraht ist womöglich ungeeignet. Und bitte auch den Schirm in der WB an der vorgesehenen Stelle auflegen damit der geerdet ist. Frage an der Stelle: da die Installation von einem Elektriker gemacht wurde gehe ich davon aus das der die WB ordentlich geerdet hat (N und PE getrennte Leiter); oder ist bei deiner Hausinstallation noch die klassische Nullung verbaut?
Anderer Punkt: Elektronik und Mikrocontroller; wie weit kennst du dich damit aus? Bei mir wäre jetzt der Punkt gekommen das ich an die serielle Schnittstelle des ESP8266 einen PC/Laptop angeschlossen hätte und mal mitlesen würde was der da so von sich gibt. Wenn das nicht aussagekräftig genug ist in die Software debug-Meldungen einbauen, die Software selber compilieren und dann weiter sehen. Ich fürchte fast auf so etwas wird es für die weitere Suche hinauslaufen.
Puh, ja langsam wird es schwierig. Das mit dem Schalter S5/1 kann ich mal probieren. Die Verkabelung ist noch so wie ich sie orginal von Steff393 gekauft habe und es lief knapp zwei Jahre. Haus ist drei Jahre alt und auf dem neusten Stand die klassiche Nullung ist mir nur aus DDR zeiten bekannt.
So und jetzt bin ich leider raus, was den ESP8266 betrifft. Ich würde mich rantrauen aber nur nach anleitung da ich da keinen Plan habe was da alles möglich ist. Ich meine ein hauch Ahnung was das Ding kann löten u.s.w ist mir klar aber Softwaremässig bin ich auf schlauere Leute und ihre Fähigkeiten angewiesen. Ich hab grad einen ESP8266 hier um ihn mit Tasmota zu flashen um mir eine Steuerung zu bauen aber ohne Anleitung wüsste ich nicht was ich da mache.
Kurz zur Wallbox. Das Laden heute Nacht hat nicht geklappt. Warum auch immer war heut morgen um 5 Uhr currlim auf 0. Okay Status war vier also hab ich currlim auf 160 gesetzt und das Auto hat geladen. Um 6 Uhr war er voll hab dann currlim auf 0 gesetzt das Auto abgesteckt und bin zur Arbeit. Die Wallbox hab ich bis jetzt nicht berührt blinkt auch nicht und wen ich die Json aufrufe kommt nur das: {}
Hab mal den ESP Editor versucht aufzurufen das hat ne Weile gedauert aber es ging dann und die Json ist nun auch erreichbar. Schläft der kleine schwarze Kasten auch ein?
Also der kleine schwarze Kasten (=ESP8266) sollte nicht einschlafen. Wenn alles gut ist für ihn sollte der tagelang einfach laufen und sein Programm abarbeiten. Wenn der aber intern Probleme hat dann macht der unkontrolliert einen Reset; wenn das häufig in kurzer Zeit passiert hat das negative Auswirkungen auf's ganze System. Ob aber das von dir geschilderte Problem dabei rauskommen kann: wer weiß.
Das System hast du also mehr oder weniger fertig gekauft und lief ca. 2 Jahre gut. Was wurde dann verändert bevor die Probleme los gingen? Hardware inklusive Verkabelung? Software?
Wenn der Aufruf der web-Seiten (z.B. Editor) etwas dauert kann das verschiedene Gründe haben, das kann auch am WLAN liegen. Was genau meinst du mit "... die Json aufrufe kommt nur das: {}"? Setzt du das Kommando "http://xx.xx.xx.xx/json" (mit oder ohne Angaben für currLim?) ab und es kommt nur "{}" zurück? Oder meinst du den Aufruf des Editor und die cfg.json ist leer, sprich bringt nur "{}"?
Wenn du die web-Seite "http://xx.xx.xx.xx/json" (egal ob mit oder ohne Angaben für currLim) sendest, welche Werte meldet wbec in der Rubrik "modbus" für lastTm und millis? Mach das doch bitte mal in einigem Abstand und besonders wenn die WB wieder Fehler meldet. Vielleicht hat da tatsächlich die MCU ein Problem und resettet sich permanent.
Eigentlich fing alles mit der 0.4.7 an. Sonst hab ich nichts gemacht.
Ich habe vorhin nur http://xx.xx.xx.xx/json im Browser eingeben um zu schauen ob alles läuft und die Seite hat nur die zwei Klammern angezeigt. Hab dann im Browser die ESP Editor aufgerufen das hat ne weile gedauert und als die Seite korrekt angezeigt wurde habe ich die Seite http://xx.xx.xx.xx/json aufgerufen und plötzlich waren alle Daten wieder da.
Chgstat ist aktuell auf zwei aber so ca. jede Stunde meldet sie 0 und dann gleich wieder 2. last tm :783095 millis: 807800
Danke für die Info. Der Wert "millis: 807800" besagt das die MCU zu diesem Zeitpunkt seit ca. 13,45 Minuten läuft. Das ist ein kurze Zeit. Der Wert sollte sich konstant erhöhen und nicht wieder zurück auf kleine Werte springen. Zum Vergleich, bei mir steht der gerade bei "1065753102" was etwa 12 Tage und 8h bedeutet. Dauernd kleine Werte zeigen an das die MCU sich immer wieder resettet; fragt sich nur warum.
Die Version 0.4.7 hast du mit Sicherheit als fertiges Image abgeholt und per OTA installiert. Ist dabei wirklich alles glatt gelaufen? Nochmal zur Sicherheit (in der Hoffnung das du das genau weißt): das Board ist ein Wemos D1 R2 Mini? Mit diesem Board arbeite ich auch (und die Hardware hat's nicht leicht mit mir!) und dabei ist mir öfter aufgefallen das das update über OTA nicht zum erfolgreichen Ende gekommen ist. Nach langer Suche im Internet bin ich auf folgendes Thema gestoßen: version 2.2.6 does not show OTA success after upload of new SW version #67 Dabei geht es um die Software ElegantOTA die hier nicht verwendet wird(!) sondern hier die AsyncElegantOTA. Allerdings ist das Fehlerbild identisch!!! Für die ElegantOTA gibt es eine Korrektur in der Version 2.2.8, diese Version gibt es allerdings für AsyncElegantOTA (noch) nicht und ich habe auch in der derzeit verwendeten Version 2.2.7 keine Korrekturen dieses Problem betreffend finden können. Wie ich schon sagte baue ich mir meine Versionen selbst zusammen. Meine Lösung war die AsyncElegantOTA auf Version 2.2.5 fest zu machen und damit habe ich seitdem keine upload Probleme mehr. Hier wäre meine Bitte an @steff393 sich das Thema anzusehen ob ich hier Gespenster sehe oder ob da was dran ist.
Langer Rede kurzer Sinn @BlackandGold1 : vielleicht ist bei deinem update auf die 0.4.7 etwas schief gelaufen und die Software macht alles, nur nicht das was sie sollte. Ist nur so eine Vermutung! Hast du eine Möglichkeit den update über serielle Schnittstelle auszuführen?
Puh...erstmal Respekt für dein ganzen Wissen,krass! Leider weiß ich nicht was Steff da verbaut hat. Gekauft habe ich sie 06/21 laut meinen Mails, in den Mails selber haben wir nicht über die Hardware gesprochen. Über serielle Möglichkeit meinst du über USB und mittels PC? Falls ja, das sollte ich hinbekommen. Müsste es nur ausbauen und wissen wie und mit was ich das machen kann.
Wenn du MCUs mit Tasmota programmierst hast du bestimmt Hardware Mittel um die Teile an den PC anzuschließen um sie erstmalig zu flashen bevor OTA verfügbar ist. Was für Platform(en) benutzt du dabei? Arduino-IDE oder PlatformIO oder die von Tasmota mitgebrachte Platform?
Der Baustein im wbec Modul sollte eine Micro-USB Buchse haben über die die serielle Kommunikation und auch die Programmierung läuft. Laut Programmcode sollte der serielle Monitor mit 115200 baud, 8 Datenbits, keine Parität und 1 Stoppbit laufen (115200bd 8N1). Wenn du einen seriellen Moitor (z.B. putty) auf dem Rechner hast solltest du bei entsprechender Konfiguration was sehen können. Das Bild von setff393 das die Hardware zeigt ist aber definitiv nicht von einem Wemos D1 R2 Mini Modul denn das hat keinen CP2102 USB Chip sondern einen CH340. Jetzt muß ich raten was stimmt. Bevor du die wbec abschaltest schau doch noch mal auf die "millis"; ist das Teil weiter gelaufen oder zeigt der Wert dort wieder nur etliche Minuten Laufzeit?
lastTm":3726946,"millis":3734812 aktuell . Scheint zu laufen.
Zum Flashen nutze ich natürlich USB und die Software MCUNode Pyflasher. Kann das Teil morgen mal ausbauen und schauen was drin ist. Grad war hier noch Sturm,Schnee und Regen.
War beruflich unterwegs und heut konnte ich mich der Sache widmen. Erstmal Danke at all. Und jetzt der Hammer! Es war das Netzteil. Es scheint unregelmäßig kleine Aussetzer zu haben und hat dadurch die Fehler verursacht. Hab jetzt ein neues verbaut und werde berichten.
Danke für die Rückmeldung an dieser Stelle. Fehler in der SV sorgen immer wieder für die "tollsten" Fehler in solchen Schaltungen. Die SV ist bei diesen MCU Modulen eine sehr wichtige Komponente und sollte sehr stabil und vor allem belastbar für kurze Impulsströme sein. Ein zusätzlicher Stützkondensator möglichst nahe am Prozessor hat selten geschadet. Wenn die Sache mit dem neuen Netzteil dauerhaft funktioniert gib bitte noch einen kurzen Eintrag hier, das hilft dann auch Anderen die diesen (langen) Beitrag lesen.
Edit: ich habe meine Software nochmal etwas modifiziert und kann den Wert standby der Box individuell verändern. Eine Einstellung auf den Wert "0" (=standby aktiviert) erzeugt keinen solchen hier beschriebenen Fehler. Die Box schaltet sich nach einiger Zeit ab und wbec meldet dann natürlich dauernd einen Modbus Fehler aber sonst passiert nichts negatives. Die Box wacht korrekt auf wenn man das EV ansteckt und dann läuft die Kommunikation wieder ganz wie vorgesehen zum laden. Die Box braucht bei mir im Wartezustand (nicht standby!) doch noch so um die 10 Watt, die wollte ich als Dauerleistung eh schon vermeiden. ;)
Hallo, leider habe ich das Problem das die Wallbox ständig dieses berühmte weiße und blaue Leuchte hat und dann hilft nur Sicherung aus machen 10 Sek. Warten und wieder einschalten. Das Problem tritt jetzt erst auf da ich jetzt Tibber benutze. Bedeutet das die App das Laden des Autos unterbricht um dann weiter zuladen wenn der Strompreis am günstigsten ist. Beim überwachen der Chgstat ist mir aufgefallen das wenn das Laden durch das Auto abgebrochen wird geht der Wert von 7 auf 4. Nach ein paar Stunden ist der Wert plötzlich Null springt dann auf 0. Das wiederholt sich ein paar mal und dann kommt das blinken und nichts geht mehr. Nach aus und an der Sicherung, Auto ist noch angeschlossen geht der Wert wieder auf 4, leider ist jetzt currlim auf 0 und wenn ich jetzt nicht schnell den Wert erhöhe kommt sofort das blinken und es geht alles wieder von vorn los. SOFTWARE IST DIE 0.4.7