Announcement

Collapse
No announcement yet.

Solar Sensor not Updating...

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

    Solar Sensor not Updating...

    Michael, for sometime now the 1Wire readings for my (two) Solar sensors have not been updating in HS. Yesterday, with renewed resolve, I updated to all of the latest versions of xapmcsHub (v1.21), xapmcs1Wire (v2.6), and mcsXap (1.4.09, ocx). The problem persists. In fact, neither of my two solar sensors, Solar1 (6C000000B63DA826, device %3) nor Solar2 (4300000061488026, device %9) have updated in HS since HS was restarted immediately after the above version updates. I can go into 1Wire and watch the different Solar readings for the sensors as it polls at the appropriate times. The new readings are just not presented in HS. Attached are debug listings for both mcsXap and 1Wire over the 5 min poll period. The HS reading started out at 3412 for Solar1 and 19 for Solar2, and of course thats what they still are. You can see in the debug that they reported 388 and 6 respectively. Let me know if you need any thing else.

    Thanks
    Gary
    PS: Let me know if you feel I should update to the .Net version of Xap, I guess I need to sooner or later.
    Attached Files

    #2
    My experience with the hobby-boards solar sensors has been rather poor. They will work for awhile then the hardware will fail. I'[ve gone through 2 or 3 and have given up on it.

    I did not look at your debug, but if you are getting readings from xapmcs1wire for this device and not in HS, then we can investigate. I suspect that the reading have stopped from xapmcs1wire.

    The .NET version of the HS plugin works for some and for others it stops after awhile. It is still in engineering development so unless you have some real need to move to .NET then I would stay with the .ocx.

    Comment


      #3
      Originally posted by Michael McSharry View Post
      My experience with the hobby-boards solar sensors has been rather poor. They will work for awhile then the hardware will fail. I'[ve gone through 2 or 3 and have given up on it.
      Michael, as mentioned I have observed this condition over a couple months now. I have always had two sensors. One did fail (I believe) and I ordered a replacement. The Solar1 sensor is new. As mentioned, neither of the two update although 1Wire clearly is polling and receiving changing values for both sensors. If I am reading the debug(s) properly, it believe that show this behavior. It is interesting that it "seems" to update in HS whenver I restart HS or have it poll of new sensors. Since I am reluctant to bring HS down any more often than I need to, I can't be sure its 100% however.

      Thanks
      Gary

      Comment


        #4
        The sensor used for the Solar (DS2438) will continue to respond normally, but if the phototransistor fails then the current measurement being read by the DS2438 will not be changing and no event messages will be sent. When you poll or query (HS restart) then a info message will be sent to transfer the current value. The current measurement is not shown in the IO window, but the behavior seems exactly like the phototransistor has failed.

        Comment


          #5
          Originally posted by Michael McSharry View Post
          The current measurement is not shown in the IO window, but the behavior seems exactly like the phototransistor has failed.
          To be clear, I am watching the 1Wire browser window, and refreshing the window at approximately the polling period. I am seeing the values change in 1Wire but those values not reflected in HS. Again, the Solar1 sensor is brand new. What information do you need to verify one way or the other?

          Gary

          Comment


            #6
            Originally posted by Michael McSharry View Post
            I did not look at your debug, but if you are getting readings from xapmcs1wire for this device and not in HS, then we can investigate.
            Michael, this is what I am talking about./Gary
            Attached Files

            Comment


              #7
              I added debug at the point where the sunlight sensor is being processed. When debug is enabled you should see the raw current values being read and then when the current changes you should see where the xAP message is being sent in the log.

              Comment


                #8
                Originally posted by Michael McSharry View Post
                I added debug at the point where the sunlight sensor is being processed. When debug is enabled you should see the raw current values being read and then when the current changes you should see where the xAP message is being sent in the log.

                Ok, I downloaded and installed v2.6.01. Stoped HS then 1Wire and Restarted 1Wire then HS. Early in the HS log I got:
                3/4/2008 1:20:28 PM ~!~xapmcs1wire~!~mcs.onewire.slvrs22g | includecontent line 490 subscript out of range

                I was wrong before when I said I thought the HS values were updated when HS restarted. This time they are not. They still show as they were set on 3/1/08 in HS. I don't think I recognized the raw data in the 1Wire debug you mentioned but the updated values that I saw before are there if that helps. Debug files attached. I let it run through about 3 polling cycles, and noticed updated readings at:
                1:29:33 & 38
                1:34:56 & 1:35:00

                Thanks
                Gary
                Attached Files

                Comment


                  #9
                  The error message comes from the temperature switch not having a number of significant digits defined. I fixed this so it will not occur again.

                  The 1-wire output shows that xAP messages appear to be sent for the sunlight. In this case below it was sent with readings of 13 and 19.

                  Code:
                  3/4/2008 1:29:33 PM | xapmcs1WireDebug  DS2438-Sunlight Raw Current =13, CalFactor=0, PriorSunlight=19 0
                  3/4/2008 1:29:33 PM | xapmcs1WireDebug Format Analog 4300000061488026=13, port=COM7, accept=True, Channel=5, Type=35 0
                  
                  3/4/2008 1:34:56 PM | xapmcs1WireDebug  DS2438-Sunlight Raw Current =19, CalFactor=0, PriorSunlight=13 0
                  3/4/2008 1:34:56 PM | xapmcs1WireDebug Format Analog 4300000061488026=19, port=COM7, accept=True, Channel=5, Type=35 0
                  In the HS Log the message is being received

                  Code:
                  3/4/2008 1:29:33 PM ~!~mcsXap Debug~!~xapbsc.event Source=mcs.onewire.slvrs22g:xapmcs1wire_solar2.4300000061488026.sunlight.5,Exists=True

                  Take a look at the mcsXap setup page where sensors are selected for "A"cceptance. Assure that mcs.onewire.slvrs22g:xapmcs1wire_solar2.4300000061488026.sun light.5 is mapped into a device code. Pay special attention to the .5 at the end of the address.

                  Comment


                    #10
                    Originally posted by Michael McSharry View Post
                    Code:
                    3/4/2008 1:29:33 PM ~!~mcsXap Debug~!~xapbsc.event Source=mcs.onewire.slvrs22g:xapmcs1wire_solar2.4300000061488026.sunlight.5,Exists=True

                    Take a look at the mcsXap setup page where sensors are selected for "A"cceptance. Assure that mcs.onewire.slvrs22g:xapmcs1wire_solar2.4300000061488026.sun light.5 is mapped into a device code. Pay special attention to the .5 at the end of the address.
                    Let me be sure I understand which Xap entry should have the "A" checked. I have two such entries, one without the .5 and one with. Are you saying the one with the .5 should be checked? If so that may well solve the problem, since all this time I have been running with the one without the .5 checked.

                    Thanks
                    Gary

                    Comment


                      #11
                      Yes that is the significant find. There was an update associated with the migration to V1.3 of xAP where a consistent approach was implemented for identification of sensor readings. The addresss is now based on the physical sensor rather than the instance of an interpretation of the sensor reading. The .5 indicates that it is the 5th interprretation of the data from the DS2438. The 5th is allocated to the Sunlight reading. Previously the convention was to only add the suffix on the second and subsequent instances of the type within a device. Since it was the first sunlight interpretation it had no suffix.

                      Comment


                        #12
                        Originally posted by Michael McSharry View Post
                        Yes that is the significant find. There was an update associated with the migration to V1.3 of xAP where a consistent approach was implemented for identification of sensor readings. The addresss is now based on the physical sensor rather than the instance of an interpretation of the sensor reading. The .5 indicates that it is the 5th interprretation of the data from the DS2438. The 5th is allocated to the Sunlight reading. Previously the convention was to only add the suffix on the second and subsequent instances of the type within a device. Since it was the first sunlight interpretation it had no suffix.
                        Great. I made the change and it is now updating properly. So is it then now correct to say that all sensors should be maped to the highest interpretation/suffix?

                        Thanks
                        Gary

                        Comment


                          #13
                          It is likely the case as far as the mapping goes.

                          Comment


                            #14
                            Originally posted by Michael McSharry View Post
                            It is likely the case as far as the mapping goes.
                            As you can see from this experience, mapping the 1Wire sensors to HS has always been something I have had great difficulty understanding and getting right. This pointer helps greatly. Thanks again Michael for all your great support.

                            Gary

                            Comment

                            Working...
                            X