xapmcsRF - W800 / RFXCOM xAP Node

[Michael McSharry]

Turns out the first byte that counts the variable count is not included in the count of bytes. Give 1.4.4 a try. I did not explicitly address the new error message, but the others should be taken care of and the new one might as well.

[bdickhaus]

The other errors are gone, but this one remains:

mcs.W800.MUAD-DIB 2006-12-25 08:28:41 | xapmcsW800 | OregonScientific_Temperature Line 170 Invalid procedure call or argument

But only after it ran for about 4 minutes. Still no debug output. And the temperature information apparently is not being recognized. I am getting the RF X10 motion sensors, and each time I run it I get one new device recognized, but it doesn't continue to update. I don't know if this will help or not:


08:24:47 |
08:24:48 | A0, 60, 90, 1B, AA | Discarding 00
08:24:48 | A0, 60, 90, 1B, AA | Discarding 00
08:24:48 | A0, 60
08:24:48 | 90, 1B, AA | Discarding 00
08:24:48 | A0, 62, 92, 3E, 47 | Discarding 00
08:24:48 | A0, 62, 92, 3E
08:24:48 | 47 | Discarding 00
08:24:48 | A0, 62, 92, 3E, 47 | Discarding 00
08:24:49 | A0, 61, 91, 1D, A6, A0, 61, 91, 1D, A6, A0, 61, 91, 1D, A6 | Discarding 00 | Discarding 00 | Discarding 00
08:25:01 | A0, 74
08:25:01 | 8B, 20, DF | B9=OFF
08:25:01 | A0, 74, 8B, 20
08:25:01 | DF
08:25:01 | A0, 74, 8B, 20, DF
08:25:01 | A0, 74, 8B, 20, DF
08:25:01 | A0, 74, 8B, 20, DF
08:25:04 | 50
08:25:04 | 0A, 4D, 10, 04, 30, 26, 00, 00
08:25:04 | 21, 00
08:25:04 | 50, 0A, 4D, 10, 04
08:25:04 | 30, 26, 00, 00, 21, 00
08:25:07 | A0, 41, B1, 2C, 6A | Discarding 00
08:25:07 | A0, 41
08:25:07 | B1, 2C, 6A
08:25:11 | 50, 0A, 4D, 10, 0A
08:25:11 | 50, 00, 00, 00, 21, 00
08:25:12 | 50
08:25:12 | 0A, 4D, 10, 0A, 50, 00, 00, 00
08:25:12 | 21, 00
08:25:22 | A0, 74, 8B
08:25:22 | 00, FF | B9=ON
08:25:22 | A0, 74, 8B, 00, FF
08:25:22 | A0, 74, 8B, 00, FF
08:25:23 | A0
08:25:23 | 74, 8B, 00, FF
08:25:23 | A0, 74, 8B
08:25:23 | 00, FF
08:25:34 | 50, 0A, 4D, 10, 04
08:25:34 | 30, 26, 00, 00, 21, 00
08:25:34 | 50
08:25:34 | 0A, 4D, 10, 04, 30, 26, 00, 00
08:25:34 | 21, 00
08:25:41 | 50, 0A
08:25:41 | 4D, 10, 0A, 50, 00, 00, 00, 21
08:25:41 | 00
08:25:42 | 50, 0A, 4D, 10, 0A, 50
08:25:42 | 00, 00, 00, 21, 00
08:25:49 | A0, 01, F1, 29
08:25:49 | 03 | Discarding 00
08:25:49 | A0, 01, F1
08:25:49 | 29, 03 | Discarding 00
08:25:49 | A0
08:25:49 | 01, F1, 29, 03 | Discarding 00
08:26:04 | 50, 0A, 4D, 10, 04
08:26:04 | 40, 26, 00, 00, 22, 00
08:26:11 | 50, 0A, 4D, 10, 0A, 50
08:26:11 | 00, 00, 00, 21, 00
08:26:12 | 50, 0A
08:26:12 | 4D, 10, 0A, 50, 00, 00, 00, 21
08:26:12 | 00
08:26:30 | 29, FF, F0, E0, 1F, 96, 00
08:26:33 | A0, 74, 8B, 20
08:26:33 | DF | B9=OFF
08:26:33 | 20, 74
08:26:33 | 8B, 20, DF, A0, 74, 8B, 20
08:26:33 | DF
08:26:33 | A0, 74
08:26:33 | 8B, 20, DF
08:26:34 | 50, 0A, 4D, 10, 04, 40
08:26:34 | 26, 00, 00, 22, 00
08:26:34 | 50, 0A
08:26:34 | 4D, 10, 04, 40, 26, 00, 00
08:26:34 | 22, 00
08:26:41 | 50, 0A, 4D
08:26:41 | 10, 0A, 50, 00, 00, 00, 21, 00
08:26:42 | 50, 0A, 4D, 10, 0A, 50, 00
08:26:42 | 00, 00, 21, 00
08:26:55 | A0, 01, F1, 28, E6 | Discarding 00
08:26:55 | A0, 01, F1, 28, E6, A0, 01, F1, 28, E6 | Discarding 00 | Discarding 00
08:27:04 | 50, 0A
08:27:04 | 4D, 10, 04, 40, 26, 00, 00, 22
08:27:04 | 00
08:27:04 | 50, 0A, 4D, 10, 04, 40
08:27:04 | 26, 00, 00, 22, 00
08:27:11 | 50, 0A, 4D, 10, 0A, 50, 00, 00
08:27:11 | 00, 21, 00
08:27:12 | 50, 0A, 4D, 10
08:27:12 | 0A, 50, 00, 00, 00, 21, 00
08:27:31 | A0, 74, 8B, 00, FF | B9=ON
08:27:31 | A0, 74, 8B, 00, FF
08:27:32 | A0
08:27:32 | 74, 8B, 00, FF
08:27:32 | A0, 74, 8B
08:27:32 | 00, FF
08:27:33 | A0, 50, AF, 00, FF | D1=ON
08:27:33 | A0, 50, AF, 00, FF
08:27:33 | A0, 50, AF, 00, FF
08:27:34 | A0, 50
08:27:34 | AF, 00, FF
08:27:34 | A0, 50, AF
08:27:34 | 00, FF
08:27:34 | 50, 0A, 4D, 10, 04, 40
08:27:34 | 26, 00, 00, 22, 00
08:27:34 | 50, 0A
08:27:34 | 4D, 10, 04, 40, 26, 00, 00, 22
08:27:34 | 00
08:27:41 | 50, 0A, 4D, 10
08:27:41 | 0A, 50, 00, 00, 00, 21, 00
08:27:42 | 50, 0A, 4D, 10, 0A, 50, 00, 00
08:27:42 | 00, 21, 00
08:28:04 | 50, 0A, 4D
08:28:04 | 10, 04, 40, 26, 00, 00, 22
08:28:04 | 00
08:28:04 | 50, 0A, 4D, 10, 04, 40
08:28:04 | 26, 00, 00, 22, 00
08:28:11 | 50
08:28:11 | 0A, 4D, 10, 0A, 50, 00, 00, 00
08:28:11 | 21, 00
08:28:12 | 50, 0A, 4D, 10, 0A
08:28:12 | 50, 00, 00, 00, 21, 00
08:28:15 | A0, 40, B0, 18, 61 | Discarding 00
08:28:15 | A0, 40, B0, 18, 61 | Discarding 00

[Michael McSharry]

I simulated your data stream and some of the data I do not recognize. For example the first item is a 32 bit sensor, but the last two bytes are not complements of each other. Do you know what type of sensor this is?

A0, 60, 90, 1B, AA

This occurs for other sensors downstream in the capture as well.

I did add a debug checkbox on the setup so data will go to the text file. I also added more decode info into the IO window and debug.

The Location field needs to be filled-in before xAP messages are produced. This is similar to the "A"ccept of many of my other xAP apps.

For X10 you can have the data delivered in x10 schema or BSC schema per checkboxes on the setup. The one you want is depending upon how the data is going to be used. I suspect for a Homeseer-oriented use the X10 mode will be used.

V1.4.5 has been posted.

[bdickhaus]

[bdickhaus]

I added a location to see what I would see on the xAP side of things. So far it looks like the three OS temperature sensors are being recognized as only one sensor, on the xAP side I can see the various temperatures cycle through, but all from the same source. In the browser window for xapmcsRF, only one temperature sensor is listed.

The rain gauge appears to be recognized, but not any of the RFXSensors, only the OS sensors. Debug is being generated (lots of it!). One thing I noticed is that negative temperatures are being reported as positive (one of the OS sensors is monitoring a freezer).

UPDATE: The negative temperature is OK when accepted into HS through mcsxAP, but the three sensors are still being reported all under the same ID. It is about to rain here, hard, so I should see some rain gauge information coming through as I also defined it to HS.

Also getting this error now and then:

mcs.W800.MUAD-DIB 2006-12-25 18:02:52 | xapmcsW800 | ProcessCommData 54, 2A, 1D, 00, 86 Line 4080 Overflow
mcs.W800.MUAD-DIB 2006-12-25 18:24:48 | xapmcsW800 | ProcessCommData 2A, 1D, 00, 86, 00, 00, 15, 02 Line 3970 Overflow
mcs.W800.MUAD-DIB 2006-12-25 18:25:39 | xapmcsW800 | ProcessCommData 1C, 21 Line 4080 Overflow
mcs.W800.MUAD-DIB 2006-12-25 18:25:39 | xapmcsW800 | ProcessCommData 92, 3E, 65 Line 4080 Overflow
mcs.W800.MUAD-DIB 2006-12-25 18:25:39 | xapmcsW800 | ProcessCommData 3E, 65 Line 4080 Overflow

Nevermind on the negative values, I just need new glasses... it is there in the hub view as well.

Bill

[Michael McSharry]

There must be some moding that needs to be considered for the RFXCOM receiver. I had coded to the RFXSensors per the X10-compatible spec. I see there is another spec for the RFXSensor that does not impose a pattern for the 3rd and 4th byte. Are there two encoding modes (x10-compatible and RFXSensor) and two receiver modes (32 bit - variable) or is your setup a single setting where all 32 bit goes into x10-compatible?

This spec shows delivery of data for the DS2438 registers, but no identification of how the DS2438 is applied. How do you know if you have it hooked up as a barometer or humidity sensor? Should I rely upon the user input in xapmcsRF to identify the type of sensor?

It looks like I need to include the address bits to make the sensors unique. I had thought it would be the channel that distinguished each.

I had decoded the negative bit. I'll need to look to make certain I masked off the correct bit.

[bdickhaus]

Sorry, the negative value was my mistake, it works.

The OS sensors can have a unique address in addition to channel, this is not obvious from the OS documentation. It is a challenge to get them unique, as they just cycle through values after a reset (or battery change). So ongoing it might be even more of a challenge, but so far I have three sensors on one channel with different addresses.

The other questions maybe Bert can answer. I am capturing the RFXSensor data today with the ACRF plug-in and I am sure it is using the 32 bit compatibility mode also, and I now understand why it is not an easy thing for Jon to add the OS support to ACRF. I appreciate the work you are putting into this, as it doesn't seem like many others besides me are even interested.

Bill

[Michael McSharry]

I did take care of adding the address to make each sensor unique. After reading the RFXSensor.pdf again I do not understand how to recognize one DS2438 register vs. another in the data stream.

I see an init sequence on poweron where a sensor reports its configuration and this might be usable to identify a DS18B20 vs. DS2438 and to associate an index with a serial number. I dont understand how this init packet relates to the 2 id bytes when a sensor later reports its readings.

The question on moding still exists.

I'm going to wait until Bert chimes in because I'm not clear on how this RFXSensor.pdf should be interpreted and how I know when this spec should be used vs when the x10-compatible one should be used.

[bdickhaus]

The ACRF plug-in requires that you specify what kind of sensor it is. Although the RFReceiver program seems to do an OK job of figuring things out, it seems to not know exactly what something is either.

For example:

A021D12426 RFXSensor addr:21D1/8657 RH:67.23% Barometer:746hPa Voltage:2.89 bits=32 from SLAVE

I don't have any barometer sensors installed at this point (if I did it would either be broken or I would be in serious trouble!) This is a humidity sensor.

Bill

[Michael McSharry]

As a humidity sensor, the DS2438 can provide reading for humidity and temperature. Do you get both from the RFXCOM humidity sensor or do you get both?

When I implemented it in x10-compatible mode I assumed only a humidity reading was being sent and the only temperature transmision was from a DS1820. The X10-compatible mode does not have support shown for the barometer. The barometer needs multiple registers of data from the DS2438 to make the calculation.

[piperpilot]

Michael, I am going away for vacation for a couple days, but when I get back, I would be willing to try this out as well and see if i cant help work out the kinks. I have the Oregon Receiver and quite a few different sensors.

This would be my first xAP installation though...so it is going to take me a little time to read through the How-Tos and figure out how to get it all set up.

I am currently running a version of the RFXCom receiver program that I modified to be a HS plugin, so I should be able to help you figure out how to distinquish the different device types, etc. Although, Im sure that Bert will chime in before I even get back from Vacation.

Regards,
PiperPilot

[bdickhaus]

As a humidity sensor, the DS2438 can provide reading for humidity and temperature. Do you get both from the RFXCOM humidity sensor or do you get both?

When I implemented it in x10-compatible mode I assumed only a humidity reading was being sent and the only temperature transmission was from a DS1820. The X10-compatible mode does not have support shown for the barometer. The barometer needs multiple registers of data from the DS2438 to make the calculation.

This is another one for Bert. Up until recently I was using only the ACRF plug-in with two W800's. It just works, I never looked under the hood to see how. And like I said, I don't have a barometer installed (it is sitting here looking at me now, but it has no wires connected to it....) I do have separate devices defined to ACRF for temperature and humidity.

Bill

[b_weijenberg]

RFXSensor

The type of sensor is partly defined by the address.
xxxx xx00 = temperature sensor DS18B20 or DS2438
xxxx xx01 = A/D sensor of the DS2438.
xxxx xx10 = supply voltage to the DS2438.

For example:
When received: A061911E0F
A0 = MSB is on so the message is received from the slave receiver and message length is hex 20 = decimal 32 bits
61= the 1st address byte is hex 61 = binary 0110 0001 so this must be the A/D sensor of a DS2438.
91 = is the same as the 1st address byte with the upper nibble in complement.
1E0F = the voltage measured by the A/D sensor + flag bit + 4 bits parity. The voltage is binary 0001 1110 000 = hex 0F0 = 2400mV = 2.4V
In the software you can detect the RFXSensor if the upper nibble of the 2nd address byte is the half complement (an X10 security sensor has the lower nibble in complement) AND the parity must be correct.
See also chapter 10 in the RFXSensor document at http://www.rfxcom.com/documents/RFXSensor.pdf

A/D sensor:
The type of sensor must be configured in the plug-in by the user. There is no way to find out the type of sensor connected to the A/D input.
A humidity (HIH4000) or barometric sensor (MPXA4115) can be connected to the A/D sensor or any user selected device with a DC output voltage from 0 to 10Volt. For this user selected device the device type RAW can be configured in the ACRF plug-in.

Supply voltage:
The supply voltage sensor data is send before the A/D sensor data but it is not send always!
The supply voltage data is only send after a reset of the RFXSensor and then with every heart-beat signal that is send every 40 or 80 minutes, depending on the sample rate selected by the user in the RFXSensor device.
The supply voltage is necessary to calculate the humidity or barometric pressure values.
The calculation of the RH = ((A/D voltage / supply voltage) - 0.16) / 0.0062
The calculation of the barometric pressure hPa = ((A/D voltage / supply voltage) + 0.095) / 0.0009
When the supply voltage is received it must be kept in a variable in the plug-in so that the calculation of the humidity and barometric pressure can be done. After a restart of Homeseer the supply voltage is not available yet and it can take up to 80 minutes before the supply voltage data becomes available. In that case the supply voltage variable in the plug-in can be initialized to 4.7 volts which the most common value. Another option is to set the humidity or barometric value to unknown until the voltage sensor data is received.
With the heart-beat signal the sensor data is transmitted in this order:
For a DS2438 1-wire sensor:
xxxx xx00 = temperature sensor DS2438
xxxx xx10 = supply voltage to the DS2438.
xxxx xx01 = A/D sensor of the DS2438.

For a DS18B20 1-wire sensor:
xxxx xx00 = temperature sensor only



Bert

[Michael McSharry]

I believe I have them all decoded based upon Berts input. I've attached a sampling of some of the test data output. The update is posted as V1.4.6

xap-header
{
v=12
hop=1
uid=FF00521B
class=xapbsc.event
source=mcs.W800.MCS5:Room1.RFXCOM______20D0.Temperature
}
input.state.1
{
state=ON
text=82.4
}

xap-header
{
v=12
hop=1
uid=FF005222
class=xapbsc.info
source=mcs.W800.MCS5:OS_RainRate.RFXCOM2A1D_286_E.RainRate
}
input.state.1
{
state=ON
text=0
}


xap-header
{
v=12
hop=1
uid=FF005223
class=xapbsc.info
source=mcs.W800.MCS5:OS_Rainfall.RFXCOM2A1D_286_R.RainToday
}
input.state.1
{
state=ON
text=1
}

xap-header
{
v=12
hop=1
uid=FF005225
class=xapbsc.info
source=mcs.W800.MCS5:OS_BatteryLevel.RFXCOM2A1D_286_L.Index
}
input.state.1
{
state=ON
text=100
}

xap-header
{
v=12
hop=1
uid=FF00521C
class=xapbsc.info
source=mcs.W800.MCS5:OS_Humidity.RFXCOM____6191_H.Humidity
}
input.state.1
{
state=ON
text=57
}

xap-header
{
v=12
hop=1
uid=FF00521D
class=xapbsc.info
source=mcs.W800.MCS5:OS_Baro.RFXCOM____6191_B.Barometer
}
input.state.1
{
state=ON
text=19.87
}

[bdickhaus]

Working good so far, however it apparently is not creating devices for RFXSensors, X10 and OS appear to be working OK. Also, it is flooding my HS system with xAP messages even when the data doesn't change. The OS sensors are very chatty, is there any way to throttle things down? I had the same issue with 1wire until I set the polling to something like 60 seconds.

Bill