borg

Wir können da noch keinen festen Termin geben, aber wir arbeiten aktiv an ISO15118. Was aber jetzt definitiv schon feststeht: Es wird möglich sein eine bestehende WARP3 Pro mit Austausch des Controller-Stapels nachzurüsten.

Hab gerade schnell in den Code geschaut, auf den ersten Blick sieht das recht robust implementiert aus. Was machst du genau um den Fehler zu erzeugen damit ich das hier reproduzieren kann?

Der Eindruck ist glaube ich tatsächlich falsch. Von den allermeisten Kunde (>> 95%) hören wir nachdem sie die Wallbox gekauft haben nie wieder etwas. Du siehst hier im Forum nur die Leute die Probleme haben oder die "Power-User" sind und neue Features/Beta-Firmwares testen. Wenn wir für jede Wallbox die wir verkaufen so viel Zeit investieren würden wie wir es hier im Forum zum Teil machen (mit Testfirmwares etc), dann bräuchten wir weit mehr Mitarbeiter für den Support als wir überhaupt in Summe haben 😅.

Das ist korrekt, der WEM 2.0 hat keinen Ausgang mehr um ein Schütz zu steuern. Er unterstützt physikalisch keine SG-Ready-Schnittstelle das können wir dort also nicht per Software nachliefern. Die ganzen anderen neuen Software Features werden sonst auch alle vom WEM 1.0 unterstützt. Beim WEM 1.0 mit der neuesten Firmware wäre die Vorgehensweise: Eine Wallbox fest 1-phasig oder fest 3-phasig anzuschließen und eine Wallbox über die Phasenumschaltung des WEM. Der WEM kann dann beide im Lastmanagement steuern und eine der Wallboxen kann für das PV-Überschussladen zwischen 1- und 3-phasig umgeschaltet werden. Entweder du aktivierst das PV-Überschussladen im WEM, dann übernimmt der das, oder du nutzt die Funktionalität die EVCC bietet, da müsstest du dann in der EVCC-Doku schauen.

Die Apps sind jetzt aus der öffentlichen Beta und veröffentlicht 🥳: Android Play Store: https://play.google.com/store/apps/details?id=com.tinkerforge.warp Apple App Store: https://apps.apple.com/de/app/warp-by-tinkerforge/id6736695801 Ich denke die meisten "Kinderkrankheiten" sind behoben und die Apps sollten ziemlich stabil laufen. Wenn ihr weitere Probleme findet könnt ihr die natürlich trotzdem hier posten und wir kümmern uns drum.

Firmware: Silent Stepper Bricklet 2.0 2.0.4 Add MotorStalled callback Download: Silent Stepper Bricklet 2.0

Firmware: Silent Stepper Bricklet 2.0 2.0.4 MotorStalled callback hinzugefügt Download: Silent Stepper Bricklet 2.0

Dann wäre die Wallbox selber der Rundsteuerempfänger, das geht natürlich technisch. Aber dafür haben wir sicher nicht die passenden abnahmen. Bringt langfristig auch nicht viel, die SMGWs werden ja jetzt ausgerollt und die Gesetzeslage ist da ziemlich eindeutig (EnWG §14a-4): Wenn ein SMGW installiert ist muss dieses genutzt werden. Also man wird leider als Wallboxhersteller langfristig nicht darum herumkommen mit den SMGWs kommunizieren zu können (im Zweifel aber auch wieder nur per potentialfreien Kontakt...).

Firmware: PTC Bricklet 2.0 2.0.5, Industrial PTC Bricklet 2.0.3 Fix integer overflow in moving average at temperatures above 325°C Download: PTC Bricklet 2.0, Industrial PTC Bricklet

Firmware: PTC Bricklet 2.0 2.0.5, Industrial PTC Bricklet 2.0.3 Fix Integeroverflow in der gleitenden Mittelwertberechnung bei Temperaturen über 325°C Download: PTC Bricklet 2.0, Industrial PTC Bricklet

Der größte Unterschied für dich beim Nachrüsten ist dass der Eltako-Zähler die Anschlüsse alle unten hat während der Eastron-Zähler die Anschlüsse unten und oben verteilt hat. Die Kabelführung in der WARP3 ist auf den Eltako-Zähler ausgelegt.

Pushnachrichten haben wir uns angesehen und halte ich auch für sinnvoll. Mal schauen wie das Feedback so aussieht, aber wenn das viele haben wollen können wir das natürlich nachziehen. Ist ein bisschen komplizierter als man im ersten Moment denkt. Mein Verständnis davon ist, dass die App sich über APNs (Apple Push Notification service) einen Token holen muss und diesen dann an die Wallbox weitergibt. Die Wallbox kann dann wenn ein Event eintritt über den Token die Nachricht an APNs schicken und Apple überträgt die Nachricht an die App und weckt diese auf und dann kann die Nachricht angezeigt werden. Ein Äquivalent dazu gibt es auch bei Android. Also es ist nicht so dass die App selber den Zustand der Wallbox beobachten kann und dann die Nachricht erzeugen, das würde zuviel Batterie ziehen.

Wer möchte kann an der öffentlichen Beta unserer WARP App teilnehmen: Android: https://play.google.com/store/apps/details?id=com.tinkerforge.warp iOS: https://testflight.apple.com/join/4NwN9xnn Die beiden Apps können über my.warp-charger.com auf euren WARP1|2|3 und WARP Energy Manager zugreifen. Die Verbindung zwischen eurem Handy und dem Gerät ist natürlich wieder Ende-zu-Ende verschlüsselt und wir können nicht reinschauen, genauso wie bei der Webversion. Technisch rendern die Apps auch das HTML welches vom WARP Charger/Energy Manager ausgeliefert wird, es werden aber der Header und das Menü durch native Android/iOS Elemente ersetzt. Zusätzlich sollte es so sein dass ihr euch nur einmal anmelden müsst und die App stellt die Verbindung automatisch wieder her wenn ihr sie wieder öffnet. Bekannte Bugs: In seltenen Fällen stürzt die Rendering-Engine(?) im Hintergrund ab. In dem Fall muss man einmal im Menü auf Geräte klicken und kann dann wieder zurück (oder die App neustarten). Der Grund dafür ist aktuell noch unklar, das wollen wir vor dem Release natürlich noch fixen. Beschreibungstexte und Screenshots usw in den App Stores sind noch nicht fertig, das wird alles noch aufgehübscht.

Galileo wird seit Mitte 2022 unterstützt, anscheinend hatte damals niemand die API-Doku aktualisiert 🙈. Hab die API-Doku gerade gefixt.

Das ist sehr komisch, hast du irgendwie beiden Bricklets ausversehen die gleiche UID gegeben (die UID bei den Bricklets kann man ja überschreiben)?

Die externe Steuerung muss in den neueren Firmwares nicht mehr aktiviert werden, allerdings sollte sie nach einem Update natürlich nicht blocken. Das schauen wir uns an, gibt dann denke ich noch ein schnelles Release hinterher was das fixt. Falls sonst noch jemand das Problem hat: Ihr könnt unter Wallbox -> Ladestatus bei "Externe Steuerung" auf zurücksetzen klicken, dann passt auch wieder alles.

Der Stecker ist ein JST PH

Das dachte ich mir, d.h. der SHARP IR Sensor gibt die Werte so analog zurück, da können wir dann nichts machen.

Kannst du den "Analog Value" auch einmal mit plotten? Hat der auch so Stufen?

Hab gerade kurz in den Code geschaut, beim Booten führen wir erst einmal eine Reset-Sequenz aus um sicher zu sein dass wir wissen in welchem Zustand sich der BNO055 befindet. Das dauert 1200ms. Danach laden wir dann die Kalibrierung falls vorhanden, dann wird die komplette Konfiguration des BNO055 einmal geschrieben und dann werden das erste mal die Sensorwerte gelesen. Also ein bisschen "Bootzeit" benötigt die IMU wirklich, aber ich hätte jetzt gedacht dass wir da trotzdem schneller sind als dein RPi bootet?

There should be no drift(*). How did you connect the encoder and how did you configure the Bricklet? (*): The only way you should be able to introduce drift is if the signal is not unambiguous anymore. For example if the high voltage is normally 24V, but if it starts to bounce back and force with high frequency the high voltage only goes up to 5V or so. In that case it can easily happen that the Bricklet starts to miss transitions.

Firmware: NFC Bricklet 2.1.0 NXP NfcLibrary aktualisiert Überschreibefehler beim Input-Buffer behoben Unterstützung für NFC Forum Typ 5 (ISO 15693) hinzugefügt NDEF-Unterstützung für NFC Forum Typ 5 und Mifare Classic hinzugefügt Verbesserte Kartenemulationsunterstützung (funktioniert jetzt richtig zwischen zwei NFC Bricklets und mit Android/iPhone) Unterstützung für benutzerdefinierte Tag-ID im Kartenemulationsmodus hinzugefügt P2P-Unterstützung entfernt Download: NFC Bricklet

Firmware: NFC Bricklet 2.1.0 Update NXP NfcLibrary Fix input buffer overwrite bug Add support for NFC Forum Type 5 (ISO 15693) Add NDEF support for NFC Forum Type 5 and Mifare Classic Improve card emulation support (now properly works between two NFC Bricklets and with Android/iPhone) Add support for custom tag ID in cardemu mode Remove P2P support Download: NFC Bricklet

Der Unterschied liegt im Messprinzip. Die EVSE 2.0 und 3.0 haben einen ADC der synchron mit dem PWM 2000x pro Sekunde die Spannung zwischen CP und PE misst (einmal wenn das Signal high ist und einmal wenn es low ist pro PWM-Durchlauf). Da wir das komplett steuern können wir bei einer High-Zeit von x us und einer Low-Zeit von y us (wobei x+y=1ms bei 1kHz PWM) genau bei x/2 und y/2 messen. Dadurch bekommen wir eine sehr gute Messung wo etwaiges "Ringing" o.ä. bei den Flankenübergängen rausgefiltert werden. Zusätzlich mitteln wir über 50 Werte um Glitches rauszuglättern. Mit den Werten können wir den Widerstand den das Auto zwischen CP und PE anlegt sehr exakt bestimmen. Das EVSE 1.0 misst über über die besagten 50ms. D.h. es bildet sozusagen das Integral über 50ms des CP/PE-Signals. Da wir die Pulsweite und die Low-Spannung genau kennen können wir daraus rein theoretisch mathematisch auch den Widerstand bestimmen. In der Praxis hat sich aber herausgestellt dass das Signal was auf CP/PE ist oft stark rauscht und bei manchen Autos treten komische kapazitive(?) Effekte auf, weswegen beim EVSE V1 die Kalbrierung notwendig ist.

Schau mal hier: https://vislog.warp-charger.com/j2ME2bJLYQxZjnrVwNvexa und aktiviere oben den Widerstand CP/PE Man sieht dass die Duty Cycle auf 26.6% springt sobald das Schütz abgeschalten wird (was ein neues Feature ist um eine möglichst gute Messung machen zu können). Der CP/PE Widerstand geht dann bis auf 22k Ohm hoch (der Threshold für den Wechsel des Status auf "getrennt" liegt bei 10k Ohm). Bevor der Wechsel dann aber stattfindet springt der Widerstand runter auf 7k Ohm und bleibt da. Deswegen denkt deine Wallbox das Auto ist noch angeschlossen will aber nicht laden. Dass der Wert da runter springt kann aber nicht an deinen Änderungen liegen oder? Das ist mir nämlich etwas schleierhaft wo der Sprung da auf einmal wegkommt.