borg

Dieses Jahr wird das leider wahrscheinlich nichts mehr werden. Zum Thema EEBUS kann ich nur darauf hinweisen das wir bereits eine Implementierung mit Beta-Status haben: https://github.com/Tinkerforge/esp32-firmware/tree/feature-eebus/software/src/modules/eebus Uns fehlt es aktuell noch an einer Steuerbox mit EEBUS-Support gegen die wir testen können. Aktuell gibt es soweit wir informiert sind noch keinen Netzbetreiber der dort wirklich etwas funktionales ausgerollt hat. Sobald das soweit ist und wir den ersten Testkunden haben mit dem wir testen können wird es den EEBUS-Support auch bei uns in der Firmware geben. Bezüglich Ethernet: Die Vorgehensweise dort ist das Ethernet-Kabel durchzuführen und dann den RJ45-Stecker drauf zu crimpen. Da werden von den Elektrikern meistens werkzeuglose RJ45-Stecker verwendet, das ist kein großer Aufwand.

Eine extra Einführung für ein §14a EnWG-Steuerkabel ist für die nächste Hardware-Änderung bereits fest eingeplant. Wir wollen auch die Einführung für das Ethernet-Kabel so groß machen dass man dies direkt mit RJ45-Stecker einführen kann. Zu unserer Verteidigung: Wir haben uns bei der Umstellung von WARP2 auf WARP3 Feedback von den Elektrikern eingeholt die am meisten bei uns kaufen und das Feedback war durch die Bank dass es für die Elektriker normal ist Löcher in Installationsgehäuse zu bohren um Kabel einzuführen, daher hatten wir davon abgesehen.

SEMP ist aktuell nicht geplant, allerdings wird es in Kürze EEBUS geben. Soweit ich weiß sollte der SMA Home Manager 2.0 auch EEBUS unterstützen.

Das einzige was mir einfällt was du probieren kannst ist den 802.11b-Modus zu aktivieren (unter Netzwerk -> WLAN-Verbindung -> Empfangsoptimierung). Das gibt es allerdings schon länger und hat nichts mit v2.8.3 vs v2.8.5 zu tun.

Entweder du machst das Loch in der Wand groß genug dass die Verschraubung reinpasst (geht ganz gut wenn es eine "Blechwand" von einem Firmengebäude o.ä. ist, ist aber blöd bei richtigem Mauerwerk), oder du lässt die Verschraubung weg und setzt es direkt an die Wand mit einem Loch das so klein wie möglich ist und dichtest es mit Dichtmasse/Silikondichtstoff o.ä. ab.

Falls das nicht zu viel Arbeit ist, kannst du das einmal reproduzieren während ein Ladeprotokoll läuft? (Wallbox -> Ladestatus -> Ladeprotokoll. Erst start, dann Problem Erzeugen, dann Stop+Download) Edit: An der Stelle können wir aber denke ich keine sonstigen Nebeneffekte haben wenn wir die Zeit die wir warten bis wir das Wakeup beginnen einfach erhöhen. Meistens hat das Auto ja über Nacht gestanden wenn das Wakeup nötig ist. Da ist es dann auch egal ob wir 30 Sekunden oder 60 Sekunden abwarten.

Du bekommst die user id über "curl http://$HOST/charge_tracker/current_charge": https://docs.warp-charger.com/docs/interfaces/mqtt_http/api_reference/charge_tracker?apiType=http#charge_tracker_current_charge_any

Ah, dann ist das vermutlich nicht das gleiche Problem wie hier (dort geht es um Phasenwechsel): https://github.com/Tinkerforge/esp32-firmware/issues/415 Um zu versuchen ein "eingeschlafenes" Auto wieder aufzuwecken wenden wir schon alle erdenklichen Tricks an die es so gibt. Du könntest versuchen unter Wallbox -> Ladestatus -> Ladeprotokoll ein Protokoll zu machen. Ich vermute dafür müsstest du dann aber Abends wenn du das Auto ansteckst händisch die Ladung stoppen (z.B. nicht per NFC freigeben) und dann am nächsten Tag das Ladeprotokoll starten, dann die Ladung freigeben und einen Moment warten (das Aufwecken kann bis zu ~3 Minuten dauern). Dann auf Stop drücken und uns das Protokoll zuschicken. Wenn du das PV-Überschussladen nutzt hast du keine so richtige Kontrolle wann das Auto das erste mal aufgeweckt wird und das Ladeprotokoll kann maximal ~30 Minuten lang sein.

Wie würde die Oberfläche im Kioskmode denn aussehen?

Nach genauerer Betrachtung: Den "Contactor Error" hast du ja nur einmal im Log, danach gibt es dann mehrere State Changes die funktionieren. Ich glaube das ist hier koinzident und hat nichts mit der Email zu tun die wir bekommen hatten. Du könntest auf jeden Fall drauf achten ob das öfter auftritt jetzt oder ob das nur ein einzelner "Glitch" war. Kannst du einmal genauer erklären wann der BMW den Ladestart verweigert? Ist das beim Wechsel von 1-phasig auf 3-phasig (oder umgekehrt) oder ist das wenn der BMW für lange Zeit nicht geladen hat und dann aufgeweckt werden muss oder ist das wenn du den BMW frisch ansteckst?

Also normalerweise würde ich sagen das muss ein Hardwareproblem sein, allerdings hat sich über das Wochenende ein andere Kunde per Email bei uns nicht exakt dem gleichen Fehler gemeldet. Das gibt mir jetzt etwas zu denken. Könntest du einmal testweise deine Firmware downgraden? Ich hab mal die 2.8.3 angehängt, das ist die Firmware bevor wir die Verbesserungen bei der Phasenumschaltung eingebaut haben. Tritt das Problem damit auch noch auf? warp3_firmware_2_8_3_683dc0c8_merged(2).bin

Ja wir samplen immer mit 40960 Hz. Du kannst dir den I2S-Treiber hier ansehen wenn du es ganz genau wissen möchtest: https://github.com/Tinkerforge/sound-pressure-level-bricklet/blob/master/software/src/ics43432.c Im Datenblatt sind Timingbeispiele für 48, 24, 16 und 8 kHz definiert. Erlaubt sind 7.18 kHz bis 52.8 kHz für WS und 0.469 MHz bis 3.379 MHz für SCK.

Am besten du erstellst unter Wallbox -> Ladestatus -> Ladeprotokoll ein Ladeprotokoll, das kannst du dann bei https://vislog.warp-charger.com hochladen und bekommst es visualisiert. Das ist allerdings eher darauf ausgelegt maximal so 5 Minuten o.ä. lang zu sein, die Kunst wäre es also das Problem aufzuzeichnen. Aber an und für sich wissen wir ja was passiert. Fehlerfall: Die Wallbox legt ein PWM an auf CP und das Auto legt dann keinen 880 Ohm Widerstand an. Dann versucht die Wallbox das Auto aufzuwecken indem es CP trennt und -12V anlegt. Beides erst für kurze Zeit und dann für lange Zeit. Das Auto reagiert aber trotzdem nicht. Nicht-Fehlerfall: Die Wallbox legt ein PWM an auf CP und das Auto legt dann einen 880 Ohm Widerstand an worauf die Wallbox dann das Schütz schaltet.

Du kannst den Debug-Report bei https://vislog.warp-charger.com/ hochladen.

Wir haben gerade erfahren dass dies anscheinend ein bekanntes Problem bei VW mit Software 5.4 ist. Hier schreibt das auch jemand: https://github.com/evcc-io/evcc/discussions/19806#discussioncomment-12935123 Da können wir also vermutlich nichts machen außer auf ein neues Softwareupdate von VW warten...

Aktualisiere bitte einmal auf die 2.8.4 (heute veröffentlicht). Wir haben in der 2.8.4 ein paar Verbesserungen eingebaut, mit denen wir hoffentlich die ID.x besser aufwecken können wenn sie eingeschlafen sind.

Als einfache kurzfristige Lösung kann ich das aktuelle .apk hier im Forum hochladen, siehe Anhang. warp.apk

Ist in der API-Doku beschrieben, z.B. Python: https://www.tinkerforge.com/de/doc/Software/Bricklets/SoundPressureLevel_Bricklet_Python.html#BrickletSoundPressureLevel.set_configuration

Was möchtest du den mit dem Zähler machen? Per Modbus/TCP auslesen für PV-Überschussladen o.ä.? In dem Fall ist er alleine nicht kompatibel da er nur Modbus/RTU (RS485) unterstützt. Du müsstest zusätzlich einen RTU/TCP-Wandler verwenden. Dann ist er kompatibel! Wenn du ihn direkt in die Wallbox einbauen möchtest oder am Energy Manager anschließen möchtest per RS485 ist er leider nicht kompatibel (das Registerset ist nicht integriert bei uns).

Da ist vermutlich die Frage was du eigentlich machen möchtest und welche Komponente was davon machen soll. PV-Überschussladen? Wärmepumpe anhand von PV-Überschuss steuern? Steuern anhand von dynamischen Strompreis? Stromflüsse hübsch visualisieren? Du hast ja jeweils mehrere Komponenten die das machen könnten. EVCC könnte z.B. eine PV-Überschusssteuerung machen, Homeassistant kann sicher hübsch visualisieren etc. Der WARP Energy Manager 2.0 könnte sich z.B. um die Steuerung der Wärmepumpe per SG-Ready-Signal anhand von PV-Überschuss kümmern. Wenn deine Wallbox eine WARP 1/2/3 ist kann er dort auch PV-Überschuss machen. Es wäre aber auch möglich dass der Energy Manager nur die SG-Ready-Schnittstelle per API bereitstellt und EVCC oder Homeassistant die Steuerung übernehmen.

Für den Fall dass ein spannungsfreier Schaltkontakt genutzt werden soll kommst du da nicht drum rum, ja. Bezüglich EEBUS/EVCC: Wenn du schon EVCC nutzt für das PV-Überschussladen macht es sicher Sinn das EVCC auch die EEBUS-Kommunikation zur Steuerbox übernimmt. Dann kommt sich die Steuerung von EVCC und eine eventuelle Abschaltung auch nicht in die Quere. Sag uns gerne Bescheid wenn dein Netzanbieter dass so anbietet und wie die Anbindung genau aussieht.

Sehr spannend, du bist der erste den wir kennen der eine FNN Steuerbox wirklich bekommen hat! Ich vermute der Netzbetreiber wird die Schnittstelle die verwendet werden soll am Ende festlegen. Rein gesetzlich ist dort für die digitalen Schnittstellen kein festes Protokoll vorgeschrieben, es könnte also sein dass sowas wie Modbus/TCP möglich ist. Von dem was wir von Insidern gehört haben werden die meisten Netzanbieter/Steuerboxen aber wohl auf EEBUS setzen wollen. Die analoge alternative dazu wäre ein spannungsfreier Schaltkontakt. Auf der Homepage von deiner Steuerbox steht: "Vorbereitet" ist für gewöhnlich Codewort für "Noch nicht implementiert". Daher wird deine Steuerbox aktuell vermutlich noch kein EEBUS sprechen. Wenn du da mehr erfährst sag uns bitte Bescheid, insbesondere wenn die Anbindung per EEBUS passieren soll. Wir arbeiten schon seit längerem an einer EEBUS Implementierung (inkl. SHIP/SPINE und dem LPC use case der von den Steuerboxen genutzt wird). Wir würden dich da natürlich gerne als Testkunden nutzen 😅. Aktuell haben wir wie gesagt noch keinen Zugriff auf eine funktionierende FNN Steuerbox die wirklich irgendwo verbaut wurde gegen die wir testen könnten. Falls ein spannungsfreier Schaltkontakt verwendet werden soll kannst du in Theorie ein "Klingeldraht" bis in die Wallbox legen und dort direkt anschließen oder ein WARP Energy Manager in den Schaltschrank setzen der den Kontakt ausliest. Wir planen da an der Stelle auch als günstigere alternative einen Shelly auslesen zu können der den Kontakt ausliest. Bevor du da irgendwas machst würde ich an deiner Stelle aber erst in Erfahrung bringen was mit der Steurebox wirklich möglich ist und was der Netzbetreiber vielleicht vorschreibt.

Firmware: IO-4 Bricklet 2.0 2.0.5 Add CaptureInput callback (can stream all 4 inputs with up to 50kHz sampling frequency) Download: IO-4 2.0

Firmware: IO-4 Bricklet 2.0 2.0.5 CaptureInput-Callback hinzugefügt (Ermöglicht einen Stream der Eingangszustände mit einer Abtastfrequenz von bis zu 50kHz) Download: IO-4 2.0

Wir haben nur einen Kabelsatz der alle Verkabelungsmöglichkeiten (Basic/Smart/Pro) abdeckt. Da bleiben ein paar Kabel über wenn du "nur" ein Upgrade von Smart auf Pro machst.