Eckdaten

• Hardware: WARP3 Charger Smart, 22 kW; eine davon als Lastmanager im Verbund, die anderen fremdgesteuert

• Zähler je Stellplatz: Eastron SDM630-MID Modbus (MID-konform, 3-phasig, Modbus RTU)

• Hausanschluss-Erfassung: Eastron SDM630MCT mit 3 × Klappstromwandler 100/5 A direkt am HAK — Basis für dynamisches Lastmanagement, das auf den Restverbrauch der Liegenschaft (9 WE + Allgemein + Heizung) reagiert. Kein Abrechnungszähler.

• Topologie: Keller-Hauptverteiler → Sammelleitung NYY-J 5 × 16 mm² (ca. 30 m) → Garagen-Sammelverteiler in Garage 1 → 5 Stichleitungen 5 × 10 mm² zu den Garagen-UVs; zusätzlich 25 m NYY-J 5 × 10 mm² zum Hofstellplatz, der keine eigene Außen-UV bekommt (FI/MID/LS sitzen alle im Keller)

• Bus: Erfassungszähler + 6× MID = 7 Modbus-RTU-Slaves auf einem RS485-Bus, durchgeschleift, am Ende Modbus-TCP↔RTU-Gateway (Idee: USR-DR302 o. ä.) im Sammelverteiler. Lastmanager-WARP3 spricht das Gateway per LAN/Modbus-TCP an, Slave-IDs 1–7.

• § 14a EnWG: drosselbar auf 4,2 kW/LP, geplante Variante: potentialfreier Steuerkontakt vom Netzbetreiber an den EN-Eingang der Lastmanager-Box, Webinterface-Automatisierung begrenzt im Trigger-Fall den Verbund auf 6 A/Phase

• KfW-Förderung vorgesehen (Antrag selbstverständlich vor Auftragsvergabe)

Fragen:

1. Externe MID-Zähler per Modbus an die WARP3 Smart
Lassen sich die externen Stellplatz-Zähler zuverlässig über den TCP↔RTU-Umweg oder direkt per RTU an die einzelnen Wallboxen (Smart) anbinden? Würde das Vorteile für das "Phasenoptimiertes dynamisches Lastmanagement" mit sich bringen? Natürlich habe ich auch die Pro-Box gesehen, doch wir möchten den Zähler gerne außerhalb der Box haben.

2. Vergleichbare Installationen mit 5–6 WARP3 schon in Betrieb?
Ich finde online sehr wenig bis gar nichts zu vergleichbaren Installationen. Hat hier wer bereits einen größeren Verbund (5+ Boxen) mit dynamischer Hausanschluss-Begrenzung und wirklich gemischter Phasenbelegung am Laufen? Wie reagiert das Lastmanagement bei sprunghaftem Allgemeinverbrauch, wie sieht es mit Reaktionszeiten und Stabilität auf Dauer aus?

3. Modbus-Gateway-Empfehlung
USR-DR302 und Waveshare DIN-Rail sind meine bisherigen Kandidaten. Gibt es bekannte Stolperfallen mit der WARP3-Polling-Frequenz, Timeout-Verhalten, Slave-ID-Mapping-Bugs? Oder eine klare Empfehlung für ein Hutschienen-Gateway, das mit Tinkerforge unproblematisch zusammenspielt?

4. Phasenrotation bei 6 Boxen
Wir planen symmetrische Verteilung (je 2 Boxen pro Rotation L123/L231/L312). Gibt es in der Praxis Probleme mit der Rotationserkennung bei einphasig ladenden Fahrzeugen über mehrere Boxen hinweg, oder läuft das mit dem WARP3-Lastmanager wirklich „set and forget"?

5. § 14a EnWG-Anbindung
Gibt es Erfahrungen mit RheinNetz / RheinEnergie? Was muss eingerichtet werden?

6. Vorrüstung — heute schon was bedenken?
Die Nachrüstung der drei Vorrüstungs-Plätze soll später auf Hardware + DIP-Schalter + Lastmanager-Eintrag + Phasenrotation + NFC + Firmware-Update reduziert sein, ohne Eingriff in Wand oder Verteiler. Übersehe ich etwas, das man heute beim ersten Schwung mit erledigen sollte, damit es in 1–3 Jahren keine böse Überraschung gibt?

7. Was übersehe ich generell?
Direktverkaufs-Modell, MID-Plombierung an zwei Orten (Keller + Garage 1), § 14a-Anmeldung, KfW vor Auftragsvergabe — habe ich auf dem Schirm.
Aber was übersehe ich und was sollte ich unbedingt vor der Umsetzung klären?

Vielen Dank im Voraus für jeden Hinweis!
Patric

jetzt, wo der Einfluss der Sonne an der PV-Anlage wieder deutlicher wird, wandert mein Blick vermehrt zur Ertragsprognose.
Ist es möglich auch die Summe aller PV-Flächen in der Webansicht als Kurve darzustellen?

Ich weiß, dann ist die Skalierung etwas gestreckter, aber im Bedarfsfall, könnte sie doch auch kurzzeitig ausgeblendet werden.

Auf diese Weise, ist die manuelle Überlegung von geeigneten Zeitpunkten zum Betrieb von großen Verbrauchern einfacher.

Vielen Dank für eine mögliche Umsetzung.

Beste Grüße
Mario

beim programmieren im HomeOffice oder in der Hochschule stehe ich vor dem Problem, dass ich ein Programm erst vollständig testen kann, wenn ich wieder Zurgriff auf die Bricks habe.

Ich kann selbstverständlich eigene Generatoren zum Testen meines Programmteils programmieren. Aber das ist je nach Projekt etwas umständlich. Gleichzeitig kann man so das Zusammenspiel zwischen brickd und dem eigenen Programm nicht testen.

Daher wäre mein Vorschlag, dass man beispielsweise in brickd eine Funktion implementieren könnte, damit quasi das Brick verhalten mit zufälligen Werten und automatischen (zufälligen) Callback Auslösung simuliert werden kann. Das würde die Programmierung beschleunigen und man könnte sein Programm anschließend direkt im Testumfeld nutzen. Fehler in der Programmierung bei der API wären so auch schon vorher aufgefallen. Das könnte vor allem Anfänger den Einstieg vereinfachen und so noch schneller positive Ergebnisse ermöglichen.

Viele Grüße 

Testling

ist ja bereits diskutiert worden, wie ein Tasmota-Stromzähler seine Werte an die Warp3 liefern kann.
Die Lösung dort sendet direkt per Post-API die Werte. Das funktioniert aber nicht so wie gewünscht, weil der Power Wert z.B. bei eHZ Zählern immer positiv ist, die Wallbox aber
ein korrektes Vorzeichen erwartet. Zudem finde ich persönlich den Weg über MQTT zukunftssicherer. MQTT ermöglicht eine saubere "Separation of Concerns".

Als Lösungsvorschlag habe ich ein python basiertes Middlewareprojekt gestartet - siehe https://github.com/WolfgangFahl/WarpMQTT2Api

Bei mir läuft die Software auf einem raspberry PI. Einfach von pypi oder direkt vom github repository aus installieren. Dann gibt es ein warp3 Kommandozeilen-Werkzeug:
 

warp3 -h
usage: warp3 [-h] [--config-path CONFIG_PATH] [--mqtt-broker MQTT_BROKER]
             [--mqtt-port MQTT_PORT] [--mqtt-topic MQTT_TOPIC]
             [--mqtt-username MQTT_USERNAME] [--mqtt-password MQTT_PASSWORD]
             [--update-interval UPDATE_INTERVAL] [--dry-run]
             [--wallbox-host WALLBOX_HOST] [--power-tag POWER_TAG]
             [--in-field IN_FIELD] [--out-field OUT_FIELD]
             [--time-field TIME_FIELD] [--meter-id METER_ID] [--debug]

MQTT to Warp3 Wallbox Middleware

options:
  -h, --help            show this help message and exit
  --config-path CONFIG_PATH
                        Path to YAML configuration file
  --mqtt-broker MQTT_BROKER
                        MQTT broker address
  --mqtt-port MQTT_PORT
                        MQTT broker port
  --mqtt-topic MQTT_TOPIC
                        MQTT topic to subscribe to
  --mqtt-username MQTT_USERNAME
                        MQTT username
  --mqtt-password MQTT_PASSWORD
                        MQTT password
  --update-interval UPDATE_INTERVAL
                        Minimum update interval in seconds
  --dry-run             Run without updating the wallbox
  --wallbox-host WALLBOX_HOST
                        Wallbox host URL
  --power-tag POWER_TAG
                        Tag in MQTT data containing power information
  --in-field IN_FIELD   Field name in MQTT data containing energy input
  --out-field OUT_FIELD
                        Field name in MQTT data containing energy output
  --time-field TIME_FIELD
                        Field name in MQTT data containing timestamp
  --meter-id METER_ID   Meter ID to use
  --debug               Enable debug logging

Ausgangspunkt ist ein tasmota-Zähler, der mit MQTT Nachrichten sendet. 

Siehe z.B. https://docs.bitshake.de/script/

Bei mir sehen diese Nachrichten so aus:

{"Time":"2025-05-10T08:24:13","eHZ":{"E_in":67299.845,"E_out":50268.783,"Power":0,"Power2":4111}}

Zunächst wird ein Stromzähler als API - Zähler für den Netzanschluss eingerichtet. Die ID des Zähler kommt dann in die Konfigurationsdatei zur Beschreibung des Zählers und der MQTT Verbindung:
 

# WF 2025-09-05
# warp3 middleware configs
# Wallbox
wallbox_host: "http://wallbox.bitplan.com"
# Zähler
meter_id: 2
# Update Frequenz in Sekunden - 1 bis 2 Sekunden sind sinnvoll
update_interval: 1 
# Beschreibung der MQTT Nachricht
time_field: "Time"
power_tag: "eHZ"
# Genaue Wirkleistung
power_field: "Power2"
# Zählerwerte zur Abschätzung und Vorzeichenberechnung
in_field: "E_in"
out_field: "E_out"
# MQTT Kommunikationseinstellungen
mqtt_broker: "mqtt.bitplan.com"
mqtt_port: 1883
mqtt_topic: "tele/tasmota_****/SENSOR"
mqtt_username: "****"
mqtt_password: "****"
update_interval: 1 # - every second
dry_run: false

Ein start script:
 

#!/bin/bash
# WF 2025-05-10
# Start Warp3 with nohup and log to /var/log/warp3

LOGDIR="/var/log/warp3"
LOGFILE="$LOGDIR/warp3.log"
APP="warp3"
OPTIONS="--config-path /home/wf/.warp3/config.yaml"

sudo mkdir -p "$LOGDIR"
sudo chmod 755 "$LOGDIR"
sudo chown wf:wf $LOGDIR

timestamp=$(date '+%F %T')
echo "$timestamp - INFO - 🚀 Starting warp3" >> "$LOGFILE"

nohup "$APP" $OPTIONS >> "$LOGFILE" 2>&1 &

crontab eintrag:
 

# run warp3 on reboot
@reboot /home/wf/bin/warp3start

dann erscheint im Log
 

2025-05-10 08:13:27 - INFO - 🚀 Starting warp3
2025-05-10 08:13:28,476 - INFO - Starting MQTT to Warp3 middleware
2025-05-10 08:13:28,476 - INFO - MQTT broker: mqtt.bitplan.com
2025-05-10 08:13:28,476 - INFO - MQTT topic: tele/tasmota_B13330/SENSOR
2025-05-10 08:13:28,477 - INFO - Wallbox host: http://wallbox.bitplan.com
2025-05-10 08:13:28,477 - INFO - Power tag: eHZ
2025-05-10 08:13:28,477 - INFO - Meter ID: 2
2025-05-10 08:13:28,503 - INFO - ✅ Connected to Warp3 - Firmware version: 2.8.0+6810d7c9
2025-05-10 08:13:28,523 - INFO - ✅ Meter 'Hausanschluss' at location 4 measures: 74: Summe der Phasenwirkleistungen (Bezug - Einspeisung)
2025-05-10 08:13:28,528 - INFO - Starting MQTT loop
2025-05-10 08:13:28,529 - INFO - Connected to MQTT broker at mqtt.bitplan.com
2025-05-10 08:13:28,529 - INFO - Subscribed to tele/tasmota_B13330/SENSOR
2025-05-10 08:13:43,751 - INFO - Power value: -3600W
2025-05-10 08:13:43,777 - INFO - ✅ -3600 Watt set
2025-05-10 08:13:53,754 - INFO - Power value: -3960W
2025-05-10 08:13:53,777 - INFO - ✅ -3960 Watt set
2025-05-10 08:14:03,761 - INFO - Power value: -3960W
2025-05-10 08:14:03,786 - INFO - ✅ -3960 Watt set

Nun ist der Zähler mit der eingestellten Tasmota-Sende Frequenz für die wallbox sichtbar.

Ist für den Raspberry Pi. Wobei ich aktuell einen ZERO 2 W nutzte. Als erstes möchte ich die Bricklets die ich habe, in HomeAssistant sehen/nutzten können.

Sourcen: https://github.com/jedie/tinkerforge2mqtt

So langsam Formen an, das auch was in HomeAssistant ankommt:

Ich bin vor Kurzem auf eine Frage gestoßen, bei der ich Sie um Hilfe bitten möchte.

Ich überlege, in meinem 3D-Drucker Schrittmotoren und Treiber mit geschlossenem Regelkreis zu verwenden. Wenn ich für eine Achse zwei Schrittmotoren hätte, würde ich sie parallel anschließen. Ist dies auch mit Closed Loop Schrittmotoren möglich, da an diese Encoder angeschlossen sind?

leider habe ich keine Informationen im Internet gefunden, die für mein Projekt hilfreich wären.

Hintergrund: Ich habe eine PV-Anlage (ca. 16 kW Peak mit 2 Solar Edge Wechselrichter (einmal SE500H für Hausdach und einmal SK8 für Flachdach-Garage) mit Teslawall-Speicher, aber noch kein Smarthome (nur WLAN per Fritz!Box vorhanden)...

und möchte im Zuge von Elektrikarbeiten eine Wallbox bis 11 kW anschließen lassen (entsprechendes Kabel mit FI liegt schon und wenn der Elektriker da ist dann kann er es gleich mitmachen). Als Wallbox möchte ich (da zukünftig wohl Elektrofirmenfahezeug) entweder die

• WARP3 Charger Pro oder die
• OpenWB oder
• Go e

zulegen, wobei meine Präferenz zur WARP3 Charger Pro geht.

Meine Frage: kann ich die WARP3 erstmal ohne weitere Komponenten und ohne Fach-Programmierung (LAN-Kabel, Raspberry PI, EVCC-Programmierung, ...) zum Aufladen nutzen (bspw. fest eingestellt auf 4 kW oder 6 kW) bzw. wenn nicht, was ist die Mindestausstattung neben der WARP3 selbst und geht das ohne große Programmierkenntnisse ? (habe mal früher mit BASIC einiges auf dem C64 🙈programmiert und etwas C+, bin da aber raus seit 30 Jahren...)

Habe derzeit keine Zeit mich mit PV-Überschuss-laden (1-phasig/2-phasig) und Raspberry/EVCC zu beschäftigen und will das dann in einem oder 2 Jahren realisieren.

Grüße

Martin

ich würde gerne einen Hall Sensor 2.0 Bricklet und einen Drehstromzähler auslesen und die Daten per Node-Red auf einem PC weiterverarbeiten.

Dazu habe ich mir folgendes gedacht:

- Der ESP32 Ethernet Brick ist über ein Ethernetkabel an meinen PC angeschlossen

- Der Hall Bricklet ist ganz normal an den ESP Brick angeschlossen

- Der Drehstromzähler, welcher über RS485 seinen Stand durchgibt ist mit einem dazwischen geschaltenen RS485 Bricklet an des ESP Brick angschlossen.

Der ESP Brick soll jetzt als MQTT-Client die Daten der beiden "Sensoren" an den Broker auf dem PC schicken, damit NodeRed diese als weiterer Client bekommt. Dazu will ich in der Arduino IDE ein Programm schreiben was genau das macht und dieses auf den ESP laden. Ich habe gelesen, dass es mittlerweile eine MQTT-API gibt. Hier weiß ich jedoch nicht wie diese angewendet wird. Wenn ich in der Arduino IDE eine eigene Firmware für den ESP schreibe, trage ich dann hier auch, wie in der Anleitung der MQTT-API beschrieben, die Adresse des Brokers etc. ein?

Ich habe außerdem gelesen, dass die Verwendung des ESP32-Bricks über Ethernet viel zusätzlicher Programmierungsaufwand bedeutet. Wäre es hier sinnvoller einfach einen Master-Brick 3.2 zu verwenden und per USB anzuschließen? Worüber die Verbindung geht ist mir prinzipiell egal.

Vielleicht zerdenke ich das ganze auch und es gibt eine einfachere Lösung. Falls mir jemand weiterhelfen könnte, wäre ich sehr dankbar.

Grüße

Dazu hab ich https://github.com/MakeMagazinDE/Taupunktluefter und die passende FAQ https://www.heise.de/hintergrund/FAQ-zum-Taupunktluefter-aus-Make-1-22-6526328.html gefunden... Aber das ganze mit Tinkerforge Komponenten und Python zu machen, macht doch viel mehr Spaß...

Als ersten Minischritt hab ich mal in tinkerforge2mqtt eingebaut das beim Humidity V2 Bricklet der Taupunkt berechnet wird.

Idee wäre aber das ganze autonom zu machen und per MQTT nur Status Informationen aufzugeben, aber nicht die Regelung in Homeassistant zu "programmieren"... Sodas die Regelung auch funktioniert, wenn HA nicht läuft/erreichbar ist.

Die Basis wäre:

• Raspberry PI ZERO
• ZERO Hat
• 2x Humidity V2 Bricklets

Offene Fragen:

• "Industrial Dual Relay Bricklet" oder "Solid State Relay Bricklet 2.0" nehmen zur Lüfter Steuerung?
  • Pro Relais: Billiger, aber wie viele Schaltvorgänge machen die Relais mit?!?
• Belüften oder Entlüften oder beides?!? (Wobei eine Belüftung, auf jeden Fall zu bevorzugen ist, wenn eine Heizung im Keller ist ;) Oder alte Kamine, sonst zieht man Zuluft durch den Kamin, was evtl. stinkt.)

Habe im Netz gesehen das es eine Anzeige gibt wo man die Daten vom Wechselrichter sich anzeigen lassen kann auf eine LED Anzeige .

Die Daten werden per Wlan zur Anzeige gesendet .

Besteht evtl. interesse so ein Projekt mit umzusetzen .

LG Mathias

Ziel war es:

• mind. 80kg Last tragen
• präzise Ansteuerung
• einbinden in Workflow

Der Tisch wurde aus Stabilitätsgründen aus 40x40-Aluprofilen gebaut. Der Drehteller (2mm Aluminium) wird von 20x20-Aluprofilen gestützt. Als Antrieb wird ein Schrittmotor mit anschließender 50:1 Untersetzung verwendet. Der Riemen liefert noch einmal eine Untersetzung von 72:14.

Für den Schrittmotor wird der "alte" Stepper-Brick verwendet, weil damit einfach höhere Stromstärken (2,2A) möglich sind. Dazu kommen 36V.
Auf den Brick ist ein Lüfter montiert, der softwareseitig mit anspringt, sobald der Stepper "enable" erhält. Dies ist auch notwendig.

Die Winkelauflösung beträgt somit 0,042' (Bogenminute) oder 2,5'' (Bogensekunde). Selbst nach mehreren Drehungen ist optisch kein Schrittverlust bemerkbar. Und Bilder - aufgenommen in verschiedenen Umdrehungen - liegen perfekt übereinander.

Die Steuerung übernimmt der gute alte RED-Brick mittels python-Script. Auf dem Bild ist noch das erste Interface zusehen: Start- und Stoppknopf, Einstellungen (Rotary Encoder) für Bildanzahl und Pause in Millisekunden, sowie manuell "drehen" (vor- und rückwärts).

Nachdem mehrere Änderungen an der Steuerung durchgeführt werden sollten, wurde sich entschieden, nicht noch mehr "bunte Knöpfchen" zu ergänzen, sondern auf das 128x64-LCD-Bricklet mit Touch zu setzen. Es können nun "Einstellungen" direkt vorgenommen werden, ohne jedes Mal den Quellcode anzufassen. Hinzugekommen ist noch das "Dauerdrehen mit variablen Geschwindigkeiten". Außerdem spart es wieder einen Master-Brick ein. Achja, der Distanzsensor dient dafür, dass man den Abstand Kamera <-> Objekt bequem messen kann.

Da noch genug "Tabs" auf dem Display übrig sind, können noch weitere zukünftige Funktionen / Einstellungen implementiert werden.

Das Industrial Quad Relay Bricklet löst direkt die Kamera aus (Port 0 => True --> Focus; Port 0 und 1 => True --> Shutter). Somit können x Bilder je Umdrehung aufgenommen, Kamera neu positioniert und erneut aufgenommen werden.

Video Display

Video 2

Die ersten Resultate könnt ihr hier sehen: sketchfab

Mein Favorit ist bis jetzt die Blaubeere. Die angegebenen 432 Einzelaufnahmen setzen sich noch einmal jeweils aus einem Fotostacking über je 7 Bilder zusammen. Größere Objekte sind bereits geplant.

ich habe dieses Jahr mit der Imkerei angefangen. Im Sommer steht bei den Bienen immer die Varroabehandlung an. Varroen sind Milben welche die Bienen schädigen und im schlimmsten Fall zum Tod des Volks führen können.

Eine der Methoden um die Varroen los zu werden ist die Behandlung mit Ameisensäure. Man fühlt Ameisensäure in einen Verdunster und stellt diesen in den Stock. Über den Zeitraum von 2 Wochen verdunstet die Säure und schädigt die Varroen so dass diese von den Bienen fallen.

Das Problem dabei ist, dass eine zu hohe Konzentration von Ameisensäure auch die Bienen schädigt - auch hier kann das Volk bei Überdosierung sterben.

Jetzt hatte ich die Idee die Verdunstung mittels einem Raspberry Pi und Tinkerforge-Bausteinen zu steuern. Auf diese Weise wäre man sicher dass immer genau die richtige Menge an Säure verdunstet. Allerdings kann ich bisher keinen entsprechenden Sensor finden - gibt's sowas überhaupt. Bzw. hat jemand alternative Ideen wie man sicherstellen kann das die Konzentration der Ameisensäure immer innerhalb eines gewissen Rahmens ist?

Danke für's lesen (und antworten )

vor längerer Zeit bin ich auf folgendes GitHub Projekt gestoßen: Open-Spectrometer

Diese Idee als Bausatz könnte beispielsweise interessierte Laien den Weg in die private Forschung verhelfen oder Bildungseinrichtungen könnten diesen Bausatz nutzen, um in Bildung und Forschung die Studierende /Schüler (m/w/d) auszubilden.

Eine ähnliche Idee mithilfe eines Spektrometers wären optische Quanten-Zufallsgeneratoren. Diese Generatoren gibt es aktuell beispielsweise von der Firma: QAnt. Leider gibt es dazu aktuell ein Patent: Patent QRNG.

Mit entsprechender Modularisierung wären in Zukunft Erweiterungen zu diesem Bausatz möglich beispielsweise in die Richtungen Analytik, Biochemie usw.

Viele Grüße 

Testling

ich habe ihr eine Wallbox von tinkerforge und würde jetzt gerne mit den Modulen eine kleinen Heizstabregelung mit Schwingungspaketsteuerung bauen.

Fronius Ohmpilot und my-pv arbeiten dabei IMHO mit einem Thyristor-Leistungssteller auf einer Phase und die beiden anderen Phasen werden über "Relays" zugeschaltet. 

Meine Idee ist es für eine Phase so einen Steller zu  verwenden, oder ähnliche Geräte.

https://www.chiemtronic.de/produkte/t-drive-1ph-compact-maxi/

und die 2 Phasen über Einfache 16A Relais zu schalten. Der Stellgrad soll einfach in 0-100% über MQTT kommen. 

ESP32 Ethernet Brick
Industrial Analog Out Bricklet 2.0
Industrial Dual AC Relay Bricklet
ESP32 Power Supply

Mit den Komponenten sollte ich da ja eigentlich hinkommen? Bis dato hatte ich mit dem ESP32 nur Berührung in Kombination mit der Arduino Umgebung. Müsste mich da wohl einarbeiten. 

nach doch sehr langer Zeit habe ich meine kleine Sammlung an (alten) TF Komponenten wieder ausgegraben.
Der Grund ist einfach - sie liegen derzeit bloß herum und ich möchte ihnen eine "Sinnvolle" Aufgabe geben.

Sinnvoll in dem Sinne, dass ich inziwschen doch einiges in Richtung Smarthome - und Energiemonitoring betreibe - über verschiedene Lösungen, alle sammeln sich in HomeAssistant.
Nun war meine Idee, mit meinen Tinkerforge komponenten etwas zu realisieren, was ebenfalls in HomeAssistant eingebunden werden kann.
Dazu gibt es hier ja bereits ein paar Ideen für die Anbindung

Aber auch die neuen ESP32 Boards klingen hier "spannend" - denn mit ESPHome sollte ggf. auch hier eine Anbindung an HomeAssistant möglich sein.

Derzeit habe ich folgende Komponenten von TF zur Auswahl:

• 1x RedBrick

• 2x MasterBrick 1.1
• 2x MasterBrick 2.1

• 2x Chibi-Extension 1.0
• 1x Wifi-Extension 1.0
• 1x Wifi-Extension 2.0
• 1x Ethernet-Extension 1.0

• 1x PowerSupply StepDown 1.1

Bricklets (Steuerung):

• 1x LinearPoty 1.1
• 2x Joystick 1.1
• 1x RotaryEncoder 1.0
• 1x RFID / NFC Reader
• 1x Keypad 4x3
• "MultiTouch" 1.0

Bricklets (Ausgabe):

• 1x Oled Display 128x64 1.0

Bricklets (Sensorik):

• 2x Temperature 1.1
• 2x Barometer 1.0
• 1x Hummidity 1.1
• 1x Temperature IR 1.1
• 1x Accelerometer 1.0
• 1x Realtime Clock 1.0

Bricklets:

• 1x PTC 1.0
• 2x IO-4 1.1
• 1x Dual Relay 1.1

z.B. für eine kleine Wetterstation habe ich eigentlich die "meisten" Komponenten schon zusammen - temperatur, hummidity und Barometer...
Auf der anderen Seite habe ich für eine Wetterstation aktuell eher keine Verwendung... Natürlich kann ich mir die Wetterdaten einfach in HomeAssistant ausgeben lassen, aber "was bringt es"?
Ich habe aktuell noch nichts, wofür ich diese Daten wirklich benötigen könnte...🤔

Des weiteren stehen mir aktuell noch zwei Arduino-Boards, ein Wmos D1 R2 (ESP 8266) und 'einige' Komponenten dafür zur Verfügung, wie mehrere Rotary Encoder, Potentiometer, Distance IR, 7-Segment LEDs, usw...
Vielleicht kann man diese Komponenten in ein Projekt mit aufnehmen?

Ich habe jetzt auch gesehen, dass durchaus ein paar Interessante Zubehör-Komponenten im Shop vorhanden sind - wie z.B. Hutschienen-Adapter ...

Ach ja... eine PV Anlage ist vorhanden (aber hier wird schon der gesamte Energiefluss erfasst) - und eine Wallbox ist ebenso vorhanden - welche selbstständig PV Überschuss verwalten kann, da sie mit dem Wechselrichter der PV kommuniziert.

- Haut raus, was für Einsatzzwecke Euch mit den o.g. Komponenten einfallen... :D
Ich versuche derweil mir ebenfalls noch etwas einfallen zu lassen ^^

für eine Raumüberwachung wollte ich gerne die aktuellen Messwerte zur Temperatur und Luftfeuchtigkeit im 4x7-Display anzeigen. Die Doku liefert zwar ein Beispiel für die Temperatur, dies ist jedoch nicht auf die V2-Versionen der Bricklets ausgelegt. Eine einfache Anpassung der API-Bindings reicht leider nicht aus. Also habe ich mich an eine Anpassung der Scripte gemacht. Hier das Ergebnis, vielleicht verkürzt es ja jemandem die Umsetzungszeit. Ich bin kein großer PHP-Programmierer, Verbesserungsvorschläge sind daher gerne willkommen.

Ich rufe das Script via Crontab zu jeder vollen Minute auf. Nach der Anzeige der Temperatur pausiert der Prozess für 30 Sekunden und gibt dann die Luftfeuchtigkeit aus. So wechselt die Anzeige in 30sek-Zyklen.

Viel Spaß damit.

Viele Grüße,

Christian

Info2Display.php

ich bin gerade im Bau eines großen RC-Schiffes. Ein altes Problem, ich will viele Funktionen, aber keine anständige Fernsteuerung ist auf dem Markt. Ein Anbieter hat noch eine solide alte analoge Fernsteuerung im Angebot, jedoch wird es hier teuer und mehr als hundert Funktionen sind auch nicht möglich.

Daher liegt es nahe, das Projekt mit Tinkerforge umzusetzen. Kostet nicht mehr, kann aber gewaltig mehr! Hier angedachte Funktionen:

- 2 Hauptmotoren

- Ruder

- 2 Querstrahlruder

- 100 Kabinenbeleuchtungen (einzeln Schaltbar mit Random-Aktivität, dass das Schiff quasi lebt)

- 10 weitere Lichtszenarien (Positionslichter, Suchscheinwerfer, Decksbeleuchtung, usw.)

- Ballastwassertanks (spart Bleib, ist realistischer und man kann auch eine Schlagseite simulieren)

- Stabilisatoren

- 2 Kräne mit 3-4 Funktionen

- Heckgalgen

Dafür sollen auf dass Schiff diverse Bricks eingesetzt werden (z.B. Servo, Master, DC, GPS, IMU, WLAN). Auch will ich den RED-Brick einsetzen, um z.B. folgende Funktionen umzusetzen:

- Web-Konsole über WLAN für Licht

- Web-Konsole über WLAN für Motorparamater, Ruderlagenanzeige, Schiffslage (Rollen, Stampfen, Beschleunigung), Batteriestatus, Stromverbrauch etc.

- Web-Konsole über WLAN für Kransteuerung

- Rückkehrfunktion, falls Verbindung abreißt, dann fährt Schiff zum Startpunkt zurück, nur auf vorher gefahrenen Strecken

- automatische Positionshaltung (trotz Wind und Strömung bleibt Schiff auf Position)

- automatische Ausrichtung (mit Ballastwasser)

Das wird vermutlich mehrere Monate ein Programmierspaß werden . Dem Detailgrad sind so nahezu keine Grenzen mehr gesetzt. Vermutlich kann dann das kleine Schiff am Ende mehr als das Original .

Bei der Steuerung bin ich mir noch nicht ganz sicher wie sie werden soll. folgende Varianten sind möglich:

- Analoge Fernbedienung, analoger Empfänger für Ruder und Motoren. Licht, Kräne usw. über Webkonsole per WLAN. Vorteil man brauch nur einen beliebigen Browser und keine Programmierung auf z.B. Android. Nachteil, analoge alte Technik für Steuerung, ergo keine Motorparameter abrufbar.

- Alles über ein Androidprogramm. Vorteil keine extra Fernbedienung. Nachteil keine analogen Steuerknüppel, steuern nur über Android-Touch-Display möglich, evtl. angeschlossenen Joystick und man muss Android-App schreiben.

- Steuerung Fahrfunktionen mit analogen Bricklets (müsste dann über WLAN mit Schiff-Stapel kommunizieren, denn Chibi gibt's ja wohl nicht mehr). Licht etc. über WLAN per Webkonsole von Tablet. Vorteil man kann eine alte Fernbedienung umrüsten und brauch nur einen beliebigen Browser, keine Androidsoftware.

Letzteres wäre meine bevorzugte Variante. Generell tauchen folgende Fragen auf:

- Hat jemand Erfahrung wie weit man auf offener Fläche mit einem Smartphone und der WIFI-Extension kommt? Denn so 100m sollten es für ein Schiffsmodell schon sein.

- Kann ein Stapel mit RED-Brick und WIFI-Extension (als Access Point konfiguriert) mit einem andern Stapel mit WIFI-Extension kommunizieren? Zeitgleich sollte einer über WLAN auf die Webkonsole vom RED-Brick zugreifen können.

Vielen Dank für den Austausch Eurer Erfahrungen und Tipps!

Gruß

boritian

nachfolgend möchte ich Euch eine Air-Quality-Station (vergleichbar mit einer CO2- bzw. Luftqualitäts-Ampel) als DIY-Projekt vorstellen.
Diese weist darauf hin, wann ein Raum gelüftet werden muss.

Gemessen werden CO2, VOC (vereinfacht: Gerüche), Temperatur, Feuchte, Luftdruck und Partikel (d.h. Feinstaub, Aersole, Sporen ect.) mittels CO2 Bricklet 2.0, Air Quality Bricklet und Particulate Matter Bricklet.
Das Gehäuse der Air-Quality-Station besteht aus MakerBeam-Profilen und 3 mm Plexiglas-Platten. Es ist vorn und hinten offen, damit der integrierte Lüfter das Gehäuse durchströmen kann. Die Durchströmungsrichtung ist dabei so gewählt, dass die Sensoren direkt mit der angesaugten Raumluft beaufschlagt und nicht durch die Abwärme der sonstigen Elektronik beeinflusst werden. Außerdem sind Grobstaubfilter integriert, die zumindest die Elektronik-Bauteile schützen, die keine Messaufgaben haben.

Den Aufbau habe ich zuvor mittels Google SketchUp in 3D geplant und konnte so die Abmessungen und die Anordnung der Bauteile optimieren.

Im Lüfter sind bereits einige LEDs integriert, die zusammen mit weiteren LEDs (Adafruit 1643 NeoPixel) die Ampelfunktion bilden (Ansteuerung über LED Strip Bricklet 2.0 und 5 V Versorgung mittels Spannungswandler Kemo #M015N). Der Lüfter hat bionisch optimierte Schaufeln (Noiseblocker B12X-PS) und ist daher mit gedrosselter Drehzahl (PWM mittels IO-4 Bricklet 2.0) praktisch nicht hörbar.

Bei einer Überschreitung der Grenzwerte für CO2 (1.000 bzw. 2.000 ppm), IAQ (100 bzw. 200) oder Feinstaub bzw. Aerosole (20 bzw. 40 µg/m³) schaltet die Ampel auf Gelb oder Rot und gibt kurze akustische Warnsignale aus (Piezo Speaker Bricklet 2.0 - siehe Video: IAQ-Station.avi). Die Messdaten werden auf einem LCD 128x64 Bricklet angezeigt. Nach Sonnenuntergang werden Ampel und die Displaybeleuchtung gedimmt und nachts abgeschaltet; es sei denn, man berührt das Display - dann erfolgt die Anzeige für weitere 30 Minuten.
Außerdem ist ein Empfänger für Außentemperatur- und Feuchte integriert (Outdoor Weather Bricklet + Temperatur/Luftfeuchte Sensor TH-6148). Auf Basis der Luftdruck-Entwicklung wird zudem eine kleine Wetterprognose eingeblendet.

Verarbeitet wird alles von einem Raspberry Pi 4B mit HAT Brick. Hierüber erfolgt auch die Stromversorgung mithilfe eines konventionellen 12 V Netzteils.
Die gemessene elektrische Leistungsaufnahme beträgt ca. 6 W.

Die Messwerte werden in einem 30 s Intervall erhoben und in einem Intervall von 5 Minuten auf der MicroSD-Karte des Raspberry Pi gespeichert. Eine Ausnahme bildet die Partikelmessung, hier wird nur im 10 Minuten Intervall gemessen und der Sensor zwischendurch deaktiviert, um die begrenzte Lebensdauer des Particulate Matter Bricklet besser auszunutzen.

Ausblick: Im nächsten Schritt sollen mithilfe der aufgezeichneten Messdaten die zeitlichen Verläufe der einzelnen Messgrößen auf weiteren Display-Tabs angezeigt werden, die per Wischen aufgerufen werden. Habt Ihr Tipps für die Programmierung der Anzeige von Grafen auf dem LCD 128x64 Bricklet in Python - ohne, dass jeder Pixel einzeln definiert werden muss?

Viele Grüße
Michael

Bilder:

In Homeassistant werden verschiedene werte angezeigt.

wenn man Pv Überschuss laden aktiviert, wird der lade Strom der Produktionsdaten angepasst.. zudem wird das Überschuss laden erst gestartet wenn der Batterie Speicher über 80 % hat.

unter 75% wird die Ladung wieder beendet.

Meine Frage was passiert wenn das Auto voll geladen ist in welchen Status geht die Wallbox?

Der Prinzip ist recht einfach. Ein Starker Servo drück eine Teppichmesser klinge mit viel Kraft in die Kunststoffplatten und Trennt sie damit sauber. Über zwei Stepper kann ich den Anschlag für die Kunststoffplatten sehr genau einstellen.  

Verbaut sind:
Step-Down Power Supply
Master brick
Servo Brick
Stepper Brick
WIFI Master Extension 2.0

Dazu noch ein 
OLED 128x64 Bricklet 2.0 auf dem verschiedene Werte angezeigt werden 
IO-16 v2 an dem der Entstop für den Anschlag hängt und 4 Fußschalter über die das ganz gesteuert wird

Die Steuerung läuft über MQTT und dann Node-Red. Ich werde die Tage die Guillotine noch mal in Aktion Zeigen und dann etwas mehr zur Steuerung schreiben.

Gruß

ich hatte für eine Wetterstation in C++ ein Programm geschrieben, um die Werte von einzelnen Tinkerforge-Bricklets aufzuzeichnen, alle 15 Minuten Mittelwerte zu bilden und die Ergebnisse in einer Logdatei zu speichern, um später per Gnuplot Diagramme der zeitlichen Verläufe zu zeichnen. Das ganze läuft bei uns auf einem Red Brick, ein Raspberry Pi wäre natürlich auch vorstellbar. Das Programm ist sehr allgemein gehalten und flexibel über eine JSON-Datei konfigurierbar. Es kann außerdem als Hub dienen, um Werte auch per MQTT weiterzuleiten (oder zu empfangen) oder an eine HomeMatic-CCU per XML-API zu senden.

Tinkerforge-Bricklets werden ganz simpel in periodischen Abständen gepollt, aber die IO-Bricklets können auch Interrupts auslösen und so als Event-Zähler dienen.

Wer Interesse hat, kann gern mal hier schauen:
https://tastyorange.de/projekte/sensorlogger.htm