Oregon RF channel usage

[Mr Spock]

I'm having intermittent problems with some of my sensors and want to get options from some of you.

I have recently installed several of the Oregon Scientific temp sensors around my house. As I get experience with them I am noticing that every now and then some seem to "flat line" or keep the same temp reading even though the temp is changing as shown below. The mcsTemperature software that produced this graph is supposed to set invalid data to 0, so seeing it "flat line" several times raises questions in my mind as to the real reason why.

Since I'm going to close a temp control loop around some of them this could be a fatal problem. My question is regarding the fact that most of these sensors have the option to pick 3 channels. Most of these sensors also seem to transmit twice in succession to improve interference situations.

So how many sensors can you put on a chanel reliably?

Common sense tells me only one, that this is the source of my problems, and therefore I can only use three 433MHz sensors. But I have a need for at least 6 of these sensors, plus eventually adding an RFXcomm RFXmeter for my 3 utilities.

I'm using the following Oregon units:
THGR122NX (4x)
THC138 (hope to replace with a THWR800) (1x)
UVR128 (1x)

In the 6 hour picture below Outside Shade Sensor flatlines 4 to 6 times, with a big one for ~90 minutes. The pool sensor was on the same channel (#2) but had no problems at all. I've seen the situation reverse in the past.

[huggy_d1]

I know this isn't ideal, but you could put two sensors in place to sense each critical function in your closed-loop control scheme. In this way, you can see which one is changing, and ignore the flat-line one until such time as it's 'back online' again.

Several others have reported similar findings as these things randomly sync up, essentially skipping the readings on one of the sensors, but it sounded like pseudo-science until I saw your graphs.

Perhaps if you decide to do a redundant sensor system, you could do something where you create a virtual temperature device that gets updated via a script driven by device status / value / string (whichever is best) change on either of the sensors, then script to compare the difference in the two, and the last time the value changed on the one that didn't get the status/value/string change. In this way, you can detect a flat-lined device, and update the virtual temp value with the one that's actually changing.

I'd put them on different channels so they don't both go offline at when they sync up their update cycles.

If you find a solution, please post here.

[b_weijenberg]

Using multiple Oregon sensors:

Communication Failures will sometimes arise if you have 2 or more Oregon sensors of the same type and with the same channel selected. One or two sensors are sometimes not received for a period of a few hours. The reason is that they transmit during that period on the same moment. The interval time differs a very little bit for each sensor and the transmit period shifts slowly and at a certain time both sensors transmit on a different time again and are received again.

The solution is to select another channel on each sensor of the same type or use different sensor types.
Note: TEMP1, TEMP2 are different types but THR128 and THC138 are the same types as they are both TEMP1 sensors!
The THGR810 is a 10 channel sensor and you can use 10 of these sensors without having the Communication Failure due to sensor transmission overlap. An out of range is then the most expected problem. Don't install the sensors near metal objects because this can limit the range too.

It can still happen that sensors transmit at the same time when having different sensor types or different channels selected but not for a long period and Communication Failures will not appear due to this.

The link to supported Oregon sensors is on this page: http://www.rfxcom.com/hsrfxcom.htm

[Mr Spock]

Hi Bert, thanks for posting.

A follow on question for you. I do not get any communication failure for the sensors when they flatline. The temperature (device string) just reports the same. Is this then still due to 2 sensors of the same type and channel or something else?

[sooty]

If you are using the RFXCOM plug-in, then the device string will not be updated until the communication failure timeout has elapsed. I think the timeout is 60 minutes for these sensors.

So, if 2 sensors are colliding, the devicevalue and devicestring will remain at the last known value until the timeout has elapsed.

Once the timeout has elapsed, the devicestring will be updated with "Communication Failure" but the devicevalue will remain unchanged.

If you are using a script or similar to record the values to a file or database and the value is obtained from the devicevalue, then the last know value will be recorded to the database or file, hence the flatline.

Edit:
How many samples are you taking per hour?
Looking at your chart, it seems like quite a lot. If you are taking samples every 1 minute or so, then you will get 60 chart points before a comm fail is detected.

Paul..

[Mr Spock]

Sooty

I'm using the ACRF2 plug-in. It has no timeout function like you mentioned for the RFXCom plug-in. However what you describe may be occurring with the ACRF2 as well.

Thanks.

[mwaite]

I have four temp sensors on three channels. The ones that share Channel 1 do not seem to be a problem for me. My only occasional problem is loss of communication due to out of range. I have never seen the flatline problem on the shared channel.

[langenet]

Ok... I'm looking at getting into this areana and am a bit confused about the sensors. I do have the ACRF2 plugin and thought I'd get the RFXCOM receiver/plugin for the temp/humidity sensors. However, according to the ACRF2 doc, many are supported and all I want to do for now is monitor temperature/humidity.

In looking at http://www.ambientweather.com/adse.html site, I see low cost sensors and thought why not? I'd probably be growing at most to 5 or so sensors. In many of my needs, I don't care for an on device LCD and see a couple of low cost THN132N ones. But what is the deference between the THN132N and the THN132N OSI WIRELESS REMOTE TEMP SENSOR-THN132N?
What does OSI mean? THe later is a bit cheaper yet...

Can someone list what sensors they are pleased with and using with high success and without issues so I can determine my path with this?
Another issue is the channel issue. I know more channels is better, but can I do without buying 10 channel devices if the sensors are the same type?


Thanks

Robert