borg

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