My well water tanks are always full, but in times of drought it can take significanty longer to fill then other times. I made WellWatcher so that i can record tank water levels 24/7 and be able to determine;
- how long it takes the take to fill (27minutes to 24 Hours)
- how much water was used in a period of time
- if the water system has a steady leak
- the current/power consumption of the well pump
- and more.
This is all accessible from real time graphs in OpenHab development package and also over the internet using a Dice display.
now that's it's in the tank and basically working, along with the pump current sensing arduino, i'm starting to see some interesting data.
here's a pic of the Water level (blue), Air temp in tank (green), and the pump current (black)
it's very dry and years of drought here. i know i can pump thousands of gallons in one pull in the spring time.
here we can see the pump time shorten for each successive pull. the last one always gets cut short by the level sensor in the tank.
i look forward to plotting the number of pulls it takes and the time/gallons in each pull.
as noted earlier, i have the water coming in from the inlet at the top taking a right turn and shooting horizontally away from the sensor. but i believe this results in too much surface turbulence and accounts for a number of features in the blue curve. i intend to turn the fill line down into the water below the water line to prevent this. i will use a T connector at the top so that air can get in and out of the fill line as needed.
I've settled on Openhab as my house controller. little challenging to learn but seems like the best choice right now. that might change with in the year, there are many young contenders out there now. I do wish it had a better looking UI. PI-dome looks very nice. i have hopes for Openhab2 and will move on that as soon as possible.
and i'm going with mysql just out of familiarity. was a simple matter to add persistence and watch a chart of my radio's temperature automatically updating and the output form the ultrasonic sensor.
i've decided to pretty much abandon the Raspberry Pi. it's not clear how it can be useful to me. I do not like to intentionally work with slow systems, and it seems not surprising that Openhab would be sluggish. even the raspberry pi 2 would make me feel constrained.
and i have a windows machine running 24/7 for years now, so why not make it earn it's keep a bit more. i'm using a serial/USB connection straight into the PC and into Openhab. no problems. I am really interested in MQTT and expect to pick that up before long, but i don't think i waste much effort by going serial for now.
still waiting for bits and pieces to start assembling some hardware.
I now have a system with 3 moteinos, one as the remote sensor, one as the permanent wireless gateway to my house RPi, and one dedicated to wirelessly burning the other 2 (and i've got plans for more)
didn't have much problem getting a python script to read in the serial data from the gateway moteino and posting it to Thingspeak, so i've moved on to ordering some bits and pieces. namely two waterproof boxes, i think i'll have the processor and battery in one box on top of the tank and the other just inside the tank with the ultrasonic sensor and cables for temp sensors. this way the battery is more removed from my water supply.
researching the latest/greatest temperature sensors i've settled on the LMT87 from TI.
also ordering a couple more moteinos, one for my under cabinet lighting needs and another for a (very) remote driveway sensor, solar powered.
thinking of laying out a shield with a LiPoly solar/charger and a coulomb counter like one of these. or texas instruments version. i would love to know such power usage details on a remote node. it could be temporarily attached just for initial characterization/tuning, so perhaps the coulomb counter should have it's own board, or even it's own arduino/moteino, report the data on it's own channel even.
Progress! Now i am posting live ultrasonic distance data to Thingspeak.
HC-S04 ultrasonic sensor connected to a Node Moteino which send the data to the Gateway Moteino which serial ports it into the Raspberry Pi which uses a python script to post directly to a Thingspeak channel.
the mechanics are in place, now for a lot more work filling in all the details.
code is still too mashed up to post. the Thingspeak channel is showing the distance from my desk to the ceiling and the radio temperature......
I've started off by following a project from Low Power Labs, called Home Automation Gateway. It offers all the features i need including encrypted data handling and extensibility. My first tasks were to configure the RPi with Debian and installing NGINX server with PHP5, Pyserial comm port routines, and more. System is up and running but barely tested. At least i do know i am serving https secure pages from the RPi. that was a fun little achievement in itself.
Next i tested the Moteinos with basic Node and Gateway example code to get familiar with them and their RF connections. very easy here. The next challenge was to program one of the Moteinos wireless with the other Moteino. I did this from a Windows based PC, so installed Python for windows and used a script provided by LowPowerLabs for the purpose. not big surprises here either. Wireless programming worked right off and i look forward to using it regularly, even structuring my whole home environment around it.
Then i connected a simple HC-S04 ultrasonic sensor to the remote Moteino and got that working, first using simple code of my own, but now i'm using a ultrasonic library called NewPing. seems to work nicely. it was a simple matter to get that data shuffled over to the Gateway Moteino.
Now i'm starting to receive data into the RPi from the Gateway Moteino using a python script. I'm a novice at python, have been for many years :-) but look forward to gaining a lot of real world experience from this project. My first goal will be to send that relatively raw data to a site such as EmonCMS.org or Thingspeak.com for instant storage and logging. My longer term goal is to store raw data on the remote sensor as much as possible, for backup, and to mainly store it on the RPi in a database, possibly NeDB?, and to serve pages mostly from the RPi in the future.