No announcement yet.

V3.0 ... V3.6 mcsTemperature Discussions

  • Filter
  • Time
  • Show
Clear All
new posts

    V3.0 ... V3.6 mcsTemperature Discussions

    This thread contains discussions on V3.0.0 of the mcsTemperature plugin downloaded from the updater and subsequent patches until the second updater download became available as version 3.7.0. The continuation of this thread is at V3.7.0 & Beyond Features and Problems

    [This message was edited by Michael McSharry on Tuesday, 04 February 2003 at 02:18 AM.]

    See DooMotion forum for example.



      V3.2.0 address PR12, PR19, and PR25. The patch file is located at the start of this thread.

      Error conditions for database fields being too small or for the field containing the "Required" attribute are now explicitly detected and the database dynamically changed to correct these defeciencies. A lockout is also provided so no data will be attempted to be recorded during the database change. If you have a lot of data in the database then the operation can take awhile. It was about 1 minute per 10,000 records when I was testing it. This feature, hopefully will have very limited use since once a database has been corrected it should never need be corrected again.

      The Forecast.asp now recognizes the "Show only Web Data" checkbox on the setup page. When checked the wind, rain, humidity, and barometer data collected locally will not be used and an expanded set of data from the web page will be used its place. This format is similiar to V1 of the forecast.asp. The forecast page still maintains 640x480 resolution in either mode to fit on Audrey-size screens.

      Note that the C vs F setup has moved to the Interface Setup section of the setup page and is now a checkbox that is checked if "C" readings are to be used for the forecast.asp and for temp readings collected on the 1-wire bus.

      4 additional checkboxes are added in the Interface Parameters section of the setup page. When checked, each will tell the plugin to use the metric scale and labels for Temperature, Wind, Rain, or Barometer. These boxes actually cause the data to be stored in the converted format if conversion is necessary.

      Duncan, you asked for the selective conversions so I expect you to provide some verification of its expected operation. Like my other changes in areas that deal with the TEMP05/DS9097 interface I am not able to test them so I need help in this area until I get back home. I hope I did not break something that was working in this area.

      If others will be using any of these 4 checkboxes then be aware that the database will store converted data and this will likely cause a discontinuity as prior data will be stored without conversion. The existing data can be updated with simple database update queries. If anyone needs these or help with these then let me know.



        I've been running fine here with 3.2.0 in Custom mode for a couple of days now. Everything seems to be working. I agree the setup is far too busy now - it needs to be set up as a tabbed table.

        When I change some item and click Update, it seems to reset/restart the timers for both the Temperature logging to the database and for the Forecast data collection. It would be best if there was some way to keep a steady interval going - every 5 minutes for the temperatures, say, and every 30 or 120 or whatever for the Forecast, even if the settings are changed in between. Even if the data collection interval changed, if the timers are counting up to the trigger value you could keep the count going. This wouldn't be too much of a problem if there was a way to trigger the Forecast immediately, but when it is set to 120 minutes and just before it triggers I change a setting, then it waits another 120 before I get a Forecast update.

        Every time I install a new version of the plugin, I have to tell Norton Personal Firewall to allow it to access the Internet, and there doesn't seem to be an easy way to do this manually - I have to wait for it (the forecast) to run, and then respond to the popup warning dialog with instructions on how to handle it. I know, I could set it to run every two minutes, wait for it to run, then set it back to 120. But if you could add a "Forecast Now" button somewhere it would be a lot easier. When it was an event-triggered script I could just right-click and "Execute Now".



          Thanks for the feedback. I'm a litle uncomfortable about posting something that I'm unable to test. Just hope the same success is obtained by those using the internal collection method.

          As ususal, your other suggestions are good and I added them to the list.



            I decided it would be good to "flush the toilet" so to speak and delete all traces of the plugin and reinstall from scratch in an attempt to regenerate the missing files and/or tables. However, it seems that the updater knows that I have already DL'd the plugin, and thus it only gives me the update. The same config pops back in, so I'm back where I started. I even tried deleting the database to see if it would recreate it - it didn't.

            I'd really like to test the calibration feature and trigger event modes, but without being able to edit the sensor map anymore, I'm stuck. Is there a way you can send me the entire install package vs. just the exe file so I can start from scratch?


              I believe I brought the full archive with me and I will send it with the instructions on how to install from the local driver rather than the homeseer ftp site.

              Update ... I think I sent it using the email in your profile. If you do not get it then send me an email and I respond to that address. I deleted your prior email with your address.

              [This message was edited by Michael McSharry on Saturday, 11 January 2003 at 07:20 PM.]


                I've tried out the checkboxes you put in for individual conversions, but I can't figure it out at all. Could you please give me a short 101 on how set set this up and I'll give you what feedback I can.

                So far all I've managed to so is wreck the asp display altogether.

                In particular, I'm trying to convert inHg baro pressures from TEMP05 to millibars (mmHg). This appears to work, but the conversion is way off e.g. 30.1inHg is giving me 765.3mmHg. As far as I know the conversion factor should be 33.8638, but this is 25.42.

                Actually Baro is the only one I'm trying to convert, but Id like the axes and legends to be correct in temperature.asp as well.

                Here's what I'm trying to acheive :

                Input inHg
                Output mmHg

                Input Centigrade
                Output Centigrade

                Input Inches
                Output Inches

                Input MPH
                Output MPH

                By "input", I mean from TEMP05 and by "output", I mean as shown in the device status, stored in the DB and displayed in forecast.asp and temperature.asp

                Also..... Over the w/e I converted to TEMP05 V5.0 and installed V3.2.0. I'm getting data logged regularly into the db now although I have missing data fields as per another post I made. Mainly, I can't see the Wind direction (possible character type error ? as I can see the other numeric values).

                BTW, you can still access the site using the log in I gave you if that's of any help.



                  Conversion 101:

                  All collected data is assummed to be English measure. All Temp05 and DS9097U data is collected as English, except perhaps Temperature which can be configured either way. A checkbox is used to indicate if C data is being collected. The same checkbox is used for forecast page.

                  All stored data is assumed to be English measure. Four checkboxes are available to used to selectively change Temperature, Wind, Baro, or Rain raw data into the Metric equivalent measure. The converted data will be stored in virtual devices and in database records.

                  All displayed data is assumed to have units consistent with the units in which it was stored in the database.


                  I concur that the wrong constant was used for pressure conversion. I'll fix it in v3.3.0.

                  If the "suppose to work" is not how it is working let me know what aspect is not as expected.

                  I am not able to read wind direction with my V5 temp05. It always returns ??? or equivalent. I had problems with it with V4.25 where it would return what appeared to be a somewhat random direction, but my wind direction is quite variable so I could not be certain it was a device/interface problem.

                  If you are also having problems with the wind direction then we probably should let Mitch know. You can turn on "Show Raw Data" to see what is being returned by the Temp05 and let me know if the problem is with bad/no data comming in or with how I handle it after it arrives.


                    I might have guessed you'd be online somewhere Thanks for the tutorial.

                    OK so I get points for spotting the Baro conversion factor, but I still can't completely figure out the temp conversions. From what you say, I should only need the Baro check box on because everything else is being read and stored in the correct units. Temp is being sent by the TEMP05 in C and I want to store it in C, so both check boxes should be clear - right ?

                    Certainly when I check either or both of them the values get wrongly converted, put it back and both the device value and the stored values are corrct.

                    However, in temperature.asp I find that checking the second box sets the scale legend to "Degrees C" (except that the figures are all wrong, unchecking this gives the right figues but the wrong legend. Is there some "double negative" logic at work here ?

                    Then there's forecast.asp .... in the .ini file I have mytemp="c", but the values are appearing in F from MSNBC.

                    I'm glad someone else has seen the ??? wind Direction problem. I was getting a lot of this under T05 V4.25, but it seems to have gone away for the moment since I a) 5V powered the 1WWS istead of using parasitic power b) redid all the cabling in CAT5 c) upgraded to V5.

                    No, the Wind Direction is definately updating via the Internal plugin method and you can see a good read in the "raw Data" log. All other parameters are getting written to the DB. Would there be any mileage in nuking the database ?



                      It is my intention that if you have the temp comming in in C and you want it stored and dislayed in C then both checkboxes are checked. The data storage algorithm for data received by the TEMP05 is to convert and store the data if the in and out checkboxes are different. If they are the same then the data is not converted prior to transfer to the virtual device and database.

                      It may be what you are seeing is that the data in the database was sometimes stored in C and sometimes converted to F based upon the checkboxes at the instant the data was obtained from the Temp05. When you went to display it then there was no setting of the checkboxes that would work because the stored data was a mixture of both.

                      On the display label part of the algorithm it only looks at the out checkbox. So, if you have C in and want to C on the display, then both boxes should be checked so no conversion will be done and the display label will be C.

                      I had totally forgot about the Forecast part of the problem with V3.2.0. Based upon your discovery I put the same logic in forecast so they should both be consistent. I'm assumming that the MSNBC web site always delivers F, independent of the ACCID. If that is not a good assumption then I will need to add a means to select it for the forecast that is independent of the Temp05.

                      Now for wind direction...
                      What I believe you are telling me is that the V5 Temp05 is delivering good wind direction based upon Raw Data log, but the virtual device that contains the wind direction is not receiving the same direction character and then the database also contains the same bad data that was in the virtual device. Please confirm this is the scenario.

                      Database field R21 contains the wind direction and if you want to clear this field out using Access you can. The only place that the plugin uses wind direction is on the forecast page.

                      The records where the temperature data was converted to F can be cleared if you wish. At this time, however, just make certain that the data is being stored in the C format with both checkboxes that control temperature in/out conversions checked.


                        This is getting complicated. I've tried again checking both boxes and it definately doesn't work the way you describe for me.

                        My TEMP05 is sending out C data and with BOTH boxes unchecked the device value is correct and the values written to the database are correct. That IS the opposite of what I would expect from the checkbox label, bit it does work for me.

                        My concern was that setting it up this way might cause forecast.asp to get completely confused and that might be the reason I'm seeing all F figures there.

                        With regard to the Wind Direction .... I AM getting valid wind direction data albeit with some random spells of ??? have started to re-appear (I'm begining to this this is either a marginal 1W situation or a broken reed switch giving errors in some places), it's just that this doesn't seem to get written to the DB in R21 with all the other data (it does enter a zero here, though). It DOES however, update the Device Value correctly when there is a good read.

                        My plan now is tp wait for 3.3.0 and see where that takes us with the improvements, you've put in.

                        And finally .... a more worrying sitiation is that data collection from the TEMP05 keeps getting locked up after about 8 hours or so. If I kill HS and hyperterm to it, it appears to be in the "what type of sensor is #nnn?" mode. Oddly I think this MIGHT be related to the Wind Direction problem as it seems to have forgotten the sensor type, but for now the only way round this is to put an appliance module on the TEMP05 and reboot it via HS every few hours, hardly ideal! - I'm going to have to let Mitch look at this one.



                          The lockup is caused by the marginal situation on the wind direction sensor. Exactly the same thing that I'm experiencing. I did put in a feature request to Mitch for a future timeout protection on user input.

                          In V3.3.0 I put in a watchdog function so that if the Temp05 does not deliver any data for two update cycles the plugin sends it a response indicating the type of device to use. This should take care of the problem. I guess you will be able to test this feature before me.

                          In V3.0.0 I interpreted the message from the Temp05 and sent a respone based upon it. The problem, I discovered however, is that on power outages the Temp05 reboots before the PC so the PC never sees the prompt from the Temp05. The watchdog should be sufficient robust to handle the situation.

                          I will try to improve the labeling of the checkboxes so it is not as confusing. Now that I know exactly what you are seeing I can look again at the logic implemented. I will also look at the Wind direction logic as well.


                            I can give you a bit more input now. I've finally climbed up onto my roof and brought down my 1WWS and guess what - a faulty wind direction sensor.

                            I don't know if it's the reed relays or the DS2nnn chip that's faulty at the moment, but the upshot is that it was sending S, SE, SSE OK but anything else was coming back as ???. There seems to be some odd logic in the TEMP05 V5 that says if it loses readings in this way and then they return, it goes into "tell me the sensor type" mode, which is exactly what you were seeing as well.

                            I don't really understand this as I would have thought the sensor type was stored in the EEPROM as wouldn't need to be re-assigned until you really wanted it to.

                            I agree that entering "W" when the lock-up occurs will probably solve the problem, but it's a bit brute force, TEMP05 could be waiting for just about any input. (Come to think about it, is it always expecting just a "W" at that point? I think I've seen it ask about all the sensors it's not sure about.)

                            I notice that Mitch left in a "1WWS Wind Direction debug mode" in V5, so I guess I'm not the only one to see this and from what I can tell it seems to be quite a common problem with the AAG 1WWS and when I spoke to them about this recently they advised "check the reed relays", so perhaps there's a common problem here.

                            Still, I think you still need to look at PR45 as when the data was coming in as S, SE, SSE, it WAS updating the device status and was NOT appearing in the DB - just a "0".

                            Bet you wonder what you've got yourself into with this plug in now ;-) Please keep up the good work, this will be an excellent Homeseer add-on when it's finally debugged.


                            [This message was edited by Duncan Ellison on Wednesday, 15 January 2003 at 03:18 PM.]


                              Thanks for the info. With my instrument I can use the DS9097 and the Dallas software and I get good data all the time so I know the unit itself is OK. The same is true with the iButton software and the DS9097U. Interestingly I can connect only the weather instrument to the TEMP05 and I get the same results with the direction sensor as if I have the entire network of sensors connected. For some reason the Temp05 just does not like that particular run of Cat5.

                              Would you mind email or post of the one line of raw data from the temp05 that contains the wind direction. That way I can make certain my parsing algorithm is not the source of the problem on PR45.