Monthly Archives: December 2012

I am writing his on my new Nook Simple Touch with Glowlight ereader. Yes, it is rooted, and yes, I am still getting used to the keyboard. Essentially this post is an exercise for myself to a) learn to type with a touchscreen keyboard (I have a QWERTY phone) and b) to determine if this is a viable blogging option. If I had to guess, I would say I could have written this post 4 times faster and with that amount fewer mistakes using a physical keyboard on a computer. Still I am really happy with the device’s capability thus far. Continue reading Nook: A Blogging Tool? →

Technology

MySQL Optimization Dillema

December 5, 2012 Mike Leave a comment

In response to this post, I have compiled some charts showing the memory usage of my VPS – specifically relating to MySQL, to determine whether or not I should not use InnoDB. Note that, this site is running on an InnoDB schema and so there would be additional migration steps to reap the benefits of disabling this feature. Check out the figures Continue reading MySQL Optimization Dillema →

Apache InnoDB MySQL VPS

Lifestyle, Technology

Dropbox: Dishing Out Storage Space

December 5, 2012 Mike Leave a comment

Dropbox is quite useful for storing specific files across various platforms including Windows, Mac OS X, Linux, Android, iOS, etc.

It provides 2GB of storage. This is enough for some files here and there but if you use it heavily you will quickly run out of space.

Here are some (free) ways to get more space: Continue reading Dropbox: Dishing Out Storage Space →

cloud dropbox

Older Posts

Lifestyle, Technology

Device Power Consumption List

Aside November 25, 2012 Mike 2 Comments

Electricity is expensive! Currently the cost per kWh is around 7.4 cents. Don’t be fooled, you still pay a delivery charge and other fees, tax and sometimes even retail fees. This brings the actual cost somewhere around 15-20 cents per kWh.

Continue reading Device Power Consumption List →

devices modem power consumption router switch wattage

Uncategorized

Automated Green House

Aside July 22, 2019 Mike Leave a comment

Purpose:
The greenhouse needs to be self sustaining and tolerant to drops in temperature and light condition. It can be scaled up and/or out for larger and/or varied environments.

Abstract:
A temperature/humidity sensor will monitor conditions polling every n minutes and a minimum/maximum can be set. Upon trigger of a low temperature event, a relay will trigger heat. A high threshold will trigger a fan, and optionally an automatic window opener.

A moisture sensor (hydrometer) will be used to monitor the soil conditions once or twice daily. The optimal moisture level will need to be calibrated by watering plants to their ideal moisture conditions. If the moisture level drops below the ideal threshold, a subroutine will run to trigger a pump to irrigate the soil, monitoring the moisture level once per second until the ideal threshold has been re-established. A rain catcher could be implemented for the pump to draw water from, with the heat from the greenhouse melting snow in the winter. Alternatively, a water source will need to be provided but is out of the scope of this implementation.

A light sensor will be used to monitor the light levels at regular intervals. The aim is to conserve energy usage while ensuring plants get the optimal amount of light throughout a preset time window. If during the window, the light drops below a set threshold (calibrated depending on required growing conditions). A relay will trigger the lights to turn on. If using lighting that does not cycle well, the light threshold should be calibrated to below the amount of light at sunrise/sunset. Otherwise, shade/overcast lighting conditions should be used to supplement available light throughout the light time window. Furthermore, this can be expanded to multiple lighting channels to control color temperature for encouraging vegetative growth or flowering (for example MH vs. HPS HID lights, or blue vs. red LED). A simpler separate system can be used which would involve a garden timer powering lights to produce the minimum light requirements to keep the plants in their light cycle time requirements. If using a 16/8 light/dark cycle, calculate the minimum day length of the winter solstice and power off the lights between this day’s sunrise and sunset times. Adjust start/end times accordingly as the light/dark cycle requirements change – note this will require manual intervention if not integrating into the system as above.

A camera can be used to detect motion if required, or to track progress of plant growth remotely. The sensors will also report near real-time data allowing override of lighting, water, temperature ahead of the pre-determined action intervals.

This system can be modified to aggregate data from multiple sensors to obtain an actionable average value for any given parameter, or, could be multiplexed into zones as required. A combination of these to methods could be used, for example, having a single heat source, but multiple channel lighting and irrigation. Of course, this would increase the complexity of the system and may exceed the IO capabilities of the interface. Instead, multiple standalone systems could be deployed, in a modular fashion, not leveraging all of the available capabilities of the system, provided there is at least one system functioning for each of the required parameters – temperature, moisture, and light.

Materials req’d (minimum)
Raspberry Pi – recommended Pi Zero WH ~$20
Temperature/Humidity sensor (1 GPIO) – ~$2
Heater – appropriate wattage to heat area to required temperature above frost at <100% utilization Fan - USB fan could be modified to be used without requiring relay Moisture sensor (1 GPIO?) - ~$3 each on Amazon https://www.amazon.ca/gp/product/B07KPH1KLC Water pump - ~$4 each on Amazon for low voltage https://www.amazon.ca/gp/product/B07BKXJXK1 Tubing - Appropriate size for pump and environment, optional irrigation kits can be used which contain T-adapters an various nozzles such as: https://www.amazon.ca/gp/product/B07M72H7YX Light sensor (1 GPIO?) - ~$10 or build your own with a photo-resistor Lights - LED recommended, ideally able to produce >25000 lux for all plants within the growing area. Wattage/lumen calculations exist based on growing area and distance from light source but expect at least 30W per sq. ft.
Relay x4 (4 GPIO) – ~$2+ per channel depending on number of channels

Technical details
We can re-use the 2-3 power GPIO pins (Ground, 3.3v, 5v) so we only require 1 pin for each sensor/relay.

It is possible to leverage low voltage pumps (3-5v) which would not require a relay, assuming there is enough available current to power the pump(s). This assumes we can default a 5v pin to OFF/DOWN. Otherwise, we are limited to initializing a 3.3v pin and setting ON/UP for the duration of the watering period. For simplicity, we will be using 3.3v power in a miniaturized proof of concept which can be directly expanded to use any voltage pump(s) via a relay.

Automated Irrigation
The moisture sensor requires 3.3v and ground, plus an pin (IN) for DO (digital output). The sensor is calibrated via a physical resistor to set the threshold. Once the threshold is met it triggers an event on the pin. This would be considered the trigger to stop the water flow. There need to be a fail-safe to prevent the condition where the cable is disconnected and no voltage is present on the line. This could be accomplished by leveraging the AO (analog output) on the sensor and an ADC (Analog to Digital Converter) to determine there is a valid reading. Alternatively, we can set a maximum water on duration to prevent over watering in the case of a sensor issue.
The water pump can be triggered by an event listener which fires when the moisture sensor reaches the low threshold. A maximum duration will be set to prevent over watering, and in the event of the maximum duration being reached, an alert should be generated for manual intervention due to the possibility of one of the following: 1) moisture sensor or pump failure/disconnect, 2) water reservoir out of water. For scenario 1, we can add some redundancy by adding multiple sensors and pumps for each channel and aggregating the sensor data using an !AND logic gate configuration where both sensors would be required to be reporting below the threshold for the watering even to occur. In scenario 2, we can mitigate this by either using a separate moisture sensor in the reservoir, mounted above the pump where there is enough volume of water to perform at least one watering cycle, or a water level sensor. Furthermore, the maximum duration event should be logged an logic should be implemented to alter watering behavior to prevent over-watering in the event of sensor configuration issues. An alternative, would be to override to a scheduled duration in the event of this type of issue. The water pump requires GROUND plus 1 OUT pin which will supply 3.3v directly to the pump or to a relay if a higher volume pump is required.

Heat and Fan
This is simply achieved by relays and polling withing appropriate intervals (~1 minute):
import RPi.GPIO as GPIO
import Adafruit_DHT
import time
heat=[PIN]
fan=[PIN]
mintemp = 10
maxtemp = 40

humidity, temperature = Adafruit_DHT.read_retry([PIN?], [PIN?])

if temperature < mintemp: GPIO.cleanup() GPIO.setmode(GPIO.BCM) GPIO.setup(heat,GPIO.OUT) GPIO.output(heat,GPIO.HIGH) if temperature > maxtemp:
GPIO.cleanup()
GPIO.setmode(GPIO.BCM)
GPIO.setup(fan,GPIO.OUT)
GPIO.output(fan,GPIO.HIGH)
else:
GPIO.cleanup()

NOTE: requires the Adafruit_DHT library https://github.com/adafruit/DHT-sensor-library

Lighting
Similar to above except using light sensor. Since a light sensor has not been obtained at this time, a start and end time will be used for the lights. This requires some manipulation of the datetime string (import datetime) and could be expanded to multiple morning/evening schedules. Ideally, once the light sensor is obtained it will be calibrated to the minimum amount of light and a not-before and not-after time of day will be configured. When the available light drops below the threshold it would trigger the lights. To prevent the lights from cycling too frequently, a longer polling interval should be used since the lights will need to be turned off to meter the newly available light. If the start time is 6AM and the light is below the threshold, the lights will be turned on. If we check the light hourly, at 7AM the lights will turn off and a metering will occur. At this time there may still not be enough light so the lights will turn on again. At 8AM we may have enough light, so the lights would turn off and stay off. Later in the day around sunset we may drop below the threshold, perhaps 9PM the lights turn on again but at 10PM they need to turn off. Once 10PM hits, it will be after the not-after time and the light will turn off until the next day 6AM not-before time.

Real-time metrics and interaction
In addition to the less frequent polling, we will check all sensors at a regular interval, likely once per minute. All data will be sent to a web service via variables in a querystring such as https://server/agh?temperature=20&light=1&water=1&reservoir=1&heat=0&fan=0&pump=0
This call will also allow for any variables to be updated, which can be done using either a database or plain text file on the server. A web interface will report the values as well. The text file might look something like agh.txt:
temperature=20
light=1
water=1
reservoir=1
heat=0
fan=0
pump=0
mintemp=10
maxtemp=40
notbefore=6:00:00
notafter=22:00:00
lastupdated=2019-07-22 16:00:00

This can be accomplished using urllib2:
import urllib2
url = https://server/agh?temperature=20&light=1&water=1&reservoir=1&heat=0&fan=0&pump=0
response = urllib2.urlopen(url)

The response can be parsed for the appropriate values and previous/default values can be used in event of a loss of connectivity to the server (the server can also be localhost if no network connectivity is available, however variables could only be modified upon restoration of connectivity).

Power Considerations
In addition to the materials costs, there may be a significant cost to operate a large scale setup due to power consumption requirements. The main factors contributing to this are heat and lights. We also need to consider the limitations of a typical 15A circuit. If heat and lights are required on the same circuit we are limited to approximately a 5×5 ft. (25 sq. ft.) growing area. This would allow for the required ~750 watts of lighting and a ~1000w heater which should be enough to heat a slightly larger than 25 sq ft room with moderate insulation. If heat can be supplemented from another source, and we only require lighting, we could potentially expand to 8×8 (64 sq. ft.) area or more, depending on supplemental light from the sun, and other factors related to the light requirements of the plants.
In the worst case scenario, it would cost up to 8 dollars per day in energy costs for only 25 sq. ft. if you had to run 1000 watts of heat around the clock and 750 watts of lights for 16 hours per day assuming 20 cents per KWh electricity cost. This is not feasible, but on the other hand, if heat is not a consideration, and there is a sufficient amount of light, a 64 sq. ft. growing area could be operated at 12+ hours of light per day by running up to 1800 watts of lights for around 4 hours each day during the winter months where the day light is only ~8 hours for under $2 per day. Using similar numbers for the 5×5 area would be well under $1 per day. An average setup could expect to cost between $1-8 per day in power costs meaning anywhere from $300 to $3000+ per year. The absolute lowest cost could be achieved by only using this solution to keep plants alive through the winter and not try to flower, meaning less heat and light requirements (above frost, and supplemental light to keep vegetative growth, at least 12+ hours per day).

Technology

Bitcoin: Data Cost

Aside October 3, 2012 Mike Leave a comment

Somehow my blkindex.dat file became corrupt the other day so I got a little nervous as I remember that one .dat file contained all my bitcoins – within a split second I realized this is the wallet.dat file so I quickly backed it up again for added piece of mind. While in the bitcoin data directory I noticed the size of the blkindex.dat file was over 1 gigabyte! And then the blk0001.dat was 2GB, blk0002.dat was another GB! Let’s not forget about debug.log – another gigabyte. Over 5GB to be able to use the currency? And how many people are using the currency? A lot. This is a problem that is inherently created due to the nature of the currency. But what are some possible solutions? Continue reading Bitcoin: Data Cost →