UPB Interface device

[KLS]

What device is used to connect the HomeSeer computer to the powerline?

Like the TW523 or CM11A that are used for X10.
Thnaks.

[Michael McSharry]

It is call a PIM (Processor Interface Module). Sells for around $100 from AutomatedOutlet.com

[Oman]

The price on many UPB devices has been dropping. The PIM (only available in serial right now, USB coming some day) is $69.99 from Automated Outlet.

1000Watt dimmers are $75.00. For about $90 you can get a switch that also has up to 8 buttons on it, with a removable faceplace that lets you choose all kinds of configurations. I wish it had backlit buttons but then they would not be able to make it have the different faceplates.

They also have IO modules that do voltage sense, doorbell ring sense, telephone ring sense, and 2 relay outputs (all in one device)

Jon

What device is used to connect the HomeSeer computer to the powerline?

Like the TW523 or CM11A that are used for X10.
Thnaks.

[wuench]

It is call a PIM (Processor Interface Module). Sells for around $100 from AutomatedOutlet.com

Does any brand of PIM work with the plug in? i.e. PCS, SimplyAutomated

[Michael McSharry]

I suspect. I use the Simply Automated product with xapmcsUPB and a serial connection. I used the documentationn from PCS to program it which makes me think the PIM needs to comply with the PCS standards. I think the HST plugin uses the serial interface as well.

[Oman]

Yes, they should all work. However I have been able to confirm a bug in the SimplyAutomated PIM that causes the unit to report that an ACK was not received from the receiving device even though it actually was.

This eliminates the possibility of having HomeSeer re-send the command if the receiving device did not get it.

This functionality is planned for the next update of the UPB plug-in but it won't work with the SA PIMs. The PCS PIMs have been confirmed to work properly. I have not had a chance to test any other PIMs yet.

Jon

I suspect. I use the Simply Automated product with xapmcsUPB and a serial connection. I used the documentationn from PCS to program it which makes me think the PIM needs to comply with the PCS standards. I think the HST plugin uses the serial interface as well.

[rocco]

This eliminates the possibility of having HomeSeer re-send the command if the receiving device did not get it.

Jon, does it? Does it hurt to send the command again, even though it was received correctly the first time? It may be redundant sometimes, but does it screw anything up?

[Oman]

Jon, does it? Does it hurt to send the command again, even though it was received correctly the first time? It may be redundant sometimes, but does it screw anything up?

If the PIM indicates that the receiving device did not get the command, the plugin will resend the command. Then the PIM will indicate that the receiving device did not get the command again, and the plugin will resend the command. This will happen until the maximum number of retries is exhausted. Then the plugin will not update the device status for the receiving device because the receiving device never got the command and the UPB bus was busy over the last several seconds trying to get this one command out.

That is all bad.

Unlike X10 the UPB format is designed to be round-trip capable. That means that a sending device is supposed to be able to confirm that the receiving device actually got the command. This greatly increases the robustness of the protocol. Unfortunately right now this capability is not being used because of the bug in the SA PIM.


I also found out that the SA PIM is not field-programmable so they can't send out a firmware update to fix it.

[Michael McSharry]

I'm using the ACK/NAK status indications with the Simply Automated PIM and I have seen a combination of NAK and ACK as well as auto retries. I've using messages that use the single frame pulse ACK/NAK. I felt that the pulse from the target module as the ACK/NAK was adequate for me to have confidence that the command was received. I do send status request messages for the situations where I use links that command activate/deactivate as well as delayed status requests for fade operations so I will know what the activate level and deactive level is actually programmed in the module. It really is just a confirmation that what I have read from the upstart export file is really what the level is.

Jon, what type of handshake did you find would not work with you SA PIM?

[Oman]

I'm using the ACK/NAK status indications with the Simply Automated PIM and I have seen a combination of NAK and ACK as well as auto retries. I've using messages that use the single frame pulse ACK/NAK. I felt that the pulse from the target module as the ACK/NAK was adequate for me to have confidence that the command was received. I do send status request messages for the situations where I use links that command activate/deactivate as well as delayed status requests for fade operations so I will know what the activate level and deactive level is actually programmed in the module. It really is just a confirmation that what I have read from the upstart export file is really what the level is.

Jon, what type of handshake did you find would not work with you SA PIM?

[Michael McSharry]

I'm in message mode as well and my ACK response is quite reliable with the Simply Automated PIM. It may be a manf flaw rather than a design flaw with your SA PIM.

[Oman]

Could you do a register dump on the PIM? I've confirmed it to be a problem with several SA PIMS with firmware 4.21. Powerline Control Systems also got some to test and found the problem as well. What is the firmware version of the one that is working? Maybe they broke something in an update. It would be nice if they were flashable.

Thanks
Jon

I'm in message mode as well and my ACK response is quite reliable with the Simply Automated PIM. It may be a manf flaw rather than a design flaw with your SA PIM.

[Michael McSharry]

My PIM is version 4.15. I'm not setup to dump the registers. Here is my startup sequence and a light control.

Sent to PIM <17>70 03 8D <0D> <2005-09-24 20:58:55 75535.86>
PA <20:58:55 75535.94><try 1>

Sent to PIM <14>07 10 01 03 FF 30 B6 <0D> <2005-09-24 20:58:55 75535.94>
PA <20:58:56 75536.03>
PK <20:58:56 75536.24>
PU080001FF03864629 <20:58:56 75536.47><try 1>

Sent to PIM <14>07 10 01 02 FF 30 B7 <0D> <2005-09-24 20:58:57 75537.47>
PA <20:58:57 75537.51>
PK <20:58:57 75537.66>
PU080001FF02860070 <20:58:57 75537.86><try 1>

Sent to PIM <14>07 10 01 01 FF 30 B8 <0D> <2005-09-24 20:58:58 75538.86>
PA <20:58:58 75538.9>
PK <20:58:59 75539.05>
PU8904010001860600E5 <20:58:59 75539.29>
PU8905010001860600E4 <20:58:59 75539.45><try 1>

Sent to PIM <14>07 10 01 00 FF 30 B9 <0D> <2005-09-24 20:59:00 75540.45>
PA <20:59:00 75540.58>
PK <20:59:00 75540.63>
PU8905010001860600E4 <20:59:01 75541.04>
PU080001FF03864629 <20:59:01 75541.26><try 1>

Sent to PIM <14>87 10 01 82 FF 20 C7 <0D> <2005-09-24 20:59:21 75561.36>
PA <20:59:21 75561.48>
PK <20:59:21 75561.77><try 1>

Sent to PIM <14>07 10 01 03 FF 30 B6 <0D> <2005-09-24 20:59:31 75571.77>
PA <20:59:31 75571.83>
PK <20:59:32 75572.13>
PU080001FF0386006F <20:59:32 75572.58><try 1>

Sent to PIM <14>87 10 01 81 FF 20 C8 <0D> <2005-09-24 21:00:33 75633.89>
PA <21:00:33 75633.97>
PK <21:00:34 75634.27><try 1>

Sent to PIM <14>07 10 01 03 FF 30 B6 <0D> <2005-09-24 21:00:44 75644.27>
PA <21:00:44 75644.36>
PK <21:00:44 75644.64>
PU080001FF03864629 <21:00:45 75645><try 1>

Sent to PIM <14>87 10 01 83 FF 20 C6 <0D> <2005-09-24 21:00:53 75653.08>
PA <21:00:53 75653.16>
PK <21:00:53 75653.47><try 1>

Sent to PIM <14>87 10 01 82 FF 20 C7 <0D> <2005-09-24 21:00:53 75653.47>
PA <21:00:53 75653.58>
PK <21:00:53 75653.91><try 1>

Sent to PIM <14>07 10 01 02 FF 30 B7 <0D> <2005-09-24 21:01:03 75663.47>
PA <21:01:03 75663.56>
PK <21:01:03 75663.84>
PU080001FF02864B25 <21:01:04 75664.25><try 1>

Sent to PIM <14>07 10 01 03 FF 30 B6 <0D> <2005-09-24 21:01:06 75666.25>
PA <21:01:06 75666.33>
PK <21:01:06 75666.63>
PU080001FF0386006F <21:01:07 75667.03>

[Oman]

I'm glad you have a different firmware version, it looks like they messed it up in 4.21.

Here is what I get...

9/24/2005 11:20:21 PM - UPB - PIM<--Sending 0A103201FF220001019000 to PIM (Try # 1)
9/24/2005 11:20:21 PM - UPB - PIM-->Received PIM Accept
9/24/2005 11:20:21 PM - UPB - PIM-->Received PIM NoAck

9/24/2005 11:20:22 PM - UPB - PIM<--Sending 0A103201FF226401012C00 to PIM (Try # 1)
9/24/2005 11:20:22 PM - UPB - PIM-->Received PIM Accept
9/24/2005 11:20:22 PM - UPB - PIM-->Received PIM NoAck

I have it setup to ignore the fact that it got a NoAck rather than an Ack. If you decode the message it should be requesting a pulse ack.

The PCS PIM works fine with the same commands, giving me an Ack back in all cases (unless I unplug a module :?)

I'll have to talk to SA AGAIN and see if I get get to the bottom of this.

My PIM is version 4.15. I'm not setup to dump the registers. Here is my startup sequence and a light control.

[Michael McSharry]

I've found SA to be one of the better companies that I have dealt with for customer support. Maybe they will give you a finders fee for locating the snafu in the firmware upgrade.