Announcement

Collapse
No announcement yet.

Quasar 3145

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Quasar 3145

    Hi,

    When using mcsTemperature the Quasar readings doesn't work ok, because it fails to display the values, and I have only 2 DS1820 connected to it and sensor 0 and 1 sometimes (only some times) show values completely wrong.

    Please verify it.

    mcsTemperature v4.38.8

    Rui Caridade.

    #2
    You need to move your sensors from 0/1 to 3/4 to work with mcsTemperature. It was a design decision made with the first person that asked for the K3145 support.
    Last edited by Michael McSharry; October 24, 2005, 12:16 PM.

    Comment


      #3
      It's not a solution.

      It have the 4 ports ocupied now and works the same way.

      das3145 works very well with it, and it's free, but I only want to use yours, because I pay for it and have support, the other one I don't know.

      And your have beter conditions for scripts.

      Do you have a manual explaining your mcsTemperatura, because it a bit confusing.

      Rui.

      Comment


        #4
        I do not have a K3145 to evaluate against. What you can do is collect some data with the debug enabled and post a section that shows where the data is not as expected.

        The mcsTemperature manual is in the updater. There is likely not much specific to the K3145, but other than the sensor #4 requirement there is not much to say about its use.
        Last edited by Michael McSharry; October 25, 2005, 11:05 AM.

        Comment


          #5
          I'm currently looking to re-issue das3145 as an HS2 plug-in. Not sure I understand the interaction with mcsTemperature ?

          Are there any changes I can make to make it more useful ?

          " And your have beter conditions for scripts." - In particular ? Not sure what temp specific events are required. das3145 holds the temperature in the device value so I had imagined almost anything is possible with the standard HS events.

          Comment


            #6
            mcsTemperature natively reads sensors from the Quasar K3145 and places the current temperature from each into virtual devices.

            The K3145 is a very simple interface and the mcsTemperature support of it is also basic. The restriction that was imposed on the user of the K3145 is that they have a sensor in posiiton #4.

            A dedicated plugin for the K3145 will also transfer temperature readings into virtual devices but it may allow some configuration options that I did not provide with mcsTemperature. Once its value in in a HS device then all the HS functionality can be applied to it.

            If someone has the K3145 they will be able to use it with HS with mcsTemperature, your plugin, or xapmcsK3145. If the user wants to do charting or want to use the temperature as part of a control loop such as a thermostat function, or has other 1-wire or file inputs to be processed then mcsTemperature provides added functionality. If the additional functionality is not needed then one of the other two will be good options.
            Last edited by Michael McSharry; October 25, 2005, 11:04 AM.

            Comment


              #7
              So does xapmcsdas3145 put an extra wrap around my das3145 plugin - or talk to the the Quasar 3145 natively ?

              Just as an aside I actually do all my charting external to Homeseer - I use some software called Cacti which is a nice php data collector which uses RRD for graphs. I have some custom PHP scripts that query Homeseer for any device value/status and graph it.

              Comment


                #8
                Some more information...

                I have actually seen this as well. I don't have the I/O log in front of me, but that happens is that after a period of time of working (anywhere from several hours to several days), the temperarture stops being reported on the data stream. The stream usually looks something like (for two sensors):
                Code:
                 
                <EPROM Version and Time Date><EEPROM Version and Time Date>{Eeprom Date/Time and Version} C|3 22.435 4 21.435|
                When the problem occurs, the data stream changes to:
                Code:
                <EPROM Version and Time Date>{Eeprom Date/Time and Version} C|<SENSOR Number>3 4<SENSOR Number><SENSOR Number><SENSOR Number><SENSOR Number>
                The "|" used here is actually some other delimiter. I've watched this data stream in Hyperterm, and think there may be a problem with the 3145 board itself as I can see the problem there as well. I can sometimes get it to clear by removing the board from the serial port for a while, but its not consistent. I have it hooked up to an Edgeport/8, but I also tried it on the mobo serial port and it doesn't make any difference. When confronted with this data stream, mcsTemperature displays the temperature as 33.3 in the devices.
                Last edited by BorisB; October 25, 2005, 11:07 AM.

                Comment


                  #9
                  The code implemented in mcsTemperature and the code implemented in xapmcsK3145 talk natively to the hardware. It is not a wrapper around another plugin. I provided no additional setup parameters to identify which sensors are actually mounted on the hardware for simplicity. The software needs to know how to modulate the control line so it assumes a sensor is mounted in position 4 and will use the dellivery of sensor 4 as the control mechanism to stop the data dump.

                  The intended logic for handling bad data is to either set it to 0 or to persist the last valid reading. These options are user configurable. If the setup is to persist then 33.3 could make sense. If not then I don't understand how it could be generated.

                  mcsTemperature provides trigger abilities that will generate a trigger event when a reading goes within a control band or outside a control band. It can have persistence logic so that it needs to be iniside or outside for a certain length of time. The same is true for simple levels such as above 25.6 degrees.

                  mcsTemperature also implements closed loop control such as one might want to emulate a thermostat with a sensor and relay. The control loop is done in the background and does not require a set of HS events and corresponding scripting action. A status device is created to observe the control parameters and turn it off or on.

                  Comment


                    #10
                    Originally posted by Michael McSharry
                    The intended logic for handling bad data is to either set it to 0 or to persist the last valid reading. These options are user configurable. If the setup is to persist then 33.3 could make sense. If not then I don't understand how it could be generated.
                    Okay, here is some Debug Log data. As you can see, I have an upper on/Lower off set of triggers to control a fan thermostaticly.

                    10/25/2005 9:11:27 PM~!~mcsTemperature Debug~!~Sampling Quasar 3145 Data
                    10/25/2005 9:11:27 PM~!~mcsTemperature DebugTrigger Device (4~!~UpperLimit Compare 33.3 vs Compare Value=79 priorValue =33.3, event Started=False
                    10/25/2005 9:11:27 PM~!~mcsTemperature DebugTrigger Device (4~!~LowerLimit Compare 73 vs Compare Value=73 priorValue =33.3, event Started=False
                    10/25/2005 9:11:28 PM~!~mcsTemperature~!~Quasar Data: 4 R V1.0 2002-01-06 20:37:37 C
                    10/25/2005 9:11:28 PM~!~mcsTemperature Debug~!~Calibrate 33.8 with bias -0.5
                    10/25/2005 9:12:28 PM~!~mcsTemperature Debug~!~setIO (60 from 0 to 19
                    10/25/2005 9:12:28 PM~!~mcsTemperature Debug~!~Log Temperature Sensor Count=5, INSERT INTO Temperature(SampleDate,sQUASAR_3145_0001,sQUASAR_3145_0002,s QUASAR_3145_0003,sQUASAR_3145_0004,Upstairs_temp) SELECT #2005-10-25 9:12:28 PM# AS QT,0 AS Q0,0 AS Q1,7960 AS Q2,3330 AS Q3,6800 AS Q4
                    10/25/2005 9:12:28 PM~!~mcsTemperature DebugTrigger Device (4~!~UpperLimit Compare 33.3 vs Compare Value=79 priorValue =33.3, event Started=False
                    10/25/2005 9:12:28 PM~!~mcsTemperature DebugTrigger Device (4~!~LowerLimit Compare 73 vs Compare Value=73 priorValue =33.3, event Started=False
                    10/25/2005 9:13:28 PM~!~mcsTemperature Debug~!~Sampling Quasar 3145 Data
                    10/25/2005 9:13:28 PM~!~mcsTemperature DebugTrigger Device (4~!~UpperLimit Compare 33.3 vs Compare Value=79 priorValue =33.3, event Started=False
                    10/25/2005 9:13:29 PM~!~mcsTemperature DebugTrigger Device (4~!~LowerLimit Compare 73 vs Compare Value=73 priorValue =33.3, event Started=False
                    10/25/2005 9:13:29 PM~!~mcsTemperature~!~Quasar Data: 4 R V1.0 2002-01-06 20:37:37 C
                    10/25/2005 9:13:29 PM~!~mcsTemperature Debug~!~Calibrate 33.8 with bias -0.5
                    10/25/2005 9:14:29 PM~!~mcsTemperature DebugTrigger Device (4~!~UpperLimit Compare 33.3 vs Compare Value=79 priorValue =33.3, event Started=False
                    10/25/2005 9:14:29 PM~!~mcsTemperature DebugTrigger Device (4~!~LowerLimit Compare 73 vs Compare Value=73 priorValue =33.3, event Started=False
                    10/25/2005 9:15:29 PM~!~mcsTemperature Debug~!~Sampling Quasar 3145 Data
                    10/25/2005 9:15:29 PM~!~mcsTemperature DebugTrigger Device (4~!~UpperLimit Compare 33.3 vs Compare Value=79 priorValue =33.3, event Started=False
                    10/25/2005 9:15:29 PM~!~mcsTemperature DebugTrigger Device (4~!~LowerLimit Compare 73 vs Compare Value=73 priorValue =33.3, event Started=False
                    10/25/2005 9:15:30 PM~!~mcsTemperature~!~Quasar Data: 4 R V1.0 2002-01-06 20:37:37 C
                    10/25/2005 9:15:30 PM~!~mcsTemperature Debug~!~Calibrate 33.8 with bias -0.5
                    10/25/2005 9:16:29 PM~!~mcsTemperature DebugTrigger Device (4~!~UpperLimit Compare 33.3 vs Compare Value=79 priorValue =33.3, event Started=False
                    10/25/2005 9:16:29 PM~!~mcsTemperature DebugTrigger Device (4~!~LowerLimit Compare 73 vs Compare Value=73 priorValue =33.3, event Started=False

                    The 33.3 is actually 33.8 with a -.5 offset specified by me in the config. The line of Quasar data is the one of interest here. I don't know how the data is getting malformed like that.

                    Comment


                      #11
                      I'm not clear as what you are trying to show. I see the sensor #3 at 33.3 and sensor #4 at 68. It looks that the thermostat control should be active, but I dont know anything about its setup. This has been an active area withe the plugin in the last few months so update if you are not current.

                      Comment


                        #12
                        Mike.


                        There is only one sensor connected (#4) in this log example. There used to be a sensor 3, but it is disconnected (although its device value remains). The problem is this:

                        10/25/2005 9:15:30 PM~!~mcsTemperature~!~Quasar Data: 4 R V1.0 2002-01-06 20:37:37 C

                        This is a malformed data string. The logged data string should consist of "V1.0 2002-01-06 20:37:37 C", followed by a delimiter, followed by another log line of Quasar data consiting of "4 {temperature reading}" and a delimiter. The temperature and the second delimeter are not being read. The device value of sensor 4 should not read 33.8 F... it's inside a room with a temperature of 78 degrees!

                        Comment


                          #13
                          It looks like the "4" was delivered to indicate the sensor number and then nothing after it including no delimiter so the 4 becomes part of the next line which is the one that starts with "R" to indicate a new data set.

                          I changed the logic to ignore the misformed sensor readings. If it is just a sync problem then this should take care of it. I'm guessing, however, that the K3145 does not deal well with only a single sensor in position 4.

                          If you have the IO window open you will get a better view of the actual traffic between the plugin and the hardware. This will show the data as it is read from the port before buffering.

                          The update is posted as 4.39.1

                          Comment


                            #14
                            That was it...

                            Originally posted by Michael McSharry
                            I changed the logic to ignore the misformed sensor readings. If it is just a sync problem then this should take care of it. I'm guessing, however, that the K3145 does not deal well with only a single sensor in position 4.
                            I believe you have hit the nail on the head here, When I plugged another sensor into position 1, I began to get correct readings on both sensors. I will chalk this up to an issue with the hardware. Thanks for your assistance.

                            Comment

                            Working...
                            X