Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MD Corie]

It still seems to me like you are trying to put together a process flow that is beyond the scope of what the CM15A was designed to do.

... their hardware via the software flexibility.  This sounded really appealing because I'd love to be able to enhance the capabilities of my system via software, but I've never gotten to the point of being able to do anything "interesting" with the software - because I can't even get it to accomplish the basic stuff that it was supposed to help cure ).

I think we might have found the source of the problem. From my experience (and I've heard the same from others here), X10's sales staff aren't anywhere near as familiar with AHP as the users here seem to be.
...

Actually, it was X10's Tech Support that told me. 

It is entirely possible that with enough workarounds and tweaks, the system you purchased MIGHT be capable of working exactly the way you want it to, but based on the responses here, it seems that nobody here knows how to do it.

I certainly hope so... but for now, I'd just be happy to know how the macros actually interact with each other when two or more are trying to run at the same time.  It would also be helpful to understand whether "collisions" can occur due to macro operations, or if the macro system is "smart" enough to issue only one command at a time... and beyond that, how macro execution responds to collisions that may occur between macro-issued commands and asyncronous commands coming from other hardware.

I'm also rather puzzled about why it takes so long for macro actions to execute.  Is this "normal", or is there some sort of latency being introduced by some operational factor(s)?

[MD Corie]

Could be as X10 is known to change things with no information passed to us or even a model number change.

That's kind of scary - especially if one has to go through a lot of "concessions" in order to make things work consistently with the current behaviors of a device.  When the device fails, its replacement may not play with these concessions.

Just look at what they did with the lamp module redesign a few years back. Or what they are currently doing with the "out of stock" status of the CM15A.
How hard would it have been for them to tack an "-S" onto the end of the model number for the SoftStart modules, to avoid confusion?
How hard would it have been to NOT use "CM15" as the beginning of the part number for the CM19A/TM751 kit?

I'm not familiar with the CM15A situation... are they trying to "emulate" a CM15A with the CM19A/TM751 combination, perhaps?

[Noam]

I'm not familiar with the CM15A situation... are they trying to "emulate" a CM15A with the CM19A/TM751 combination, perhaps?

Sort of. They are out of stock of the CM15A (and have been for a while now).
They decided to put a CM19A and a TM751 in a box, and slap a "CM15K" label on it, selling it in place of the CM15A.
They are strongly indicating that it is an equal substitute for the CM15A, but it is severely lacking:
1. It has no internal memory, so it needs to be connected to a running PC 24/7.
2. It has no PLC transmitter, so they give you a TM751, which is "impolite," and can cause PLC collisions.
3. It has no PLC receiver. They have no solution for that one. The setup is "dumb" when it comes to PLC triggers (like from the floodlight motion sensor, or a PowerFlash module, or a plug-in controller).

[MD Corie]

I'm not familiar with the CM15A situation... are they trying to "emulate" a CM15A with the CM19A/TM751 combination, perhaps?

Sort of. They are out of stock of the CM15A (and have been for a while now).
They decided to put a CM19A and a TM751 in a box, and slap a "CM15K" label on it, selling it in place of the CM15A.
They are strongly indicating that it is an equal substitute for the CM15A, but it is severely lacking:
1. It has no internal memory, so it needs to be connected to a running PC 24/7.
2. It has no PLC transmitter, so they give you a TM751, which is "impolite," and can cause PLC collisions.
3. It has no PLC receiver. They have no solution for that one. The setup is "dumb" when it comes to PLC triggers (like from the floodlight motion sensor, or a PowerFlash module, or a plug-in controller).

Yikes!  That is a real bummer if the CM15A is no longer available, and there is no viable replacement:  In its current configuration, my system relies on that CM15A to do much of anything useful.  So, when the CM15A fails, the system will be dead in the water!  (I always was going to buy a backup CM15A, but economics forced other priorities... Ugh!)

I suppose that it would "resolve" the problems with the macros, though!   

[Noam]

Well, X10 has been saying they are getting more of them in someday.
They just posted on FaceBook that they have SocketRockets again.
However, it looks like a new part number (LM15A-COM), and it doesn't appear to be dimmable.

Since there were rumors that they had closed a far-east manufacturing plant, perhaps the "out of stock" condition was due to the ramp-up time of their new manufacturer. If they do introduce a redesigned CM15A, I'd hope they fix some of the bugs and shortcomings of this one, and give it a new number.

[Brian H]

The old LM15A isn't dimmable either.
Maybe they used a better triac so it dent fail with a bulb blowing out.

[MD Corie]

Well, X10 has been saying they are getting more of them in someday.
They just posted on FaceBook that they have SocketRockets again.
However, it looks like a new part number (LM15A-COM), and it doesn't appear to be dimmable.

Uh-oh...  I have a couple of SocketRockets with CFLs in them.  I thought mine said they were non-dimmable, so I'll have to confirm that ASAP!  (Fortunately, they are only being controlled with plain On/Off commands, anyway).

... If they do introduce a redesigned CM15A, I'd hope they fix some of the bugs and shortcomings of this one, and give it a new number.

Here, here!

[Noam]

The old LM15A isn't dimmable either.
Maybe they used a better triac so it dent fail with a bulb blowing out.

You're right, the old one wasn't dimmable, either. I was going on a comment that someone posted on Facebook about these not being dimmable. I never paid attention to the old one (since I don't have any).
The page shows the new model number.  I'm not sure if it is CFL/LED friendly or not.  The upper part of the page says "any standard incandescent light," while the lower part (in the picture) says "accepts ALL light bulbs."

[MD Corie]

...  I'm not sure if it is CFL/LED friendly or not.  The upper part of the page says "any standard incandescent light," while the lower part (in the picture) says "accepts ALL light bulbs."

Good question!  From experience, I can vouch that none of the SocketRockets that I have put CFLs in have failed or had other problems - unlike some others that have failed (repeatedly) while having ordinary incandescents in them.

[Noam]

...  I'm not sure if it is CFL/LED friendly or not.  The upper part of the page says "any standard incandescent light," while the lower part (in the picture) says "accepts ALL light bulbs."

Good question!  From experience, I can vouch that none of the SocketRockets that I have put CFLs in have failed or had other problems - unlike some others that have failed (repeatedly) while having ordinary incandescents in them.

Well, per their Facebook rep, "The model number is still LM15A. The only change that has been made is that they respond quicker to programming. They are still not compatible with CFL bulbs."

[MD Corie]

...  I'm not sure if it is CFL/LED friendly or not.  The upper part of the page says "any standard incandescent light," while the lower part (in the picture) says "accepts ALL light bulbs."

Good question!  From experience, I can vouch that none of the SocketRockets that I have put CFLs in have failed or had other problems - unlike some others that have failed (repeatedly) while having ordinary incandescents in them.

Well, per their Facebook rep, "The model number is still LM15A. The only change that has been made is that they respond quicker to programming. They are still not compatible with CFL bulbs."

I'd say that's typically ironic:  They have been working with CFLs (which they're reportedly incompatible with), but some have failed repeatedly when used with 100W incandescent bulbs (which is what they are supposedly intended for).  Go figure...

[Brian H]

The triac in a Socket Rocket even when full on. Can effect some CFLs. I have a CFL that generated lots of X10 power line noise as read by my XTBM when in a Socket Rocket.
The no CFL statement is a cover you butt thing. On the chance a certain CLF destructs. They can say "We told you not to use a Socket Rocket with a non incandescent bulb". 

[MD Corie]

The triac in a Socket Rocket even when full on. Can effect some CFLs. I have a CFL that generated lots of X10 power line noise as read by my XTBM when in a Socket Rocket.
The no CFL statement is a cover you butt thing. On the chance a certain CLF destructs. They can say "We told you not to use a Socket Rocket with a non incandescent bulb". 

Maybe I just got lucky with my (few) CFLs, then...  I've never detected any noise issues on the system.  (Thankfully - because there are enough other problems).

The thing that baffles me is why the SocketRockets tend to self-destruct when used with the larger incandescent bulbs.  Mine say they are rated for up to 150W bulbs, and so I'd think a 100W would be well within the rating.  And I use them either full on or full off, not dimmed.  I wonder if there is some issue with cooling;  do the SocketRockets have to be installed in open-air sockets, as opposed to semi-enclosed fixtures, in order to get adequate cooling?  On second thought, the failures occur within 30 seconds after installation, so it doesn't seem like things would heat up to a failure point that fast...

But we digress...