There has been lots of detail about components of the system, but I thought it worthwhile to show what the overall block diagram of the system is and explain how it works at the macro level. You may also note some modules that have not been discussed yet, so read on.
The system is conceptually very simple, there are inputs and outputs to modules that manage those sensors, this information is processed, converted to usable information and send onto the central broker. Then, the front end front-end user interfaces allow simple interaction with the entire platform in a unified manner.
Working from left to right and generally top to bottom, the system is made up of the following components.
Power
The whole system is powered from its DC power source, a used car battery, making the system stand-alone and not dependant on any house power. The battery is charged from a solar panel using a solar charge controller. The power generated by solar, the charge to the battery and the load from the battery is monitored by the power sensing module, allowing visual information to be provided about energy gains and usage. An alternative DC power source from the house is also available over the winter months when there is no solar power. This does not go via the power sensing module, since I can determine the consumption rate directly from the main boards power sending capabilities
Other modules may have other power sources, but we will get to them later.
The main unit
The main coop controller is what manages the central system, it can stand alone and run the coop, using just its power feed and all the sensors and control outputs. It can determine date/time/location via either GPS or via NTP, so it doesn't even need WiFi
The main unit interfaces directly with the power sensing module and front panel so that it can detect anomalies with power and protect its self. it can also interact locally with anyone in the coop, for example if the main door is opened and closed, the user interface is interacted with, etc.
AI Modules
Artificial Intelligence modules will be deployed into the main coop and the conservatory. The coop module will be able to detect chickens and hence count their presence, plus see if anyone is staying in the coop for extended periods. This generally means that the chicken is either broody, or perhaps it has died overnight. The module will be able to detect an egg, so you know how many eggs are in the coop, ready for collection.
The same module will be used in the conservatory under the coop, this will perform the same role as above, which means it can see chickens during the day, or sick chickens during the evening when the healthy ones go back to roost. The same egg detection will be used to locate any stray eggs that were not laid in the coop.
In order to do this, it also needs to be able to tell the difference between an egg and other similar shaped objects, such as stones, thus protecting against false positives. The module will also be able to tell the difference between a Chicken and a Rat as that latter turn up at any time of day or night. This allows me to arrange pest control either via poison outside the coop as that works 24x7 and is located well away from the pen, so the Chickens can't get it, Alternately, an Air rifle can be used for pest control. Similarly, the family dog, is a really good ratter outside the pen and a herder of chickens when they are in the garden and need to go back to their pen.
Food and Water sensing
One area that is glaring by its absence in the current design is monitoring of the critical supplies - food and water. This has been a bit of a challenge to date, since the feeders are in the pen and wires are ugly and a trip hazard. However, now that we have ESP32's in many roles and their low power capabilities are significantly better than the older modules, perhaps we can come up with a stand-alone design that allows sensing of food and water levels along with the rate of consumption, since this tells you how many days of the consumable is left. If the food or water feeder is blocked or if the water has iced up and alternative water sources are needed.
Combining the data feeds
The system has a number of data feeds, yet most are stand-alone and all of them are outside the house, whereas we are mainly in the lounge, so how do we bring all of this together to make it a useful integrated system ?
The answer is simple, its to use Message Queue Telemetry Transport (MQTT), since this is commonly used in Internet of Things (IoT) solutions to aggregate information and allow for higher level processing of events and telemetry information.
A Mosquitto server acts as the MQTT broker, allowing all of the modules to:
- Send telemetry - regular updates on critical sensors.
Examples are temperature, currents, voltages, food and water levels, etc. - Send events - irregular information / low frequency updates
This may include system restarts, door movement, charging system state changes, firmware updates processed, etc. - Commands
Commands are sent to modules instructing them to perform some form of action.
This could be to control the pophole door, restart the module, turn on or off a light, go and pull the latest firmware from the local web server, etc.
This is all achieved via the Pub/Sub approach used in MQTT platforms. Systems Publish (the pub part of the name) information, to topics, this tells the broker what is happening. The detail is provided in the payload that is delivered to that topic. An example is that the internal temperature in the coop is 21.5c, or the battery is now at 85% charged.
Subscribers (the sub part of the name), ask the broker to be notified if specific topics are updated, hence allowing them to see the information in near real-time.
Turning the process around, you can send commands to modules by publishing to their command name space, telling them to perform certain actions and the beauty of this is that they don't even have to be on when you send the message, as long as you mark it as persistent. The broker will queue persistent messages up until the client connects again. This makes the protocol ideal for low power solutions where nodes may be asleep, conserving battery power, when commands are sent to them. When they wake up, they get a list of instructions to perform. Non-persistent messages are sent to all nodes that subscribed and are currently on-line, since there is no point getting 500 messages about what the temperature was several hours ago.
User Interfaces
Now that I have a single, central view of the truth, I can provide a user interface to all of the modules, irrespective of what they are and how they work. This allows for a central control panel to be provided in our lounge that allows for the same information on the front panel to be visible locally, so no more squinting through the window to see what colour the status LED's are and no more welly boots to go and find out what's wrong. The same approach also allows for future enhancements such as aggregating the data into a time series database, then visualizing that to produce fancy graphs about food and water consumption through the week, temperature change of the month, power generation from the solar panel through the year. The options are endless.
The same central broker also provides a simple way to integrate Amazon Alexa into the platform. A single module just needs to handle the interface to Amazon Alexa and then issue the relevant command via MQTT or provide the latest information that we subscribed to. We could say "Alexa, what is the temperature in the coop" or "Alexa, how much food is in the feeder". It could also tell us "A rat was detected in the conservatory" or "There is an egg in the conservatory", or "the water feeder is frozen"
But, at the moment, these are all just interesting ideas on the project backlog.
Engineering
The final capability to consider is the engineering support holding this whole platform together. I need the ability to reach out to all the modules in a consistent manner so that I can see what is having problems, that implies having a console to talk to the modules, or centralised logging so that I can see what is going on, plus the ability to push firmware updates to modules as required, this can be done via over the air (OTA) updates, pulling firmware from a web server within the house.
Environments
Having considered all the modules above, don't forget that these are the individual modules for a single environment. The platform has two environments, Dev, where development is performed in a comfy office with tools, warmth and absolutely no mud or chicken poo and probably a coffee or perhaps a cold beer. The other is production, which is in the coop, where there are no home comforts and plenty of mud and chicken poo and plenty of inquisitive hens that want to know what's going on and can I eat it ?.