In my constant effort to integrate more stuff into my home automation setup, one thing was bugging my for some time: The A/V stuff as well as the ambient lighting in my living room was already integrated, but not the damn PC. I even got the projector with its proprietary connector and an ESP8266 integrated.

Once the PC is on, I can control it thanks to OpenHAB's Kodi binding. But turning the PC on was a problem, because it only has WiFi: Goodbye WakeOnLAN. I already had something in mind: use an ESP8266 to "press" the power and reset buttons.

Last weekend I had my final break through: why not hack my own RGB LED strip controller? I had some boards lying around and they have three FETs. Two to push the buttons and with some trace cutting and rewiring I can even monitor the power LED to stay in sync in case the real buttons are pushed. Its powered by the standby power rail of the ATX power supply.

I published the LED strip controller board on OSHpark. If you are interested in the changes I made, please let me know.

I was a bit lazy on the software side. Usually I prefer my own custom-fit firmware, but this time I tried tasmota and ESPEasy. In the end, I went with ESPEasy, because it worked better in this scenario (at least for me).

Integration into OpenHAB was another experiment: I wanted to use the Jython rule engine. All my other customizations are running with the internal rule language, but I find that a bit inflexible at times due to the lack of encapsulation. Jython was a good fit: the integration is fully encapsulated within its own class. The control and status items that link the rules to the hardware are passed in on initialization.

Here's the Jython code. It is running on OpenHAB 2.2; I think the trigger creation has slightly changed on newer versions, but I haven't had time to update yet.

scriptExtension.importPreset("RuleSupport")
scriptExtension.importPreset("RuleSimple")

from org.slf4j import Logger, LoggerFactory
log = LoggerFactory.getLogger("org.eclipse.smarthome.automation.pc_ctrl")

log.info("Loading pc_ctrl rules.")

from org.eclipse.smarthome.automation import Rule as SmarthomeRule
from org.eclipse.smarthome.core.types import UnDefType
from org.eclipse.smarthome.core.library.types import IncreaseDecreaseType, NextPreviousType, OnOffType, OpenClosedType, PlayPauseType, RewindFastforwardType, StopMoveType, UpDownType, DecimalType

import time

class PcCtrlRule(SimpleRule):
    _pulse_cmd_pwr = 'Pulse,14,1,500'
    _pulse_cmd_rst = 'Pulse,12,1,500'
    _pulse_sleep = 0.5

    def __init__(self, name, cmd_item_name, on_state_item_name, ctrl_item_name):
        self._name = name
        self._cmd_item_name = cmd_item_name
        self._cmd_item = itemRegistry.getItem(cmd_item_name)
        self._on_state_item_name = on_state_item_name
        self._on_state_item = itemRegistry.getItem(on_state_item_name)
        self._ctrl_item_name = ctrl_item_name
        self._ctrl_item = itemRegistry.getItem(ctrl_item_name)

        # create the triggers
        trigger_on_state = Trigger('{}OnStateTrigger'.format(name),
                                   'core.ItemStateChangeTrigger',
                                   Configuration({'itemName': on_state_item_name}))

        trigger_ctrl = Trigger('{}CtrlTrigger'.format(name),
                                   'core.ItemCommandTrigger',
                                   Configuration({'itemName': ctrl_item_name}))

        # register them
        self.triggers = [trigger_on_state, trigger_ctrl]

    def execute(self, module, inputs):
        event = inputs.get('event')
        command = inputs.get('command')
        trig_item = itemRegistry.getItem(event.itemName)
        trig_item_state = trig_item.state

        log.debug('inputs=\n{}'.format(inputs))

        if event.itemName == self._on_state_item_name:
            log.debug('on_state_item changed')
            log.debug('oldItemState={}, itemState={}'.format(event.oldItemState, event.itemState))
            log.debug('trig_item_state={}'.format(trig_item_state))

            if (event.oldItemState == UnDefType.UNDEF) or (event.itemState != event.oldItemState):
                if str(event.itemState) == str(ON):
                    log.debug('Going ON')
                    events.postUpdate(self._ctrl_item, ON)
                else:
                    log.debug('Going OFF')
                    events.postUpdate(self._ctrl_item, OFF)

        elif event.itemName == self._ctrl_item_name:
            log.debug('ctrl_item cmd received')

            on_item_state = self._on_state_item.state
            cmd_to_send = ''

            log.debug('currentState={}'.format(on_item_state))
            log.debug('command={}'.format(command))

            if (str(on_item_state) == str(OFF)) and (str(command) == str(ON)):
                log.debug('Switching ON')
                cmd_to_send = self._pulse_cmd_pwr
            elif (str(on_item_state) == str(ON)) and (str(command) == str(OFF)):
                log.debug('Switching OFF')
                cmd_to_send = self._pulse_cmd_pwr

            if cmd_to_send != '':
                log.debug('Sending cmd: \'{}\''.format(cmd_to_send))
                events.sendCommand(self._cmd_item, cmd_to_send)
                time.sleep(self._pulse_sleep)
                events.sendCommand(self._cmd_item, '')

automationManager.addRule(PcCtrlRule('WZ_Watt_control_', 'WZ_Watt_control_cmd', 'WZ_Watt_control_pwr_state', 'WZ_Watt_Power'))

And the corresponding item definitions:

Switch WZ_Watt_Power "watt" <player> (gWZ)
String WZ_Watt_control_cmd "watt control command" (gInternal) { mqtt=">[home:whan/pc_ctrl/xxxxxxxx/cmd:command:*:default]" }
String WZ_Watt_control_pwr_state "watt control power state" (gInternal) { mqtt="<[home:whan/pc_ctrl/xxxxxxxx/pc_on/state:state:MAP(ONOFF_to_01.map)]" }

Please note that I changed the topic structure a bit from the defaults. It matches my other devices better this way.

The control logic is implemented in the IrrigationController class. Because it usually is hard to describe program flow details in text form, I created some flow charts. They are not 100% accurate, i.e. they leave out some details and are drawn a little different than actually implemented for better "readability".

The logic is implemented within a (FreeRTOS) task. I chose using a task to have the flexibility to keep the controller running all the time (e.g. in the development and configuration phase) or run the task just once every "now and then" and put the processor into deep sleep most of the time.

The following flow chart shows the initialization phase of the task. There is nothing special there: It basically waits for WiFi and the system time being set. Both waiting times do have a timeout. That is to ensure the controller tasks comes up without a network connection.

After initialization the task enters its task loop. It doesn't explicitly exit it ever. The only time it "exits" is when the processor enters deep sleep, because a wakeup from this state will reboot the system right from the very beginning.

In essence, the task loop does the following:

• Collect (internal and external) sensor data.
• Check for critical conditions (and disable an active irrigation if detected).
• Process all irrigation events that (may have) occurred since the last loop run. This ensures that no event will be missed, even if the task loop run gets scheduled a little too late by the OS.
• Publish the current state (i.e. sensor data and irrigation event info) via MQTT (if a network connection has been established).
• Decide whether to deep sleep or to "lightly" sleep by a task delay/yield.

Testing the control logic

To test the control logic over several days, I setup a data logger on a Raspberry Pi Zero-W board. It's hooked up via its GPIOs to the relay outputs of my board.

I'm using a slightly modified version of the gpio-monitor found on the Raspberry Pi community forum. Other than that, a serial monitor connected to the debug console is logging the debug output of the controller itself as well. That should give some insight in case something goes wrong.

Here's an example of logged events (time is displayed in UTC):

2018-03-11@06:00:00.59 010
2018-03-11@06:00:15.62 110
2018-03-11@06:00:20.65 111
2018-03-11@06:01:00.74 011
2018-03-11@06:01:15.78 001
2018-03-11@06:01:20.80 000

The start of each line displays the date and time the monitored GPIOs have changed. The next three digits show the current state of the three monitored GPIOs. They represent the state of the MAIN, AUX0 and AUX1 relay outputs (left to right).

MQTT info

Each control loop run will publish a state info via MQTT to a configured MQTT broker. The info is published in JSON format and currently looks like that:

{
    "batteryVoltage": 12958,
    "batteryState": 1,
    "batteryStateStr": "OK",
    "reservoirFillLevel": -2,
    "reservoirState": 3,
    "reservoirStateStr": "DISABLED",
    "activeOutputs": [],
    "activeOutputsStr": [],
    "nextIrrigationEvent": "2018-01-01 07:00:00"
}

The state info contains internal and external sensor data as well as system state data:

• The battery voltage in mV and a state representation (as an integer value and a string, i.e. CRITICAL, LOW, OK, FULL and DISABLED)
• The reservoir fill level in percent multiplied by 10 and a state representation (as an integer value and string, i.e. CRITICAL, LOW, OK and DISABLED).
• Information about currently active outputs (as integer values and strings).
• Date and time of the next occurring irrigation event based on the currently set date and time.

I have chosen to publish the voltage and reservoir fill level in mV and "percent multiplied 10" to prevent the usage of floating point variables as much as possible.

Sadly, the reservoir fill level sensor has proven to be unreliable. I was planning to use a voltage measurement over a voltage divider, which is influenced by the number of gold contacts covered in water. It's starting to go crazy when the pump is turned on.

That's the reason why I implemented configuration options to disable battery monitoring and/or reservoir fill level monitoring. If one is disabled, it will not take part in the decision if an irrigation should take place or not. This not only allows continuing with the development regardless of the fill level sensor, but it also adds more flexibility in the hardware setup.

One other missing piece in the software is proper SNTP handling. The control logic requires to be notified of changes in the system time to work properly. Manually setting the time through the debug console is no problem at all, because I have all the software under my control. But the SNTP implementation is part of the lwIP stack used in the ESP-IDF. It doesn't signalize any state changes at all. According to a discussion on Github, I'm not the only one needing such a feature and it looks like it's already in development. I hope it will go public soon. Otherwise, I would have to patch the ESP-IDF sources, which would not be publicly available.

The software is progressing, maybe a little slower than I planned. But that's mainly a problem of finding some free time to work on it. The current github checkins update the main controlling loop that keeps track of upcoming events.

The events are represented by a separate class (IrrigationEvent), which are managed by the IrrigationPlanner. The planner is being periodically polled by the main controller task. The planner is still missing a query method for the actual tasks to perform. It also uses only hard-coded events, but that will suffice for now.

The hardware is also starting to take shape. I mounted the board in the IP67 enclosure. I ordered a buck+boost converter plus a switching AC/DC power supply. The buck+boost converter combo is used to later power the device by solar (+ battery backup), which varies widely in the input voltage, i.e. it can be below or over the needed voltage of the connected pump (approximately 14VDC).

The image shows the initial cabling within the IP67 enclosure. The controller and power supply isn't mounted yet.

All the components have now been properly mounted within the enclosure, including fuses on the primary (mains) side and both secondary power rails. Only the connections to the pump and the water reservoir sensor are missing.

This post is just a quick status update. It's mostly about the software side, because that's what I have mostly been working on the last weeks. I already mentioned some of the things, but I try to give a full view of the current state this time.

Hardware-wise, most of the board is tested:

• The switching regulators are working. The second regulator can be switched on and off on demand.
• The ESP is flashable and executes code.
• The relays can be controlled by the ESP.
• The battery voltage can be measured.

I still haven't tested the UART connections yet, but that's what I plan to do next (hardware-wise).

The software is also starting to take shape:

• A command console via the debug/programming UART is implemented for testing purposes.
• The fill level sensor protocol handler is implemented, but mostly untested.
• WiFi connects properly to my home WLAN. I'm planning to implement a WiFi manager class to encapsulated it better.
• An MQTT client connects to my local broker. This will be used later for status information and alerts. I'm currently working on the implementation of an MQTT manager class to handle multi-threading properly.
• The real time clock of the ESP is keeping the time, when the ESP is in deep sleep to preserve power. The time system is able to sync with an SNTP server. But the time can also be set via the command console.
• A rough plan to implement the control logic for the fixed irrigation plan is written down as comments within the IrrigationController class.

The configuration of the WiFi and other services is currently hardcoded in a config file. I'm planning to change the configuration mechanism either by providing console commands or by implementing a webserver.

Besides working on the software implementation, I worked on getting the code and documentation in a good shape. This ultimately resulted in publishing both the hardware documents and the software itself on Github:

• The software repository, which is also the main place for documentation.
• The hardware repository, which contains the KiCAD schematics and board files. The schematic is also available as a PDF and PNG.

Well, getting the documentation into a good shape also was a result of registering the whole project at Elektor's ESP32 Design Contest! You can also check out my project page there. Wish me luck!

In the last article I talked about my motivation and some thoughts and design goals of the Irrigation Controller. In this article I will talk about about bringing up the board for the first time.

The hardware

Many of my early projects taught me a lesson: don't populate all components of the board at once. Something will fail!

So, the first step was to populate the two switching power supplies of the board. Nothing more, nothing less. The first one's task is to power the main 3.3V rail of the board. It is always powered. Lo and behold, it worked in the first place!

The second switcher is normally turned off and will be enabled by the main controller, the ESP32. I didn't populate the logic around that yet, so the default of the switcher was to power up, too. This one is used for the auxiliary power to the relays and external sensors. It came up as well! The nominal voltage would have been 12V due to the relays, but I designed the switcher for ~10.4V to be able to provide power even when the controller will be powered by an nearly empty battery supply. 10.4V are enough to safely activate the relay coils.

Encouraged by this success, I went ahead and populated all other components. I decided to do this, because most parts are supporting stuff around the ESP32 itself, so I felt save populating it at once.

So, the time was right to connect the USB-to-UART bridge to the ESP32. The esptool did detect the device without a hitch! So I flashed some initial test code, which I developed on a simple breakout board before I even started to design the PCB. It came up as well!

What didn't work auto as expected was the "auto programming" circuit, which is able to bring the ESP into programming mode and reset it. When entering the schematic, I missed the fact that one of the bipolar transistors (which I replaced with MOSFETs) was flipped in the original schematic. So I ended up with wrong Drain and Source connections. I spotted the error, because my reset and and prog buttons didn't work when the UART-bridge was connected. The solution was to rotate the FET by 45° and add a flying wire for the now landing-pad-less pin. Problem solved.

This is an excerpt from schematic showing the correct auto programming circuit:

And this is how I fixed it on the board:

There was another mistake on the board: The drill diameter of the footprint for the pluggable connectors was too small. I didn't read all of the recommendations in the datasheet. I ended up rasping the connectors' pins down. I did that because I didn't have a drill with the correct diameter at hand. It also saved the copper to connect the upper and lower layers within the holes/pads.

All hardware problems have been fixed in the schematic and layout - just in case I should need to order the PCB again. I am planning on posting the schematic and layout on github, but I need to clean some stuff up and come up with a fitting license. Update: The hardware repository is online.

And the software

My initial test code didn't have any means to test the IOs of the ESP32, so that got pretty urgent once the board was assembled. I implemented very basic getter and setter routines for the IOs. I can now call them with a serial command console on the debug and programming UART. The console is a modified and ported version of Elecia White's command console, which is released in the public domain. You can find her and the embedded.fm podcast at @logicalelegance. I can highly recommend the podcast when you are interested in embedded development!

With that code implemented I was able to test the relays and the shutdown-mechanism of the second switcher. Here's a screenshot of a short session in the command console:

You can't see the commands I'm entering, because I missed to configure the terminal to send CR+LR instead of just the CR line ending. What I did was:

help
io_dir 2 1
io_set 2 1
exit

What you can see, is that I already got some MQTT test code in the build and a time keeping task, which gets the time from an NTP server.

Update: The software repository is online. It's also the main point of documentation for the project as a whole.

What's next

What's still missing to be tested are the two UART connections for external sensors. One of them will be connected to a fill level sensor that I'm currently building and trying to finish. The software is basically in place, but I need to finish the hardware and give it a test drive!

There's also an additional IDC connector bringing out an SPI interface. It has no planned use right now, but I wanted to be prepared to install additional sensors or other extension boards within the same enclosure as the main board. Obviously this hasn't been tested as well. I will do that when I have a use for the interface.

Let's face it: I'm a poor gardener. My main problem: Forgetting to water the plants. I'm thinking about this problem for many years now. Many ideas came to my mind, but I didn't actually start something in this regard.

But this year, sometime between spring and summer, I stumbled across the Gardena MicroDrip system. It's a starter-kit that uses a (indeed very very small) pump within some sort of water reservoir. The last part was pretty important, because my balcony has no direct water tap. The kit came with some pipe, some drippers, the water pump and a very basic controller. The controller is able to do some fixed-interval programs, but you can't freely program it. It has a connection for either a rain sensor or a moisture sensor, but that's all.

I used the controller over the summer and autumn and it worked pretty good. The plants were happy even when we were on vacation. The system didn't account for rainy days, but basically it worked fine.

What didn't work was: me - again. Because I tend to forget to fill up the reservoir. And that's one of the main issues I want to address with my own controller. The idea of my own "Internet of Plants" was born.

I'm also aiming at more flexibility in regard to watering the plants. The basic idea is still to use fixed intervals, but drop waterings in case of rain or extend the watering time if the sun was shining heavily.

My hardware platform is based on an ESP32. I designed a base board with some relays, power supply, UART interfaces (for sensors, e.g. the fill level sensor for the reservoir) and the ESP-WROOM-32 module.

Did you notice the color of the board? It's from OSH Park and they seem to like purple ;) I do like their board quality and price, even though the shipment takes a bit longer. They are producing in the US.

The image shows my first assembled prototype of the board. I assembled it by hand (as I always do), but this time I got myself a cheap hot-air gun (thanks Simon for your blog article! I got a Kaleep-branded version on eBay). I needed it because of the exposed pads of the switching regulators I designed in. It worked perfectly and I was really impressed how easy and fast I got it assembled!

The ESP-WROOM-32 also has an exposed pad, but I used a different approach there: I placed a fairly big via within the pad, so that I could solder it from below. The hot-air gun wouldn't have worked too well because the ESP-WROOM-32 is a fully assembled PCB (with RF shielding!) by itself.

On the top edge of the board are connectors for power, the relay outputs and the UARTs. The connectors are screw terminals which can be disconnected without loosening the screws, which might be handy when installing the hardware in its IP67 enclosure.

As of now, I just did some basic tests of the board. The ESP32 comes up fine and I'm able to flash it. The two switching regulators also work fine. But I do have to write some more debug and bring-up code (e.g. to stimulate the GPIOs the relays are connected to).

In case you wonder why there are two switching regulators: The first one is the main regulator for the 3.3V I use to power the ESP32 and all other digital stuff on the board. The second regulator is used to power the relays and external sensors. This regulator is normally off and can be activated via a GPIO of the ESP32. The UART level-shifters are also held in standby by default and can be powered up by the ESP32 on demand. I did this to reduce the power consumption as much as possible. I plan on driving the whole system on solar power sometime in the future. That's also the reason why I connected an ADC channel to the power input for voltage monitoring.

Despite the fact that I came up with the "Internet of Plants", I'm planning the software to be basically autonomous. I plan on using weather forecasts from the internet, but I also want to use local environmental sensors. If there is no forecast available (e.g. the internet is down), the fixed interval schedule will ensure the plants stay happy ;)

That's a quick overview of the project's state right now. Much coding to be done, more testing of the hardware and the fill level sensor needs to be tested (I plan to write another post about that sub-project as well).

My website got pretty outdated over the last ten years, I guess. I didn't only use it to show some of my projects, hobbies and interests, but also to try out PHP, MySQL and web technologies. That meant I did all the programming myself. YAML was the only CSS framework I used on the previous incarnation of the site.

But my free time got more and more limited, so I had no chance on keeping all that up. So, I decided to try out something new. The site is now powered by Ghost. Not only the technical aspect changed with that decision, but also the format: Previously, I hand-crafted static, categorized pages for my projects. And now it is a blog!

The idea isn't new, not even for technical and electronic sites out there. More and more of the sites I come across are blogs or they are written in an article-like style. So, that's what I'm going to try, too! I hope to find the time to move some of my old - but interesting - projects over, but I should try to focus on new things first ;)

If you are interested in my old page (German only), check out the archived version.