Announcement

**Richard** · July 23, 2013, 06:52 PM

2 screen shots to include.

2 screen shots to include. Shows all the HS devices.

**Michael McSharry** · July 23, 2013, 07:42 PM

I suspect that the firmware in this unit has no operating options and is designed to talk only using the proprietary protocol known by the host PC driver. I have seen this on other low end units in the same price range.

As indicated before mcsSprinklers will communicate with the IP/Serial device with no protocol wrapper. One byte sent by TCP will be expected to be put on the RS-232 output without interpretation. One byte received on RS-232 UART will be delivered via TCP back to mcsSprinklers.

The high CPU utilization with the driver is likely a result of poor design by a hardware manufacturer rather than a supplier that is focused on system operation. It could also be some setup assumptions that are not correct, but I have no experience or visibiltiy with this specific product.

If it turns out that the unit is operating in a RAW mode with no protocol, then the mcsSprinklers setup would be on the line where the COM port is now defined. 24 would replace the COM port number and the IP of the unit (e.g. 19.168.0.10) would go into the IP checkbox. You will see the same traffic with 3 bytes out and 3 bytes in in the Serial IO log if the unit functions in this mode. I suspect that the COM emulation driver would need to be uninstalled to try it because this driver has already claimed connection to port 24. You could setup the unit to use something other than port 24 and have mcsSprinklers to that same alternate port. That way you would not need to mess with the COM driver. The driver may not be happy becuase the hardware it is talking to has disappeared, but this will at least allow you to test.

**Richard** · July 23, 2013, 09:42 PM

Reply

Thanks for the information, the mcpu.exe program appears to be a 32 byte compile, at least some on the internet think that might be behind the load?

I have the setting "acknowledge after command" selected.

What is the best way to determine if communication is passing from a log?

When I move over to mcsSprinkler to serial /IP, and talking about the units you are familiar with, (what hardware types are these?) what settings would need to be configured for these to communicate? ..... I have configured telnet over to ports with other applications, is that the communication that mcsSprinkler uses?

It seems that the mcsSprinklers plugin heals and restarts in some time period? What timer / or process, sets and then clears the communication failing or being established? I have seen valves marked "failed" red indicator, but then get marked " Status: Within Last 24 Hrs" with a blue indicator. This was when I was making com port changes. Do I have to stop and restart the plugin?

Also I am going to separate some drip irrigation valves that will run daily instead of the lawn type cycles. So I will use it's own area and make it a daily or daily with ET if possible, correct?

Thanks again for a powerful irrigation control.

Richard

**Michael McSharry** · July 24, 2013, 04:15 AM

The name most often used for the "protocol" is Raw. There is no protocol. It is simply a byte for byte transfer in both directions just as if it was a wire connected between PC and RS-232 device. I have used Lantronix and Qualtech units. I have some Lantronix units built in the early 1990's and they seem to use the same core firmware for their more modern units. I know several others that have been successfully used in Raw mode over the years. Only recently have I seen units that do not support it and this change also correlates with sell prices under $100 for new units.

What you posted showing the byte by byte commands in both direction is the best place to look if communications are good. A lack of communicaiton will show up as timeout lines in that list.

mcsSprinklers has developed heuristics based upon user field experience on communicaiton failure modes and data inconsistencies. In general it assumes communication out was successful and the failure is in the reporting by the device. This means every time a scheduled (or manual) valve control is needed it will "heal". The failure indication is for notification and does not affect the scheduling. Of course if there is a communication failure the valves will not actually open and close.

Allocating your drip zones to new area will allow the desired scheduling.

Announcement

Further down the road mcsSprinklers

Further down the road mcsSprinklers

Comment

Comment

Comment

Comment