SA PIM - what's the real story on confirmation of commands?

[JKaplan]

Oman -

I'm still a bit confused about where this stands. I think you posted a 'fixed' version of the plug-in that somehow worked around or corrected the lack of proper ACK from the SA PIM? What exactly does this mean?

* When the plug-in is talking to the SA PIM, does the SA PIM confirm back to it that the controlled device received and executed the command?

* Or, are you just assuming that the command got executed?

* Or, are you recommending that we set the plug-in to 'retransmit' the command several times to increase the probability of success?

* If I do set the 'retransmit' parameter in the plug-in to more than 1, does this increase traffic on my power lines, and/or is it possible that the command gets executed twice?

* Does the PIM itself, independent of your plug-in, monitor the power line for a confirmation of command execution from the devices and resend if none is forthcoming?

My goal: determine if I should swap out the SA PIM that I have for a PCS PIM (I have to send some other stuff back to the retailer today, so I can include this item as well.)

Thanks,

Jerry

[Michael McSharry]

The SA PIM that you have is the same version as the SA PIM that I use and it properly generates the ACK/NACK bit. I would not return it based solely on this criteria.

I'm not tracking versions of the UPB Plugin, but I believe that the initial release ignored the ACK/NACK because the SA PIM 4.2.x did not process it correctly. I never knew that a problem existed with the 4.2.x firmware so xapmcsUPB does process it and gives up to three retries if either the ACK is not received or a NACK is received.

[Oman]

The issues have been worked out. There is a slight difference in the way the PCS PIM and the SA PIM process commands. There is nothing wrong with either of them, but the plug-in needed to change a bit to work properly with both. The new build should be posted this week.

This is the way it works: UPB has the ability to send multiple copies of the same message such that the messages are seen as a single command. With X10 commands are always repeated a few times over but the way UPB does it is more sophistocated. The plug-in allows you to send multiple copies just in case you have a device with borderline reception. This is one method of improving reliability.

There is also an option to retry when the receiving device does not respond to the transmitted command. This is what is slightly different with the PCS and SA PIM. They both work fine now and one is no better than the other (as far as I can tell).

If you have a borderline device you can use one or both of these options to make sure the device works 100%. There are several reasons that these are options and not just "on".

The multiple transmission option will increase the amount of "time" that a single UPB command is taking up. It will not decrease or increase the response time of the receiving device but it does make more traffic.

The retry option would generally be on unless you have devices that might not respond in normal use. Some users have "switch on a switch" situations where the controlled device might sometimes be turned off at a more centralized switch and thus would not respond in all cases. The plug-in will try to send the command 5 times. While this command is being re-tried no other commands can go out and this could cause a delay.

For most systems a single transmission with retry is a good setting. If you see a few retries in the log you could bump it up to two transmissions and retry. Before I installed my coupler I needed two transmissions to assure 100% reliability.

Oman -

I'm still a bit confused about where this stands. I think you posted a 'fixed' version of the plug-in that somehow worked around or corrected the lack of proper ACK from the SA PIM? What exactly does this mean?

* When the plug-in is talking to the SA PIM, does the SA PIM confirm back to it that the controlled device received and executed the command?

* Or, are you just assuming that the command got executed?

* Or, are you recommending that we set the plug-in to 'retransmit' the command several times to increase the probability of success?

* If I do set the 'retransmit' parameter in the plug-in to more than 1, does this increase traffic on my power lines, and/or is it possible that the command gets executed twice?

* Does the PIM itself, independent of your plug-in, monitor the power line for a confirmation of command execution from the devices and resend if none is forthcoming?

My goal: determine if I should swap out the SA PIM that I have for a PCS PIM (I have to send some other stuff back to the retailer today, so I can include this item as well.)

Thanks,

Jerry

[JKaplan]

Thanks for the clarification.

So if I understand you correctly, I should set the "Number of Transmissions" on your UPB Plugin Configuration screen to "1 ...".

This way, if I check the "Resend UPB command if no acknowledgement is received" checkbox, the plugin will automatically attempt some number of retries (5?) if it doesn't get a proper ACK from the device, but then stop trying.

In the unlikely event that some device still doesn't respond even after the retries, I can increase the "Number of Transmissions" parameter, which will repeat the whole process above, but this will happen for ALL UPB commands even if they have been properly ACK'ed - which won't alter the behavior of the devices, but wastes time transmitting on the power line.

While I have your attention, may I ask a few more questions?

1. "LED Tracking is enabled on PCS keypads in UPStart" checkbox: I don't have any such pads, so I don't think this option appears for me in UPStart and I'm not sure what this is about. I've left this checked, I assume that's OK.

2. "Reset keypad LEDs at startup so that they are in-sync with HomeSeer" - same story.

3. One thing I don't get about the Links: Why is there an 'activate' and 'deactivate' command? More precisely, what does 'deactivate' mean? If a switch is (say) at 50% dim, and you 'activate' a link in which it participates to turn off, what's supposed to happen when you 'deactivate' the link? Should it go back to 50% dim? Why wouldn't you just have a link that (for example) turns a bunch of lights on, and another that turns them off? In other words, what's the negation of an activation?

4. You mention in another post... "SetDeviceValueByName "Livingroom Light Link", 1, Where 1 is activate, 2 is deactivate, and so on down the list."

What's the rest of the list? This must be documented somewhere that I don't know about?

5. In HS, the UPB devices show up as "apostrophe number". It looks like I'm supposed to refer to them in scripts as "dollarsign number"? Or preferably, by device name?

6. Is the blink UPB function available through HS, either through the web interface or in scripts? It's not a big deal, just curious.

Thanks for you help,

Jerry

[Oman]

So if I understand you correctly, I should set the "Number of Transmissions" on your UPB Plugin Configuration screen to "1 ...".

Yes. Generally this is good for most installations.

This way, if I check the "Resend UPB command if no acknowledgement is received" checkbox, the plugin will automatically attempt some number of retries (5?) if it doesn't get a proper ACK from the device, but then stop trying.

Yes.

In the unlikely event that some device still doesn't respond even after the retries, I can increase the "Number of Transmissions" parameter, which will repeat the whole process above, but this will happen for ALL UPB commands even if they have been properly ACK'ed - which won't alter the behavior of the devices, but wastes time transmitting on the power line.

Generally if the plug-in tries 5 times and you get nothing then increasing the number of transmissions won't help. It is if you see any retries then increasing the number of transmissions might help.

While I have your attention, may I ask a few more questions?

1. "LED Tracking is enabled on PCS keypads in UPStart" checkbox: I don't have any such pads, so I don't think this option appears for me in UPStart and I'm not sure what this is about. I've left this checked, I assume that's OK.


2. "Reset keypad LEDs at startup so that they are in-sync with HomeSeer" - same story.

It is fine to leave this setting alone if you don't have any keypads

3. One thing I don't get about the Links: Why is there an 'activate' and 'deactivate' command? More precisely, what does 'deactivate' mean? If a switch is (say) at 50% dim, and you 'activate' a link in which it participates to turn off, what's supposed to happen when you 'deactivate' the link? Should it go back to 50% dim? Why wouldn't you just have a link that (for example) turns a bunch of lights on, and another that turns them off? In other words, what's the negation of an activation?

Links serve two purposes; scenes and groups. Activate and Deactivate are like "Set to scene" and "Scene Off". The lights will go to their preset levels for that link at their preset rates. You also get On/Off/Dim controls for the lights associated with the link.

4. You mention in another post... "SetDeviceValueByName "Livingroom Light Link", 1, Where 1 is activate, 2 is deactivate, and so on down the list."

What's the rest of the list? This must be documented somewhere that I don't know about?

The list is the list as you see it on the HomeSeer interface for the links. It starts with activate.

5. In HS, the UPB devices show up as "apostrophe number". It looks like I'm supposed to refer to them in scripts as "dollarsign number"? Or preferably, by device name?

Each installation will have its own house code for the UPB devices. Substitute the house code in your system.

6. Is the blink UPB function available through HS, either through the web interface or in scripts? It's not a big deal, just curious.

The blink and restore level commands are available on the newest build of the plug-in, but only for links.

Thanks for you help,

Jerry

No problem.

[JKaplan]

House code for UPB devices?

OK, I think I've got the links figured out. The main problem was that I couldn't find anything about them in the HS interface, but it turns out that's because I hadn't defined any links yet in UPStart. So I defined one, and sure enough, links show up as a 'location' under "Status", with the list of commands as you indicated.

So links work 2 ways:

1. You preset (program) a light level, fade rate, etc. into each device referenced in the link. When you send an 'activate' command, the devices execute that preset. When you send a 'deactivate' command, the devices basically just turn off their loads - probably at their default fade rate, if any.

2. You can issue a link number with several other commands, such as "blink", and all the devices programmed with that link number will blink, ignoring the preprogrammed preset value for that link.

Each installation will have its own house code for the UPB devices. Substitute the house code in your system.

Sorry to be so thick, but I don't get this. I have a UPB Network Name, Network ID, and Network Password. I don't see anywhere where a house code (A-P?) gets assigned to the UPB devices in HS. Where the house code normally appears for X-10 devices in the "Device List", i.e. "P9", I get "'2" (for example) for UPB devices.

Where am I supposed to find out what house code is assigned?

Jerry

[Oman]

Yes - you are dead on with links.

Look at the "CODE" column when you are looking at the HomeSeer devices. X10 ones look like "A1", etc.

UPB ones will have a code like "$", or "}", or similar. There is a code for every device. Just look along the device row. X10 house codes use A-P but since UPB devices are not X10 they can (and do) use the extended house codes that HomeSeer supports.

OK, I think I've got the links figured out. The main problem was that I couldn't find anything about them in the HS interface, but it turns out that's because I hadn't defined any links yet in UPStart. So I defined one, and sure enough, links show up as a 'location' under "Status", with the list of commands as you indicated.

So links work 2 ways:

1. You preset (program) a light level, fade rate, etc. into each device referenced in the link. When you send an 'activate' command, the devices execute that preset. When you send a 'deactivate' command, the devices basically just turn off their loads - probably at their default fade rate, if any.

2. You can issue a link number with several other commands, such as "blink", and all the devices programmed with that link number will blink, ignoring the preprogrammed preset value for that link.




Sorry to be so thick, but I don't get this. I have a UPB Network Name, Network ID, and Network Password. I don't see anywhere where a house code (A-P?) gets assigned to the UPB devices in HS. Where the house code normally appears for X-10 devices in the "Device List", i.e. "P9", I get "'2" (for example) for UPB devices.

Where am I supposed to find out what house code is assigned?

Jerry

[JKaplan]

See attached screen shot...

OK, so if you look at the picture, the third device down, for example, has house code "`" and device code "2".

(I didn't know I had a ` on my keyboard, but there it is right under ~. I don't even know if this character has a name!)

If I wanted to refer to this in a script, I could write, for instance:

hs.Exec10 "`2", "ON"

...but the prefered method would be...

hs.Exec10byname "Garage Main Room", "ON"

To activate a link, I could write:

hs.SetDeviceValue "#1", 1

to activate link 1 (the #1 isn't in the screen shot, but trust me that's what's in the Code column of the the Device List screen under location "UPB Device Link")

...but the preferred method would be...

hs.SetDeviceValueByName "Test Link", 1

Have I got this right?

Jerry

[Oman]

You can choose if you want to use the device code or the location/device name. Generally the device codes will stay the same unless you delete or heavily edit devices in UPStart.

Many people over-use scripts when events would work better. See if you can make events work for your needs first.

[DC]

I have been unable to find any logic behind how HS assigns device codes to UPB devices. A change in UPStart can result in device codes being assigned differently in HS. For this reason, I don't see how you could ever use device codes in HS scripts with any confidence that you are controlling the device you think you are.

Generally the device codes will stay the same unless you delete or heavily edit devices in UPStart.

I have seen the device code change simply by deleting the device (from HS only) and then restarting HS to reimport the device definition from UPStart.

[Oman]

Device codes are assigned in order that they appear in the UPStart database. Then when a change is made in the UPStart database that changes the device order or number an attempt is made to re-associate the devices so that usually the code is preserved. Changing the location or name of the device, the links or transmit options should not cause the device code to change. Changing the UPB ID in UPStart of a device is a fundimental change that will cause the plug-in to regenerate the device code. The UPB device ID and the HomeSeer device code are not forced to match because they have different ranges. Some versions of UPStart actually started some devices at a higher ID number than HomeSeer can support as a device code.

Adding a new device should not cause any other devices to change their device code. The same should be true of deleting. When the plug-in has to rebuild the HomeSeer devices because of an UPStart change new devices are added first before old (now unused) ones are deleted.

So if your exising database is:

UPB 1 HomeSeer $1
UPB 2 HomeSeer $2
UPB 3 HomeSeer $3

and then you delete UPB 2 and add a new device UPB 4 at the same time in UPStart you will get:

UPB 1 HomeSeer $1
UPB 3 HomeSeer $3
UPB 4 HomeSeer $4

and then you add UPB 5:

UPB 1 HomeSeer $1
UPB 3 HomeSeer $3
UPB 4 HomeSeer $4
UPB 5 HomeSeer $2

Links however are matched on the link names. Changing the link name may cause the HomeSeer device code to change. There is very little to match on with links. Matching on the LinkID originally failed because UPStart would re-order the link numbers. I don't think the later versions are doing this and I have been considering changing the plug-in to use the link number as a reference rather than the name.

I have been unable to find any logic behind how HS assigns device codes to UPB devices. A change in UPStart can result in device codes being assigned differently in HS. For this reason, I don't see how you could ever use device codes in HS scripts with any confidence that you are controlling the device you think you are.


I have seen the device code change simply by deleting the device (from HS only) and then restarting HS to reimport the device definition from UPStart.