borg
-
Gesamte Inhalte
3.550 -
Benutzer seit
-
Letzter Besuch
-
Tagessiege
51
Posts erstellt von borg
-
-
Die Firmware des Ladecontrollers ist Bestandteil des Firmware Updates, da brauchst du dich nicht separat drum kümmern.
Version 1.5 bezieht sich auf die Hardwareversion des Ladecontrollers.
-
Du müsstest das Ladekabel ersetzen (da hast du schon das richtige gefunden) und den 680 Ohm Widerstand zwischen PP/PE durch 220 Ohm ersetzen: https://www.tinkerforge.com/de/shop/warp/warp1-spare-parts/warp-res-220.html
Danach wird die Wallbox dann automatisch als 22kW Variante erkannt und man kann 1-phasig mit bis zu 32A/7,4kW laden.
-
Unfortunately we currently don't have the manpower to add support for openhab 3 🙁.
-
If the connectors get too hot you can always connect your power supply directly to the servo.
So connect 5V/GND to the servo directly and only GND/PWM signal to the Servo Bricklet. The current doesn't have to flow through the Bricklet!
-
You can't control it with a IO-16 Bricklet 2.0. Maybe you can use the Industrial Quad Relay Bricklet. How much current does the light source use?
-
Please try to enable SPI and add the Bricklet ports to the brickd.conf as described here: https://www.tinkerforge.com/en/doc/Hardware/Bricks/HAT_Zero_Brick.html#compatibility-to-other-boards-and-images
-
Das RS485 Bricklet liest den Zähler aus. Du musst RX/TX/GND vom RS485 Bricklet mit TX/RX/GND vom SDM72 verbinden.
-
Am 8.8.2022 um 08:34 schrieb AXXCCESS:
Die Info mit der Verbindung sollte evtl. auf der Seite von RS485 Master Extension Teil gepostet werden. ;)
In der Tat. Hab es mal direkt im Shop hinzugefügt bei der RS485 Extension.
Nochmal Entschuldigung für die Probleme! Mit der nächsten Produktion Master Bricks ist das auch wieder gefixt.
-
Der Master Brick 3.1 hat leider einen Hardware-Bug auf Grund dessen er nicht mit den RS485 Extenions funktioniert: https://www.tinkerforge.com/de/doc/Hardware/Bricks/Master_Brick.html#errata-hardware-version-3-1
In der nächsten Fertigung von Master Bricks ist das gefixt. In der Zwischenzeit haben wir da leider sonst keine direkte Lösung um das mit der RS485 Extension zum Laufen zu bekommen.
Ihr könntet vielleicht je ein ESP32 Brick + Sensor nehmen und das dann über WLAN verbinden. Das wäre preislich nicht teurer als Master Brick + RS485 Extension.
-
1
-
-
The _*_low_level_* functions are used internally to implement the public streaming-functions like tf_sound_pressure_level_get_spectrum and the callback for
SOUND_PRESSURE_LEVEL_CALLBACK_SPECTRUM.So please use either tf_sound_pressure_level_get_spectrum or
sound_pressure_level_set_spectrum_callback_configurationtogether with theSOUND_PRESSURE_LEVEL_CALLBACK_SPECTRUM.You can use the decibel callback and the spectrum callback at the same time. The decibel value is not directly included in the spectrum (it can in theory be calculated from the spectrum though: https://github.com/Tinkerforge/sound-pressure-level-bricklet/blob/master/software/src/pcm.c#L122).
-
Wir gehen aktuell von 249€ brutto aus (ohne Gewähr).
-
EVCC hat Unterstützung für unsere WARP Charger, ja: https://www.warp-charger.com/evcc.html
Ansonsten arbeiten wir auch gerade an einem Energiemanager mit dem man PV-Überschussladen realisieren kann. Der Energiemanager kann auch zwischen 1-phasig/3-phasig umschalten wodurch man mit geringerer Leistung laden kann.
-
Für IEC61851 State C (Das Auto lädt, Schütz ist geschaltet) akzeptieren wir Widerstände zwischen 300 und 1790 Ohm. Der Widerstandsmessung bleibt auch wenn sich der Strom ändert definitiv hinreichend stabil (880 wäre optimal):
In deiner zweiten Messung wird am Anfang bevor das Auto lädt 2350 Ohm gemessen (das ist OK). Im Fehlerfall springt CP/PE dann aber auf einmal zwischen 1750 und 1880 hin und her:
Das ist natürlich Murks. Der Standard sieht hier 2700 Ohm vor wenn das Auto noch dran ist aber nicht laden will.
Anbei eine Kalibrierung die alle Werte ein bisschen hoch zieht, so dass die 880 Ohm genauer erreicht werden sollten und wir auch im unteren Fall weit über 1790 bleiben.
-
1
-
-
Das Protokoll dieser "Standard-Wetterstationen" nutzt eine CRC: https://github.com/Tinkerforge/outdoor-weather-bricklet/blob/master/software/src/rfm210.c#L84
Ein Bitfehler als Fehlerquelle ist also eher unwahrscheinlich. Es gibt allerdings andere ähnliche Wetterstationen welche die gleiche CRC aber einen anderen Payload nutzen...
Ich weiß von mindestens drei unterschiedlichen Protokollen die gleich aufgebaut sind und anderen Inhalt haben. Das hier ein anderes System stört halte ich für wahrscheinlicher.
-
Kannst du einmal ein Ladeprotokoll starten (unter Ladecontroller -> Ladeprotokoll) und dann eine Ladung starten und diese wenn es geht von 16A in Schritten auf 6A verringern?
Dann das Ladeprotokoll stoppen, runterladen und hier hochladen. Dann kann ich schauen ob vielleicht die Kalibrierung die wir in WARP1 für den ADC für die Widerstandserkennung haben nicht OK ist.
Optimalerweise würde dann am Ende natürlich das Problem auch auftreten, ist aber auch OK wenn es nicht auftritt.
-
Ich vermute das Bricklet ist einfach nicht geflasht. Wenn du einen Linux-PC und ein Master Brick 3.1 zur Hand hast kannst du den Bootloader über das "write_bootloader_to_comcu_bricklet.sh"-Script aus diesem git https://github.com/Tinkerforge/flash-test drauf flashen.
Wenn der Bootloader drauf ist kannst du über den Brick Viewer ganz normal die Firmware flashen.
Ansonsten müsstest du das Bricklet einschicken, wir flashen es und schicken es zurück.
Entschuldigung für die Probleme!
-
1
-
-
Oh man, da hast wirklich einen Bug gefunden. Das Boot-Pad (mit dem man das Bricklet beim Booten in den Bootloader bringen kann) war auf den falschen Pin gelegt:
Das Problem ist, den Bootloader (und damit diese Änderung) kannst du mit dem Brick Viewer nicht überschreiben.
Falls du in deinem Aufbau nicht vermeiden kannst den Magnet beim Booten in der nähe zu haben müsstet du das Bricklet einmal einschicken und wir flashen dass dann neu.
Alternativ würdest du einen Master Brick 3.1 benötigen und einen Linux Rechner auf dem du aus diesem git https://github.com/Tinkerforge/flash-test das Script write_bootloader_to_comcu_bricklet.sh ausführst.
-
vor 13 Stunden schrieb Superp:
The documentation seems a bit inconsistent re onboard antenna?
It is fixed now. There was a bit too much copy+paste from GPS V2 documentation.
-
-
@rtrbtschickt dir gleiche eine Firmware zum Testen.
Wir haben in der Zwischenzeit überlegt woran es mechanisch liegen könnte. Die Schützüberwachung betrifft eigentlich nur ganz wenige Leitungen. Du könntest einmal beim Schütz A1, A2 und 1 nachziehen (vielleicht sogar einmal kurz lösen und wieder fest ziehen) damit 100%ig sicher gestellt ist das wir da keinen Wackelkontakt o.ä. haben. Zusätzlich einmal das PE ganz links an der Klemme lösen und neu reinmachen.
-
vor 2 Stunden schrieb Photon_1978:
Im Ladecontroller bei der Anzeige für den Low-Level-Zustand springt im Ruhezustand ein Zustand (Schutzprüfung vorher) ständig zwischen high und low hin und her. Soll das so sein?
Das ist OK, das ist wirklich der Low-Level-Zustand des Pins, d.h. der geht mit 50hz zwischen low und high hin und her falls Strom angeschlossen ist.
Wir haben uns deine Ladelogs angeschaut und tatsächlich eine Idee die wir testen können, wir machen morgen eine Testfirmware dafür fertig.
-
Die Änderung hat es leider nicht in das neue Bindings-Release geschafft, für das Beta-Release müsstest du einmal wieder downgraden auf die C#-Bindings aus dem Thread den du verlinkt hast.
-
Wir können tatsächlich reproduzieren das wir über den "Start"-Button eine Ladung starten können wenn der Schlüsselschalter auf aus steht bei WARP1.
Das ist so natürlich nicht gedacht, da haben wir uns einen Bug reingeholt als wir die "Charging Slots" eingeführt haben. Wir fixen das am Montag.
-
There is actually a small SPITFP protocol definition in the SPITFP implementation of the XMC Bootloader firmware source as a comment.
Take a look here: https://github.com/Tinkerforge/brickletboot_xmc/blob/master/software/src/bootloader_spitfp.c
Benutzerverwaltung - speichern nicht möglich - Error: Still applying the last operation. Please retry
in WARP Charger
Geschrieben
Mh, komisch. Die Fehlermeldung sollte nur kommen wenn du auf speichern drückst und während dessen gerade schon eine Änderung gespeichert wird.
Du hast nebenbei aber nicht EVCC o.ä. laufen was vielleicht per API auf die Nutzerverwaltung zugreift?