Not recording Temp08 sensor output consistently

[johnnyt]

Attached (1st file) is raw output from my Temp08 showing sensor readings for five Midon Design Temp/Humidity Sensors plus the built in temp sensor in the Temp08 (11 readings in all), followed by the entry mcsTemp recorded in its database (and HS devices).

You'll see that (indoor) sensor 410000004FEE3A26 (sensor "41") reports humidity as 35%, but the database (and device) registers it as 88, a value it recorded from a previous mysterious disappearance of sensor 41 (a separate problem I will report to Temp08 forum) that caused it to record the data from the next sensor in line, 800000004FE5AA26 (an outdoor humidity sensor now at 90 for this log entry).

By the way, the mishandling (at least in my view) of disappearing sensors was reported here.
http://board.homeseer.com/showthread.php?t=105315

And here
http://board.homeseer.com/showthread.php?t=105316

but apparently could not be fixed without messing other people up (if I understood right). - Is this still the case?

Anyway, the improper recording is not consistent across sensors as most of the other sensor readings were properly recorded (note that I do add *small* calibration adjustments to many sensor readings). But the misrecording did occur consistently over a period of time (and through an HS restart too).

The second attached file shows the history from about the disapperance of sensor 41 at 11:08 entry, through it's reappearance around 11:20 and a restart at 11:23 until it began recording properly again at 11:39.

The third attached file is really for Temp08 forum but included here for completeness showing a sample of the appearance and disappearance of sensor 41 over a number of cycles and to add weight to my interest in finding a way to handle this phenomenon. (Ignore Temp08 date, e.g. FRI 20:41:19, its clock always goes out of sync for some reason)

Is there anything that can be done?

[Michael McSharry]

There are two separate things at issue here. The first is the 35 showing up as 88 in the database. A humidity reading of 35 is often a bad reading just like 85 is a bad reading for the Temperature sensor. These are processed by mcsTemperature as bad readings and will record either the last know reading or a value of zero depending how you have error handling configured.

You "41" sensor appears to located at a point on the 1-wire where the waveforms are poor. This is likely due to reflections that amplify/supress the signal or capacitance that shifts/absorbs the signal.

The design model of mcsTemperture was based upon compatibility with another Temp05 plugin and this design uses the sensor number index from the Temp05/08 for both input identification as well as discrete output identification.

The design model of xapmcsTemp0x uses the sensor id as the form of identification. The failure mode where the sensor index dynamically changes will not cause a problem with xapmcsTemp0x. I do not know what Jim uses for DooTemp08, but since he started out without the backward compatibilty requirements that mcsTemperture has it is likely he uses the serial number as I have done going forward with xapmcsTemp0x.

Based upon Mitch's response in your reference link he uses the memory contained within devices on the network rather than memory internal to the Temp08 to associated IDs with indexes. This is also a design decision with pros and cons.

You are at the point where a design incompatibily exists between the Temp08 firmware and the mcsTemperature software. It is not that these two items are not meeting their design objectives. It is simply that when used together on a unreliable 1-wire bus they do not yield the desired results for your system's operation.

If I was integrating these items I would first assess the need for "41" and then find a way to install it so it exhibits reliable operation. The next step, if necessary, is to work with components the are compatible for your needs. You can change the PC interface to something like DS9097U and eliminate the Temp08 indexing problem. You can change the PC software so the index to ID relationship does not cause an issue.

The 35 value for humidity can be made a user-selectable filter in mcsTemperature, but this is not the essence of your problems and I do believe that you would not want record questionalble readings.

[johnnyt]

Thanks for the quick reply.

While the 35% humidity level is not - as you say - the essence of the problems I'm reporting, fyi, here's a chart of recommended indoor humidity levels at various winter temperatures right off the humidistat on my furnace humdifier:

-20 F -> 15%
-10 F -> 20%
0 F -> 25%
+10 F -> 30%
+20 F -> 35%
over +20 -> 40%

Temps of -20 F (and humidity levels of 35%) or less are not uncommon in many northern states, and certainly in Canada, where I live and where temps can go down to -40 F some nights in the dead of winter.

So the current readings I'm getting of between 25% and 35%, although a bit dry (my current target is 40 and has my Home Automation calling for my furnace humidifier to go ON - which I just got working in our new house yesterday -) are quite normal and accurate.

For the reason above, I do set "minimum reasonable humidity" in mcsTemp to 15.

---------

The problems I'm reporting are really about 1) mcsTemp not reading my Temp08 output properly, and 2) mcsTemp's error handling for temporarily removed sensors from my 1-wire bus (whether manually or because of some bus or other defect) using a Temp08 to deliver the readings.

To add to the first issue, I've attached some more output from my Temp08 showing relatively consistent readings of 35 for sensor "41" and the matching mcsTemp database records showing 100 for that sensor (I did uncheck the setting "Use previous on bad" and do have "min humidity" at 15 and checked for these particular entries). Why are these valid readings not being recorded?

To the error handling issue, I'm a little disapointed to hear that backwards compatibility with the older Temp05 appears to be more important than upgrades that would support the more current Temp08. But if I'm the only one that uses a Temp08 w/ mcsTemp and gets bus errors or occasionally removes a sensor, I guess there isn't much of a case to make improvements in this area and I'm S.O.L.

[Michael McSharry]

I usually try to be accomodating, but I know what a can of worms the sync of the index with serial number for the various V4, V5, and Temp08 units is and I do not want to open that can. It is just too much risk to existing users. It would be very hard to test all the permutations. I also don't know what it may break with those that still use the early units if the core logic changes.

What I did do is add the checkbox to open up 35% humidity as a valid reading . It is located at the same location where the minimum limit is input. It is posted as V4.44.0.

[johnnyt]

I understand the issue about the can of worms and that you do try to be accomodating as much as possible...

Regarding a reading of 35 and the "minimum reasonable humidity" feature in mcsTemp, can you elaborate on what's happening there / what this feature is for? Does the Temp08 sometimes overshoot 100 when the humidity is high? Is it only when the humidity is high or is it an error that can happen when the humidity is at or around 35 too? Is the number 35 a magic number? What about 34 or 36, etc.?

[Michael McSharry]

The Temp05 delivers humidity reading of 101, 102 etc, but only provides the last two digits so it looks as if the humidity is 1%, 2% etc. If values under the "reasonable minimum" are receieved then the plugin will add 100 to the number.

There is also an independent feature of the plugin that will limit the humidity to 100%. If both of these are employed then a value of 1% from the Temp05 would be treated by the plugin as 100%.

The 35 is the number reported by other users and is what I implemented. What I actually observe with my sensor is one-frame dropouts in the range of 30 to 40. In my case I consider single-sample readings under 40 to be invalid. This single-frame filter was not implemented in mcsTemperature.

Another technique that can be used is to apply the moving average calibration in mcsTemperature to reduce the dropouts to minor bumps rather than major extensions of the charted humidity line. This works fine if humidity is used as a slow moving weather indication. It may not work so well if the humidity is part of a faster moving control loop since changes in humidity will not be visible as s soon as changes in the raw readings.