1. Einfach bedienbares Kontrollpanel im Heizungskeller
  2. Kontrollpanel ebenso über Rechner und Smartphone vom internen LAN/WLAN aus
  3. Manuelle Anforderung Kurzbewässerung am Ventil
  4. Keine Batterien im Aussenbereich
  5. Sicheres Schliessen aller Ventile bei Stomausfall
  6. Warnung, besser Schliessen der Ventile, bei Kabelbruch oder Kurzschluss
  7. Möglichst keine Dauerstromversorgung im Aussenbereich
  8. Bodenfeuchte- und Temperaturmessung von Ventilkästen aus an mehreren Stellen
  9. Eventuell Statuspanel (ohne Kontrolle) über Internet


  1. Raspberry 4.B-1.1: PostgreSQL datenbank, MQTT, Node-red
  2. t4-gartenhub-can-mqtt: Teensy 4.0, W5500 Ethernet, TJA1050 CAN, MQTT boot client, CAN boot server, MQTT-CAN-bridge
  3. Ventilbox, Hauptventil: Atmega328PB, CAN boot loader


9V+ 9V- 9V+ 9V- 9V+ 9V- 9V+ 9V- CANH CANL 9V+ 9V- 15V+ 15V-


Prototyp 1,2: aus Modulen
    • PD0 - RXD, PD1 - TXD, PD2-PD7 - D2-D7, PB0-PB5 - D8-D13, PC0-PC7 - A0-A7
  • MCP2515/TJA1050 CAN module
  • 2x DRV8833 H-bridge modules, C:/Users/Hobbyraum/Documents/Arduino/gardena_1251/drv8833.pptx
  • HC-SR04 ultrasonic distance module
  • I2C soil humidity sensor
  • RG rain gauge with reed contact (rep. 0.011„ per tick, Ambient Weather WS-1080 replacement,
    • Measurement: 57.93cm² (52mm x 112mm mid of frame, -31mm² for four edges of ~6mm radius mid of frame),
    • 106g water @ 20° → 50 ticks, 105.8cm³/57.93cm² = 18.2634mm, 0.365mm/tick (~0.014“)
  • Gardena 1188-20 Bodenfeuchtesensor (1 Ohm wet, 10k dry)
  • [3x TTP223 capacitive touch switches TS1/TS2/TS3, CMOS output (VCC-1V, GND)]
  • 3x capacitive touch areas, CAP1203, SDA, SCL, VCC5V, GND
  • Connections:
    • VCC9V - 56k - A3 - 10k - GND
    • VCC9V - |>MBRS130LT3G - VIN - 2200uF/16V - GND
    • VIN,GND - TS295050 - VCS5V
    • Pro Mini RAW - VIN, Pro Mini GND - GND
    • D10 - CAN CS, D11 - CAN MOSI, D12 - CAN MISO, D13 - CAN SCLK, D2 - CAN INT, CAN VCC - VCS5V, CAN GND - GND
    • D4 - HB BI1, D5 - HB BI2, D6 - HB AI1, D7 - HB AI2, A1 - HB1 NSLP, A0 - HB2 NSLP, A2 - HB NFLT?, HB VIN - VIN, HB GND - A7 - 2.2Ω - GND, HB1 BO1 - >|1N5819,120Ω - V1I, HB1 BO2 - V1O, [HB1 AO1 - >|1N5819,120Ω - V2I, HB1 AO2 - V2O, HB2 BO1 - >|1N5819,120Ω - V3I, HB2 BO2 - V3O]
    • D8 - SR04 ECHO, D9 - SR09 TRIGGER, SR04 VCC - VCS5V, SR04 GND - GND
    • A4 - I2C SDA - 2k2Ω - VCC5V, A5 - I2C SCL - 2k2Ω - VCS5V, I2C VCC - VCS5V, I2C GND - GND
    • D3 - RG+ - 4k7Ω - VCS5V, RG- - GND
    • A6 - G1188+ - 200k - VCS5V, G1188- - GND
    • TS VCC - Pro Mini 5V, TS GND - GND, TS1 - 2k2 - A6, TS2 - 4k7 - A6, TS3 - 10k - A6
  • TODO:
    • Probe valve without disabling interrupts.
    • Manufacture own board.
    • Power loss valve shut capacitor and logic
    • Measure air temperature and correct speed of sound accordingly.
    • Build soil humidity sensor.
    • Replace 120Ω by 150Ω (with DRV8833 voltage is around 8.5V, and we want to restrict the demagnetisation current to about the specified 50mA).
    • Process CAN REBOOT request
    • Case
    • Process manual switches
    • Support Gardena soil humidity sensor (see valvecontrol02, 1Ohm wet, 10kOhm dry, requires analog input pin for presence detection)
    • Implement valve opening/closing plan
Prototyp 3: can_g1251_v01

Verbaut: can_g1251_v01_mod








  1. Anscheinend verhindert canboot nicht zuverlässig das Überschreiben seiner selbst. Siehe C:\Users\Hobbyraum\Documents\Atmel Studio\Atmega328P\valvebox-6406-m328pb-canboot-valvecontrol04.hex

CAN Kommunikation

Step From To Message
1 Client Hub HEARTBEAT(0x200|nr), len=8, data=uptime:32,interval:16,apimajor:8,apiminor:8
2 Hub Mqtt 'iot/heartbeat/' nr : '{"uptime":' uptime ',"interval":' interval ',"apiversion": apimajor '.' apiminor '}'
Step From To Message
1 Hub Client HUBBEAT(0x280), len=6, data=uptime:32,interval:16
2 Hub Mqtt 'iot/heartbeat/hub' : '{"uptime":' uptime ',"interval":' interval '}'
Step From To Message
1 Client Hub JSON(0x240|nr), len=8, data=json
n-1 Client Hub JSON(0x240|nr), len=8, data=json
n Client Hub JSON(0x240|nr), len=6/7, data=frames:16, crc:16, jsonlen:16 [,heading=status(0),update(1):8]
n+1 Hub Mqtt 'iot/status/'/'iot/update/' nr : json
Step From To Message
1 Mqtt Hub 'iot/set/' nr : json
2 Hub Client JSON(0x240|nr), len=8, data=json
n-1 Hub Client JSON(0x240|nr), len=8, data=json
n Hub Client JSON(0x240|nr), len=6/7, data=frames:16, crc:16, jsonlen:16[,heading=set(2):8]


  1. The crc of the JSON completion frame pertains to all data frames for len=6, plus the completion frame itself (with the crc set to 0) for len=7
  2. Expect clients to have only a limited amount of memory at hand to process incoming JSON requests.
  3. Expect clients to implement only a limited form of JSON parsing, for instance only allowing integer numbers or strings as values.
  4. TODO: Are clients able to receive JSON data at high pace? Otherwise either the Hub should throttle or ACKs should be introduced.
  5. TODO: Include frames and jsonlen of last frame into crc.
Step From To Message
A.1 Mqtt Hub 'iot/reboot/' nr: deviceno
A.2 Hub Client REBOOT(0x270|nr), len=4, data=kind(3):8,:8,deviceno:16
A.2 Hub Client FIRMWARE_ACK(0x130|nr), len=4, data=kind(3):8,:8,deviceno:16
B.1 Client Hub FIRMWARE_ACK(0x130|nr), len=4-5, data=kind(2):8,:8,deviceno:16[,mcusr:8]
B.2 Hub Mqtt 'iot/boot/' nr: '{"id":' deviceno ', [',"mcusr":' mcusr] '}'
C.1 Mqtt Hub 'iot/firmware/' deviceno ('/flash'|'/eeprom'): hexfile
D.1 Hub Client FIRMWARE_CONTROL(0x100) len=5, data=version(0x10):8, 'E'|'F':8, deviceno:16, 'B':8
D.2 Client Hub FIRMWARE_ACK(0x130), len=1, data=ack(1)|nack(0):8
D.i Hub Client FIRMWARE_CONTROL(0x100) len=5, data=addr:32, 'A':8
D.i+1 Client Hub FIRMWARE_ACK(0x130), len=1, data=ack(1)|nack(0):8
D.j Hub Client FIRMWARE_DATA(0x110) len=1-8, data
D.j+1 Client Hub FIRMWARE_ACK(0x130), len=1, data=ack(1)|nack(0):8
D.n Hub Client FIRMWARE_CONTROL(0x100) len=5, data=frames:16, crc:16, 'E':8
D.n+1 Client Hub FIRMWARE_ACK(0x130), len=1, data=ack(1)|nack(0):8


  1. Clients booting for other reasons than being requested via A.2 would begin the sequence at step B.1.
  2. Some clients (T3/T4) implement firmware reception within the application. New firmware can be pushed to those clients at any time, in this case the process above starts directly at step C.1.
  3. New firmware can also be pushed to the MQTT/CAN hub itself. In this case no CAN communication takes place, and the process consists only of step C.1.
  4. TODO: Clean up the deviceno 16/32 bit mess. Also, the boot announcement from the client is without nr currently.

MQTT Hub Kommunikation

Step From To Message
1 Hub Mqtt 'iot/heartbeat/hub': '{"uptime":' uptime ',"interval":' interval '}'
Step From To Message
1 Hub Mqtt 'iot/status/hub': '{"id":' deviceno ', "hw":"TEENSY40", "type":"mqtthub", "sw": "' sw '"}'

Zentrale Steuerung

Erste Tests

Kabel C Buchsen CAN. 3a (CANL) - Ventilbox - 3c (CANL Rück), 3b (CANH) - Ventilbox - 3d (CANH Rück). Jedes Segment ca. 60m. 9,3Ω Schleife gesamt. 42,3Ω und 51,2mH (!) zwischen 3a/3b hausseits mit Ventil an 3c/3d hausseits. 106nF zwischen 3a/3b hausseits mit 100nF an 3c/3d hausseits.

Pololu DRV8801

Folks, I bought two an am investigating the CS output when driving ENABLE by PWM. To understand better I've also looked at VPROPI before it enters the 10k on-module resistor.

According to discussion in, VPROPI has a bandwidth of 1MHz but is very weak (<100uA).

What I find is that at 30kHz PWM CS is rather stable due to being buffered behind the 10k by 33nF to ground. But I also find that VPROPI is being distorted by the load imposed by the 33nF through the 10k. At 66% duty cycle SENSE alternates between 180mV and 0mV, VPROPI alternates between 670mV and 395mV, and CS reads 575mV (close to the expected 600mV of five times 120mV average SENSE). At 33% duty cycle SENSE alternates between 90mV and 0mV, VPROPI alternates between 235mV and 95V, and CS it at 145mV (again close to the expected 150mV of five times 30mV average SENSE).

The Hunter PGV-100 valve (24Ω, 55mH) requires 300mA to switch on and then 80mA to stay on. With 15V supply and the DRV8801 (with a 500mΩ Rsense, PHASE HIGH and MODE1 HIGH) a 55% PWM duty cycle gives 290mA current through the valve in steady state (SENSE 145mV/0mV, CS 400mV), and a 15% PWM duty cycle gives 80mA (SENSE 40mV/0mV, CS 30mV).

bewaesserungssteuerung.txt · Zuletzt geändert: 2021/08/25 20:04 von sebastian