Trouble reading SA UPB status with M1

mikefamig

Senior Member
I have a message thread going in the automation section that is not getting much traffic so I would like to link to it here:
 
http://cocoontech.com/forums/topic/27356-elk-m1-not-receiving-upb-device-status/
 
I am having trouble with reading the status of my SA 11-40 dimmer switches. When the switch is turned on and off by tapping the rocker switch the status does not change in m1togo or ekeypad. When switched by m1togo or ekeypad both show the status change.
 
As a test I set a rule to speak when the switch goes on and off.
 
12        WHENEVER Front Porch [2 (A2)] IS TURNED ON BY SOME EXTERNAL DEVICE
            THEN ANNOUNCE On (vm310)
 13        WHENEVER Front Porch [2 (A2)] IS TURNED OFF BY SOME EXTERNAL DEVICE
            THEN ANNOUNCE Off (vm311)
 
To sum it up, the elk speaks when the light is switched by ekeypad or m1togo but is silent when physically switched at the rocker. Why doesn't the status update in ekeypad?
 
I also see the PIM-E LED change hue slightly when the rocker switch is tapped so the link appears to be getting there.
 
Why isn't the rule being triggered when switched by the paddle?
 
Mike.
 
 
 
If I remember correctly from years past, the M1 is not polling the devices, which is why you are not getting the status, but when the M1 is the one that is initiating the command, you will get the status, as it is the originator.
 
As I said, I believe the M1 isn't able to actively poll unless you write a rule to do such, and in doing such, it slows down the M1's serial due to all the extra traffic. As I said elsewhere, I believe this is covered either in the XSP manual (or old rev's) or the white papers that are on their site (although buried since the redesign).
 
I believe this held true all the way back to the X-10 control days on the M1.
 
DELInstallations said:
If I remember correctly from years past, the M1 is not polling the devices, which is why you are not getting the status, but when the M1 is the one that is initiating the command, you will get the status, as it is the originator.
 
As I said, I believe the M1 isn't able to actively poll unless you write a rule to do such, and in doing such, it slows down the M1's serial due to all the extra traffic. As I said elsewhere, I believe this is covered either in the XSP manual (or old rev's) or the white papers that are on their site (although buried since the redesign).
 
I believe this held true all the way back to the X-10 control days on the M1.
I've been testing with the help of Elk and Automated Outlet and have been learning about UPB and how it communicates with the Elk. They are certain that the SA dimmer switch does send a link when it is physically switched at the rocker. I'll post it here when I learn anything conclusive about why the status isn't getting to the elk controller.
 
Mike.
 
drvnbysound said:
You aren't having a shortage of problems with this installation... you'll be an expert before long ;)
 
 I don't think that I'm the only one with system startup problems or have UPB that doesn't upgrade the status on ekeypad and M1TOGO. I've seen a lot of references around the net of systems with similar problems but people ignore them or find a work around or the installer just never tells the home owner that it's going on at all. I do this as a hobby and love troubleshooting so I dig in and try to get to the bottom of it all until I understand what's going on.
 
For example, I was almost ready to call the UPB status problem normal based on what I read on the net until I talked to the manufacturers. They assure me that it is not normal. When a rocker is pressed on an SA UPB switch and it is programmed properly it will transmit a status and the M1 should acknowledge it. That is the official answer that I have gotten and we're working on finding out why mine isn't behaving that way.
 
We have done tests that proved that my switch is transmitting a status. We have also determined that the status is being received by the PIM-E based on the light flickering onthe PIM-E when the rocker is tapped. We have then determined that the status can NOT be seen by elk rules. Knowing this we see the status getting lost at the PIM-E and are going to try to replace it with an xsp and UMC which is known to work.
 
Mike.
 
drvnbysound said:
You aren't having a shortage of problems with this installation... you'll be an expert before long ;)
I see in hindsight that most of my problems have been caused by design flaws caused by my lack of experience. I designed this system from scratch with no previous experience in Home Automation or Security. The startups were resolved by replacing the p212s with a more powerful power supply and larger gauge power supply wire.
 
The errant chimes were resolved by a system reset and removing all of my rules. I am still adding rules back slowly to try to determine what is going on there but the system has been good for a week or so. I would love to be able to get a bunch of elk users to leave their chimes on for a week or so and see if they don't get an unexpected chime or two. It seems to me at this point that certain circumstances (maybe the system auto startups, maybe rules?) are capable of scrambling something in the system memory and it causes the errant chimes. A reset and reload straightened me out so far. Elk did supply me with a new controller but they have thoroughly tested my old one and report that it is fine.
 
And yes I have learned a lot in the process.
 
Mike.
 
Back
Top