Boxing, part 1

Now the project is taking shape, there is a need to house:

Wooden box

So far, the best potential solution I found would be a nice wooden box like this:

Wooden Box

They exist in different sizes and shapes, including 16.5 cm and 20.5cm. I have these 2 sizes and am currently testing what feels best.

Adiabatic enclosure

Having vague memories from my University years and the concept of adiabatic enclosure, notions of heat and the First Law of thermodynamics, I am also trying to work out if vents will be mandatory or not.

The Raspberry model B+ seems a lot cooler than my old B (CPU is around 10°C cooler). I added a DS18B20 temperature sensor to monitor the temperature inside the wooden box and it is about 6-7°C more than that outside the box.

According to Raspberry Pi Engineer Gert van Loo heat should not be a problem, but I'm trying to keep the temperature as low as I can.

    Lacrosse, Digispark, Raspberry Pi, Roundup

    Quite happy with the results from the current setup, I decided to complete my collection of sensors with a WSTX3-TH to put on the front balcony.

    WSTX3-TH

    As a free bonus, since I moved to the final version (from prototype breadboard to a PCB one with all the necessary pins properly grounded), I seem to receive the signal from a neighbouring sensor as well. With 3 temperature readings from outdoors, I think I'm covered for the winter!

    Code is available on github :https://github.com/guillier/la_crosse_sensors

    Schematic is quite simple:

    Schematic

    Time to move on (and to concentrate on the main programme, maybe?)

    Duty Cycle and Presence

    I can think of 2 cases where I want to record binary data:

    • Duty-Cycle of the boiler
    • Presence of the members of the familly at home

    Use Cases

    Boiler

    As said in a previous post about Z-Wave, the status of the switch on the actuator is available and will be dumped every 5 minutes in a JSON file.

    Presence

    This is a little bit more tricky. One of the best way to know if someone (and who) is home might be to check if the mobile phones are around. I looked into possible solutions but every phone has its peculiarities: ping doesn't respond on iOS but does on Android. iOS has Bonjour/mDNS activated by default but Android hasn't, etc...

    Then, I discovered that my ISP's Box has an JSON API listing all the deviced connected with a flag called "active" bearing the values true or false. Unfortunately, this flag is not very reliable but combined with another one called "lastConnection" (returning a date), it seems possible to check if a given mobile was around in the last 10 minutes. The value 10 minutes comes from iOS which can be silent for up to 10 minutes. By running a check every 5 minutes, I can check if a phone is back home with a 5-minute resolution or has left home with a 10-minute resolution.

    One day, I might investigate the bluetooth tag/tiles on keyfobs but in the meantime, mobiles detection rules!

    Filtering is done by the MAC address so an associative array MAC address => owner is all what is needed.

    Storage

    In this case, we are not talking about a rate (something per second) nor a gauge (temperature, humidity, ...) but I still believe that RRD can be used here:

    At the end of the 5-minute period, we have a binary value (on/off, in/out, ...). Once consolidated (30 min ou 1 day), the only relevant information is either the total time for each state or simply the percentage.

    So if "always on for a given period" is represented 100%, then the easiest way to store the information is to use the value 30000 as base.

    rrdtool update presence1.rrd 1407153600:30000 # if on/present
    rrdtool update presence1.rrd 1407153600:0     # if off/away
    

    Why 30000?

    Remember that RRD will (for non gauge) always store a rate, hence will divide that value by the base period (called step).

    Here 30000 / 300s = 100.

    When consolidating to 30-minute periods, 6 values will be taken for the average calculation. If the heating is on for half an hour, then average will be 100. If it is on for only 15 minutes, the average will be 50 and so on. These values look like nice percentages :-)

    The same apply to the daily value. We end-up with the duty cycle of the heating or the percentage of presence at home day by day. Useful? No idea but that's not the point here!

    RRD creation parameters

    rrdtool create presenceX.rrd --step 300 \
    DS:personX:ABSOLUTE:600:0:30000 \
    RRA:AVERAGE:0.9:1:24 \
    RRA:AVERAGE:0.9:6:35064 \
    RRA:AVERAGE:0.9:288:1826
    
    rrdtool create heating.rrd --step 300 \
    DS:heating:ABSOLUTE:600:0:30000 \
    RRA:AVERAGE:0.9:1:24 \
    RRA:AVERAGE:0.9:6:35064 \
    RRA:AVERAGE:0.9:288:1826
    

    New RF 433Mhz receiver

    Following my post about the receiver for La Crosse sensors, I started to doubt about the quality of the reception.

    On my left: XY-MK-5V

    XY-MK-5V + FS1000A

    As I said before, I found this one on ebay for 1 € (inc. postage)!

    But it is not specially noted for its quality of reception and output signal is very noisy.

    On my right: RXB6

    RXB6

    I decided to break the piggy (hum!) and ordered a RXB6 module which has a far better reputation. Cost from China is $5 (inc. pp). Obviously it took 3 weeks to arrive but finally, I was able to try it on the Arduino.

    Surprise! It didn't work at all. Nothing, no signal on the PIN 13.

    After a while, and really thinking I got a duff one, I hooked it on the Digispark and... miracle!

    Performances

    But if I had some readings, it occured to me that something must be wrong as TX sensors are quite chatty (a repeted signal every minute or so) and I had only 20 values for a whole evening.

    Something was definitely amiss. OK pulseIn is not necessarily the best method ever but since the microcontroller is not doing anything else, this should not be a problem.

    While decoding, I ignore the LOW part of the signal (the 1000μS gap) but still...

    After a lot of trial and error, I finally understood where the lock was: A tiny little bug!

    The Bug

    The first loop validate the preamble by checking the value is 10d (00001010b) but the variable was defined by int so depending on the preceding bits it could have held a different (higher) value despite a correct preamble.

    To correct this behaviour I could either do a AND 255 with the value but I simply defined by variable by 8-bit byte type.

    I also changed the boundary timings to be less restrictive.

    Pin 13

    Reading about different receivers, it seems that the RXB familly (at least) doesn't cope well with pull-ups. Since the pin 13 of the Arduino has a LED, this might be the reason why it didn't work when I first tried it. It works fine on any other pin...

    Additional items

    Adding an external antenna to the RXB6 doesn't seem to make much difference but when hooked on the digispark, a decoupling capacitor (100nF) seems mandatory for the RF receiver!

    And the winner is...

    RXB6 module is definitely better, especially with the outdoor sensor, but it also uses twice as much power (6.7mA vs 3.8mA). And the XY-MK-5V has an unbeatable value for money.

    « Page 6 / 8 »