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


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 '"}'
bewaesserungssteuerung.txt · Zuletzt geändert: 2021/06/01 11:29 von sebastian