Issue with Elk and UPB

[comet48]

UPB devices do not report their status when it is changed in response to a link. The best they can do is to report that they have received a command. As configured from the factory, the SAI devices dont request an acknowledgment when they transmit a link. Likewise, when the Elk transmits a link or any packet for that matter, it doent ask for an acknowledgment either. The only time I know of when an SAI switch will report status is when it is configured to transmit its status on a button press.

I just want to make sure that nobody is confused by your first sentence above. I think you meant to say "by default". I have SA switches and I've enabled "Report light level after any button or rocker is pressed". When a button is pressed OR when a link is received, the switch sends a UPB message reporting it's new light level. I assume this is true of all vendors.

Doug

That is not true. When a Simply Automated link is received, it does not report to the Elk that the status has changed. Only when a rocker is pressed AND that rocker is assigned to a load.

I just talked to SA and they confirmed

 

[acheslow]

Has there been any progress on this issue? It's annoying that the M1 incorrectly reports the status of my lights, but I'm considering using a UPB module to control my sprinklers and I definitely want to know when those are on or off. I haven't checked here in a while and was hoping there may have been a firmware update or other solution?

Thanks,

 

[electron]

It's not something ELK can fix It's a UPB 'limitation'.

 

[acheslow]

It's not something ELK can fix It's a UPB 'limitation'.

Thanks. And something tells me that SA would say it's an Elk limitation ;-)

Are there any other workarounds then? I seem to remember a thread that I can't find now which described a way to have all of the transmitters send link commands to the Elk, and then the Elk would send different sets of link commands to the receivers. This way the Elk would always know and report the correct status of the loads since it is the only device that is transmitting links to the receivers.

Is that right or am I hallucinating?

[Edit: I found the previous thread at http://www.cocoontech.com/forums/index.php?showtopic=5978]

 

[ano]

It's not something ELK can fix It's a UPB 'limitation'.

Thanks. And something tells me that SA would say it's an Elk limitation ;-)

Are there any other workarounds then? I seem to remember a thread that I can't find now which described a way to have all of the transmitters send link commands to the Elk, and then the Elk would send different sets of link commands to the receivers. This way the Elk would always know and report the correct status of the loads since it is the only device that is transmitting links to the receivers.

Is that right or am I hallucinating?

[Edit: I found the previous thread at http://www.cocoontech.com/forums/index.php?showtopic=5978]

Links are just numbers to an ELK or other controller watching the powerline. So by itself, and ELK could never know which switches are to change when a link is activated, but it could be resolved. The UpStart file contains this information, which is how programs like HomeSeer CAN respond correctly to link changes. Also, HAI somewhat gets around this problem as well, IF and only IF you use its internal link creation and management. If you program your links in UPStart, HAI works like an ELK. ELK would need some type of utility to import a UPStart export file, and use that to tell it which links control what. Certainly possible to do, but not at this point.

 

[Digger]

I was planning on trying the following simple idea when I get the time:

Switches are A, B, C where A has the load and B and C or virtual 3 way etc.

When A is turned on and off the ELK sees its status change (no problem)

When B is turned on and off dont link it directly to A but have the ELK see it. So When B is turned on turn on A and when B is turned of turn off A though the ELK. Since teh ELK will be telling A what to do it will know the status of A at all times. Do the same for C.

Not sure it would work but it seems like it would.

 

[bmil]

UPB Link commands will always be problematic. A lot of us were just wishing Elk would implement the capability of an M1XSP to resend a direct command to a device if it doesn't receive an ACK back. Currently it doesn't even do that...

 

[dBeau]

It's not something ELK can fix It's a UPB 'limitation'.

It's most certaintly NOT a UPB limitation. The protocol has full support for link tracking. There are even controllers out there that get it right. It's just not easy and takes a bit of program space and RAM. The Elk is very short on both. I will, at least, agree with the first part of your statement.

 

[electron]

Which controller supports tracking each device, via a link activation, without being the device responsible for activating that link (or have an internal database which requires manually entering/configuring which device belongs to what link)?

 

[dBeau]

Which controller supports tracking each device, via a link activation, without being the device responsible for activating that link (or have an internal database which requires manually entering/configuring which device belongs to what link)?

Hmmm... clever change of subject But it's a great question. Assuming you dont consider upstart to be a controller, the only controller I know of that fits your description is my own (not yet released). Since the protocol supports it, I'd think others have done it too. But I'll admit to not having done the market research.

The trick, as you point out is having that internal database. The protocol supports querying each device to determine which links it responds to and what it does in response to receiving the link. That's what I do. Another other way to get this information is from reading the upstart export file. This approach is a bit easier and seems to be what most others are doing. I dont have a list of the controllers that do this so I'll have to hope others will chime in here.

My point was that controllers can choose not to implement or make good use of the protocol. But it's their choice, not a limitation of UPB. In the case of the elk, it would take an external processor with a bit more memory to pull it off.

If you are interested in hearing about the features of the UPB protocol that make it all possible, I'd be happy to get you started.

 

[electron]

Well you haven't proven me wrong yet From what I can tell, a UPB device still can't broadcast a status change whenever they respond to a link command. You are relying on a database (which will probably take a while to generate if you have a good amount of UPB hardware) to compensate for something which UPB devices don't support, unless I misunderstood you.

Would love to learn more about that controller of yours tho, sounds very interesting

 

[dBeau]

Well you haven't proven me wrong yet From what I can tell, a UPB device still can't broadcast a status change whenever they respond to a link command. You are relying on a database (which will probably take a while to generate if you have a good amount of UPB hardware) to compensate for something which UPB devices don't support, unless I misunderstood you.

I am not quite sure what I should be proving. Your first statement was that Elk couldnt get it right because of a limitation inherit with UPB. My response was that the Elk couldnt get it right because of it's limited CPU and memory resources. A weak position would be that we are both right. To some extent we are.

When it comes to the limitations of UPB it might be helpful to spell out exactly what is lacking. From your comments I'm assuming that you think the problem is that UPB devices dont broadcast a status change whenever there is one. I'd have to agree that would be a great feature especially if the goal was to make it easy to implement a controller. Sadly, engineering is all about trade-offs.

The root of the "problem" with implementing that feature, in my opinion, is the low bandwidth of the connection between the devices. 30 bytes (or so) per second over a broadcast medium isnt all that much. Now consider that a device status report can take up to 23 bytes. Most only send about 10 but that's still 1/3 second. The fun starts when a link with more than just a few devices is activated. Now you've got all these devices all trying to reply at the same time and having to figure out if their reply made it to it's destination. Imagine a link with all 250 devices, it could take minutes to sort itself out all the while your button presses at the switches would have to fight for a chance to send their messages. While this is a solved problem (ethernet works like this) it does put a bit of load on the individual device and, to work in a timely fashion, needs a lot of bandwidth. Note also that I havent even mentioned the problems associated with reporting the status of a slow fade.

The UPB designers chose to keep the cost down and not put that kind of power into the devices. Instead, they chose to put the burden on the controller. Back to the trade-offs again. If they doubled the price of the device, they could probably pull it off.

The designers, I assume, didnt feel the need to implement this feature. They likely considered the problem it would solve to be a non-problem because the protocol has support for device discovery and configuration. Any controller can query the network and build the database needed to track the device state.

What, I think, they didnt count on is that nobody (except perhaps a crazed hobbyist) would want to implement a controller that actually made full use of the protocol! What's really sad is their decision not to publish the source code for upstart. I am sure that with a "reference implementation" available to third parties, there would be much better software support for their devices. The engineers did a great job of making a very usable protocol. I suspect someone in marketing perceives some value in keeping the key to using it all locked up.

In the case of the Elk, I gather from all the postings here that it has long been at the limits of it's CPU and memory resources. So, much like the UPB designers being stuck with some of their decisions (300 baud) the Elk designers have to deal with what they have. Specifically, a box designed to work with the much simpler X10 protocol. They had to make a lot of trade-offs to get it to work at all with UPB. I am not surprised that they didnt get link tracking right. What does surprise me is that they missed a couple of simple things that would make their UPB support a bit better at least with respect to its interaction with controllers that do have more smarts. The ability to set the ackrq bit and repeat count, for example.

So who's to blame for the Elk not properly supporting UPB? I guess we can agree to disagree here, but it seems odd to me to blame UPB for not implementing a protocol that can be easily used by devices designed for X10... especially when the main complaint centers around a feature that X10 never had.

Would love to learn more about that controller of yours tho, sounds very interesting

Right now I have support for UPB, Elk, Brultech, 1-wire, Intellitouch, Statnet (AprilAire), and RFXCOM. The primary goal of the package is to simplify adding support for new devices. At this point it's a collection of device drivers that map hardware to higher level virtual devices. But the drivers are all coded with a common toolkit designed to decode and encode data from packed binary and ASCII protocols and publish the results to a distributed, object oriented database.

Lately I've been putting thought into how to license the code. On the one hand I'd like to turn it into a product. On the other, I'd really like to simply release it as open source. A dual license (GPL/commercial) is not out of the question, but since I prefer to write code over contracts, that decision is likely to take some time. And since I still need to pay the bills, the code is not getting my full attention.

 

[ano]

The HAI Omni Pro II will track links if you use its method of creating the links (not Upstart). HomeSeer will track links but you have to import in the UPStart DB for it to do it. CQC uses a rather primative way to track links by polling every switch involved in a link after the link is activated/deactivated. This is rather slow, but it generally works.

 

[sharby]

Reviewing the responses to this topic, I'm thinking that 2 possible scenerios can be done to have true status:

1. Work with ELK tech support in writing a rule using their RS323 protocol spec to "Get Status" to lights affiliated with a LINK

2. Writing a rule that "Gets Status" to selected lights when a particular link is executed.

I understand that have a PC running (with Powerhome) is not an option. However, the logging and currently configuration allows every light to show true status when a LINK is triggered. PH knows to adjust the light statuses accordingly PLUS initiate "Get Statuses" to only those affiliated devices on the LINK. And with GenII technology, I have a 99.9% reliability of the true status.


-=*Sharby*=-

 

[ddennerline]

Can anyone who has an Elk M1G installed with UPB lighting system comment on how reliable the integration is *without* external PC help?

How happy are you with your UPB purchase?

How reliable are scenes using only physical rockers?

How reliable is Elk trigger a scene (i.e., are lights not turned on/off)?

I have been spending dozen of hours reading Internet posts and talking directly with Elk Technical Support (thanks Brad). Elk Technical Support indicates that UPB is one of the more reliable lighting technologies it supports.

ELK M1G has a documented limitation related to tracking current load (on/off/dim) status if the UPB Link command feature. Since I am not yet allowed to post URLs, then Google: “UPB Link command†and click on Simply Automated FAQs.htm, Item#9.

Limitations:
UPB modules will not send their recent status changes in response to link commands. Therefore, the status displayed by the M1 Controller may not always match the true status of UPB devices if they have been controlled by a Link command.
From my understanding, If the UPB Link command *is* issued by any Elk control software, then Elk M1G will statically update the on/off status of each device that is part of scene. I believe the M1G know which devices that are part of scene because configuration map it imported into ElkRP. But if the Link command is manually invoked by, â€scene switch,†then Elk’s view of the lighting network will be desynchronized.
Elk Technical Support:

The Elk system can activate and deactivate UPB Links using Rules or from the keypad or using one of the GUI Interfaces for example “Virtual Keypad or ELKRMS. The limitation is that the UPB devices don’t report their status change after being changed by a Link command.

My lighting/load automation system will have around 20-30 switches/plugins. I am leaning more towards UPB because I am not a big fan of wireless technologies in general (this is really a personal preference and less about technical superiority). My biggest concern is Elk integration. In addition, I am not very excited to use any PC-based helper applications.
For my lighting needs, I want to create functional or story-book types of light scenes. Each scene emulates a “typical†behavior. Example may be:
• Leave House Scene
• Coming Home Scene
• Going to Bed Scene
• Having a Party Scene
• Suspicious Event Outside/Nighttime Scene