Announcement

**Michael McSharry** · December 20, 2015, 06:09 PM

I think the PIM is configured to be in pulse rather than message mode. Pulse mode is used by Upstart, but applications such as mcsSprinklers use message mode. The serial PIM comes from the factory in message mode. Never have looked at USB PIM, but should have the capability to set it back to message mode by setting it back to factory defaults. Documentation with the PIM should describe how to do this.

**pete@malibubeach.com** · December 20, 2015, 10:43 PM

Thanks Michael---sounds right as the only thing I have ever used this PIM for is UPstart. I'll figure out how to get it back in message mode and let you know if I have any problems.

**spud** · December 21, 2015, 08:04 AM

Originally posted by pete@malibubeach.com View Post

Thanks Michael---sounds right as the only thing I have ever used this PIM for is UPstart. I'll figure out how to get it back in message mode and let you know if I have any problems.

FYI, the UPBSpud plugin sets the PIM in message mode everytime it starts, I'm not sure if it is persistent or not, but you could try it.

**Pete** · December 21, 2015, 09:18 AM

@Pete,

Curious what is the second UPB Pim that you are using?

I am guessing too that you know that the PCS and the SA USB PIM are totally different.

The PCS PIM is a true USB to serial thing while the SA USB PIM is using a unique SA only set of USB drivers.

I have one of the SA USB PIMs here today (aside from multiple serial PIMs).

**pete@malibubeach.com** · December 21, 2015, 12:21 PM

I have the UPB plug-in talking to an HAI USB PIM (and that has worked fine for a long time). The MCSSprinklers is talking to the PCS PIM-U. Both are just using a standard USB to serial driver. I reset the PCS PIM to factory default settings, following their instructions. I also tried switching the PIMs. In both cases, the UPB plug-in seems to work okay; MCSSprinklers is much better now but not perfect. I still get the same error message; but before I reset the PIM the error occurred several times per second. Now it is occurring only once every minute or two---this is tolerable.

**pete@malibubeach.com** · December 21, 2015, 12:26 PM

Still have problem

It looked good---it just turned on one of the Rain8UPB zones on schedule. The sprinkler went on, but there is a message in the log

Dec-21 9:20:55 AM mcsSprinklers Zone R19 has been declared failed after multiple attempts due to timeout in expected response

So I guess MCSSprinklers does not know the valve is on, and then there is no attempt to turn off the sprinkler 5 minutes later. It went off by itself based on the default timeout programmed into the Rain8. Could be repeated collisions since the UPB plug-in is still doing its initialization (which sends a lot of messages).

This is not great, but tolerable if MCSSprinklers will try it again in two days on its next scheduled run time

**Michael McSharry** · December 21, 2015, 01:21 PM

Can you provide the IO log so the communication stream can be observed? The failure report means that a status response was not received from Rain8UPB. Are you setup in mcsSprinklers to poll status or to request status after command?

During initialization mcsSprinklers does send hex bytes 70 and 03 to try to set the mode. Again don't know of difference between serial and USB PIMs.

**pete@malibubeach.com** · December 22, 2015, 01:02 PM

Michael,
Here is an Excel file with your log on one tab and the HS log for the corresponding period on another tab. All of the errors seem to occur during a period of UPB activity (no real surprise, I guess). I had the UPB plugin log running at debug level for the duration of this.

Attached Files

MCS logs.zip (196.4 KB, 2 views)

**Michael McSharry** · December 22, 2015, 03:02 PM

I decoded the first set of what looked like Rain8UPB commands. ON command sent, the two PIMs respond as expected (PA & PN). STATUS REQUEST sent, but no response from Rain8UPB. mcsSprinklers retries the STATUS REQUEST four times and then will declare a failure. Other UPB traffic existed, but not traffic from Rain8UPB.

Since you reported the valve was actually controlled the problem appears to be on the Rain8UPB through PIM on ability of Rain8UPB to report its state. I don't have any specific suggestions. I believe the test utilities provided by WGL provide ability to command, but they do not have ability to evaluate the state response. I do have both a Rain8UPB and Rain8UPB PRO hardware for testing and both do function with status response using serial PIM from SA and HAI.

@9:20:03 08001B5BFF2264FD ON command sent
NID = 1B
DID = 5B
SID = FF
MDID = 22 (goto)
ARG = 64 (level 100%)

@9:20:03 PA ack from PC PIM
@9:20:03 PN ack from Rain8UPB PIM

@9:20:13 07001B5BFF3054 STATUS REQUEST command sent
MDID = 30 (report state)

@9:20:23 PU07141B0DFF308E ... not Rain8UPB data

@9:20:23 07001B5BFF3054 STATUS REQUEST command retry sent

@9:20:45 PU08001BFF0D86004B
SID = 0D (not Rain8UPB)
MDID = 86 (state report)
ARG = 00 (likely off for something)

[Revision]
I took a look at the HS log on the other tab and found the following which is the Rain8UPB response that was expected. The question now is why did the PIM connected to HS see the Rain8UPB status and the PIM connected to mcsSprinklers not see it. It seems the issue is isolated to this PIM.
DEBUG PIM_RCVR:: Received UPB command [PU08001BFF5B866499]

**pete@malibubeach.com** · December 24, 2015, 08:13 PM

Thanks Michael,
It seems to be more or less working. Still getting the occasional error messages that you can see in the Homeseer log (for no reason that is obvious to me). But they are relatively infrequent. I think it is all tolerable at this point. The two PIM'[s are plugged in adjacent to each other, so it is a little surprising that one saw the response and the other did not.

Announcement

Error messages with Rain8UPB

Error messages with Rain8UPB

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment