rtrbt

Hi,

Da geht einiges durcheinander:

• Du musst die Konstanten wie MODE_READER usw nicht neu definieren, das hat keinen Effekt.
• Das NFC-Bricklet funktioniert wie ein Zustandsautomat. Du musst also die Zustandsübergänge auslösen bzw. abwarten. An der jeweiligen Funktion, ist dokumentiert, welche Zustände du durchlaufen musst. Vergleiche am besten mal die Dokumentation von z.B. reader_write_page und dem Write Read Type2-Beispiel. Folgender Abschnitt der Hardware-Doku erklärt das auch nochmal.
• Die Beispiele benutzen alle das state_changed-Callback als Signal, dass sich der Zustand des NFC-Bricklets geändert hat. Das würde ich dir auch empfehlen. Wenn deine Programmstruktur das nicht zulässt, kannst du auch (blockierend) den Zustand immer wieder abfragen, bis er sich ändert. (dann mit nfc.get_state() in einer Schleife)
• Du versuchst die GPS-Koordinaten als Text als NDEF-Record zu schreiben, NDEF-Nachrichten haben aber ein spezifisches Format, vermutlich musst du stattdessen eine Page direkt schreiben.
• Das wird bei Typ-2-Tags aber knapp, wenn ich unsere Hardware-Doku richtig verstehe, hast du pro Page 4 Byte Platz, du müsstest also für Breiten- und Längengrad (binär, nicht als Zeichenkette) jeweils eine Page verwenden und noch eine für die Vorzeichen von beidem.

The Isolator Bricklet is compatible with the HAT Zero. The docs are a bit outdated in this case, as they often assume, that all Bricks come with the 10p connector.

Hi,

19 hours ago, Overlander said:

Aber sobald ich versuche die Daten zu verändern, die geschrieben werden sollen, geht krieg nur noch Fehlermeldungen. 

Zeige am besten mal, wie du das Beispiel verändert hast, sowas sieht man "am Objekt" am besten.

18 hours ago, zef said:

Does that sound likely at all?

Maybe. As a simple test, you could build a minimal setup with only the bricklet and the probe (attached to the HAT and Pi or, if you have one, a Master Brick) without an enclosure, connect to the Brick or Pi with Brick Viewer and see if the bricklet gets stuck again. Of course this depends on how often the errors happen.

Hi,

Do you see any activity on the error state callback while the value is stuck? The firmware does not update the temperature value while the open circuit error is set.

Du kannst dir unsere "geheime" EVCC-Anleitung ansehen, die sollte in den nächsten Tagen öffentlich werden: https://www.warp-charger.com/evcc.html

Mit den Einstellungen sollte es klappen, ja.

On 4/24/2021 at 7:03 PM, Docmac said:

Da ich kein e-Auto zum Testen da habe ich dann aber vermutlich immer noch nicht viel sehen (ausser ev. eine Null-Linie ;-)) aber zumindest müsste das dann ja im Stromzählerbereich der Warp graphisch dargestellt werden?!

Ja sollte sie. Die Wallbox unterscheidet (inzwischen) zwischen nicht empfangenen Werten und 0 W. Du kannst dann entweder die Graphen ansehen, oder unter [wallbox-ip]/meter/state und /meter/live die Rohdaten auslesen.

Moin Gustav,

Ich habe in der Anleitung die Herstellerangaben für Kabeldurchmesser (11-21mm) und Anzugsdrehmoment (10 Nm) eingefügt, danke nochmal für den Hinweis. Warum in deinem Fall die Kabel nicht gehalten wurden ist uns aber unklar.

Hast du bei beiden Extensions das kurze schwarze Kabel? Ich habe hier erst mit einer älteren getestet, die hatte das längere graue Kabel, wie es oben abgebildet ist. Bei denen die wir noch im Lager haben ist aber auch das kürzere schwarze verbaut. Damit funktioniert es bei mir auf dem Tisch aber trotzdem.

Die AP-Geschichte habe ich auch getestet, das klappt mit deiner Konfiguration manchmal, manchmal kann ich den Startup Error aber auch erzeugen.

Falls du nicht dringend auf die Möglichkeit eine externe Antenne anzuschließen angewiesen bist, würden wir dir beide Extensions gegen die 2.0-Variante umtauschen. Damit scheint dein Setup ja zu funktionieren. Schreibe dazu mal eine Mail an sales@tinkerforge.com, mein Kollege klärt dann alles weitere.

Moin,

Ich habe hier gerade mit einer 1.0 und einer 2.0 getestet und hatte mit beiden vergleichbaren Empfang. Es gibt auch keine Erfahrungswerte, dass die alte Extension deutlich schlechteren Empfang hätte. Deshalb erstmal folgende Fragen:

• Steckt der UFL-Stecker auf dem Bricklet richtig?
  
• Hast du die Probleme auch mit anderen APs? Du könntest z.B. eine der alten Extensions als Access Point betreiben und dann mit der anderen btw. der 2.0 testen.

Mit einer Bluetooth-Freischaltung habe ich tatsächlich schon experimentiert, bin dabei aber über zwei Probleme gestolpert:

1. Ist es nicht so einfach eine Bluetooth-Profil zu finden, zu dem sich die Smartphones automagisch verbinden. Ich habe dafür erstmal ein HID genommen, dann ist die Wallbox aus Sicht des Handys ein Controller mit einem Button. Das ist aus Anwendersicht etwas unschön bis verwirrend aber eventuell gut genug. Was ich genau für ein Profil nehme ist aus Wallbox-Sicht egal, da ich außer dem Verbindungsaufbau keine Daten austauschen will.
2. Der Bluetooth-Stack frisst ziemlich viel Arbeitsspeicher auf dem ESP. Das ist das Hauptproblem, weswegen ich das ganze erstmal nach hinten verschoben habe.

NFC zu untersuchen ist noch auf der TODO-Liste, sowohl bezüglich Software, als auch der Hardware-Platzierung. Wenn sich das jemand von euch selbst bauen will, sollte das mit dem NFC-Bricklet relativ einfach möglich sein, man muss halt ein Firmware-Modul dafür schreiben, das im Endeffekt den Auto-Start (de)aktiviert. Ob und wenn ja wann es da etwas offizielles gibt kann ich aber noch nicht sagen, nicht wegen Geheimniskrämerei, sondern weil wir das auch noch nicht genau wissen.

Moin,

Da sind die Beispiele in der API-Dokumentation schlecht. Unter Windows funktioniert das nur, wenn du alle einfachen Anführungszeichen durch doppelte ersetzt und die "verschachtelten" (also die im JSON-Payload) mit \ escapst, zum Beispiel so:

curl -H "Content-Type: application/json" -X PUT -d "{\"current\": 8000}" 192.168.0.62/evse/current_limit

Der Unterschied zwischen vehicle_state und iec61851_state ist nur, dass, wenn du auto_start deaktiviert hast, der iec_state 0 meldet (also "A" bzw. "nicht verbunden"), weil das aus Sicht des Autos so ist. Der vehicle_state sagt aber trotzdem 1 (also "verbunden"), das ist gewissermaßen die Sicht der Wallbox. Damit kannst du detektieren, ob ein Auto da ist, ohne dass du das Laden freigibst.

Coole Sache :) Zwei Fragen dazu:

Hast du die Stromverbrauchswerte irgendwo vertauscht oder einen komischen Zähler? Mich wundert gerade, dass der zurücksetzbare Stromverbrauch (lies: energy_rel btw. Register 389) höher ist als der nicht zurücksetzbare (lies: energy_abs bzw. Register 73). Das bringt keinen um, ist mir nur aufgefallen.

Das die Live-Ansicht so "lang" ist liegt daran, dass du weniger oft abfragst? Oder hast du dir mehr Live-Historie gegönnt?

Moin,

On 3/27/2021 at 10:51 AM, Docmac said:

Daher sollte das ganze sicher sein, da die WB generell noch die Führung im Fehlerfall hat, richtig?

Die Fehlerbehandlung übernimmt die Wallbox, ja.

On 3/27/2021 at 10:51 AM, Docmac said:

Muss ich noch einen WB Reset o.ä. einbauen, wenn ein Umschalten der Phasen erfolgt?

Einen Reset solltest du nicht brauchen. Es sollte reichen, wenn du:

• Die Ladung beendest (falls eine lief),
• Sicherheitshalber auto-start ausmachst (das solltest du sowieso deaktivieren, wenn du abhängig von deiner PV-Leistung selbst steuern willst wann geladen wird)
• Wartest bis du iec_state 0 (also A) siehst
• Dann die Phasen ab/zuschaltest
• Wartest dass dein Schütz geschaltet hat
• Dann das Laden wieder startest

On 3/27/2021 at 10:51 AM, Docmac said:

Welche Taktung ist in Hinblick auf WB, Kommunikation mit dem Auto, dem Phasen-Schütz und PV Anlage sinnvoll?

Das musst du mit deinem Aufbau ausprobieren. Je nach Trägheit des Autos würde ich eher schätzen, dass der Bereich 5 bis 10 Sekunden sinnvoll ist. Du kannst natürlich öfter den Ladestrom nachjustieren, aber wenn das Auto da nicht hinterher kommt hast du nicht viel davon, weil es praktisch deine Reglung glättet.

50 minutes ago, poohnet said:

Ich nehme an, dass man nach dem Build die "warp_firmware_xxx_merged.bin" flashen muss, oder?

Stimmt.

Moin,

Testet mal bitte diese Version. Wir hatten das Zertifikat für den Download-Server gewechselt, der Brick Viewer hat aber noch die alte Zertifikatskette mitgeliefert. Deshalb konnte er keine TLS-Verbindung aufbauen.

On 3/27/2021 at 10:14 AM, duaw said:

Was der ESP32-Brick grundsätzlich anders machen soll als der Red-Brick überblicke ich nicht. 

Grundlegend ist der Vorteil des ESP32-Bricks, dass du kein Linux darauf hast, sondern direkt mit der Hardware reden kannst, z.B im Arduino-Stil.

On 3/26/2021 at 2:28 PM, luxor said:

Ich hoffe das wird sich mit dem ESP32 Brick ändert, dort soll man ja auch eine Art MQTT Proxy laufen lassen können, so das sich die Tinkerforge Bausteine dann Aktiv beim MQTT Sever melden und man nicht mehr das MQTT Binding braucht. Ich hoffe zu mindestens das sich das so verstanden habe

Da verwechselst du Dinge. Der ESP32 Brick hat einen Proxy-Modus, was aber nicht über MQTT läuft, sondern das normale Tinkerforge-Protokoll. D.h. du kannst ihn genau wie alle anderen Bricks verwenden und z.b. dich mit dem Brick Viewer darauf verbinden. Deshalb funktionieren dann auch die MQTT-Bindings damit. Aktiv macht der Brick aber nichts über MQTT, es sei denn man schreibt eine entsprechende Firmware.

Moin,

Stand jetzt kannst du das nicht einstellen. Die Wallbox schickt MQTT-Nachrichten nur bei Änderung der Werte, prüft aber jede Sekunde auf Änderungen, auch damit das Webinterface nicht extrem langsam ist (das Webinterface benutzt bis auf MQTT selbst die selben Mechanismen). evse/state und ein paar andere Topics beinhalten Werte, die sich praktisch immer ändern (z.B. die Uptime), deshalb bekommst du jede Sekunde eine Nachricht. Ich habe noch auf der TODO-Liste mir zu überlegen ob und wenn ja wie man das limitieren kann.

Moin,

Sorry für die späte Antwort, war im Urlaub.

On 3/28/2021 at 4:19 PM, poohnet said:

Wenn ich das richtig sehe, dann wird die RS485/ Modbus-Verbindung zum Zähler (zumindest aktuell) ja nur für das Webinterface benötigt, oder?

Benötigt wird die Verbindung garnicht. Wenn das RS485-Bricklet nicht gefunden wird, deaktiviert das Webinterface den entsprechenden Teil der Oberfläche.

On 3/28/2021 at 4:19 PM, poohnet said:

Was haltet ihr davon? Spricht da aus eurer Sicht etwas dagegen (außer vielleicht, dass ich diese Anpassung mit jeder neuen Firmware-Version erneut machen müsste)?

Prinzipiell sollte dein Plan funktionieren. Die eModbus-Bibliothek sollte sich gut in die Firmware einfügen, PlatformIO und AsyncTCP benutzen wir auch. Wenn du dir das sdm72dm-Modul aus der Firmware umschreibst und die API einhältst (also sowohl die des Moduls, als auch die "nach außen", meter/state und so) sollte das funktionieren. Die interne API zwischen den Modulen ist Stand jetzt nicht stabil, aber ich erwarte da keine größeren Änderungen.

Moin,

Der Zähler gibt einen Messwert mit bis zu 3 Nachkommastellen aus (also 0,001 kWh = 1 Wattstunde). "Bis zu " weil es ein float ist, Nullen hinten werden also abgeschnitten. Die Wallbox reicht die Messwerte des Zählers unverändert weiter.

Hi Gustav,

Ich habe deine Anmerkungen mal in die Anleitung eingepflegt. Die aktuelle Version findest du hier: https://www.warp-charger.com/documents/WARP_Betriebsanleitung.pdf

Hi,

I don't think so, sorry. Finishing the binding will take some time, I would estimate about two to four weeks. So it is not really squeezeable. I will continue to work on the binding as soon as the heap of tasks for our charging station is done.

Moin,

Gibt es leider nicht. Wenn du nur Pixel zeichnest, kannst du die Koordinaten flippen, bei Text müsstest du auf eine Bitmap-Schrift umsteigen und die selbst zeichnen.

Gemergt. Ich biege die Partitionstabelle noch etwas um, das große SPIFFS brauchen wir Stand jetzt nicht und bei ESPs die man zur Entwicklung nutzt ist es kein Problem die Partitionstabelle noch umzuändern. Andere Frage: Wenn du bei dir die upload_port-Zeilen beide auskommentierst, funktioniert dann die Auto-Detection? Dann würde ich das so in die ini packen, damit man nicht seine seriellen Ports jedes Mal anpassen muss.