UPB network traffic

[BobS0327]

That's how the HLC protocol works.
It's not an error or an issue, it is by design.
 
The UPB unit numbers are divided into rooms.
Whenever an action is taken within that room, links, the controller polls the status of all the units allocated to that room. 
Even if there is no physical device installed in a particular unit allocated to that room.
 
The protocol was programmed this way to automate the status tracking process and fit it all into the limited memory space of the Omni.
So there were some efficiency measures taken.
 
With respect to manually activating the rockers.
In order for the panel to know when a particular switch turns on or off, you have to configure it to transmit the ON and OFF links 241/242.
When the panel sees those links it checks which unit sent them.
This is how the WHEN UPB Switch ON or OFF triggers get generated.
Otherwise it has no way of knowing when a switch is operated manually.
If a rocker is configured to transmit another link, or no link at all, the panel will not be able to detect rocker presses.
Generally you get around that by configuring the switch's firmware to update it's own status independently when the rocker is pressed.

Yea, I guess that does make sense to me.  One room plus seven devices gives me eight packets. I wish I could interpret the packets the OP2 is sending.  They just don't make sense when you're using the PCS protocol document. Maybe ano's right. It could be possible that Leviton is using some sort of modified proprietary UPB protocol.
 
But anyway, they really should fix the checksum algorithm.  It generates a fair amount of invalid checksum values.  OTOH, maybe the intern created his/her own "special" checksum algorithm.

 

[ano]

But anyway, they really should fix the checksum algorithm.  It generates a fair amount of invalid checksum values.  OTOH, maybe the intern created his/her own "special" checksum algorithm.

I'd be interested in hearing which commands have errors because it all seems to work OK. Either the bad commands are unimportant, or the switches ignore the error.

 

[Desert_AIP]

You can watch the traffic in real time via the UPStart log.
The traffic in the log includes the plain language descriptions.

So you can see "Unit 1 Request Status"
From Unit 1 "50"
"Unit 2 Request Status"
From Unit 2 "70"

Etc.

 

[Desert_AIP]

This thread may help you understand the HLC transmissions.

http://cocoontech.com/forums/topic/26748-upb-configuration-into-ominpro/

 

[BobS0327]

I occasionally get a bad checksum  from the eight packets that are transmitted.  A bad checksum can't really be attributed to any particular command since it can happen to any command issued. Below is an excerpt from the PCS protocol document explaining the checksum algorithm.  Those who have a programming background would understand that this is an extremely simple algorithm to implement.  It's often taught in a freshman level comp science programming class.
 
The bad checksum *ONLY* randomly occurs on one of the eight packets generated by the OP2 which I presume to be querying the status of a room and switches.  A "guesstimate" on my part is that it occurs about every 250 manual switches.
 
Standard protocol packets are usually transmitted twice as the norm.  So, I would assume that if the first transmission had a bad checksum, the second would have a recalculated packet with a valid checksum.  I've been running my "sniffer" app now 24/7 for about the last two weeks and I have yet to see a bad checksum from any of the switches.  So, I don't know if this is a valid assumption on my part.
 
But the 8 OP2 packets, IMHO appear to be transmitted only once. AFAIK, the 8 packets generated by the OP2 are undocumented.  So, it's anybody's guess as to whether this is good, bad or indifferent.
 
I have a Java project posted on github which monitors all the UPB traffic on the powerline.  It translates all the packets to a human readable form.  Part of this translation is a checksum validation.  It independently calculates the checksum and will display a message when a received packet has a invalid checksum.  It will also display the correct checksum.  I have also used paper and pencil to independently verify that the checksum is invalid just to  be sure that my program calculations are correct.
 

The Packet Checksum (CHK)
Every UPB Communication Packet must end with a 1-byte field called the Packet Checksum. The
Packet Checksum is used to verify the integrity of the received packet. The Packet Checksum is
computed as follows:
Sum all of the bytes of the Packet Header and UPB Message fields together. Then take the 2’s
complement of the sum and truncate the result to 8-bits.
In this way, a UPB Device that receives a UPB Communication Packet can verify its integrity by
summing all of the bytes of the packet (including the Packet Checksum byte) together. The sum of
all of the packet bytes should result in a value of 00 for a UPB Communication Packet that was
received correctly.

 

 

[cobra]

Have you ruled out command collisions?  I don't see you mention this, but maybe you considered it already.  I'd think if the OP2 is polling the room, those commands have a higher chance of a command collision with another status (for example, a manual switch operation.)  Those may appear as checksum errors or otherwise modified commands (which I would think would also have a checksum error...)
 
Often simple checksums like this are used to check if the command is at all valid.  Commands with a checksum failure are probably just ignored.

 

[BobS0327]

I don't think command collisions would be an issue.  I think the loss of packets is the real issue.  The UPB protocol can transmit a packet from one to four times with a transmission count of two being the norm.  A two transmission count is done to ensure that the receiving device does get the packet.  One transmitted packet can be lost but the probability of losing both transmitted packets is extremely low. You could almost compare this UPB protocol to the UDP (connection less) network protocol. 
 
As far as the checksum is concerned, the receiving device will recalculate the checksum on the packet.  If the checksum is not valid, the device will simply toss the packet.  The packet is ignored.
 
I honestly don't think the OP2 is polling anything.  I contacted PCS (888-701-9831) about this issue.  They reviewed it and it's their opinion that the OP2 is just spitting out packets whenever the switches are manually manipulated.  No data is ever returned to the panel.
 
The response I got from one of the tech's

 

Sorry, I have no idea.  The MDID of 38 (decimal) is not a command I would expect to see the controller sending. It isn’t a status request or anything.
 
Wish I could help!

 
So, the response from PCS coupled with the fact that these mystery packets occasionally  generate check sum errors leads me to believe it's probably a firmware issue.  It's not a show stopper for the development of my application.  I just toss these mystery packets.
 

 

[pete_c]

Over the years there has been some overlapping of new Omni pro firmware code over old firmware code.
 
Not related to UPB but Leviton HAI did overwrite the firmware code for the legacy OmniTouch 5.7 pop up cameras touch screen stuff a while ago making it dysfunctional.
 
Relating to this issue / concern I confirmed it with Leviton HAI tech support and they were able to duplicate it. 
 
I opened a service ticket with them but they never sent me a confirmation via Email.   
 
Leviton did fix the pop up camera issue in a firmware update to the OmniPro 2.
 
CCTV Camera pop up not working with OmniTouch 5.7 touchscreens - FW V3.14A - December 2014
 
CCTV Camera pop up working with Omnitouch 5.7 touchscreens - FW V3.15 - November 2015
 
Who knows what else might have gotten written over in firmware revisions. 
 
That said do the mystery packets cause dysfunctional Omni Pro UPB PIM / HLC issues? 
 
I am guessing not from reading posts here. 
 
I know the OmniPro bus is really antiquated being some 15 years plus old these days.  Works fine for me today.

 

[ano]

For anyone new to Leviton/HAI, lets just say software/firmware is not their strong-point. 

 

[BobS0327]

That said do the mystery packets cause dysfunctional Omni Pro UPB PIM / HLC issues?

 
They don't cause me any dysfunction.
 
I was just totally confused why the controller would would attempt to fully turn on a non existent device four times and then fully turn off a non existent device four times each time a switch rocker was manually depressed.  It's usually the same non existent device ids of 104 and 210 that are being turned on/off.  I never knew this was occurring on my network until I started "sniffing" the power line packets.  So, for me personally, it's a non issue since IMHO, my UPB network is just about 100% reliable.
 
 
 
 

 

[ano]

If things were different, we would tell you to notify Leviton and they would fix it, since if nothing else, having any extra unneeded UPB transmissions on the powerline should be avoided. However from experience, we know that when Leviton "fixes" something it often breaks three other things in the process and ultimately probably doesn't fix the original problem either. :unsure:

 

[BobS0327]

Have you ruled out command collisions?  I don't see you mention this, but maybe you considered it already.  I'd think if the OP2 is polling the room, those commands have a higher chance of a command collision with another status (for example, a manual switch operation.)  Those may appear as checksum errors or otherwise modified commands (which I would think would also have a checksum error...)
 
Often simple checksums like this are used to check if the command is at all valid.  Commands with a checksum failure are probably just ignored.

You're right about the command collisions.  I learned from an email discussion with PCS techs that only ONE packet should be on the powerline at any given time.  Otherwise, as you said, collisions will occur.
 
In situations where I need a response from the UPB device, I've had to use a minimum of a five second delay between issuing commands. That is, issue the command, wait four seconds before the response is available, spend another second reading the response and then finally I am able to send another command packet

 

[cobra]

I wondered, because of what you mention.  The powerline is similar to a multi-drop serial setup (think slow protocol on a single bus with multiple talkers), so collisions are always something to watch out for.

 

[BobS0327]

Well, after testing my upbServer app for over 30 hours of automated non stop  testing, I've concluded that the extraneous packets put on the powerline by the OP2 really have to be eliminated.  Thus, I sent an email into Leviton/HAI requesting that they address this issue.
 
The problem is when a UPB switch is manually toggled on/off, the OP2 puts eight extra packets on the powerline.  Thus, IMHO, these packets are colliding with the status packet being sent by the UPB device.  My guesstimate is that one out ten times, my app fails to receive the status update packet because it collided with the extraneous OP2 packets.  My app may not be receiving all the status update packets leaving the accuracy of the device status database  questionable at best.
 
I've also done extensive automated stress testing of the app for at least 30 hours continuously WITHOUT the OP2 on the powerline.  I changed the UPB network id in PC Access to a bogus id before running the tests.  Test was totally successful.  Absolutely no problems.  This test included several people simultaneously toggling switches for a couple of minutes at a time.  The app worked like a charm.
 
A kludgy solution would be to do a status query  of all the devices every time the app receives a "crazy" packet from the OP2 controller.
 
A copy of my email to Leviton/HAI tech support follows:
 
 

To Whom It May Concern

I'm currently working on a application to monitor/control UPB devices.  Every time I MANUALLY control a UPB switch, the OP2 controller generates eight questionable UPB commands.  There are two commands which each are generated four times by the OP2.


The first command is PU880C0167FF26647B

0x26 Indicate Command
Requests the receiving indicator-type device(s) or
channel to go to a specified Level (or State).
 
0xFF indicates the source, the OP2 controller sends the command FOUR times

Destination ID is 0x67 (103) which is a scene

I have a Scene 0x67 (103) which indicates to turn interior lights to 100% in 0.8 seconds.
This link controls 6 interior dimmable switches including the one switch that was manually
turned on.  NOTE that none of the other switches are turned ON when this command is issued by the OP2.

The OP2 controller then sends a PU880C01D2FF266410 command FOUR times
 
0x26 Indicate Command
Requests the receiving indicator-type device(s) or
channel to go to a specified Level (or State).

0xFF indicates the source, the OP2 controller sends the command FOUR times

Destination ID is 0xD2 (203) which is a NONEXISTENT scene

I believe this to be excess powerline traffic generated by the OP2 which is causing my own app to fail to receive some command packets.  IOW, the eight
packets generated by the OP2 are colliding with the status packet sent by the device.  My app needs to receive this status packet to ensure that
my database is up to date on the current status of all UPB devices.

I believe best practices dictate that UPB powerline traffic should be kept to a minimum to ensure total reliability of the UPB devices.

I would greatly appreciate any assistance offered to resolve what I believe to be a  OP2 UPB issue.
 
Thanx

 
 
 

 

[Desert_AIP]

I may have missed it above.

What are your UPB settings in PCAccess for repeats and time delay?
What repeats are your switches set to?