HydraFerret: Multi-sensor IOT with a simple interface.
↓↓ Dig deeper ↓↓
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:
The planned release cycle is expected to roughly follow this time line:
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.
Some scenarios for its use include, but of course are not limited to:
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.
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:
|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||bmp280||1||Temperature, Humidity, Pressure|
|I2C||css811||4||CO2, TVOC (Total Volatile Organic Compounds)|
|I2C||ina226||32||Volt, Amps, Watts|
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:
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|
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:
These are not listed in any order of priority. Not being actively developed or worked on at present.
|Thank you for visiting this website||Home|