Introduction to HydraFerret
Enfield Cat's Blog: Arduino and other projects.
Introduction
HydraFerret allows for an ESP32 processor to be configured to write environmental data to xymon, where multiple sensors can be added on a plug and play basis. This allows the user to relatively easily build an "intranet of things". Its goals include environmetal awareness and supporting "citizen-driven science". It is hoped that a low monetary cost of entry combined with some hands on work to implement also encouraces interest in STEM subjects at school. (STEM = Science, technology, engineering, and mathematics) Commercial data loggers are available, but can be very pricy, and may be out of reach for students and community groups. Too often science subjects are viewed as the domain of geeky kids and on greying old white men. It should be the space where anyone with a curious mind can make a contribution, regardless of age, ethnicity, religion, disability or gender orientation. Therefore there is an emphasis in these pages at low cost of entry and some hands on implementation.
HydraFerret is free to use and does not contain advertising. It uses inexpensive modules which can be bought off AliExpress or EBay. A basic one node configuration reporting to xymon server on AWS or Azure free tier should cost less than USD 10-. Alternatively a RaspberryPi (or other Linux server) could also be used for the xymon server.
There are two parts to HydraFerret:
- ESP32 module This interfaces with various sensors, and returns the data to a webserver. See Installing HydraFerret on ESP32 for details on installing firmware on an ESP32 module.
- Webserver Either Nginx or Apache with xymon installed. Xymon will classify collected data and allow for data to be graphed. See Configuring xymon for HydraFerret for more detail.
The planned release cycle is expected to roughly follow this time line:
- Nov 2020 - Mar 2021 Initial beta releases: closed source
- April 2021 Release 1.0, open source
This release cycle should allow the initial functionality to be defined and initial drafts of documentation to be created. Support will be limited to information published on this website during these initial releases. There is no commercial support for these releases.
NOTE: While HydraFerret uses xymon, it is not xymon. Please do not expect this project to answer questions about xymon beyond its configuration with HydraFerret, nor can the xymon project answer questions about HydraFerret.
What can HydraFerret be used for?
Some scenarios for its use include, but of course are not limited to:
- A curious house holder wants to know climate variations between the north and south side of their home, or the temperature and humidity difference on either side of a curtain.
- A vegetable grower wants to monitor conditions (light, temperature, humidity, soil moisture levels) inside greenhouses.
- A vinyard may want to set up a frost warning system
- A "Fish 'n Chips" shop owner wants to have constant fridge/freezer temperature monitoring, and would like to know kitchen temperature and humidity.
- A bank of solar panels use a common ground connection could be monitored.
- An environmental group monitoring the effects of a quarry (eg pm2.5 pollution levels), place sensors on the properties of residents who live around the quarry site.
- A school meteorology course tracking seasonal and monthly pressure, temperature and humidity changes.
What should HydraFerret NOT be used for
Please understand the limitations of HydraFerret before deploying it. Its original intent was a data logger.
It is not a burglar alarm system, or a home-automation system. It has limited automation ability and potentially a delay of up to a few minutes on sending an alarm. While it does have some features which allow alarms to be created or to control external devices, these should only be used where failure to trigger or delayed triggering is acceptable. Do not use it in any application which would threaten life, limb or property!
HydraFerret can create an alert, but logged data is based on 5 minute averages, and in addition to the averaging period there may be a delay in raising an alert. So lets assume you want to know when the UV index hits 10. What may happen is over the 5 minute period you have 5 samples, they read 9.5, 9.8, 10.3, 9.8, 9.5. Here we can see in one sample the threshold of 10 was exceeded, but the average is less than 10. The result is no alert is raised.
HydraFerret tries as far as possible to use affordable components. This means its readings might not have the range or accuracy of "laboratory grade" equipment which may cost many times more. However, it should none the less provide reasonably accurate and consistent readings.
When using outputs, typically these only become effective after the first 5 minute monitoring period. Therefore on start up, they should default to a fail-safe default setting. while it is possible to control high voltages using relays, that does not mean that it is something you should do, or is somehow automatically endorsed by using using HydraFerret. Only use outputs for things you can thoroughly test, and are within your own capabilities to test. Always assume things won't work as expected, or fail under unexpected conditions.
So how does HydraFerret work?
Most sensors supported by HydraFerret are I2C devices, allowing multiple devices to be added on a "Plug 'n Play" basis. Up to 2 I2C busses can be defined. In addition to this it supports interrupt counters, analogue to digital conversion and serial devices. When configuring HydraFerret, the assignment of in/output pins and i2C addresses should be manually tracked so as to ensure there are no conflicts. HydraFerret won't detect incorrect pin or address assignments.
The support matrix looks as follows:
| Type | Device | Max Count | Comments |
|---|---|---|---|
| Digital In | Interupt | 8 | Interupt counter can be used for devices such as water flow meters |
| Digital Out | Relay, PWM, Servo | 8 | Uses RPN calculator to determine output state |
| Analogue | Analogue | 8 | Various devices such as pressure sensors (currently disabled) |
| Serial | Serial | 2 | Used for pm 2.5 counter, eg pms5003 or zh03b. Also accepts ASCII and NMEA input. |
| I2C | bh1750 | 4 | Light: Lux |
| I2C | bmp280 | 1 | Temperature, Humidity, Pressure |
| I2C | css811 | 4 | CO2, TVOC (Total Volatile Organic Compounds) |
| I2C | hdc1080 | 2 | Temperature, Humidity |
| I2C | ina226 | 32 | Volt, Amps, Watts |
| I2C | veml6075 | 1 | UV Index |
| OneWire | ds18b20 | 10+ | Temperature |
What does the output look like?
For general overview of what xymon looks like and how to navigate through it see the xymon web pages. A screen shot of one device's output is shown below. There a few things to note:
- The unit name and test type appear at the top of the page
- A history button allows you to review the history of any status changes
- The date and time of the the measurement is given. xymon uses a 5 minute interval by default, and the individual sensor may have made multiple readings over that time and provides a 5 minute average in the display.
- The measurements are provided in metric and imperial measure. Graphs can be adjusted to show either metric or imperial measure.
- The default graph shows a 48 hour period, but clicking on it will show 48 hour, 12 Day, 48 day and 576 day histories.
- Using the magnifier icon allows you to zoom in on just a short period or narrow range of data.
- If there is a break in communications for 10 minutes or more, say because of a network fault, there will be a gap in the graph.
How are multiple devices distinguished?
lets assume there are 4 ina2xx devices attached, on i2c bus 0 they are 0x40 and 0x41, on bus 1 they are 0x41 and 0x44. The i2c busses are scanned in sequence, then each bus is scanned in address sequential order. Discovered devices are numbered with an index number in the order they are discovered, starting with index number 0. Assume the HydraFerret unit is using a default name of "HydraFerret". In the example here the devices are indexed as follows:
| i2c Bus | Device Address | Index | Default Displayed Name |
|---|---|---|---|
| 0 | 0x40 | 0 | HydraFerret |
| 0 | 0x41 | 1 | ina2xx_1 |
| 1 | 0x41 | 2 | ina2xx_2 |
| 1 | 0x44 | 3 | ina2xx_3 |
The first device is name by default to the of the monitoring unit, and successive devices are automatically named with the device type and index number. Gaps in the addess ranges such as on bus 1 are not an issue. Where there is only one i2c device attached that naming may be sufficient. But these default names can be changed, eg: if the 4 ina2xx devices were monitoring solar panels sharing a common ground they could be named: panel_north, panel_south, panel_east, panel_west.
If a hdc1080 temperature sensor were added to bus 1 with an address 0x40 of the example above it is distinguished as a different device type, and automatically becomes hdc1080.0. Note the new device address does not conflict with other addresses on that i2c bus, and the address list of each i2c bus is independent of the other. This automatic scan and name similies the process of adding or removing sensors. But some cautions also need to be applied:
- Power off the HydraFerret unit when adding or removing sensors. Do not assume they are "hot plugable".
- Always check all devices have address unique to that bus. eg. you not be able to place 2 sensors with address 0x40 on the same bus even if they are different types.
- Adding new devices might muddle up naming. eg; there is one hdc1080 on a system, it is on bus 1 and is named "inside". When the unit starts it will scan i2c bus 0 ifor sensors before bus 1. At a later date another hdc1080 is added to bus 0, to be called "outside". Since the name "inside" is associated with hdc1080.0, it will require both devices to have appropriate names assigned to them. These names will then be what is displyed in xymon reports and graphd for these devices.
Proposed additions
These are not listed in any order of priority. Not being actively developed or worked on at present.
- Local display of data, so that the unit can be a viable standalone unit without requiring a xymon backend.
- Support for a binary switch input, eg to over-ride an output setting.
- Support for sonar range detection, may be useful for monitoring water tanks, small grain silos, waste skips.
- Support for other sensor types.
| Thank you for visiting camelthorn.cloud | Home |