DEV Community: Neil Gall

Advent of Code 2021 Day 4

Neil Gall — Sat, 04 Dec 2021 13:07:01 +0000

It's a rainy Saturday and a nice logic puzzle so I went for Prolog. I'm specifically using Scryer Prolog for its nice DCG library which makes parsing the input text a breeze.

The bit in part 2 that caught me out was that multiple boards can win at the same time, so capturing all the scores and dropping the winning boards took a bit of work.

:- use_module(library(charsio)).
:- use_module(library(dcgs)).
:- use_module(library(lists)).
:- use_module(library(pio)).
:- use_module(library(reif)).

%% parsing

digit(D) --> [D], { char_type(D, decimal_digit) }.

digits([D|Ds]) --> digit(D), digits(Ds), !.
digits([D])    --> digit(D).

number(N) --> digits(Ds), { number_chars(N, Ds) }.

draw([N|Ns]) --> number(N), ",", draw(Ns), !.
draw([N])    --> number(N).

board([R|Rs]) --> row(R), "\n", board(Rs), !.
board([R])    --> row(R).

row([N|Ns]) --> whitespace, number(N), row(Ns), !.
row([N])    --> whitespace, number(N).

whitespace --> "  ", !; " ", !; "", !.

boards([B|Bs]) --> board(B), "\n\n", boards(Bs), !.
boards([B])    --> board(B).

input(Draw, Boards) --> draw(Draw), "\n\n", boards(Boards), "\n".

load(File, Draw, Boards) :-
    phrase_from_file(input(Draw, Boards), File).


%% model

match_row(_, [], []).
match_row(N, [N|Xs], [x|Xs]) :- !.
match_row(N, [X|Xs], [X|Ys]) :- match_row(N, Xs, Ys).

match_board(_, [], []).
match_board(N, [X|Xs], [Y|Ys]) :-
    match_row(N, X, Y), match_board(N, Xs, Ys), !.

match_boards(_, [], []).
match_boards(N, [X|Xs], [Y|Ys]) :-
    match_board(N, X, Y), match_boards(N, Xs, Ys), !.

winning_row([x]).
winning_row([x|Xs]) :- winning_row(Xs), !.

winning_board_([R])    :- winning_row(R).
winning_board_([R|Rs]) :- winning_row(R); winning_board_(Rs), !.

winning_board(B, true) :-
    winning_board_(B);
    transpose(B, B2), winning_board_(B2).

winning_board(_, false).

score_row([], 0).
score_row([x|Xs], S) :- score_row(Xs, S), !.
score_row([X|Xs], S) :- score_row(Xs, S2), S is X + S2.

score_board([R], S) :- score_row(R, S), !.
score_board([R|Rs], S) :- 
    score_row(R, S1),
    score_board(Rs, S2),
    S is S1 + S2.


%% game

win_score(Draw, Win, Score) :-
    score_board(Win, S),
    Score is Draw * S.

wins(Draw, Boards, BoardsLeft, Scores) :-
    tfilter(winning_board, Boards, Wins),
    maplist(win_score(Draw), Wins, Scores),
    foldl(select, Wins, Boards, BoardsLeft).

game([D|Ds], Boards, Scores) :-
    match_boards(D, Boards, NextBoards),
    wins(D, NextBoards, BoardsLeft, WinScores),
    game(Ds, BoardsLeft, MoreScores),
    append(WinScores, MoreScores, Scores).

game([], _, []).


%% problems

part1(Draw, Boards, Score) :-
    game(Draw, Boards, [Score|_]), !.

part2(Draw, Boards, LastScore) :-
    game(Draw, Boards, Scores),
    reverse(Scores, [LastScore|_]), !.


%% tests

test_part1 :-
    load('test.txt', Draw, Boards),
    part1(Draw, Boards, Score),
    Score is 4512.

test_part2 :-
    load('test.txt', Draw, Boards),
    part2(Draw, Boards, Score),
    Score is 1924.


main :-
    test_part1,
    test_part2,
    load('input.txt', Draw, Boards),
    part1(Draw, Boards, Part1),
    write('Part 1 : '), write(Part1), nl,
    part2(Draw, Boards, Part2),
    write('Part 2 : '), write(Part2), nl.

github

Advent of Code 2021 Day 3

Neil Gall — Fri, 03 Dec 2021 08:30:30 +0000

I really wanted to switch away from C today but it was a bit twiddling problem. The challenge was discarding entries from the report structure. In higher level languages you'd build new lists of the remaining items but doing all that copying by hand is tough in C, so I opted for efficiency (both programmer and CPU) and added a "keep" flag to each entry, ignoring the entries whose flag had been cleared on subsequent passes.

Is it more efficient to be passing over all those discarded entries? Probably, for this size of data set which fits in the CPU cache. Checking the keep flag is very cheap. But if you increased the problem to millions or billions of entries, copying to a new smaller array would make sense. You'd only need about 50% more memory as on average you're halving the data set each time. Just double-buffer, copying the retained items back and forth between two buffers on each iteration.

Reusing the string/file readers from day1 and day2...

#include <ctype.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include "reader.h"

// ----------------------------------------------
// Report structure

typedef struct entry {
    uint16_t value;
    uint8_t keep;
} entry_t;

struct Report {
    size_t capacity;
    size_t count;
    size_t entry_length;
    entry_t entries[];
};

size_t report_size(size_t count) {
    return sizeof(struct Report) + sizeof(entry_t) * count;
}

struct Report *empty_report(size_t capacity) {
    struct Report *report = (struct Report *)malloc(report_size(capacity));
    report->capacity = capacity;
    report->count = 0;
    report->entry_length = 0;
    return report;
}

void append_entry(struct Report **report_p, entry_t entry, size_t length) {
    struct Report *report = *report_p;
    if (report->count == report->capacity) {
        report->capacity *= 2;
        *report_p = report = (struct Report *)realloc(report, report_size(report->capacity));
    }
    if (length > report->entry_length)
        report->entry_length = length;
    report->entries[report->count++] = entry;
}

struct Report *read_report(struct Reader *reader) {
    struct Report *report = empty_report(100);
    struct entry entry = { .value = 0, .keep = 1 };
    size_t length = 0;
    char c;
    while ((c = reader->next(reader)) != 0) {
        if (isdigit(c)) {
            entry.value = (entry.value << 1) + (c - '0');
            length += 1;
        } else {
            if (length > 0) {
                append_entry(&report, entry, length);
            }
            entry.value = 0;
            length = 0;
        }
    }
    if (length > 0) {
        append_entry(&report, entry, length);
    }
    reader->delete(reader);
    return report;
}


// ----------------------------------------------
// Problems

size_t ones_in_bit_position(struct Report *report, unsigned bit) {
    size_t ones = 0;
    for (size_t e = 0; e < report->count; ++e) {
        if (report->entries[e].keep && report->entries[e].value & bit)
            ones++;
    }
    return ones;    
}


int part1(struct Report *report) {
    unsigned gamma = 0;
    unsigned epsilon = 0;
    for (size_t i = 0; i < report->entry_length; ++i) {
        unsigned bit = 1 << i;
        size_t ones = ones_in_bit_position(report, bit);
        if (ones * 2 > report->count) {
            gamma |= bit;
        } else {
            epsilon |= bit;
        }
    }
    return gamma * epsilon;
}


void keep_all_entries(struct Report *report) {
    for (size_t i = 0; i < report->count; ++i) {
        report->entries[i].keep = 1;
    }
}


size_t discard_entries(struct Report *report, unsigned bit, unsigned discard) {
    size_t discarded = 0;
    for (size_t i = 0; i < report->count; ++i) {
        if (report->entries[i].keep &&
                !(report->entries[i].value & bit) == discard) {
            report->entries[i].keep = 0;
            discarded++;
        }
    }
    return discarded;
}


unsigned first_kept_entry(struct Report *report) {
    for (size_t i = 0; i < report->count; ++i) {
        if (report->entries[i].keep)
            return report->entries[i].value;
    }
    abort();
}


unsigned oxygen_generator_rating(struct Report *report) {
    size_t remaining = report->count;
    size_t bit_pos = report->entry_length;

    keep_all_entries(report);
    while (bit_pos-- > 0 && remaining > 1) {
        printf("bit %d remaining %u\n", bit_pos, remaining);
        unsigned bit = 1 << bit_pos;
        size_t ones = ones_in_bit_position(report, bit);
        unsigned keep = (ones * 2 >= remaining) ? 1 : 0;
        remaining -= discard_entries(report, bit, !keep);
    }

    return first_kept_entry(report);
}


unsigned co2_scrubber_rating(struct Report *report) {
    size_t remaining = report->count;
    size_t bit_pos = report->entry_length;

    keep_all_entries(report);
    while (bit_pos-- > 0 && remaining > 1) {
        unsigned bit = 1 << bit_pos;
        size_t ones = ones_in_bit_position(report, bit);
        unsigned keep = (ones * 2 < remaining) ? 1 : 0;
        remaining -= discard_entries(report, bit, !keep);
    }

    return first_kept_entry(report);
}


int part2(struct Report *report) {
    return oxygen_generator_rating(report) * co2_scrubber_rating(report);
}


// ----------------------------------------------
// tests

void test(const char *input, int (*f)(struct Report *), int expect) {
    struct Report *report = read_report(string_reader(input));
    int actual = f(report);
    free(report);
    if (actual != expect) {
        fprintf(stderr, "test failed input='%s' expect=%d actual=%d\n",
            input, expect, actual);
        abort();
    }
}

static const char test_data[] = 
    "00100 11110 10110 10111 10101 01111 00111 11100 10000 11001 00010 01010";

void tests() {
    test(test_data, part1, 198);
    test(test_data, part2, 230);
}

// ----------------------------------------------
// Main

int main() {
    tests();

    struct Report *report = read_report(file_reader("day3/input.txt"));

    printf("Part 1: %d\n", part1(report));
    printf("Part 2: %d\n", part2(report));

    return 0;
}

Advent of Code 2021 Day 2

Neil Gall — Thu, 02 Dec 2021 20:59:52 +0000

I created a Kotlin project and the configuration boilerplate and noise is just awful, so I deleted it. I started writing a Haskell solution but my tooling seems all broken. So I factored out the reading code from yesterday to a common library and did it in C again!

Building the linked list by appending rather than prepending brought back an old pointer-to-pointer trick. And you can get a lot of parsing done with a simple state machine.

#include <ctype.h>
#include <stdio.h>
#include <stdlib.h>
#include "reader.h"

// ----------------------------------------------
// Data model

enum Direction {
    FORWARD,
    DOWN,
    UP
};

struct Instruction {
    enum Direction direction;
    int amount;
};

struct Course {
    struct Instruction instruction;
    struct Course *next;
};

struct Course **add_instruction(struct Course **next, enum Direction direction, int amount) {
    struct Course *step = (struct Course *)malloc(sizeof(struct Course));
    step->instruction.direction = direction;
    step->instruction.amount = amount;
    step->next = NULL;
    *next = step;
    return &step->next;
}

struct Course *parse_course(struct Reader *reader) {
    struct Course *course = NULL;
    struct Course **next = &course;
    enum Direction direction;
    int amount;
    int state = 0;

    char c;
    while ((c = reader->next(reader)) != 0) {
        switch (state) {
            case 0:
                switch (c) {
                    case 'f': 
                        direction = FORWARD;
                        state = 1;
                        break;
                    case 'd':
                        direction = DOWN;
                        state = 1;
                        break;
                    case 'u':
                        direction = UP;
                        state = 1;
                        break;
                }
                break;
            case 1:
                if (isdigit(c)) {
                    amount = c - '0';
                    state = 2;
                }
                break;
            case 2:
                if (isdigit(c)) {
                    amount = (amount * 10) + (c - '0');
                } else {
                    next = add_instruction(next, direction, amount);
                    state = 0;
                }
                break;
        }
    }
    if (state == 2) {
        add_instruction(next, direction, amount);
    }

    reader->delete(reader);

    return course;
}

void delete_course(struct Course *course) {
    while (course) {
        struct Course *next = course->next;
        free(course);
        course = next;
    }
}


// ----------------------------------------------
// Part 1

struct Position {
    int horizontal;
    int depth;
};

struct Position follow_course(struct Course *course) {
    struct Position pos = { .horizontal = 0, .depth = 0 };
    for (; course; course = course->next) {
        switch (course->instruction.direction) {
            case FORWARD:
                pos.horizontal += course->instruction.amount;
                break;
            case DOWN:
                pos.depth += course->instruction.amount;
                break;
            case UP:
                pos.depth -= course->instruction.amount;
                break;
        }
    }
    return pos;
}

int part1(struct Course *course) {
    struct Position pos = follow_course(course);
    return pos.horizontal * pos.depth;
}


// ----------------------------------------------
// Part 2

struct Position2 {
    int horizontal;
    int depth;
    int aim;
};

struct Position2 follow_course2(struct Course *course) {
    struct Position2 pos = { .horizontal = 0, .depth = 0, .aim = 0 };
    for (; course; course = course->next) {
        switch (course->instruction.direction) {
            case FORWARD:
                pos.horizontal += course->instruction.amount;
                pos.depth += pos.aim * course->instruction.amount;
                break;
            case DOWN:
                pos.aim += course->instruction.amount;
                break;
            case UP:
                pos.aim -= course->instruction.amount;
                break;
        }
    }
    return pos;
}

int part2(struct Course *course) {
    struct Position2 pos = follow_course2(course);
    return pos.horizontal * pos.depth;
}


// ----------------------------------------------
// tests

void test(const char *input, int (*f)(struct Course *), int expect) {
    struct Course *course = parse_course(string_reader(input));
    int actual = f(course);
    delete_course(course);
    if (actual != expect) {
        fprintf(stderr, "test failed input='%s' expect=%d actual=%d\n",
            input, expect, actual);
        abort();
    }
}

static const char test_data[] = "forward 5\ndown 5\nforward 8\nup 3\ndown 8\nforward 2";

int main() {
    test(test_data, part1, 150);
    test(test_data, part2, 900);

    struct Course *course = parse_course(file_reader("day2/input.txt"));

    printf("Part 1: %d\n", part1(course));
    printf("Part 2: %d\n", part2(course));

    delete_course(course);
    return 0;

}

Full code on github

Advent of Code 2021 Day 1

Neil Gall — Wed, 01 Dec 2021 21:30:50 +0000

No rules this year, I'll pick a language on the day. How about some production quality C? (I really hope there's no bugs!)

If I do more C I'll no doubt factor out the reusable bits.

#include <ctype.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

// ----------------------------------------------
// Abstract reader

struct Reader;
typedef void (*reader_delete_f)(struct Reader *);
typedef char (*reader_next_f)(struct Reader *);

struct Reader {
    reader_next_f next;
    reader_delete_f delete;
};


// ----------------------------------------------
// String reader

struct StringReader {
    struct Reader reader;
    const char *p;
};

char string_reader_f(struct StringReader *sr) {
    return *(sr->p++);
}

struct Reader *string_reader(const char *s) {
    struct StringReader *sr = (struct StringReader *)malloc(sizeof(struct StringReader));
    sr->reader.next = (reader_next_f)&string_reader_f;
    sr->reader.delete = (reader_delete_f)&free;
    sr->p = s;
    return (struct Reader *)sr;
}


// ----------------------------------------------
// File reader

struct FileReader {
    struct Reader reader;
    FILE *fd;
};

char file_reader_f(struct FileReader *fr) {
    int c = fgetc(fr->fd);
    return (c == EOF) ? 0 : (char)c;
}

void file_reader_delete(struct FileReader *fr) {
    fclose(fr->fd);
    free(fr);
}

struct Reader *file_reader(const char *filename) {
    FILE *f = fopen(filename, "rt");
    if (f == NULL) {
        perror("can't open file");
        abort();
    }
    struct FileReader *fr = (struct FileReader *)malloc(sizeof(struct FileReader));
    fr->reader.next = (reader_next_f)&file_reader_f;
    fr->reader.delete = (reader_delete_f)&file_reader_delete;
    fr->fd = f;
    return (struct Reader *)fr;
}


// ----------------------------------------------
// Report structure

struct Report {
    size_t capacity;
    size_t count;
    int entries[];
};

size_t report_size(size_t count) {
    return sizeof(struct Report) + sizeof(int) * count;
}

struct Report *empty_report(size_t capacity) {
    struct Report *report = (struct Report *)malloc(report_size(capacity));
    report->capacity = capacity;
    report->count = 0;
    return report;
}

void append_entry(struct Report **report_p, int entry) {
    struct Report *report = *report_p;
    if (report->count == report->capacity) {
        report->capacity *= 2;
        *report_p = report = (struct Report *)realloc(report, report_size(report->capacity));
    }
    report->entries[report->count++] = entry;

}

struct Report *read_report(struct Reader *reader) {
    struct Report *report = empty_report(100);
    int entry = 0;
    int entry_digits = 0;
    char c;
    while ((c = reader->next(reader)) != 0) {
        if (isdigit(c)) {
            entry = (entry * 10) + (c - '0');
            entry_digits += 1;
        } else {
            append_entry(&report, entry);
            entry = 0;
            entry_digits = 0;
        }
    }
    if (entry_digits > 0) {
        append_entry(&report, entry);
    }
    reader->delete(reader);
    return report;
}


// ----------------------------------------------
// Problems

int part1(struct Report *report) {
    size_t increments = 0;
    for (size_t pos = 1; pos < report->count; ++pos) {
        if (report->entries[pos] > report->entries[pos-1])
            increments++;
    }
    return increments;
}


int window(struct Report *report, int pos) {
    int *es = report->entries + pos;
    return es[0] + es[1] + es[2];
}

int part2(struct Report *report) {
    size_t increments = 0;
    for (size_t pos = 3; pos < report->count; ++pos) {
        int prev = window(report, pos-3);
        int curr = window(report, pos-2);
        if (curr > prev) 
            increments++;
    }
    return increments;
}

// ----------------------------------------------
// tests

void test(const char *input, int (*f)(struct Report *), int expect) {
    struct Report *report = read_report(string_reader(input));
    int actual = f(report);
    free(report);
    if (actual != expect) {
        fprintf(stderr, "test failed input='%s' expect=%d actual=%d\n",
            input, expect, actual);
        abort();
    }
}


// ----------------------------------------------

static const char test_data[] = 
    "199\n200\n208\n210\n200\n207\n240\n269\n260\n263";

int main() {
    test(test_data, part1, 7);
    test(test_data, part2, 5);

    struct Report *report = read_report(file_reader("day1/input.txt"));

    printf("Part 1: %d\n", part1(report));
    printf("Part 2: %d\n", part2(report));

    free(report);
    return 0;
}

Self-Referential Generics in Java

Neil Gall — Mon, 08 Jun 2020 18:30:56 +0000

I've been having an ongoing debate with colleagues about the use of self-referential generics in Java, in which I assert they are unsound, and others continue to believe in their use. By self-referential generics I mean a type defined in terms of itself, e.g.:

interface Foo<T> { ... }

interface Bar extends Foo<Bar> { ... }

On the surface this appears useful as it can enforce correct typing of parallel hierarchies. For example, consider a warehouse system which deals with various types of parts. Each part has a type-specific identifier:

class Serial<P> {
    // stores some identifier specific to P
}

interface Part<P> {
    Serial<P> getSerial();
}

Whenever we define a part class, we declare that it implements Part parameterised with the class itself. This enforces that the serial gets the same type:

class Whatsit implements Part<Whatsit> {
    private final Serial<Whatsit> serial; 

    @Override
    public Serial<Whatsit> getSerial() {
        return serial;
    }
}

We can even have a part database which uses a polymorphic method to ensure if you ask for a Whatsit you only get a Whatsit.

interface PartDatabase {
    <P extends Part<P>> P getPart(Serial<P> serial);
}

So far this is all sound, and we can even work with parts generically in this way:

class HomogenousPartCruncher<P extends Part<P>> {
    private final PartDatabase database;

    void crunchParts(List<Serial<P>> serials) {
        serials.forEach(serial -> crunch(database.getPart(serial)));
    }

    void crunch(Part<P> part) {
        // TODO
    }
}

Any given instance of HomogenousPartCruncher can only work with one type of Part however, the type it is instantiated with. The clue's in the name. But as soon as we try to use an Object Oriented style of coding it all falls apart:

class HeterogeneousPartCruncher {
    private final PartDatabase database;

    void crunchParts(List<Serial<? extends Part<?>>> serials) {
        serials.forEach(serial -> crunch(database.getPart(serial)));
    }

    void crunch(Part<?> part) {
        // TODO
    }
}

We don't know the type of each Serial in the list but it's at least a Part<?>. We can therefore try to get the actual Part<?> from the database using this serial. But the compiler complains with

error: method getPart in interface PartDatabase cannot be applied to given types;
        serials.forEach(serial -> crunch2(database.getPart(serial)));
                                                  ^
  required: Serial<P>
  found: Serial<CAP#1>
  reason: inference variable P has incompatible bounds
    equality constraints: CAP#2,CAP#1
    upper bounds: Part<P>
  where P is a type-variable:
    P extends Part<P> declared in method <P>getPart(Serial<P>)
  where CAP#1,CAP#2 are fresh type-variables:
    CAP#1 extends Part<?> from capture of ? extends Part<?>
    CAP#2 extends Object from capture of ?

It seems to be suggesting that the type bounds in Serial needs to be extends Part<P>, but if our application uses Serials for things other than Parts we can't do this. It also creates a cyclic dependency which is never an improvement to your overall code structure.

The only way to fix this is to pretend that Part is not generic at all, and implement crunchParts() like this:

    @SuppressWarnings("unchecked")
    void crunchParts(PartDatabase database, List<Serial<? extends Part>> serials) {
        serials.forEach(serial -> crunch(database.getPart(serial)));
    }

And in fact everywhere you refer to Part in relation to this code, it has to be Part<?>, including return types which is a terrible code smell. Part may as well not be generic at all:

interface Part {
    Serial<? extends Part> getSerial();
}

class Whatsit implements Part {
    @Override
    public Serial<Whatsit> getSerial() { ... }
    }
}

interface PartDatabase {
    <P extends Part> P getPart(Serial<P> serial);
}

class HomogenousPartCruncher<P extends Part> {
    private final PartDatabase database;

    void crunchParts(List<Serial<P>> serials) {
        serials.forEach(serial -> crunch(database.getPart(serial)));
    }

    void crunch(P part) {
        // TODO
    }
}

class HeterogeneousPartCruncher {
    private final PartDatabase database;

    void crunchParts(List<Serial<? extends Part>> serials) {
        serials.forEach(serial -> crunch2(database.getPart(serial)));
    }

    void crunch2(Part part) {
        // TODO
    }
}

The code is cleaner and easier to understand, has the same guarantees of type safety, yet doesn't need <?> wildcards nor @SuppressWarnings("unchecked") everywhere.

The only way to use self-referential generics without annoying wildcards and suppressing unchecked cast warnings is for all - and I mean all - your code to work with concrete types only. Which is a distinctly non-object oriented style that I find curious in a language so singularly devoted to promoting Object Oriented programming that class hierarchies are pretty much the only abstraction tool it offers.

Pirrigator, part 8: Year 2

Neil Gall — Mon, 08 Jun 2020 10:09:10 +0000

Last year's series fizzled out a little without a strong conclusion, I apologise for that. The good news is the Pirrigator is back in action this year and is so far working better than ever.

I've replaced the Raspberry Pi model B with a Zero which is neater and has slightly lower power requirements. I also sorted out my solar power supply and replaced the 15-year old car battery which it turned out was long past its best, and it's now been running continuously since April with smaller 7Ah battery.

I added a transistor to control the power to the moisture sensors to eliminate the corrosion issue. This is controlled by an additional GPIO pin; the code pulls the pin high, waits 20ms to avoid any weird startup issues, reads the moisture then drops the power again. After that change the probes remained intact for the rest of the summer. I replaced them this year as they weren't all working reliably, but I suspect that was more a consequence of storing the hardware in the shed all winter.

I've updated all the library dependencies without many issues, although Seed had some major changes since I first used it, for the better. I did have to re-read all the code to get back into it, as I'd forgotten a lot. I'm glad to say I found it easy to pick up again, hopefully a combination of good code quality and Rust forcing you to be very explicit everywhere.

One consequence of all the fiddling last year was I neglected the actual tomato plants a bit, and they ended up a bit messy looking. This year I got all the hardware reinstalled and working reliably in early April, when the plants were still seeds germinating in the house, and it has operated autonomously and reliably since then with a nice consistent level of moisture in the soil. Hoping this continues, we've gone for nine tomato, three cucumber and three courgette plants this year - hopefully I'll have time to maintain them better and get a bumper crop later in the summer!

I'll be talking about this project in a Rust Edinburgh virtual meetup on 25 June. Everyone welcome!

Pirrigator, part 7: Problems emerge

Neil Gall — Mon, 10 Jun 2019 08:33:43 +0000

At a basic level everything has been working for a few weeks now and the plants are all growing well and looking healthy. But two major, and probably related, problems have emerged.

Firstly the battery has run low several times, causing the charge controller to cut power to the Raspberry Pi to prevent over-draining the battery. We've had pretty dull weather and a fair amount of rain for several weeks so maybe the panel just hasn't been able to provide enough energy. But I suspect another issue.

The moisture sensors are corroding really quickly, lasting about two weeks before enough metal has gone to affect the readings. I think the fundamental problem here, and maybe in both cases, is I didn't build any switching into the circuit. All the sensors are powered continuously, even though I only read them very infrequently. There is a constant current flowing through those moisture electrodes powering a continuous chemical reaction with the water in the soil. Similarly the BME280 weather circuit is continually powered even though I only read it every 5 minutes. Reading takes a few milliseconds at most, so even if its energy demand is modest, 99.99% of it is wasted.

It'll be messy but I'm planning to add some additional circuitry using NPN transistors to switch the power to the sensors and control these from Raspberry PI GPIO pins - I still have a few left. A little code tweak would then switch the power on, wait an appropriate time for everything to settle, read the sensor and power it down again.

I've also attempted a few refactors of the code and run into Rust borrowing issues. I guess this is the normal Rust learning curve, but at times it has started to feel like hard work. One particular problem I keep hitting is iterating over one part of a data structure, accessing another part inside the loop - the iterator borrows the whole thing so I can't get a second borrow in the loop body. I'm sure there's a Rust idiom to deal with this but my searches have so far come up with nothing. Clearly I need to read more of other people's Rust code.

I'll update again on the performance of modified electronics. Time is running out before we head off on holiday for a couple of weeks and I need something I can rely on by then!

Pirrigator, part 6: In for a penny...

Neil Gall — Sun, 12 May 2019 14:35:15 +0000

In my last post I outlined how all the data gets gathered, stored and served over a JSON API. I turned to look at making a front end for viewing the data - the idea in my head the whole time was "draw pretty graphs!" - and had to venture into web development, an area which I'm really a novice at. I did do six years of mobile apps professionally, so I'm familiar with some kinds of front-end development, I've written a few toy things with React, I've dabbled with Elm, I can make really simple changes to the Angular + Typescript UI at my present day-job, but other than that I've shied away from web development for years.

The big question therefore was what technology could I build a front-end in. I thought again about my original goal of learning Rust and the well-known fact that Rust compiles to WebAssembly and can run in the browser, but I had no idea if any of this technology was ready for use. I googled "rust web front-end" and came across this Reddit discussion on the subject. That in turn linked to Markus Kohlhase's excellent Rust web framework comparison document.

Unsurprisingly there's a lot of activity in this area. Knowing I wanted to draw graphs I looked through the front-end frameworks for one with an SVG example, and the only one was Draco. I spent an evening going through the examples and got as far as serving the SVG clock example from the Iron webserver.

I made a possibly interesting choice here not to add a static file mount to the webserver, but to build the binary blobs of the three files I needed right into the server binary. I have two reasons for this. First, deployment is simple as there's always a single file to copy to the device. And second, while I'm not sharing the address widely as it's running on a really low-end device with a poor wifi connection 20 metres from my house, the port is open to the internet via my router. Limiting the data the server can access to only what Rust code can generate seems a good way to maximise the benefits of Rust's safety and security claims. A handy crate for this was lazy-static-include which builds binary blobs into release builds but loads them from the source files at runtime in debug builds. I do build the app on my development laptop with hardware access disabled so I can test out the database and server side of things, so this gives me the best of both worlds.

With the success of serving the SVG clock from the Iron webserver, I set about replacing this UI with my own, and quickly ran into trouble. On loading the WASM blob the web console showed a link error for some __wbg_error handler. I googled this, read more of the wasm-bindgen guide and even browsed the source but came up short. It seems Draco just hasn't reached a maturity level to address things like easy debugging yet.

Back at Markus's comparison document I looked at the popularity of the individual web frameworks, realising it was a bit of schoolboy error to ignore this in the first place. The most starred framework is Dodrio but the example code looks too low-level for my liking. I definitely want something that gives the kind of abstraction that Elm and React offer.

The next most popular framework is Seed and I have to say I'm really impressed. The documentation is great, introducing concepts in the right order (although not all of it is completely up to date), and the API is pretty nice to use. It was a really straightforward translation from the small amount of Draco-based code I'd written to use Seed instead. Quickly I had a simple UI to query blocks of historical sensor data from the server and show it in tables. Then I set about writing an SVG chart component to draw 2D line graphs. A few hours later I had rudimentary charts!

I really like the way the UI can be decomposed with Seed. Roughly following the Elm architecture, at the root a UI is a model, a view function which turns a model into a virtual DOM tree, and an update function which updates the model from a message. To decompose into smaller units I really want those units to work in terms of their own model and messages, and Seed provides the tools to make this easy.

I separated the main UI into Weather and Sensors sub-modules. The main model becomes

struct Model {
    weather: weather::Model,
    sensors: sensors::Model
}

The top-level event type just wraps the lower layer events that are possible:

enum Message {
    Weather(weather::Message),
    Sensors(sensors::Message),
}

The view for this just renders the sub-modules views, and crucially, maps the sub-module's event types to the higher layer's using the Message instance constructors.

fn view(model: &Model) -> El<Message> {
    div![
        h1!["Pirrigator"],
        model.weather.render().map_message(Message::Weather),
        model.sensors.render().map_message(Message::Sensors)
    ]
}

The update works in reverse, unwrapping the top-layer messages, passing the underlying message through the sub-modules, then wrapping the result back up in the top layer structure. Fundamentally it's an fmap:

fn update(msg: Message, model: &mut Model) -> Update<Message> {
    match msg {
        Message::Weather(msg) => model.weather.update(msg).map(Message::Weather),
        Message::Sensors(msg) => model.sensors.update(msg).map(Message::Sensors)
    }
}

This is great, as it lets you decompose into self-contained units, and can even instantiate multiple instances of these units into the larger UI. Perfect for tables, grids and the like.

Because the data comes from the server, the weather model is itself an enum representing the states this data can be in.

pub enum Model {
    NotLoaded,
    Loading,
    Loaded(Vec<WeatherRow>),
    Failed(String)
}

The render function shows a heading, some buttons to select the time range of data to load, and the rest depends on the data state:

pub fn render(&self) -> El<Message> {
    div![
        h2!["Weather"],
        button![simple_ev(Ev::Click, Message::Fetch(HOUR)), "Last Hour"],
        button![simple_ev(Ev::Click, Message::Fetch(DAY)), "Last Day"],
        button![simple_ev(Ev::Click, Message::Fetch(WEEK)), "Last Week"],
        button![simple_ev(Ev::Click, Message::Fetch(MONTH)), "Last Month"],
        match self {
            Model::NotLoaded =>
                p!["Select a time range"],
            Model::Loading =>
                p!["Loading..."],
            Model::Failed(e) =>
                p![e],
            Model::Loaded(data) =>
                div![
                    h3!["Temperature"],
                    chart(data, true, &|r| r.temperature).render().map_message(|_| Message::Fetch(HOUR)),
                    h3!["Humidity"],
                    chart(data, true, &|r| r.humidity).render().map_message(|_| Message::Fetch(HOUR)),
                    h3!["Barometric Pressure"],
                    chart(data, false, &|r| r.pressure).render().map_message(|_| Message::Fetch(HOUR))
                ]
        }
    ]
}

The best bit about this code is it's hard to see where you could write bugs. You can only render data when in the state where there is data to render. You can only show an error in the error state. How many UIs get this wrong by failing to make impossible states unrepresentable?.

The chart function uses the provided lambda to pull one axis out of the weather data and build a Chart sub-model, which is then immediately rendered. As with the top-layer the Chart module's message is then mapped into a Weather module message. Right now my chart module doesn't actually produce any messages but when it does it's already plumbed all the way up to the root.

fn chart(data: &Vec<WeatherRow>, y_origin_zero: bool, f: &Fn(&WeatherRow) -> f64) -> chart::Chart {
    chart::Chart {
        width: 600,
        height: 200,
        y_origin_zero,
        data: data.iter().map(|r| chart::DataPoint { time: r.timestamp, value: f(r) }).collect()
    }
}

I'm not going to go through the chart code. It was fun to write but is fairly self-explanatory as it just builds a bunch of SVG elements. There was a little arithmetic involved to scale the data to SVG coordinates (and also to deal with the fact that my X axis consists of SystemTime objects, but the chrono crate came in very useful here).

The weather sub-module's update function is interesting as it updates the current state. To do this it's necessary to dereference the &mut self reference:

pub fn update(&mut self, msg: Message) -> Update<Message> {
    match msg {
        Message::Fetch(t) => {
            *self = Model::Loading;
            Update::with_future_msg(self.fetch(t)).skip()
        }
        Message::Fetched(rows) => {
            *self = if rows.is_empty() { Model::NotLoaded } else { Model::Loaded(rows) };
            Render.into()
        }
        Message::Failed(e) => {
            *self = Model::Failed(e.as_string().unwrap_or("Unknown error".to_string()));
            Render.into()
        }
    }
}

The sensors module works very similarly but has the added twist that it needs to fetch the list of sensor names with one API call, and then the data for each one separately. Following the same pattern I encoded all these states into the model.

After my false start with Draco this has been a joy to work on. UIs are inherently stateful and being able to think about and explicitly encode the complete set of states your code can be in is such a massive improvement from where we came from. Apart from a couple of bugs with scaling the data to the graph, on the whole this has been a "if it compiles it works" scenario.

There are only two major components left before this is up and running. I have three sensors but only two water valves as one of the three I bought doesn't work. So I'll need some additional configuration to define irrigation zones, how they map to sensors and valves, and some parameters for how the water should be added (e.g. after 6pm every day until the moisture reads a certain percentage). Then a final back-end module to execute this logic and store irrigation events in the database, and a UI addition to show when water has been added in each zone.

The final component to install will be the tomato plants. It's mid-May, I better get a crack on!

GitHub

Pirrigator, part 5.

Neil Gall — Thu, 02 May 2019 23:39:51 +0000

In my earlier posts I outlined my plan to automate watering the tomatoes in my greenhouse with a Raspberry Pi and Rust. The first few posts mostly outlined the hardware and my procrastination at writing proper Rust code for the first time. But we're now into May and the plants will be going in soon, so I really need this working pretty quickly. The good news is much of the core code concepts are in place.

Configuration

I stumbled across the config crate in my news feed one morning and it was exactly what I need. It deserialises from various sources and formats into a data structure, so I can keep the hardware configuration and detail out of the main code.

#[derive(Debug, Deserialize, PartialEq, Eq)]
pub struct Database {
    pub path: String
}

#[derive(Debug, Deserialize, PartialEq, Eq)]
pub struct Settings {
    pub database: Database,
    pub weather: Option<WeatherSensorSettings>,
    pub adc: Option<ADCSettings>,
    pub moisture: Vec<MoistureSensorSettings>,
    pub buttons: Vec<ButtonSettings>,
    pub valves: Vec<ValveSettings>
}

impl Settings {
    pub fn new() -> Result<Self, ConfigError> {
        let mut s = Config::new();

        s.merge(File::with_name("Settings"))?;
        s.merge(Environment::with_prefix("PIRRIGATOR"))?;

        s.try_into()
    }
}

A central setup chunk of code takes the settings read from a file and constructs the various objects I need. So I can do various tests on my development laptop I made all the hardware modules optional so I can configure the system with just a database and web server.

impl Pirrigator {
    pub fn new(s: settings::Settings) -> Result<Pirrigator, Box<Error>> {
        let (tx, rx) = mpsc::channel();

        let weather = traverse(&s.weather, &|w|
            weather::WeatherSensor::new(&w, tx.clone())
        )?;

        let moisture = traverse(&s.adc, &|adc|
            moisture::MoistureSensor::new(&adc, &s.moisture, tx.clone())
        )?;

        let buttons = button::Buttons::new(&s.buttons, tx.clone())?;
        let valves = valve::Valves::new(&s.valves)?;

        let db = database::Database::new(Path::new(&s.database.path))?;

        let mut controller = Controller {
            database: db.clone(),
            weather,
            moisture,
            buttons,
            valves
        };

        let thread = spawn(move || controller.run(rx));

        return Ok(Pirrigator { 
            thread,
            database: db
        })
    }

The traverse feels like the wrong way to do things but I'm still learning how the Option and Result combinators all work. I'll sort it out at some point. It's a standard traverse function like in Haskell:

fn traverse<T, U, E>(t: &Option<T>, f: &Fn(&T) -> Result<U, E>) -> Result<Option<U>, E> {
    match t {
        None => Ok(None),
        Some(t) => f(t).map(Some)
    }
}

Sending data from sensors

As I mentioned in an earlier post my grand idea was to run each sensor on its own thread and post events to a controller which dispatches these events to the places they need to go. For now, I store sensor data in an sqlite database, and act on the button presses, which are a manual on/off for the water valve for now.

The sensor modules all follow a similar pattern. new() spawns a thread which mostly sleeps but wakes up periodically, reads data from the hardware and posts an event to the multi-producer-single-consumer channel.

impl WeatherSensor {
    pub fn new(settings: &WeatherSensorSettings, channel: Sender<Event>) -> Result<Self, Box<Error>> {
        let device = Bme280Device::new(&settings.device, settings.address)?;
        let period = Duration::from_secs(settings.update);
        let thread = spawn(move || { main(device, channel, period) });
        Ok(WeatherSensor { thread })
    }
}

The local main() function for a sensor thread is just a polling loop:

fn main(mut device: Bme280Device, channel: Sender<Event>, period: Duration) {
    loop {
        match device.read() {
            Ok(data) => send_event(data, &channel),
            Err(e) => error(e)
        };
        sleep(period);
    }
}

And send_event() just translates away from the hardware module's data structure, adds a timestamp, and sends it over the channel.

fn send_event(data: Bme280Data, channel: &Sender<Event>) {
    let event = WeatherEvent {
        timestamp: SystemTime::now(),
        temperature: data.temperature,
        humidity: data.humidity,
        pressure: data.pressure
    };

     match channel.send(Event::WeatherEvent(event)) {
        Ok(_) => {},
        Err(e) => error(e)
    };
}

Receiving data from sensors

The controller's run() is the main dispatcher loop. Nothing too fancy.

        loop {
            let event = rx.recv()
                .expect("receive error");

            self.database.store_event(&event)
                .expect("database store error");

            match event {
                event::Event::ButtonEvent(b) => self.button_event(&b),
                _ => {}
            }
        }

For the database I chose rusqlite. I don't need an ORM or anything - there are no relations in my data yet so I'm just doing SQL by hand. I do want the controller's receiver thread and web server handler threads to be able to access the database however, so there's an r2d2 connection pool in there. The Database abstraction provides methods like

    fn store_weather(&self, event: &weather::WeatherEvent) -> Result<(), Error> {
        self.conn().execute(
            "INSERT INTO weather (time, temperature, humidity, pressure) VALUES (?1, ?2, ?3, ?4)",
            &[&to_seconds(&event.timestamp) as &ToSql, &event.temperature, &event.humidity, &event.pressure]
        )?;
        Ok(())
    }

Dates are always a nightmare so I'm just translating the time to 32-bit Unix seconds. If I'm still using this in 2038 I'll be amazed. I had to cross-compile the sqlite C library for ARMv6 but this turned out to be really simple - just download the autoconf package, configure with --target=arm-unknown-linux-eabihf, make, and copy the resulting libraries to the Rust deps directory. It looks like Cargo can be configured to do all this, but it's not my main concern right now.

Web Server

Primarily it's an automation system but I do want to be able to check in, and of course with all that collected data we want graphs! So the final component so far is a web server. I looked at a few Rust web frameworks. Rocket looks great, similar in feel to Flask but I feel the developers have made a gigantic mistake requiring the Rust nightly compiler. Back in the early days of Swift I had a terrible time with code unable to compile across releases. Maybe Rust's change management is better than Apple's was in the Swift 2 to 3 days, but the unstable language base meant an instant rejection for Rocket.

Some of the other web frameworks looked far too removed from anything I've used before. But Iron seemed simple to get started and quite extensible so that's my choice for now. Following this example I managed to build a middleware to plug my database abstraction into requests:

struct DbMiddleware {
    database: Database
}

impl typemap::Key for DbMiddleware {
    type Value = Database;
}

impl BeforeMiddleware for DbMiddleware {
    fn before(&self, req: &mut Request) -> IronResult<()> {
        req.extensions.insert::<DbMiddleware>(self.database.clone());
        Ok(())
    }
}

pub trait DbRequestExtension {
    fn get_database(&self) -> Database;
}

impl <'a, 'b>DbRequestExtension for Request<'a, 'b> {
    fn get_database(&self) -> Database {
        let database = self.extensions.get::<DbMiddleware>().unwrap();
        database.clone()
    }
}

Thus in any request handler I can do req.get_database() and invoke methods on the database abstraction. The middleware also plugs in a JSON response handler and a logger. All useful things that you need in almost any project.

So far the web server has a /status route which just reports that the app is running, and a /weather route which reports the latest recorded weather conditions.

fn status(_: &mut Request) -> IronResult<Response> {
    Ok(Response::with((status::Ok, "running")))
}

fn weather(req: &mut Request) -> IronResult<Response> {
    let weather = req.get_database().get_latest_weather();

    let mut response = Response::new();
    match weather {
        Ok(w) => {
            response.set_mut(JsonResponse::json(w)).set_mut(status::Ok);
            Ok(response)
        }
        Err(e) => {
            let err = IronError::new(e, status::NotFound);
            Err(err)
        }
    }
}

pub fn run(database: Database) {
    let mut router = Router::new();
    router.get("/status", status, "status");
    router.get("/weather", weather, "weather");

    Iron::new(middleware::insert(router, database))
        .http("0.0.0.0:5000")
        .unwrap();
}

Again I'm sure there are more succinct and idiomatic translations between error types but I'll just have to learn these as I go. I was emphatic in an earlier post that you just have to do what works when learning, and improve it as you go.

After all that, I can GET a JSON blob with the current greenhouse weather conditions! For fun I exposed the port on my router and threw together an Alexa skill to query the weather and read it out. We've had fun asking Alexa what the weather in the greenhouse is like.

Still to do

Loads has come together in the last week or two, but there's tons to do. There's still no automation of course - I'll need a final thread which runs a state machine and some logic deciding when the plants need water. I haven't really thought much about this yet, but the infrastructure now available allows it to be modular and gives me options.

I'll also need to expand the web server to expose more data suitable for drawing graphs - the last hour, day, week of weather and moisture data for example. Since Rust has a WebAssembly target I'm starting to wonder if I could even build a front-end in Rust?

There are other odds and ends - there's a camera module hanging off the Raspberry Pi, so I want to be able to at least serve up a still image every few hours. Remote override of the water might be an idea; if I'm away from home and everything looks a bit dry because the automation isn't behaving correctly I could at least water the plants manually.

The experience

The first Rust code I wrote was to read the hardware sensors and collect the data into structures. It felt like C for the most part. Since then I've moved up the stack to accessing a database and serving web content, and Rust no longer feels like C. I've had few ownership issues and have always had a notion of "who is responsible for this object" when programming, so I'm actually really enjoying making this explicit in Rust. No exceptions is great - I think they result in terrible code - but finding the right way to use Rust's tools like Option and Result together while keeping the code simple and clean is tricky. I feel I'm doing too many unwrap()s and not enough passing errors up the call stack. All part of the learning process, which is ultimately what this project is about. If you want to learn a language do something real in it.

The full code is on github, as ever.

Pirrigator, part 4.

Neil Gall — Fri, 12 Apr 2019 21:35:37 +0000

Apologies, I haven't posted an update here for a while for a few reasons. The weather is getting better and I've been more inclined to get outdoors and enjoy it. I'd recommend the same to anyone, no matter how much you love your coding time. Also I've mainly been working on the electronic parts of my project, making it up as I go, and working through the Rust book on the side.

The circuit is almost complete. At first I was going to bring wires out to screw terminals on the exterior of the box but that seemed clunky and fragile so I've ordered a bunch of 2.5mm DC jacks which I'll mount around the box, and connect everything up with cables that plug in. Should be much more robust, although using the same connector for everything from 12V supply to the moisture sensors is not ideal. I'll just have to make sure I label them.

On the board are the weather sensor, three moisture sensors with the analog outputs fed into an MCP3008 ADC chip, and three TIP120 darlington transistors controlled by GPIO lines, for the water valves. I've added LED indicators to show when the valves are (meant to be) open. On the top of the box is a push button wired directly to a GPIO line and ground - I'll add a feature in software to open and close the water valves directly when the button is pushed. Manual overrides are handy.

I'm really enjoying learning Rust. It feels familiar like C but with the added advantages of a strong type system and modern programming features. The ability to write chains of iterator adaptors, functional style, and have it compile to much the same machine instructions as the imperative loop is really impressive. I look forward to using this more.

The controller software structure is getting clearer in my head - essentially an event bus onto which various modules can publish or subscribe to events. Then I'll write separate modules for all the various bits of hardware and software features, and use an external config file to determine which modules are instantiated. Seems like that'll be enough to force me to write something resembling real-world code, at the same time it will also be maintainable for behaviour tweaks as the summer passes. At the weekend I'm hoping to get started with multithreaded Rust code so I can start putting together the basic structure of the application.

Pirrigator, part 3. Being a newbie and writing bad code.

Neil Gall — Sun, 17 Mar 2019 13:29:01 +0000

I procrastinated a bit this week. There were other things to do - I received the darlington transistors and got the water valve working under Raspberry Pi control with the sysfs interface to GPIO. I also received the MCP3008 ADC and got some Python code reading the analog output from my moisture sensors.

But I find the hardest thing about learning a new language is the feeling you're doing it wrong. I don't mind the feeling of being less productive, having to look everything up or having a very short and frequent edit-compile cycle to catch all the silly and syntactic mistakes. I've been writing code in many languages for over three decades and I like to think I have a good sense of what the right and wrong way to do things is, but entering the new world of Rust feels like I've lost this sense. I've learned enough to be able to write stuff that works, but is it the right way to do it in Rust? I found myself saying I'll wait until I've read more of the book, or find someone else's code which does something similar, then I'll write my own code. But I had to fight this urge. Writing anything, even if it's terrible, is progress. The wonderful thing about software is you can always rewrite it again later.

So I have produced my first Rust code! It's hideous, probably non-idiomatic in countless ways, but it's Rust code which compiles and works. I have built an ARMv6 native binary for Raspberry Pi which reads the temperature/pressure/humidity sensor (I think I'll just call this the weather sensor from now on) and prints the current values to the console. I will still wait to learn a little more Rust before publishing on crates.io, as I don't think it's ready for "production" yet but its beautiful functionality and straight-port-from-C ugliness is available for all on GitHub.

I've also been working on a module to read the moisture sensors, which have an SPI interface. I really wanted to have everything on I²C but SPI is only a few more wires, and a bit more code. RustpiIO is looking pretty promising as a base to build this on.

So today's message is to push on when you're learning and write that bad code. The worst you've ever written. Awful nonsense that reinvents the standard library or misses language features which would make it more concise or robust. Throwaway garbage that other people will laugh at. One day you'll be the other people laughing at it, because the bad code will have taught you more than all the examples of perfection you can find.

Pirrigator, part 2.

Neil Gall — Mon, 11 Mar 2019 18:56:51 +0000

I got the WiFi working on boot on the Raspberry Pi. I'm still a bit of an Arch noob when you get down into the guts and I was mistakenly using both NetworkManager and netctl. Dropping the latter and learning how to use nmcli to create a system connection and everything came to life. These projects are all about learning.

There are several GPIO crates for Rust. Again, I learned something new - that GPIO is a sort-of core Linux thing, not something Raspberry Pi specific. I will try a few out, but I picked sysfs-gpio more or less at random and gave it a go. I now have a blinking LED driven by Rust!

Next I wanted to get I²C working and read the temperature/humidity/barometric pressure sensor. This was a bit more involved and I admit I had moments of wondering why I am doing this on Arch instead of Raspbian where it all just works out of the box, but again the learning motivation prevailed. As long as I push the edges of my comfort zone and still make progress I'm happy. The basics of getting I²C working are covered in the Arch Linux Arm wiki. The sensor I have is the BME280, which has a rather nice tutorial here, which is in Python but was really useful to confirm the hardware and interfaces working correctly. I'll tackle porting the code to Rust in time.

I also got the moisture sensor to work, on its digital output at least. I decided that a simple wet/dry binary indication is a bit coarse and doesn't lend itself to plotting nice graphs, so I'm going to get the analog output to work. I can measure the voltage on it, which is 3.3V when dry and dropping down to about 1.5V when the sensor is completely submerged in water. The Raspberry Pi doesn't have any analog inputs however so I've ordered an Adafruit MCP3008 which provides 8 channels of analog input readable over I²C. To open the water valve I also ordered some darlington transistors with 1000x amplification, so I can drive that big 12V solenoid with a tiny I/O current from the Pi.

The hardware basics have come together really quickly and I'm feeling the thing that's really holding me back now is comfort writing Rust code. So this week I'm switching my focus to learning Rust. I'm working through the book and will have a stab at the Rust Koans pretty soon.

I'm starting to think about software system design. I'd like to keep it all modular and lightweight (a) so I can remove or turn things off if they prove problematic or not worthwhile and (b) so I can add more in the future. Plus I want to make use of the concurrency features that Rust is famous for, so I'm thinking along the lines of running a thread for each sensor, each reporting its reading(s) at a configurable interval. These reports will all queue up on a single consumer thread which will write records to an sqlite database. The core irrigating thread will wake up periodically and add some water if the recorded moisture is too low. And finally I'll generate and publish graphs of the collected data periodically. Testing such a modular design should be fairly straightforward.

In the would-be-nice region of the priority list is some kind of remote control and tweaking of the parameters. I'll put a camera on the Pi and grab a photo of the plants every day to see how they're doing but that's probably just a shell script and systemd timer rather than anything clever in Rust. Watch this space for updates!