What does MCSTemp use for calculations in Temp Events

[aldonc]

I recently changed from the USB 1-Wire interface (9097) to the Hobby Boards Master Hub and it seems that the behavior of Temperature Control based Events has changed. I'm wondering which device parameter (devicevalue, devicestring, etc) gets used in the temp events to calculate differences.

I have the Temperature Control setup in the trigger as follows:
Trigger Type = Temperature Control
Sensor on which to trigger = $1 (a 1-wire sensor)
Sensor for Delta = $2 (another 1-wire sensor)
AND conditions Checked
Upper Limit = 6

Delta increases above Upper Limit Checked
and persist for = 1
ReTrigger after = 20

In the action, a fan gets turned on for a few minutes and a log entry made.

My impression of the way this should work (and the way I think things worked before the Master Hub change) is: When $1 changes if the difference between it and $2 has been 6 or greater for at least a minute, trigger the action. Also, Retrigger in 20 minutes if the 6 or greater condition is still met.

It seems that the condition triggers every 20 minutes - no matter what the difference between $1 and $2. I have added writes to the log of the devicestring and devicevalue for $1 and $2 and there are times that the difference is less than 6 but the event still triggers the action.

I had to change the way the 1-wire info was read into MCSTemp since the Master Hub requires MCS1Wire but it seems that everything's still running fine for MCSTemp (temps being read and stored, charting working OK). I am just wondering where the values come from for the Temp Controlled Event and if there is something I have done to invalidate the calculations. Any test I can do to make sure it's doing the delta properly?

thanks,
Aldon

[Michael McSharry]

DeviceString is normally used. I think there is a case for Temperature types if the setting is to show only icons then it will use DeviceValue.

There is debug output, when enabled in mcsTemperature, that shows some of the periodic 1 minute calculations that are done. If you enable this and post a few minutes of the log then I should be able to see what the internal state may be and if I will need to add more to the debug to get greater visibiltiy. Your understanding of the setup looks to be correct.

I do not recall, but another source of potential problem, is that HS2 deals differently with devices that are not associated with a plugin. Since your incoming data is now owned by mcsXap and not mcsTemperature, then HS 2 will not inform mcsTemperature about events related to that device. This may or may not be a consideration in this case. I would need to look at source code to see what dependencies may exist.

[aldonc]

OK, I just turned on the General Debug log (let me know if you want the special debug log instead).

I originally though that the icons may be the cause so I have turned them off in mcsxap1Wire. The device string only has the "bullet" and the temperature.

I also have these devices in MCSTemp. I have included them by house/device codes in the Sensors screen.

As I was writing, some stuff got placed in the log. Here are lines that I think may be important:

9/11/2007 1:39:31 PM mcsTemperature Debug (0) Trigger Device $1, Compare Device $2, Upper Delta Compare vs Delta Value=78.3, event Started=True
9/11/2007 1:39:31 PM mcsTemperature Debug (0) True Condition Found, Current True Count=1, needed=1
9/11/2007 1:39:31 PM mcsTemperature Debug (0) SampleEventTriggered=True, Trigger Repeat Time=9/11/2007 1:57:29 PM, TriggerDwell=1, DwellStart=9/9/2007 3:53:03 PM
9/11/2007 1:39:31 PM mcsTemperature Debug EvaluateDeviceAction DeviceActionCollection.Count=0, MonitoredEventCount=0

Near the time of this $1 had a device sting of 80.2 and $2 had 74.5.

thanks,
aldon

[aldonc]

Hi Michael,
Attached is a snippet of the log this morning. Let me know if there's more or different info that would help.

thanks,
aldon

[Michael McSharry]

Based upon your first set of data the debut shows the following:

Upper Delta Compare value is null which is treated as 0
abs(DeviceString($2) - DeviceString($1)) = 78.3
Note that if DeviceString($2) after HTML tags are removed is null then DeviceValue($2) is used

Trigger Device $1,
Compare Device $2,
Upper Delta Compare vs Delta Value=78.3,
event Started=True

Since the 78.3 is in the middle or your estimated $1=80.2 and $2=74.5 it is hard to see if $1 or $2 likely has a null string. You can use an xAP viewer to see what data is coming from xapmcs1Wire. DisplayText key goes into DeviceString. Text goes into DeviceValue.

In the second set of data it looks as if you added some Info output to the log

Trigger Device $1,
Compare Device $2,
Upper Delta Compare
Delta Value=77.8,
event Started=True

Info-String - Den Fan Started, closet temp is 80, room temp is 73.6
Info-Value - Den Fan Started, closet temp is 80, room temp is 74 = 6

The expression evaluation looks to see if a term is numeric and if so it uses it as a literal and then if not it looks to see if it is a device code. The $2 may be considered as a valid number ( 2 dollars ) and in that case the expression would be 80 - 2 = 78 which is about the same as the 77.8 Delta value. If you believe this is a correct interpretation then there are two approaches. One is to use a different house code for these sensors and the second is to made a special case check for the $ in the expression evaluation.

[aldonc]

Working on it...

Hi Michael,
I think it might be the $2 that you mentioned. I did a log print of the devicestring and devicevalue for both and they had the expected values (no nulls).I got a match of subtracting the $2 (as a number) from one o fthe values to get the delta value in the MCSTemp logging.

I changed the housecode to ` but everything went bad in MCSTemp (kept throwing log errors that some devicecodes weren't associated with physical devices...). I changed to % and things seem to be going ok. I now need to wait for my server room to cool a bit before I'll know if the delta function will work. I should have an update in the morning.

thanks,
aldon

[aldonc]

Seems to have fixed it

HI Michael,
That seems to have done it (changing the housecode from $). The delta in the MCSTemp logging is now showing the right delta between the two sensors so it gives the event a chance to work right.

One thing I noticed with MCSTemp logging on after the housecode change is a pretty steady stream of:
9/13/2007 7:02:02 AM - mcsTemperature - setIO %3 from 0 to 19, brightness=36
9/13/2007 7:02:02 AM - mcsTemperature - setDevice %3 from 2 to 2
9/13/2007 7:02:02 AM - mcsTemperature - setIO %5 from 0 to 19, brightness=46
9/13/2007 7:02:02 AM - mcsTemperature - setDevice %5 from 2 to 2

%3 and %5 are 2 temp readings from Speedfan via XAP (note that these are different than the ones used in the issue above). MCSXAP is loading them into HS devices where I have set them up as Type Temperature (presumably the same Temperature Type as other sensors). I entered them into the sensor screen of MCSTemp and selected a temperature device type.

The log leads me to believe they are being considered something other than Temperature sensors. I have changed them to different sensor types in MCSTemp but it doesn't change the message that's reported. There is one more sensor coming in from the same Speedfan XAP message that is set up in the same way and that is not getting a similar message. Note that these are being saved to the database and charted OK, this is only seen in the MCSTemp debug logging.

thanks,
Aldon

[Michael McSharry]

The SetIO is a call made by Homeseer to a plugin where the .Interface property of the device matches the plugin name. When mcsXap creates a device (call it [1) it will set the .Interface property to mcsXap. When mcsTemperature creates a device (call it *1) it will set the .Interface property to mcsTemperature. When something changes [1 then HS will call mcsXap and when something changes [1 it will call mcsTemperature. These calls are the SetIO calls.

Another device proerty is .Device_type_string and is something that HS shows on its GUI for device properties while it leaves .Interface only visible via script.

[aldonc]

As I made the change in housecode from $ to %, I did it first in mcsXAP, verified it was OK in HS then updated the device in mcsTemp. Since the is with a HB Master Hub, I am assuming that mcsXap "owns" the device (by way of mcsXAP1Wire) and mcsTemp is just reading HS device changes. I take your explanation to mean that HS is notifying mcsTemp of changes to the device which is not what I'd expect since it didn't create the device. The other thing that threw me was that it is reporting a brightness value so I assumed that the device type was set wrong somewhere.

I guess the ultimate question is do I need to worry about this? If not, I'm OK with putting it out of mind and let things continue to run happily.

Also, I'd like to give a thank you to you Michael. You always take the time to give patient & thorough explanations when I'm sure there are times you are banging your head on the keyboard!

thanks,
aldon

[Michael McSharry]

Thank you for the acknowledgement. It is always good to hear.

I wrote a utility to help manage the .interface property. One I posted is at http://board.homeseer.com/showthread.php?t=113064. It may require some components to be downloaded such as the grid control. Once you have it running then you can see the .Interface setting of the HS devices and it will allow you to edit a large group of them to change ownership between plugins. I have not used it for a long time so I do not recall specifics, but as a minimum it will show you who owns what.

For devices that are only input devices such as temperature sensors then it really does not matter who owns them. Output devices, however, need to have the proper association so you are able to control the output.

It looks as if mcsTemperature is the .Interface property value for your %3 device. When Setio is called mcsTemperature will check if it owns the house code % and if not will exit without too many cpu cycles burned. mcsTemperature reports its two house codes on one of its setup pages or the bottom of the setup form. If it is its code then it will see if it knows how to manage it and in this case will likely find it does not know what to do so will exit after a few more cpu cyclces are burned.

The brightness is no more than the DeviceValue. If you have a temperature reading of 70 then the brightness will be 70. Homeseer evolved from an X10 paradymn and this was the nomenclature associated with the DIM/BRIGHT X10 operations.

[aldonc]

Interesting that there were 5 out of 6 devices assigned to MCSTemp including 2 from Speedfan's XAP which never went directly to MCSTemp, always ->MCSXap -> HS -> MCSTemp.

Oh well, fixed now and the errors are gone in the logging.

Thanks again for the help and off to see if I can break something else!

aldon