Librato – Real-Time Monitoring of my room temperatures

The electronic radiator controllers in my house send out the current temperature every now and then. I receive this messages with my CC1101 based hardware solution and needed a solution how to graph diagrams that show the room temperature over time of day.

Librato is a cloud service provider that allows me to visualize this metrics in beautiful charts … in just a few minute’s time! It is really awesome how fast it was able to compose a dashboard using the charts I created for temperature values and the received signal strengh (RSSI) of the radiator controller as sender of the data.

I used python (librato-python) to send the metrics up to Librato:

api = librato.connect(“myemailaddress@gmx.de”, “some_api_key”, sanitizer=librato.sanitize_metric_name)
q = api.new_queue()
q.add(controller[deviceId], temperature)
q.add(“RSSI_” + controller[deviceId], convertRSSI(rssi))
q.submit()

Librato provides even more, check out their website at https://www.librato.com

Check out his picture of my dashboard

Librato Dashboard

What can you see? In some rooms, at night the temperature slightly goes down from 21°C   to approx. 19 °C. In the morning at 7am, the central heating controller puts it up to 21°C again, and 23°C in the bathroom.

SPI communication issues with Raspbian “Jessie”

Now that we are in the middle of autumn in Germany, and the daylight gets less and less, I decided to re-activate this little project of mine.

First thing was to update my Raspberry Pi (1) to Raspbian “Jessie”.

First check of my CC1101 Socket Driver Stack – and: Of course, it did not work.

Reason was that with Raspbian “Jessie” the way to enable the SPI kernel driver has changed. You can enable it using the “Advanced options” in the “raspi-config” configuration tool. Check out the description here: http://www.raspberrypi-spy.co.uk/2014/08/enabling-the-spi-interface-on-the-raspberry-pi/

Okay, after a reboot

  • lsmod shows the SPI kernel driver spi_bcm2835
  • The device files /dev/spidev0.0 and /dev/spidev0.1 exist

After that, the CC1101 Socket Driver Stack still did not work. Nothing was received over the air. Doing some analysis revealed that the ioctl calls responsible for the SPI data transfers between RPi and CC1101 failed.

Reason was that Raspbian “Jessie” uses a newer kernel than “Wheezy” and that the main ioctl message structure got a new field named “pad”

After I did take some more care to initialize this message structure in the code, everything worked will again.

And now the bad new: When analyzing the issue, I also killed my cross-compile installation  on Mac OS. It still does not work until now 😦

Works (almost) as expected

20130825-133922.jpgThe picture shows the board plugged into GPIO expansion headers of the Raspberry Pi. The question was: Will the “new” hardware work with the “old” software controlling the CC1101 and responsible for receiving the RF messages? Well, only partly. The SPI communication worked directly without any changes neccessary. But, not a single RF message was received by this “new” hardware. The reason is, that the Anaren A1101R08A-EM1 evaluation module uses a 27 MHz crystal osciallator, while the previous hardware and also the RFBee used a 26 MHz crystal oscillator. All my calculations regarding the frequencies (frequency related configuration registers in the CC1101) where of course based on 26 MHz, and had to be recalculated. After having done that, everything worked pretty well.

Message from socket:  1810755110755130C903000849EF -81dBm
Message from socket:  1800A20100A20130C9030008CCD2 -66dBm
Message from socket:  1810755132BC3F10600301FF0171 -82dBm
Message from socket:  1810755132BC3F2309030101F4C0 -82dBm
Message from socket:  1810751A32BC3F315002010098 -79dBm
Message from socket:  1632BC3F0B1F09030008205F -79dBm
Message from socket:  1632B44AE21F09030008574E -73dBm
Message from socket:  1800A1E2FFFFFF10600301FF01F4 -74dBm
Message from socket:  181071F91071F930C9030008CC24 -68dBm
Message from socket:  181071E8FFFFFF23090302083415 -50dBm
Message from socket:  181071E532B44A3150020100CE -80dBm
Message from socket:  1810755132BC3F10600301FF0171 -81dBm
Message from socket:  1800A20132B44A230903010834A9 -66dBm
Message from socket:  1810751A32BC3F2309030101F4F7 -81dBm

After soldering

This is how the board looks like after soldering the two plug connectors and the GPI connector for the Raspberry Pi. Can’t wait to check if my software will work it …

Image

BTW: I still have one PCB left and also the required plug connectors and a GPIO socket. So, if you like to have it please contact me and we can talk about a fair compensation.

PCB: First picture of the baby

Although it is not in production yet, Elektor PCB Service has made available a first picture of the PCB I designed a few days before in Eagle. I am really excited and wonder if everything will work as expected … as soon I hold it in my hands.

On the right side you can see the holes for the 2×13 pin socket for putting the PCB on the Raspberry PI’s GPIO header, while on the left side you can see the holes for the two Samtec TFM-110-01-L-D-A headers.

Image

Samtec headers arrived

Samtec TFM-110-01-L-D-AAs I already wrote in a comment of my previous posting, I was quite unhappy with the Anaren A1101R08A-EM1 evaluation module, as the spacing of the socket connector is 0.05 inch and the socket is quite to narrow to put in a test wire in a reliable way.

Possible solution: I ordered the counterpart to the socket connectors, two Samtec TFM-110-01-L-D-A 050″ Tiger Eye™ High Reliability Terminal Strip. Unfortunatelly, I wasn’t allowed to directly order it at Farnell as a private person, but I had to go through Heinz Büchner Elektronik (Berlin). The picture above shows these Terminal Strips.

What’s next: Design a PCB to which to solder this terminal stips and connect them to a 2×13 pin socket suitable to plug into a Raspberry Pi.