UPB Programming and the Elk M1G

[DotNetDog]

OK, let's say I have an Elk M1G with a UPB PIM attached for UPB lighting control. Since the M1G cannot maintain switch status for linked devices, I decide that I want some software on a PC to keep the M1G synchronized.

By the way, just for clarification: let's just assume that I already planned to have a PC running 24/7 for other reasons.

The goal would be for the PC to read the UPStart data file so that it knows what devices participate in each given link. The PC would need to "see" any UPB commands that are sent out. Whenever a link command is sent the PC would extract the link ID, read the list of devices participating in the link and query the status of each device. The PC would then need to update the device status stored in the M1G.

So my question is...would the PC be able to receive UPB events directly from the Elk M1G? Or would the PC need its own PIM?

I'm just thinking through the possibilities...I haven't opened up Visual Studio [yet].

 

[dBeau]

The goal would be for the PC to read the UPStart data file so that it knows what devices participate in each given link. The PC would need to "see" any UPB commands that are sent out. Whenever a link command is sent the PC would extract the link ID, read the list of devices participating in the link and query the status of each device. The PC would then need to update the device status stored in the M1G.

So my question is...would the PC be able to receive UPB events directly from the Elk M1G? Or would the PC need its own PIM?

The elk protocol is well documented. Connecting a PC to the elk for constant monitoring is easy. When a UPB link command appears on the power line, the elk will report it to the PC. The next step is querying the affected devices for their status. The elk protocol supports a device status request so it might work... but I've not tried it. It's possible that the elk will only respond with what it thinks the status is, rather than send a status request out over the power line.

Assuming the best, after sending the status request, the UPB device would respond with it's status and the elk would update it's internal state accordingly. You're done.

Assuming the worst, the elk wont deliver a status request to the power line on behalf of the connected PC. In this case, you'd need a second pim connected to the PC to send the status requests.

Armed with decent enough libraries for dealing with the elk protocol and possibly the UPB protocol, the task is pretty straightforward. If you plan to write the drivers yourself, you are in for a bit of a haul.

 

[DotNetDog]

The goal would be for the PC to read the UPStart data file so that it knows what devices participate in each given link. The PC would need to "see" any UPB commands that are sent out. Whenever a link command is sent the PC would extract the link ID, read the list of devices participating in the link and query the status of each device. The PC would then need to update the device status stored in the M1G.

So my question is...would the PC be able to receive UPB events directly from the Elk M1G? Or would the PC need its own PIM?

The elk protocol is well documented. Connecting a PC to the elk for constant monitoring is easy. When a UPB link command appears on the power line, the elk will report it to the PC. The next step is querying the affected devices for their status. The elk protocol supports a device status request so it might work... but I've not tried it. It's possible that the elk will only respond with what it thinks the status is, rather than send a status request out over the power line.

Assuming the best, after sending the status request, the UPB device would respond with it's status and the elk would update it's internal state accordingly. You're done.

Assuming the worst, the elk wont deliver a status request to the power line on behalf of the connected PC. In this case, you'd need a second pim connected to the PC to send the status requests.

Armed with decent enough libraries for dealing with the elk protocol and possibly the UPB protocol, the task is pretty straightforward. If you plan to write the drivers yourself, you are in for a bit of a haul.

Thanks for the info...that helps. I written this kind of stuff before. In fact, I was VP of Development for a home automation company back in 1999... bad timing...we went down with the rest of dot COM. Anyway, I'll contact Elk about the question that you raise. Does the Elk send out a UPB status request or does it merely reflect its internal state?

Thanks again!

 

[DotNetDog]

I just heard back from Elk:

"The M1 will report the UPB status it “thinks†is current. You would need a second PIM for the computer. Please let me know if you have other questions."


So if I were to go with a PC-based solution then I would need a 2nd PIM. Hmmm...now I have to return to the old hardware -vs- software home automation controller. Since I'm already planning to run a PC 24/7 the software solution is proving to be far more robust. While I could go with the OmniProII, I really think that my rules may exceed the abilities of that product as well.

(off to research software-based solutions...)

 

[dBeau]

...a couple more thoughts.

To get the job done, you really dont need to read the export file from upstart. The UPB protocol supports a pretty clever acknowledgment mechanism. If you send a NoOp command to the same link that was just triggered, and set the ack bit properly, each device that is participating in that link will respond in turn. Just collect up the list of devices from the response and use that list to query the status from each device. This way, you dont have to worry about keeping the export file up to date.

Also, you'll need to watch out for links that have many devices. Say you have 60 devices and a link is used for "all off". You'll have to send a status request to each device and wait for the reply before moving on to the next. This will take about 1 second per device. The potential problem is that for that minute, you'll be pretty close to using all the bandwidth of the UPB powerline bus (30 bytes/sec or so). So, if during that minute, someone activates a wall switch that is configured to send a link command, there is a good chance that the command will be missed. Sure it's an extreme case, but it wont hurt too much to think about it some.

*If* there was a command you could send to the elk to convince it that a given device was in a particular state, it would be better to parse the export file to determine how each device in a link will react to a link command. Then, upon seeing a link command, just assume each device actually received it and send a "fake" status update command back to the elk. Again, I havent played with the elk lighting commands enough yet to know if there is a way to fake the status updates. Of course you could get really crazy and just code up a PIM simulator for the elk to talk to.

Consider too that UPB devices can be set to take minutes to fade up or down. If you query their status while in the middle of a fade you'll get back the current status... and that will be out of date shortly. Here the parsed upstart file can give you a clue about when or how often to ask for another status update.

 

[DotNetDog]

...a couple more thoughts.

To get the job done, you really dont need to read the export file from upstart. The UPB protocol supports a pretty clever acknowledgment mechanism. If you send a NoOp command to the same link that was just triggered, and set the ack bit properly, each device that is participating in that link will respond in turn. Just collect up the list of devices from the response and use that list to query the status from each device. This way, you dont have to worry about keeping the export file up to date.

Also, you'll need to watch out for links that have many devices. Say you have 60 devices and a link is used for "all off". You'll have to send a status request to each device and wait for the reply before moving on to the next. This will take about 1 second per device. The potential problem is that for that minute, you'll be pretty close to using all the bandwidth of the UPB powerline bus (30 bytes/sec or so). So, if during that minute, someone activates a wall switch that is configured to send a link command, there is a good chance that the command will be missed. Sure it's an extreme case, but it wont hurt too much to think about it some.

*If* there was a command you could send to the elk to convince it that a given device was in a particular state, it would be better to parse the export file to determine how each device in a link will react to a link command. Then, upon seeing a link command, just assume each device actually received it and send a "fake" status update command back to the elk. Again, I havent played with the elk lighting commands enough yet to know if there is a way to fake the status updates. Of course you could get really crazy and just code up a PIM simulator for the elk to talk to.

Consider too that UPB devices can be set to take minutes to fade up or down. If you query their status while in the middle of a fade you'll get back the current status... and that will be out of date shortly. Here the parsed upstart file can give you a clue about when or how often to ask for another status update.

OK, now this is interesting... So really I have two solutions.

1. Watch for link commands and send a NoOp with the ACK bit set
2. Try to fake the statuses

If I "watch" for link commands and then send out a NoOp with the ACK bit set this would get me true status updates. The issue with this approach being that a link containing a large number of receiving devices could/would bog down the UPB communications.

On the other hand, I could read the UPStart file and logically determine the new state of each linked device. Then if I can update the device status in the Elk I would be done.

I'll check with Elk to see if I can tell the M1G a device status without it going out to query the device.

Thanks for the ideas.