I have a pet hate – the so called “np result backfill”
This is a syndrome that occurs on websites that use text search – and in situations where your search normally would result in no results returned.
The commercial owners of sites are so afraid that you will leave their site in disgust – and will rather show you non-relevant results than no results at all.
Personally I’d rather see nothing than being presented by non-relevant stuff.
One more type of displays
I’ve tried to do some further analysis of the problems I have with the FHT80B wireless thermostats – and the interference from the Jeenodes in the house.
As I have mentioned before I store all read ins from all the house sensors in a memcached instance on one of the servers – and for the FTH80B’s it looks like this (after I throttled the Jeenodes sending frequency)
It basically shows that the last time I heard from the FHT80’s was 55 seconds ago for the conservatory thermostat, and 99 seconds from the living room one.
It is also clear from this that the actuator values are send frequently – the rest only less often.
This timestamp makes it a lot easier to discover noise.
So when I run updates to the displays in the house with no real interval between updates I can loose any update from the FHT80b for up to 12 hours at a time. At the same time I can not see any such loss of data between the Jeenodes – indicating that I either have a problem with the CUL receiver for the FHT80B’s – or the protocol used for the FHT80B’s is very interference sensitive.
More to come.
From Amazon – specifications for one of their LED floodlights
– eh – 50.000 years?? How did they test this?
I have a problem with the house monitoring system – it looks like I’m a victim of interference
If you look at the graphs for our FHT80B radio thermostats you will notice something missing :
There is not red line (temperature readings) for the top graph (Concervatory) at all – and only a short line for the second graph (living room).
A bit of experimentation shows me that this is due to the Jeenode transmissions that update the Jeenode displays! If I turn these off (or even lower the update frequency) then the temperature readings start appearing again.
The reason that we can see some reading for the living room is because the transmitter is closer (read: less noise).
I will try to pin point the problem to see if a bit is shielding can reduce the problem – or moving the CUL receiver.
I have been working on upgrading this site to run under Drupal 7 – not without its challenges – but the problems were solved one by one, until just one major one was left.
It turns out that the “Blog API” calls that enable external editors like Ecto to communicate with Drupal was removed from the core in the move to Drupal 7. And it is currently not available – so this is a showstopper for me.
On a positive note – the blog Api module project has reached its goals for chipin contribution and expects to have the module ready around January 1st – 2012.
So I’ll wait for this.
The high level software in the house monitoring system works on a simple principle
(Click for a larger pic)
All the data collected from the various sensors is sent to a memcached instance running on one (or more) of the servers, and stored together with a timestamp.
A small library makes it easily accessible for all the other software in the system.
In a simple display it looks like this :
As I was feeling rather under the weather on Friday and Saturday I spent some quiet time rewriting parts of the home monitoring software, but before I write up something about the details I;d better describe some of the high level details
(Click for larger image)
On the right hand side are a large number of jeenodes and other nodes with a variety of sensors.
All the jeenodes send data wirelessly to 2 different collecting jeenodes in different parts of the house. This is because coverage can get spotty with just one receiver. As a matter of fact the design of the system means that the transmitters effectively multicast and the data can be picked up by as many receivers as you may want to have to provide cover. All these receiver run the standard jeelabs demo code – as it makes programming everything really easy.
There is also one extra node running separate software to receive data from a RFID transmitting jeenode with some homegrown software.
A last jeenode acts as a transmitter (again running the jeelabs standard demo software (!) to send data to a number of LCD screen equipped Jeenodes around the house, plus a number of jeenodes with attached relays for control of various devices.
All this is controlled by distributed software running on a couple of old Mac Minis – mainly homegrown software written in Ruby (and Ruby on Rails) to pull all the data together.
– Posted using BlogPress from my iPad