Untidy RFXCOM events

[khun]

Hi again!

I am now controlling the heating with RFXCOM sensors and thermal actuators on radiators through a phidget board. Thanks to the forum so far!

But I don't quite like that the RFXCOM sensors seem to send a lot of rubbish! I have several "433.92MHz RFXSensor Type-3 with temperature sensor", some with external temperature sensors (DS2438) attached. Even without any external sensors, Girder seems to receive not only the temperature readings, but also 2 more messages from 2 "sensors" one and two unit numbers higher. The first sends some values I can't really interpret, which sometimes jump from like 0.5 to 3.5 within seconds and sends quite often. The one 2 numbers higher sends values like 62.5 once in a while.

Sometimes I also get an "Error or info: Unspecified error". Also rather annoying...

Can anyone explain what this is? Am I setting things right in the RFXCOM settings, when I expect the "Type" settings there to be the same "type" as in the web page?

And: can anyone explain how to open this boxes without destroying them? For some reason, you have to open them if you want to change the accuracy of the temperature readings.

Thank you!

[Rob H]

Those two other 'sensors' are actually the "potmeter middle position" and the supply voltage. See http://www.rfxcom.com/documents/RFXSensor.pdf

As for opening them you should find that there is a screw (or possibly several) hidden under the label.

[khun]

Thanks, Rob!

I was expecting something like that, but I was wondering why the values seemed so strange. I have been deciphering how the data are read in the W800RF32.lua script and realized that there is nothing there to read anything other than temperature data in 0.5 degree format and that the pdf file you mention lists some more error codes than the script includes. I will try to change some of the code to accomodate interpretation of the other values as well. Unfortunately, that means you _have_ to set a proper type for all sensors, I think.

If anyone has any more elaborate code for handling RFXCOM sensors, please let me know, otherwise I will be working on this within some days.

About the screws, I didn't think of removing the label, thanks for the tip!

[Promixis]

The G5 implementation is more comprehensive. The addition of RFXCOM sensors in the G4 implementation was an after thought :(

[khun]

Thanks, and I was sticking to G4 because I got the impression RFXCOM didn't work in G5 :-)

I'll try the switch this weekend!

[b_weijenberg]

Khun,

To select the low sampling rate you have to cut the red wire in the battery compartment. (not the battery wire)
Chapter 6. in the RFXSensor document has been updated.

6.1. Fast sampling rate. (default) (Battery consuming!!!!!)
To select the fast sampling rate pin 8 must be connected to pin 14. By default those pins are connected by a red wire. This red wire is accessible in the battery compartment.
This mode is battery consuming but gives a high accuracy.
This results in a fast sampling rate of 1 minute. An RF packet is transmitted if a temperature change of 0.5 degrees Celsius is detected.
Every 40 minutes an alive RF packet will be transmitted.

6.2. Low sampling rate.
To select the low sampling rate remove the connection between pin 8 and pin14 by cutting the red wire (not the battery red wire) in the battery compartment. After cutting the wire the RFXSensor must be reset to set the low sampling rate mode.
This mode is battery saving but less accurate.
This results in a low sampling rate of 5 minutes. An RF packet is transmitted if a temperature change of 1 degree Celsius is detected.
Every 80 minutes an alive RF packet will be transmitted.

Some explanation on the RF packets.
The RFXSensor transmits the temperature packets only if there is 0.5 or 1 degrees difference, depending on the sample rate.
The A/D value is transmitted only when a different value is measured.
The supply voltage is only transmitted with the alive (heart-beat) transmission. This transmission occurs after a reset and every 40 or 80 minutes, depending on the sampling rate.
The supply voltage is necessary to calculate the humidity and barometric sensor values because the supply voltage to those sensors is part of the calculation. After a system restart it can happen that the hum/baro value is received but the supply voltage is not yet known. In that case you can choose to don't do anything with the received hum/baro until the supply voltage is received or you can calculate using a supply voltage of 4.8 which is a normal average supply voltage.

And don't tell me the RFXSensor is transmitting rubbish :-(

Bert

[khun]

I did write _seem_ to send rubbish :-)

After looking through the implementation in Girder 4, I realize that it is somewhat lacking. When I have got Girder 5 up and running (hopefully within a few days), I will get back to the matter.

The good news is: the temperature in my house is already much more stable than when we were adjusting every radiator manually!

[khun]

While I was writing the last message, I suddenly realized something. I have now checked this and improved the W800RF32.lua script somewhat to improve the reading (couldn't wait to get G5). It was actually not only incomplete, but even incorrect!

It had:


if serial.bextract(serial.hextodecimal(Byte4), 8, 8) then
Temperature = Temperature + 0.5;
end;

which is erroneous, since bextract returns either 0 or 1, and both of these are "true", which explains why I only got values ending in .5!

And since the default now is fast sampling, I should be getting 0.125 steps, not jumps from 19.5 to 20.5.

I now have:


Temperature = serial.hextodecimal(Byte3)+
serial.bextract(serial.hextodecimal(Byte4), 8, 8)*0.5+
serial.bextract(serial.hextodecimal(Byte4), 7, 7)*0.25+
serial.bextract(serial.hextodecimal(Byte4), 6, 6)*0.125;

and get much better accuracy here! Bringing me by far closer to a happy customer!