Announcement

Collapse
No announcement yet.

xapmcsRF - W800 / RFXCOM xAP Node

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    The table attached is from Bert's X10-mode for the Visonic devices in 32 bit mode. An xAP message where the code is FEDDKF will be a reception of an RF signal from the keyfob column. These will be 02,, 82, 42, 26, and 0E. The FEDDS0 will be fromt he Sensors Bit7-Off column. The FEDDS1 will be from the Sensors Bit7-On column.

    This was my guess as how the Visonic system is setup. If I'm wrong then suggest a more useful organization based upon the what is available in the table

    Code:
    Sensor (xxxxS0 or xxxxS1)
       State (on/off)
       BatteryLow (on)
       Tamper (on)
    Keyfob (xxxxKF)
       ArmAway (on)
       Disarm (on)
       LightsOn (on)
       Panic (on)
       ArmHome (on)
    Attached Files

    Comment


    • #17
      Hello Michael,

      Thanks for the explanation, it's a lot clearer now.

      Here are some notes from my testing, they may be useful for other users:

      On initial setup each sensor will have 3 device codes in the browser no matter what sensor type it is, so for example a PIR will have:

      32E9KF
      32E9S0
      32E9S1

      For future sensor status / activity, only one device code will "contain" the status message. The device code will depend on the sensor type:

      ....KF = for keyfobs
      ....S0 = for sensors that don't report "restore"
      ....S1 = for sensors that report "restore"

      Sensors that report "restore" are those such as magnetic contacts where they will send an "alert" when opened and a "normal" when closed.

      Sensors that don't report "restore" are those that only send an "alert" - from my testing so far these are PIRs.

      So for the above PIR code of 32E9, future status / activity will be on the 32E9S0 and 32E9S1 & 32E9KF can be ignored.


      Hope this helps!

      Martyn

      Comment


      • #18
        KeyFobs

        KeyFob events appear ok in the browser but generate the following xap messages:


        Code:
         xap-header 
         
        {
         
        v=12
         
        hop=1
         
        uid=FF005200
         
        class=Homeseer.Event
         
        source=mcs.W800.AHSHA
         
        }
         
        Event.Log
         
        {
        time=02/09/2006 11:24:01
         
        type=xapmcsW800
         
        data=xapName Line 20 Object variable or With block variable not set
         
        }
        Code:
         xap-header 
         
        {
         
        v=12
         
        hop=1
         
        uid=FF005200
         
        class=Homeseer.Event
         
        source=mcs.W800.AHSHA
         
        }
         
        Event.Log
         
        {
         
        time=02/09/2006 11:24:01
         
        type=xapmcsW800
         
        data=ProcessCommData Line 2150 Object variable or With block variable not set
         
        }

        Comment


        • #19
          Give the new posting at the top of this thread a try to eliminate the error messages and get event data sent

          Comment


          • #20
            Originally posted by Michael McSharry
            Give the new posting at the top of this thread a try to eliminate the error messages and get event data sent
            Thanks Michael, no error messages now, but no xAP messages either! Other sensors are ok, it's just the keyfobs.

            The IO window and browser are both updating fine though.

            Martyn

            Comment


            • #21
              Next try with V1.3.5. When I was testing with dummy data I did only the switches so that is why the keyfob problems did not show up during that testing. Also make certain that the Location field on the browser page has a value for the keyfob otherwise no message will be produced. You should of had an invalid xAP message with V1.3.4 for the keyfob.

              I'll be leaving for the Holiday so if this update does not work then it will be next week when we can make the next attempt.

              Comment


              • #22
                Thanks again Michael, keyfob xap messages are now present.

                Have a great holiday!

                Martyn

                Comment


                • #23
                  Oregon Scientific sensors and RFXCom

                  Michael,

                  Do you have any plans to add support for the Oregon Scientific sensors? I've asked Jon the same question about ACRF. I picked up the RFXCom receiver that can receive the Oregon sensors, and it works fine, but I need something on the HomeSeer end to process the information.

                  Thanks,
                  Bill

                  Comment


                  • #24
                    If you point me to the RFXCOM info then I should be able to do it. The last time I looked I had everything from Bert's site supported.

                    Comment


                    • #25
                      Maybe it is already supported, this is from the Oregon Scientific docs that came with the receiver:

                      In 32 bits modes the RF data from the sensor is translated to the RFXSensor format.

                      I think the issue with the ACRF plug-in is that it is not using the 32 bit mode of the interface. If you are, then it is taken care of already.

                      The document isn't on Bert's website, not sure why.

                      Bill

                      Comment


                      • #26
                        In 32 bits mode: The position where the temperature field is in the Oregon sensor packets is translated to the RFXSensor temperature sensor format. The other Oregon data is not translated.
                        In variable length mode all Oregon packets are transmitted to the PC.

                        The RFXCOM documentation about the Oregon protocol in not yet for general distribution or publication. I've send Michael an email so I think that the Oregon sensors are supported soon ;-)

                        Bill, if you have Oregon sensors that are not on the list in the documentation I would like to receive a trace of the packets with the values displayed at the Oregon main unit for each packet. This enables me to add those sensors as known to the list.

                        Bert

                        Comment


                        • #27
                          Bert,

                          So far I only have temperature sensors, which is why in the "RFX" 32 bit mode I thought they might work. I tried to put xapmcsRF into 48 bit mode but the change didn't "stick", so I am assuming it is running in 32 bit W800 compatibility mode. I understand about the documentation.

                          I have the THR138 (that came with an OS clock/weather station) and THC138 (apparently the same as THR138 but with a remote waterproof probe) that I use to monitor refrigerator temperature. I think you can safely add THC138 to your list. RFReceiver seems to be able to decode the data.

                          I am contemplating a rain gauge. I don't need temp/humidty/baro because I am using RFX sensors for that.

                          Bill

                          Comment


                          • #28
                            Bill,
                            What mode do you want the RFXCOM receiver to operate? If all you have is Temperature then why no just use it in 32 bit mode and you should get the desired output?

                            If fixed the setup for 48 bit mode with V1.3.15. I do not have either the RFXCOM or OS hardware so supporting it depends upon a user with this configuration. I'll work with you for either 32 or 48 bit mode if you want to go through the debug process. I dont recall what I now have for debug output, but a segment of the IO window when the RFXCOM output shows the OS sensor transmission and the debug log would be a good place to start. The 32 bit mode should already be supported. For the 48 bit mode I'll need to get and look at the documents from Bert.

                            Comment


                            • #29
                              Michael,
                              In whatever mode you are putting the receiver in, it isn't sending the temperature data at all. All I see are the X10 RF (motion sensor) values. Nothing shows up in the mcsxapRF I/O monitor for the temperature. When I then open RFReceiver it doesn't understand the data either. I have to set the receiver mode to either 32 bits, X10 32 bits or variable, then it starts working again.

                              Bill

                              Comment


                              • #30
                                Bill,

                                First the receiver must be set to a mode when using the RFreceiver program. This to be sure that the RFreceiver program and the receiver are in the same mode. If the receiver is set to a mode it will stay in that mode even if the receiver is powered down. So when you set the receiver to 32 bits mode (not 32 bit X10 mode!!!) using the RFreceiver program the receiver is in the W800 compatible mode and if you connect the receiver to an application that talks to a W800 the RFXCOM receiver will operate correctly.

                                The application can also initialize the receiver to a mode. This is for example done by the ACRF plug-in. If you configure the RFXCOM receiver as a W800 then the ACRF plug-in xmits hex "F029" to the RFXCOM receiver and the receiver responds with hex "29" like a W800 does. The ACRF then knows that the receiver is connected and operational in 32 bits mode. If you configure the RFXCOM receiver as an RFXCOM receiver then the ACRF plug-in xmits hex "F02C" and the receiver responds with hex "2C". The ACRF then knows that the RFXCOM receiver is connected and operational in variable length mode.

                                The software version of an RFXCOM X10/Oregon receiver must be "0C" or up. This can be checked with the RFreceiver program.

                                If the RFXCOM receiver is set into variable length mode and the xap plug-in expects a 32 bits receiver it will not run. Put the RFXCOM receiver in 32 bit mode (again not in 32 bit X10 mode) and the xap plug-in will operate with the RFXCOM receiver.

                                Bert

                                Edited: sw version must be "0C" and up
                                Last edited by b_weijenberg; December 20th, 2006, 09:39 PM.

                                Comment

                                Working...
                                X