Announcement

Collapse
No announcement yet.

xapmcsRF - W800 / RFXCOM xAP Node

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

    You have it set up correctly. The rain gauge does not reset. The Oregon receivers do that, but with HomeSeer you will need to do it yourself. You will need to create a couple of events and scripts. I have the scripts if you are interested. I switched over to using ACRF2 but I am going to switch back to xapmcsrf for the rain gauge.

    The Oregon rain gauge has a little lever that flips back and forth based on rain flow through the unit. This is the actual count, for some 1wire and other sensors, this is the only data available. With the Oregon rain gauge, it is interesting, but I can't think of anything to use it for, since the rain gauge computes and transmits rain rate and rain total.

    Bill

    Comment


      Thanks Bill. That explains things. I certainly would appreciate seeing your scripts. It would save some time and work.

      Henry

      Comment


        location not defined for sensor

        hello, sorry for my english

        I have xapmvsRF
        It is working fine except that I have to intervene manually when starting the program.

        I have to go on the icon, then browser then "Save changes" (without any change).

        If I have this error message:
        09:35:15 | 5E, 51, 04, FB | 5E51=ON | Security 5E5104FB Ignored because location not defined for sensor

        Any idea on what I have done wrong?

        Another issue, there happens a tutorial newer than the "march 20, 2006?

        Thank you very much

        Lionel, french

        Comment


          The manual has a file date of 7/30/2006 and the document body shows March 20, 2006. If this the the one you have then it is the latest I have produced. It is part of the download at http://mcsSprinklers.com/xapmcsRF.zip.

          The message about the security sensor is not unusual. There are many decoding options available and sometimes RF data is not 100% correct so the software tries to decode it as a device that your really do not have. If it persists then you should use the RF receiver program from RFXCOM and see if it decodes it differently and if so post the data on the board so xapmcsRF can be updated.

          I have no immediate ideas about the startup. I would suggest enabling the debug checkbox and restarting. The debug data will go into a file in the \Data subfolder. You can post the startup data to see if anything shows up there. You should also look for xAP messages that use the Homeseer.Event schema class as this will be messages that could provide a hint.

          Comment


            column send

            Hello

            Can you tell me what the column "Send"?
            Thank you

            Comment


              It allows you to generate a xap-x10.request messages to the House/Unit code that you enter into the text box. The message will be sent whenever the RF receives a sensor ON/OFF. For example, if you have a motion sensor at A1 and you want to turn a light on at B5 whenever the A1 ON is received (and off when A1 OFF is received) then put B5 in the Send column box.

              Comment


                Hello Michael,

                I have some trouble with the "Inv" function on the latest version. When I restart the application, it seems not remember the Inv option on all my switch devices (DS10 and MS10).

                Comment


                  Oregon THGR328N

                  Hello Michael,

                  I bought a probe THGR328N Oregon and a probe THGR228N.

                  The 228 works very well but the 328 seems to have worries in XapMcsRf.

                  Rfxcom 433 works well.

                  RFreceiver is OK :
                  50CA2C13C67822604653E0 TH4[50689] THGR328 CH 1 counter:12 addr:C6 temp:22.7°C | 72.86°F hum:66 Comfort bits=80


                  Windows I/O XapMcsRf :
                  13:26:44 | 50, CA, 2C
                  13:26:44 | 23, DC, 48, 24, 00, 46, 54, C7 | Discarding 50 after seeing invalid ID for 80 byte packet | Discarding CA while trying to sync on byte-count byte | 23DC = 36 | Digimax 54C7 Ignored because location not defined for sensor

                  Concern in the encoding of id ??

                  I asked RFXCOM send me the document : "Oregon Scientific RF format - rev 11.3"
                  Page 14 : TH4 - THGR328N Outside Temp-Hygro

                  Have you this document ?
                  or give me your mail.

                  Can you help me ?
                  Last edited by ; June 3, 2008, 09:46 AM.

                  Comment


                    I have version 8.5 or the OS RF Format from Bert which shows the following
                    Model: Oregon-THGR328N
                    Sensor id 0x????

                    Based upon your data for sensor ID I added it and uploaded V1.8.1

                    Comment


                      version 1.8.1 de XapMcsRF
                      Oregon-THGR328N work

                      Thank

                      Comment


                        Hello Michael,
                        I bought a probe RTGR328N Oregon ,
                        it seems to have some trouble in XapMcsRf.

                        19:45:34 | 30, 24, 20, 46, 4C, 5F | Discarding 50 after seeing invalid ID for 80 byte packet | Discarding BA while trying to sync on byte-count byte | Discarding CC while trying to sync on byte-count byte | Discarding 43 while trying to sync on byte-count byte | Discarding 67 while trying to sync on byte-count byte | Discarding 30 while trying to sync on byte-count byte | Discarding 24 while trying to sync on byte-count byte
                        19:45:34 | 50, BA, CC, 43, 67 | Discarding 46 because byte 3 & 4 are not complements | Discarding 46 while trying to sync on byte-count byte | Discarding 4C while trying to sync on byte-count byte | Discarding 5F while trying to sync on byte-count byte
                        19:45:34 | 30, 24, 20, 46, 4C, 5F | Discarding 50 after seeing invalid ID for 80 byte packet | Discarding BA while trying to sync on byte-count byte | Discarding CC while trying to sync on byte-count byte | Discarding 43 while trying to sync on byte-count byte | Discarding 67 while trying to sync on byte-count byte | Discarding 30 while trying to sync on byte-count byte | Discarding 24 while trying to sync on byte-count byte

                        maybe this probe are not already implemented in Xapmcsrf because it have date and time ?
                        Can you help with this new probe ?

                        Thanks

                        Comment


                          This one is an oddball with only a 12 bit ID and a variable packet size. I made the changes in V1.10.0 at http://mcsSprinklers.com/xapmcsRF.zip. Please confirm it works as expected.

                          Comment


                            Hello michael,
                            The probe is now recognized but works strangly.

                            Probe report only Temp , Humidity , and Battery status , no time , no mode (comfort,wet,dry)

                            for sure this is not critical , the most important is temp and humidity of course
                            the second strange thing is that:



                            each time it detect the probe 5 times with 5 different ID ??
                            same for humidity and battery but all have the same value.

                            This probe has a large advantage compared to the others Oregon i have, it less frequently "speaks" (1 time each 60 second) What limits the collisions when have a lot of probe.

                            Anyway thanks for this update Michael.

                            Comment


                              Hello michael,
                              The probe is now recognized but works strangly.

                              Probe report only Temp , Humidity , and Battery status , no time , no mode (comfort,wet,dry)

                              for sure this is not critical , the most important is temp and humidity of course
                              the second strange thing is that:



                              each time it detect the probe 5 times with 5 different ID ??
                              same for humidity and battery but all have the same value.

                              This probe has a large advantage compared to the others Oregon i have, it less frequently "speaks" (1 time each 60 second) What limits the collisions when have a lot of probe.

                              Anyway thanks for this update Michael.

                              Comment


                                Hello michael,
                                The probe is now recognized but works strangly.
                                Probe report only Temp , Humidity , and Battery status , no time , no mode (comfort,wet,dry)
                                for sure this is not critical , the most important is temp and humidity of course
                                the second strange thing is that:


                                each time it detect the probe 5 times with 5 different ID ??
                                same for humidity and battery but all have the same value.
                                This probe has a large advantage compared to the others Oregon i have, it less frequently "speaks" (1 time each 60 second) What limits the collisions when have a lot of probe.
                                Anyway thanks for this update Michael.

                                Comment

                                Working...
                                X