rtrbt

Kannst du ruhig einfach machen, dafür gibt's kein separates Unterforum.

Moin, Am einfachsten wäre es, wenn du pro Wägezelle ein Load Cell Bricklet nimmst. Du kannst theoretisch auch mehrere Wägezellen parallel schalten (siehe z.b. diese Diskussion) das scheint aber nicht ganz so einfach zu sein, sowohl mechanisch, als auch von der Messgenauigkeit her.

Moin, Der Master Brick hat zwei Knöpfe neben dem USB-Anschluss: Erase und Reset. Wenn du (während der Brick angeschlossen ist) Erase gedrückt hältst, Reset drückst und dann Erase wieder los lässt, sollte der Brick als serielles Device auftauchen. Du kannst dann mit dem Brick Viewer die aktuelle Firmware flashen. Das ganze wird hier: https://www.tinkerforge.com/de/doc/Software/Brickv.html#brick-firmware-flashing noch detaillierter erklärt.

Moin, Das ist leider missverständlich formuliert, "openHAB 2.5.0 or newer" meint nur, dass weitere 2.5-Versionen (oder falls es 2.6 gegeben hätte das) problemlos funktioniert. Ich ändere den Text mal, damit das nicht so verwirrend ist. Die openHAB 3-Version dauert noch etwas, ich bin Stand jetzt noch gut mit der Wallbox beschäftigt.

Im Debug-Log ist auffällig, dass die Bindings TLS 1.3 sprechen, du Mosquitto aber auf TLS 1.2 betreibst (da kannst du nicht so einfach auf 1.3 wechseln, das gibt es erst ab Mosquitto 1.6 und Raspberry Pi OS liefert noch die 1.5.7 aus) Als Schnellschuss: Teste mal mit der angehangenen Bindings-Version, in der ich TLS 1.2 erzwungen habe. tinkerforge_mqtt_bindings_2_0_14_rc2.zip

Um kurz die Zählerverwirrung zu klären: Ihr müsst zwischen der Versorgung des Zählers und der Messung unterscheiden. Der Zähler selbst muss dreiphasig versorgt werden, kann aber ungleiche Lasten auf den Phasen messen (damit auch den Extremfall "Auto lädt nur einphasig"). Das heißt eine Bastellösung, die zwei der drei Phasen hinter dem Zähler abschaltet würde meines Wissens funktionieren. Möglicherweise ist das aber nicht nötig, denn: Das hier stimmt nicht unbedingt, bzw. hängt vom Fahrzeug ab: Bei den Zoes ist es z.B. so, dass (wie batti geschrieben hatte) der Lader im Auto ungefähr bei 8 Ampere auf einphasiges Laden wechselt. Wenn man das ausnutzt könnten also Ladungen < 4,2 kW darüber erreicht werden, dass dem Zoe nur 7 Ampere Ladestrom erlaubt werden. Das hat natürlich das Problem, dass es dann diesen Sprung bei ~ 1,8 kW (einphasig, also 8 Ampere) gibt wo der Zoe dann auf 3 Phasen wechselt und auf einmal ~ 5,5 kW zieht.

Das ist kein Problem. Wenn dein Programm beendet wird, werden auch die Verbindungen geschlossen.

Moin, Teste mal immer mit tinkerforge_mqtt --debug ... andere Flags Dann bekommst du mehr hilfreiche Ausgabe. Mich wundert folgendes: Die Bindings verwenden als Default-Port immer die 1883, d.h. wenn du den Broker ohne Verschlüsselung auch auf der 8883 laufen hast, hätte das nie funktionieren dürfen, wenn du den Port nicht angibst. Teste bitte nochmal, wie das bei deaktiviertem TLS mit den Ports genau ist, also ob du, selbst wenn du in mosquitto.conf 8883 konfigurierst, du mit der Default-Einstellung der Bindings eine Verbindung bekommst. Dann wäre auch interessant, was passiert, wenn du explizit --broker-port 1883 oder --broker-port 8883 mitgibst. Die ganze SSL/TLS-Geschichte werde ich unabhängig davon in den nächsten Tagen hier nochmal durchtesten, bisher gab es da keine Beschwerden, aber auch kein positives Feedback, eventuell ist das also wirklich einfach kaputt und es hat bisher noch niemand gemerkt. Bis ich zum testen komme kann es aber noch etwas dauern, also durchaus erst nächste Woche oder so. Ich gebe Bescheid ;)

Moin, Ich hatte dein Script falsch gelesen, eigentlich hätte ich schon sehen können, wo das Problem ist: Du hast im Script ja eine Endlosschleife und darin die for-Schleife, die die Spannungen durchgeht. Das Problem ist jetzt, dass nach einem Durchlauf der for-Schleife du auf eine Eingabe wartest und danach die Verbindung zum Brick Daemon schließt, dann aber wegen der Endlosschleife die nächste Runde Spannungssetzen machst, was aber nur klappt, wenn die Verbindung noch da ist. Du müsstest also die beiden letzten Zeilen aus der Schleife rausnehmen, wenn du die ganze Zeit die Spannungen durchlaufen willst, oder alternativ, wenn du immer auf einen Tastendruck warten willst vor der nächsten Runde lässt du das input("...") in der Schleife, dann würde ich aber den Text ändern, ist dann ja kein Exit mehr.

Update: https://www.warp-charger.com/api.html

Moin, Die MQTT-API steht soweit, ich bin gerade dabei sie zu dokumentieren. Ich bin optimistisch, dass das diese Woche fertig wird. Stand jetzt kannst du (neben nicht direkt ladebezogenen Dingen): den aktuellen Zustand (ist ein Auto angeschlossen, wird geladen, usw.) auslesen den Ladestrom in mA einstellen, den Ladevorgang starten, stoppen und Autostart konfigurieren Bei der Pro-Variante den Zähler auslesen Wenn du für deinen Anwendungsfall noch andere Features brauchst, wäre das sehr interessant zu wissen. Aktuell kann ich die API noch beliebig ändern, ohne dass ich funktionierende Software breche. OCPP wird mit der ersten Software-Version noch nicht kommen, Support dafür wird dann eins der Updates.

Wäre hier nicht bekannt, zumindest als Client. Wenn du die Extension als Access Point verwenden willst, geht aber nur b/g.

Moin, Wenn du wirklich nur bemerken willst, ob es regnet und dir eigentlich egal ist, wie viel, kannst du einen Regensensor, wie z.B. diesen hier benutzen. (Die findest du bestimmt auch irgendwo qualitativ hochwertiger). Du kannst damit entweder direkt den Widerstand an den zwe Kontakten des Sensors messen, oder benutzt den digitalen Ausgang von dem Zusatzboard mit einem geeigneten Bricklet. Das sieht so aus, als ob da ein Komparator drauf sitzt und du mit dem Potentiometer einstellen kannst, wann der auslöst.

Moin, Du kannst dieses Script, das eigentlich für den RED-Brick ist, verwenden. Das sollte auch auf dem Pi funktionieren, du müsstest nur das Sudo-Passwort ändern.

Im Handbuch steht auch (Seite 6): "Das Gerät dient NUR zum Einsatz von dreiphasigen Wechselstromstromnetzen mit Neutralleiter." Ich habe bei mir einen auf dem Tisch legen, den wir zwecks einfacherer Entwicklung nur einphasig verkabelt haben, der startet dann alle 30 Sekunden oder so neu.

Die Sequenznummer kannst du in der Tat eher als Jobnummer betrachten. Die ist nur dafür da, ansonsten identisch aussehende Anfragen unterscheiden zu können. Den Bricklets ist egal, ob du die Reihenfolge der Sequenznummern einhältst oder nicht. Edit: 15 Zahlen, nur die 0 ist für Callbacks reserviert.

Moin, So wie das Script aussieht, sollte das funktionieren: ipcon.connect blockiert, bis die Verbindung aufgebaut ist, deshalb ergibt das keinen Sinn, dass danach ein "Not connected"-Fehler kommt, kann ich mir dann nur so erklären, dass sich dein Brick Daemon beendet o.Ä. Teste mal folgendes: Mach den Brick Viewer auf, verbinde dich zu localhost (Mach dann am besten einen Screenshot vom Setup-Tab und häng ihn hier an), lass dann dein Script laufen, und sieh nach ob der Brick Viewer auch die Verbindung verliert. In jedem Fall kannst du mal ein Brick Daemon-Log anhängen. Der Log Viewer (siehe Start-Menü) verbindet sich automatisch zum Brick Daemon. Im Menü oben gibt es den Punkt "Logfile" -> "View Log Directory", in dem Ordner sollten zwei Dateien liegen (brickd.log und brickd.ini). Häng die beiden mal auch an.

Moin, Da gibt es mit der alten WiFi-Extension und einigen Routern tatsächlich Probleme. Siehe zum Beispiel dieser Thread. Ich habe hier mit dem extra Router für Wifi-Experimente getestet (eine alte Fritz-Box 7360 SL mit Fritz OS 06.33) und sowohl b/g/n, als auch nur g/n funktionieren. An dem Router kann ich leider nicht g auch deaktivieren um den Support für 802.11n zu testen, den der Wifi-Chip auf der Extension zumindest laut Datenblatt haben sollte, aber g/n geht aber von der Extension aus.

Ich hoffe, du hast diese Warnung gelesen, ich vermute deine LEDs würden bei maximal 30 Hz ziemlich flackern und mehr ist wie beschrieben wirklich keine gute Idee. Falls du mit den niedrigen Schaltfrequenzen leben kannst, hast du das nächste Problem, dass du mit einer openHAB-Regel sauber ein 30 Hz Timing hinbekommen musst. Da sehe ich ehrlich gesagt schwarz. Du könntest stattdessen z.B. ein Pythonscript schreiben und mit openHABs Exec-Bindung ausführen. Dann darfst du aber nicht das Relay Bricklet parallel in openHAB benutzen (lies: nicht aus der Inbox als Thing übernehmen).

Das ist eine gute Erklärung, die Platine hat da ja auch ziemlich viel Spiel. Gut das jetzt alles funktioniert!

Das Pluviometer ist ein Reedschalter. Du kannst also, wenn du ein Multimeter oder Oszilloskop zur Hand hast, an die Kontakte gehen und dann Wasser nachgießen, du solltest dann bei jeder Wippenbewegung einen Impuls sehen. Statt des Wassers kannst du auch das Gehäuse vom Pluviometer abmachen (unten an den Befestigungsösen sind zwei Haken, die kannst du reindrücken, dann geht die ganze obere Verkleidung ab) und die Wippe von Hand betätigen. Wenn du von der Seite reinsiehst,siehst du den Magneten, der den Schalter auslöst. Wenn das auch nicht tut, kannst du die Leiterkarte mit dem Schalter aus dem Gehäuse ziehen, das ist nicht geklebt oder so. Vielleicht siehst du da einen Schaden.

Moin, Steckt der Stecker des Pluviometers richtig? Du kannst den Sonnenschutz (siehe dieses Bild) komplett hochschieben, darunter müsste der Stecker des Pluviometers in der rechten Buchse stecken. Sieh dir mal die Kontakte an (das sind nur die zwei mittleren im Stecker), eventuell siehst du da was. Gruß, Erik

Moin, Sorry dein Post ist hier etwas untergegangen. Den MQTT-Broker musst du selbst mitbringen, die Wallbox hat nur einen MQTT-Client Nein und Ja: Die Ladeleistung anpassen kannst du sowohl per MQTT, als auch über das Webinterface von minimal 6 Ampere bis zum konfigurierten Limit der Wallbox. Die Box kann aber nicht zwischen einphasigem und dreiphasigem Laden umschalten. Es kann aber sein, dass dein Auto selbst auf einphasiges Laden wechselt, wenn du den Ladestrom weit genug begrenzt, beim Zoe passiert das z.B. irgendwo zwischen 8 und 10 Ampere (habe den genauen Punkt gerade nicht im Kopf).

Das sieht wieder genau nach dem Problem aus, das die Spezialversion fixen sollte: Alle 5 ThingHandler-Threads hängen wieder beim Versuch zu testen ob ein Bricket erreichbar ist. Bist du dir sicher, dass es die Version ist? ;) Wenn ja muss ich mir das nochmal in Ruhe ansehen, Multi-Threading ist kompliziert. Das kommt auf jeden Fall ganz oben auf die openHAB-Todo-Liste, wird aber wie gesagt noch etwas dauern, bis ich dazu komme.

Bezüglich der Taktfrequenzen: Brick Daemon bis einschließlich 2.4.2 erwartet eine core-Clock von 250 MHz (die die du mit vcgencmd measure_clock core ausgelesen hast). Beim Pi Zero kannst du die Frequenz mit core_freq=250 in /boot/config.txt festlegen. Die Umbauarbeiten in 2.4.2 und 2.4.3 sind genau dafür da solche Probleme zu umgehen, der Pi skaliert nämlich die SPI-Clock mit der core_freq, d.h. wenn er auf 400 MHz läuft, läuft SPI so schnell, dass die Bricklets das nicht mehr verstehen. Das liegt vermutlich daran, dass der Brick Daemon für den Pi auch Stacks per USB unterstützt. Das ist keine spezielle gestrippte Version, die nur SPI kann. Das ist interessant, dazu muss ich @photron mal befragen. Das sollte kein Problem sein, du hast ja ein HAT Zero, das hat sowieso keine RTC an Bord. Nein, weil der Kernel nicht genug CS-Pins unterstützt. Meines Wissens nur zwei. Ab Brick Daemon 2.4.2 umgehen wir sowieso das ganze Kernel-Interface und sprechen direkt mit dem BCM2835.