MCS stops recording data

[gcyeaw]

Michael,
I removed a couple of plug-ins I wasn't using (mr26a, webcam,MCSmusic) and then unregistered ane re-registered the remaining plugins. The discrete events have been running ever since without failure. It has been less than 24 hours, but it hasn't run that long for a while.

I know that the webcam plugin would produce script error messages in the log ocasionally, so it was a prime candidate anyway.

Gardner

[Michael McSharry]

HST looks at all help desk tickets pretty quickly and may be able to provide some feedback without investing much time. I could submit the ticket, but you are better able to describe your configuration.

[gcyeaw]

Michael,
Thanks. I will see what can be done. The first thing is to remove any plugins I dont need or am not currently using. Since this doesn't seem to be something others are experiencing, I may be able to clear it up that way. I plan to move on to HS 2, but frrom what I have been reading I will need alot of time and patience to do it

Thanks again, Gardner.

[Michael McSharry]

A normal sequence is
1. Callback from HS to HSEvent/CheckDevice in mcsTemperature
2. LogDiscrete evaluation in mcsTemperature
3. Log Discrete store to database in mcsTemperature
4. Event Trigger HS Message to Log

When the failure occurs the sequence is
1. Event Trigger HS Message to Log

which means that a HS is not delilvering a callback to mcsTemperature, hence the opportunity to record the status change never occurs

When looking back in the log for the last callback the following can be observed with the warning coming from HS.

2/18/2006 2:49:09 AM~!~mcsTemperature Debug~!~Check Device Event \63=17,DictionaryExists=False
2/18/2006 2:49:09 AM~!~Warning~!~In status change event callback, object removed, error number: 9 Subscript out of range Source: HomeSeer

Device \63 is not a discrete managed by mcsTemperature so the activity performed by mcsTemperature in CheckDeviceEvent is simply four lines where a lookup in the discrete dictionary confirms the device is not of interest and return back to HS.

To go any further HS needs to be involved which means a help desk ticket is needed. If you are running HS1 then I don't know if they accept tickets, but even if they do not make any code changes to HS1 they could at least provide some indication what this error really means and if anything can be done external to avoid it.

[gcyeaw]

Michael,
Here is another trace, hopefully with the data you need. The discrete values stopped recording at 2:48 for Boileron and Burneron. The analog values continued to be recorded.

Thanks, Gardner

[gcyeaw]

Michael,
I will check when I get home tonight.
Gardner

I went through the install, unregister, register, and it now shows 4.46.3, I must have made a mistake unregistering and registering before. It looks good now, with colors and new debug entries. Back to data collection. Sorry for the waisted time.
Gardner

[Michael McSharry]

In my prior post I showed 6 ways that the discrete could be recorded. Are you doing anything related to these burner devices to cause a recording to occur? I do not see any messages resulting from a HS device status change, yet we do see the Log Discrete. Does the version show on the mcsTemperature setup in the lowest row of the form as 4.46.3? I know the file is 4.46.0.3, but perhaps another copy is registered and it is actually running the other copy. This would also explain the lack of discrete color control.

[gcyeaw]

Michael,
I have a new trace. Discrete entries stopped being logged to the database at 12:01:18. The values were burneron and boileron. The version from the properties display is 4.46.0.3.

Thanks, Gardner.

[gcyeaw]

Michael,
Thanks.
I loaded the new one this evening. It shows as 4.46.0.3 in the properties display so I know I have the latest. I started debuging and will update when I have results.

One thing that I did notice is that the discrete values still don't display in the chosen color on the graph.

Gardner

[Michael McSharry]

I just recompiled and reposted as 4.46.3. Should be the same, but just in case I messed up at my end.

[gcyeaw]

Michael,
I reinstalled 46.2, but in the lower right it still says 46.0. The file properties show 4.46.0.2, so I assume this is the right file?

Gardner

[gcyeaw]

Michael,
Please accept apologies, I must have been sleepy, I had 46.0 rather than 46.2 installed. I have updated and will collect new debugs...Sorry.


Gardner

[Michael McSharry]

There are six paths for which discretes are logged.

TemperatureAction
Setio relay controlled by mcsTemperature
StoreDiscrete external script
Temp05 DS2405/06, Rly08
DS9097U DS2405/06/08
HS Status Change

I added debug code in V4.46.2 for the HS Status Change path and did not see any of those debug outputs. It looks like the BurnerOn discrete is coming from the ocelot so I would have expected the HS status change path to have been executed. Are you certain you are running this version? Are you doing anything such as calling StoreDiscrete via script?

[gcyeaw]

Michael,
The discrete data collection keeps stopping. I know the status is changing in Homeseer, but can't tell from the trace what is wrong. I restart Homeseer and the discrete data is updated for a while, then stops again. I have a trace, the data stopped about 3:55. The remaining analog inputs continued to log properly.
One specific device is +8, BurnerON. I do see updates in the trace from Homeseer, but they aren't gertting into MCSTemp database.

Gardner

[Michael McSharry]

A totally different logic path occurs with discrete recording. It starts with an event callback from HS telling the plugin that a status change occurred and the data is written at that time to the database. If no status changes occur there will be no data written. This is unlike the analog data where it is written periodically.

In this update I put debug logic in the discrete data collection path. The log will not contain entries for every device that changes state and we will see if HS stops delivering status updates or the plugin stops processing them. V4.46.2