-
UPDATE:
04/24/2016 at 10:16 • 0 commentsAs you can probably tell, I do indoor projects in winter, and it's coming up on winter in the South half of the world... %) Meanwhile, the Thermomuno has been in continuous operation since last year, and hasn't missed a beat. But watching it for that time has pointed out one other thing - the DHT-11 sensor is pretty shoddy - the humidity never shifted much either side of 40% during the whole year, while officially the RH moved between 20% and 80%. A slightly upmarket sensor might be on the cards, or maybe a range of them, in which case I'll keep this project updated.
-
End of Cycle
09/04/2015 at 00:09 • 0 commentsThermomuno is at the end of its cycle, I'll update the github code when I'm over this months-long flu.
Changes haven't amounted to much, I made the display routine randomly print the temperature and humidity at different heights on the screen to look a bi like a screensaver, and a "heartbeat" which is just printing an asterisk in two different colours alternately so that you know the program's doing something.
Thermo is being replaced by a newer project Kitchenduino which will monitor inside and outside air temperature and log that to a laptop, air pressure, two fire/flame sensors (as it's near both the wood fired heater and the stove) and movement, and will flash a few Neopixels and control the kitchen's LED lighting via a Darlington array and relays depending on time of day and movement.
Thermonuno's hardware will become something else, never fear.
-
Code breakdown
08/03/2015 at 02:44 • 1 commentAs I want to use this for several projects, I'm working to break down the one big loop into subroutines. ( aka functions )
The sensor reading could be done inline but then it's not quite as universal as it will be once I abstract out the hardware specific stuff. Because then, I can call ReadTemp(t,h) in my loop and just put the ReadTemp() module for the particular hardware I'm using into the code.
I'll still have to make sure the relevant library is compiled and the right input pins etc, are initialised but changing a sensor to a different type will be as easy as just including the appropriate version of ReadTemp().
This makes sense because I'd like this to be applicable to as many different sensors as possible, in combination with as many others, as possible. In particular, I want this to work with ModulUno as part of a network of sensors around my homestead that automates absolutely everything for me, so some FEPs (Front End Processors) may well do a dozen different (but overlapping between different FEPs) things, and then it's easier to have just one place in the repository to find all the code snippets.