Call for Feature/Problem Reminders

[Michael McSharry]

I would like to wrap up this cycle of mcsSprinkler changes and put the latest into the updater. I know of confirmation needed from bunkers on Syringing and Cecil for Calendar popup, but otherwise I have forgotten about any other issues or features that have been promised. Could you remind me so I can address them now.

I want to start working the logic for Rain8UPB and would prefer to not have changes occuring on the base mcsSprinklers while I'm testing out the Rain8UPB hardware interface.

[DougLorenz]

NetIOM-xAP serial port support would be a good addition. However, I'm going out of town for the next few days on a business trip, and I still haven't gotten my NetIOM completely configured. I'd hate to delay your pursuit of another project with something that is probably more of a curiosity feature at this point...

[Michael McSharry]

Doug,
I've added the logic to support it and will test it with simulated data to confirm the implementation. It should only be minor tweaks if the netiom behaves a little different than I expect.

[Cecil]

Still having ET problems

Now running 227, but the problem has been occuring for quite a while.

When I make the change on the other setup page to use my HS device for ET value, MCS stops update the hourly and daily ET values on the general status page. When I change back to using calculated ET, the values update as expected. The HS device code for ET is "]20'. Not sure if this is relevant as other sensors update as expected, but the thread on popups mentioned a problems with '/' in device codes so I mention it here.

I've tried all sorts of different approaches up to an including re-starting the entire computer after making the change.

Attached is the section of the general debug log. Look around 7/26/2006 at 10:31:28 for the change to calculated ET. Look around 10:35:16 for the change back to using the HS device "20'.

Cecil

[bunkers]

I'm hoping to report back to you on that status of the syringing functionality by tonight.

I have continued to try an use the monitoring capability, but I am confused by how to utilize the "test" / "no test" button and when I have tested it (by shutting down mcs sprinklers, after enabling the monitoring) ... it gives me multiple popups (2 or 3) saying it hasn't heard from mcs sprinklers and asked whether is should continue waiting or shut down the monitoring.

So I was kind of expecting it to just restart mcs sprinklers, but instead it stalls on these windows, till I click on shut down monitoring ... maybe I am confused, but I was expecting it to either restart mcs sprinklers or reboot ... but the stalled window prompts seem confusing to me.

So I went back to using the original monitoring method you showed me, but it doesn't work anymore either ... so I was wonder if maybe you changed something ... so bottom line, its not working for me and I can't tell if its a personal issue or a bug.

I am willing to work more with you on this to get this resolved and I apologize if this is just user error or a lack of understanding on my part.

I think the current enhancements should keep us happy fore a long time. I can understand your desire to freeze things at this point.

[Michael McSharry]

The design for monitoring is as follows:

mcsSprinklers will deliver a role message on 5 minute intervals unless the Test button is active.

xapmcsRoleMonitor will wait until it sees a role message. After it receives the first one it will look for a period of 10 minutes for which no role message has been received. When this times passes it will restart mcsSprinkles or the PC.

The changes that have been made in the last build is to provide a handshake at the start to assure that xapmcsRoleMonitor sees the initial role message. This is the design:

For up to 10 following startup, mcsSprinklers will send a role query message to xapmcsMonitorRole. It after 10 minutes a role notificaiton has not been seen by mcsSprinklers it will provide a notification through standard notification mechanism.

xapmcsMonitorRole continues to look for the first role message from mcsSprinklers. If after 10 minutes it has not seen one then it will provide a popup to this effect with some options to select from.

You expect to get the xapmcsMonitorRole message if the Test button has been activated before the first mcsSprinkler role message has been delivered. It can take up to 5 minutes to deliver the first role message.

To effectively do the test you need to keep the xapmcsHub window open or use an xAP Message Viewer and wait for the role message from mcsSrinklers. After it is seen then use the Test button. You could also just wait morre than 5, but less than 10 minutes to press the Test button. After about 10 more minutes then xapmcsMonitorRole will do its restart thing.

If you continue to see the popup from xapmcsMonitorRole after following this procedure then it means initial communication between these two applications has not occurred. If, for example, the hub is not running then you expect to receive notification from both applications.

[bunkers]

Thanks a lot for that explanation. Now I understand!!

I tried the time based syringing today and it worked perfectly. I'm going to try the temperature based tomorrow, but I suspect it'll work also.

[Michael McSharry]

Cecil,
I looked at your log and see the use of ]20 as the source at 10:35. Before that what surprises me is the use of }20 as the source.

When }20 is used the input for the daily cumulative ET is 0. When ]20 is used the input is 0.01.

What I expect is that if the ET sensor is left blank on the Other page then the logic path which produces the "ET Source=" would not be executed. Does the }20 device mean anything to you?

The ET updates on General Status are done at 7 past the hour. If the input data is the same then it will look as if an update did not occur. If you have a log for a period of a couple hours with ET from Davis changing and mcsSprinklers using this input then I'd like to see it.

[Michael McSharry]

Doug,
When trying to use the netiom serial port then select the Rain8Net source to be "External via XAP Serial". In the text box put in the xap target address of the netiom without the subaddress. (e.g. vendor.product.instance)
On the Other Page select the Xap to include Basic Status and Control to be enabled.

When mcsSprinklers tries to control a valve it will send a message such as

xap-header
{
v=12
hop=1
uid=FF000900
class=xapbsc.cmd
source=mcs.mcsSprinklers.MCS5
target=mcs.netiom.xyz:SerialPort.Out
}
output.state.1
{
state=on
text=!400142
}

It is expecting a return message from subaddress SerialPort.In, text field with the data from the Rain8Net. It ignores the state key in the received message. For example:

xap-header
{
v=12
hop=1
uid=FF003900
class=xapbsc.event
source=mcs.netiom.xyz:SerialPort.In
}
input.state.1
{
state=on
text=!400142
}

Set the netiom wait time between character received and its transmission via xAP to a low value. The Rain8Net sends 3 bytes at a time so I would set the timeout to be something like the time it takes to receive 6 bytes at 4800 baud. This will result in a single xAP message for each transaction.

I have a timeout-retry set to the same as with the TCP connection for the Rain8Net which is 1 second. This means if the netiom does not turn around the status response from the rain8net within 1 second of the command, then mcsSprinklers will retransmit. I think it will be 10 retries before it gives up.

Note the section title of the message is output.state.1. Some vendors use output.state if there is only one section in the body. It is not per the xAP spec, but it is done anyway. mcsSprinklers will accept inputs using input.state or input.state.1.

I have tested the command going out, but I did not do any testing for the incoming data from the netiom. If there is a problem then I will add some debug code.

[Cecil]

Michael,

The "}20" was an error in my typing when I was trying various start/stop options to see if I could figure out what was going on. The "]20" is the correct input source.

The day is just starting to heat up here in South Carolina, so ET should start increasing soon. I'm going to set the ET sensor to "]20" now and should have several hours of data by early afternoon EDT.

Cecil

[Cecil]

ET Logs and a Theory

Micheal,

Attached are three log files - end of day on 7/26, start of day on 7/27 and new log after re-start to install .229 on 7/27. I spent some time looking at them and think I may have discovered the "problem."

The last ET entry in the 7/26 log is..."7/27/2006 12:00:03 AM | mcsSprinklers Debug | ET Source=]20, Hour=23, sCurrent=0, nCumulative=0, nCurrent=0.13, Change=False,String=0.13". This entry shows the cumulative ET for the new day (now 7/27) set to zero.

The first entry in the 7/27 log is ..."7/27/2006 12:04:09 AM | mcsSprinklers Debug | ET Source=]20, Hour=23, sCurrent=0, nCumulative=0, nCurrent=0.13, Change=False,String=0.13". Nothing appears to have changed.

However, at the 12:05:09 mark, a change takes place as cumulative ET is set back to the current value..."7/27/2006 12:05:09 AM | mcsSprinklers Debug | ET Source=]20, Hour=0, sCurrent=0.13, nCumulative=0.13, nCurrent=0.13, Change=True,String=0.13." It would appear that the old end of day ET value is still being used by the sensor at this point.

Then about 20 seconds later at 12:05:30, it appears the sensor reading is updated..."7/27/2006 1:05:30 AM | mcsSprinklers Debug | ET Source=]20, Hour=0, sCurrent=0, nCumulative=0.13, nCurrent=0, Change=True,String=0". However, it is too late now as MCS already has set todays cumulative ET to 0.13. So no current value of less than 0.13 will ever cause a change (if I"m deducing the logic correctly).

Nothing then changes in any of the ET log entries until the ET sensor now reflects a reading of greater than zero. This at 10:07:41..."7/27/2006 10:07:41 AM | mcsSprinklers Debug | ET Source=]20, Hour=0, sCurrent=0, nCumulative=0.13, nCurrent=0.01, Change=False,String=0.01" As anticipated as the ET value is less than the cumulative ET, no change occurs.

After looking at all this data, I investigated the time of my computer clock versus the weather station clock. The weather station clock was 8 minutes behind the computer clock. This could potentially explain the cause of the error. MCS sets the cumulative ET to zero at midnight (computer time). The weather station sets the cumulative ET to zero at midnight (weather station time). The eight minute difference would mean that after MCS reset at midnight any reading of the HS ET sensor for the next eight minutes would still get yesterdays cumulative ET value.

I've synchronized both clocks and will monitor into the evening to make sure they stay very close together. Will let you know tomorrow morning if the synchronization made any difference or not.

Cecil

[ka7gzr]

Cecil,
I notice your "hour" always reads "-1". My hour cooresponds to the time. eg 10:00 AM reads "10", 1:00PM reads "13".
Jim

[Cecil]

I noticed that also. Was thinking that perhaps it never changed because MCS never saw a need to calculate the hourly ET as the sensor ET never climbed above the stored cumulative ET.

Of course, my entire theory could be all wet and it could be something else entirely is causing the problem. :-)

Cecil

[Michael McSharry]

Cecil, I suspect you are correct.

At xx:00:00 through xx:04:59 mcsSprinklers ignores the input. This gives a 5 minute buffer to allow the source data to stabalize on the hour transition. If the hour is 00 during these first 5 minutes of the hour then it will force the cumulative to 0 and the hourly to 0.

At xx:05:xx or later it will accept the *** reading from the sensor (nCurrent) and determine the delta from the prior hour to determine the hourly value (sCurrent). It also captures the current *** ET (nCumulative) from the sensor.

At xx:07:xx it will capture the hourly ET, update General Status devices, and take a snapshot of all sensors and place them in the database.

In your case at 12:05:09 mcsSprinklers believes the inputs source has stabalized and captures the 0.13 as the daily cumulative. On the original design this would not have been a problem, but when integrating with ka7gzr we saw some *** ET values of 0 interspersed with the good readings and if it this reading happened at xx:05:xx it was a problem because it would look like the following hour had a very big ET change. To overcome this mcsSprinklers only accepts larger ET values throughout the day.

At the 12:05:30 update the input of 0 is discarded because it is lower than the 0.13 from the 12:05:09.

Another thing I can do is to force values of 0 for the 00:xx:xx period. This way the clock can drift up to 60 minutes before there is a problem rather than 5 minutes causing a problem. I'll have this change in the next build.

[Cecil]

At about 5:45 today, the ET sensor reading in HS reached 0.14. Sure enough at 6:07, mcsSprinklers updated it's ET device to 0.14. The hour also changed appropriately. If I remember my math correctly (been a long time), then the hourly value calculated of 0.01 would also be correct as mcsSprinklers thought the previous cumulative ET was 0.13.

Here's the log entry..."7/27/2006 6:08:49 PM | mcsSprinklers Debug | ET Source=]20, Hour=18, sCurrent=1.000001E-02, nCumulative=0.14, nCurrent=0.14, Change=True,String=0.14"

Looks like it has been a timing problem all along.

Cecil