[SOLVED] CM11A gets 'stuck' (and fix)

Well it looks like I've found the source to a recent spat of control
problems. It's my new laser printer. Here's what happens: when the
laser printer starts up there is a sudden dip in the power because of
the laser heating up (or at least some heating element is heating up).
This causes my CM11A to get stuck. I can talk to it like when I send
commands but the commands never get sent. Normally when the CM11A
gets stuck I can just use another device to send an X10 command. This
usually unsticks the CM11A. That doesn't work in this scenario. To fix
this problem you must unplug the CM11A and plug it back in. Then it
begins to work fine. Both the CM11A and the printer are on the same
circuit. I'll have to change that. One more thing to note, the CM11A
doesn't get hot. I left this problem over night and the CM11A is cool
as it normally would be.
So the short of it is that the CM11A doesn't like brown outs.
Reply to
Neil Cherry
Loading thread data ...
Hello Neil,
Those are the typical symptoms of what us analog/mixed signal guys call a "dirty reset". Happens a lot, even with expensive equipment such as the multi-purpose hub machine here in my office. Somehow the art of designing a proper reset hasn't sunk in :-(
Even some micro controller data sheets suggest a simple RC scheme for the reset. That isn't going to cut it for brown-outs.
Reply to
Joerg
It's the fuser (uses heat to fuse the toner to the paper). The laser is a minute fraction of a watt unless you have special equipment (and don't the feds require a license?) to laser engrave your printouts into something more substantial than what you buy at the office mart. :)
Thanks for posting this. I hadn't tracked it down, but I think that must be happening to my CM-11 when the central air cycles quickly (comes on again while high pressure is still in the system). Probably I'll have to wait until next summer to figure it out. :)
sdb
Reply to
sylvan butler
I documented that brownouts could cause CM11A lockups several years ago. I found some instances where it was necessary to leave the CM11A unplugged for some undetermined length of time to clear it. I tested by rapidly cycling a rocker type switch on a powerstrip.
If my memory is correct, it was you who (with a long wail of frustration) first reported experiencing problems that you speculated were due to brownouts. This was all way back, shortly after the CM11A was introduced.
Neil Cherry wrote:
Reply to
Dave Houston
My memory was OK (at least on this point).
formatting link
You had posted earlier detailing the symptoms and expressing your frustrations. I alluded to your earlier post in the above thread.
Neil Cherry wrote:
Reply to
Dave Houston
formatting link
Your memory is very good, I remember that thread (to some extent). The laser printer problem differs slightly in the the dip appears to be much 'stronger' (the overall voltage is lower), it's a single pulse that lasts a bit longer and doesn't continuously 'flash' the lights over a short time interval. The previously mentioned brownouts were pretty nasty. The cause was loose crimps on the mains cable. I called the power company to repair the problem.
The previous fix (a reset switch and/or a power watchdog) won't work as this CM11A is now dieing, probably a blown PIC port. Looks like I have another candidate for a hack. Unplugging it worked for a short period of time but now it can't send any X10. It receives fine, just no longer sends. I'm now going to work on the Insteon code. Bruce Perens found out how to read and write with libusb (an open source library for talking to the USB interface). It's supposed to be portable to Unix, Mac and Windows.
On a side note, the cost of the Insteon dev kit has gone up to $199 (US). I'm going to have to bug Insteon to release Open Source compatible documentation. I'm not sure how I'm going to accomplish this. They've doubled the cost of their kit and are not providing anything extra to the Open Source community. The software they provide is all Windows based. I can see this putting a damper on things.
Reply to
Neil Cherry
Thanks, I forgot the name fuser. This is a standard laser printer and I'm happy with it other than the brown-out condition. I've put my other equipment on battery backup (but not the PLCs of course)..
Yes an air conditioner or heat pump would probably cause the same condition. Our air conditioner had a hard time keeping up with the demands this summer and caused similar problems. Also anything with a heating unit, such as a toaster oven, in could cause similar problems.
Reply to
Neil Cherry
It will likely disappear as soon as SmartHome sees this but there is some (somewhat amateurish) ZBasic code to send/receive with the 2414S that was posted by someone to the ZBasic files forum. As best I recall, it doesn't include any linking/unlinking functions.
formatting link
I haven't looked at their license lately. While they did change some of the terms, it still prevents sharing of code, etc. so I think you'll be butting your head against the wall. Maybe the fact that you're a published author will influence them.
Yesterday, I received two upgraded 2414S units to replace the two I had. I don't yet know what the upgrade entails but you probably should get the upgrade (it's free) before doing much coding.
Given the paucity of info, I surrendered a few months back and bought the SDK. At least I got it before the price increase. Reverse engineering the PLC protocol is trivial but linking/unlinking, writing to EEPROM, setting/reading the RTC, etc. pretty much requires documentation.
From all of the complaints they are fielding about the lack of quality Insteon software, I think they should have listened to us about the license terms. I think acceptance would have gone faster had there been lots of busy fingers playing with and sharing code. ;)
Neil Cherry wrote:
Reply to
Dave Houston
Libusb is what I use on Linux to talk to the cm15a. Was going to try the windows version too, but never did. (it's a bit different than the linux version)
The windows version is under libusb32 on softforge, while the linux version is under just libusb
Reply to
AZ Woody
It DEFINITELY would have sold me some units. I specifically did not buy the sdk and etc. because I did not want 1) code was not freely available and 2) I did not want to be contaminated by restrictive licensing.
sdb
Reply to
sylvan butler
Hello Sylvan,
That begs the question: When will they ever learn? Many a fine bus or protocol has quietly gone lalaland because of elitist treatment. Either too restrictive or too expensive, or both. Remember GPIB?
Reply to
Joerg
Thanks I may need that info later on. First I'm going to get things working under Linux! :-)
Reply to
Neil Cherry
No! ;-)
Reply to
Neil Cherry
I think the code will be OK, I had spoken with them about that very subject. I made it very clear that my comments would contain various information that is contained in the docs. The Insteon rep had no problem with that. I'm still puzzled by their lack of Open Source. They seem to think that they have and open product. The one thing I don't want to see right now is their SDK document posted to the internet, at least not until I can get them to OK it first (that wasn't aimed at you Dave).
This may be the first useful thing to come out of the book. :-) I'm still not used to that title. But since I've got I'd better flaunt it while it's worth something.
I know this is one thing that really bothers me. I'm beginning to wonder about their quality control and the control of the protocol (3 big changes to the way you talk to the PLC, not nice). I'll talk to Bruce to see if he's had any experience with this kind of thing. Maybe he know's an Open Source expert that can help. otherwise it may be off to UPB me.
Reply to
Neil Cherry
I'm hoping that I can forget it someday.
Reply to
B Fuhrmann
It certainly seems to violate the letter of the license. But, I think the license is deliberately ambiguous so they can say (as they have) things like, "It really doesn't mean THAT." and "You cannot do THAT."
As we discussed before, I think publishing the documentation and then charging a one-time fee for support (with various tiers) would work much better for most developers without increasing Smarthome's support burden. Of course, their corporate developers might object.
For all its defects, X10 did a good job in this area with details of the protocol published early on in Circuit Cellar (with Dave Rye's help). Of course, they've now gone the other way with the CM15A.
So, what have you published lately? ;)
Of course, you'll be remembered longer if you made some serious errors. ;)
On the one hand they do have an excellent policy of replacing defective units or upgrading units for free. On the other hand, they seem to have more need for such a policy than do most manufacturers.
Reply to
Dave Houston
I agree whole heartedly, very ambiguous! I'd like to see a clear license that allows the Open Source community access to the documentation.
My opinion; the Open Source (OS) folks would get no BBS support because they didn't pay for any. I wouldn't mind hosting a support forum on my bbs for such a thing. The OS folks also wouldn't get the software that comes with the dev kit (I haven't been able to get any of it to work when my controllers go AWOL). We would need to find some channel to share bugs in the documentation but not the same support as the paying customers.
This is a shame, it is my opinion that the first challenger to have a stable product may very well beat X10 in the HA market. X10 seems to be putting no extra effort to challenge the competitors.
Well not published but I'll be on The Linux ink Tech Show on Oct 11th. (
formatting link
:-) I'm also getting back to work on the Insteon stuff. Bruce Perens posted some code that should make it easier to use USB devices with Linux (no more driver and kernel compiles). I'm also making a Linux based HCS II (see
formatting link
). Plus a few other things (I always have too many projects). I may take my extra chapters and convert them into articles for one of the online magazines. There were 2 partial chapters that took too long to write and added another 60-70 pages to the book.
Oh I think I have that covered, in many ways! ;-) Right now I have to spend the next few days creating a few web pages for the book's support. What I currently have is not enough.
I must say I am pleased at the response so far, most has been positive and the complaints have been mistakes such as a corrupted file or missing files.
I'm a little surprised that my coworkers have let one mistake slide. I posted a diagram with ~6 network devices with the same IP address. If I did that in my professional work I'd never hear the end of it.
I've got to send a bunch of stuff back (recall items & hosed up serial controllers). I also need to purchase more stuff to solve a complicated '3-way' problem in my home. The CFO won't be happy if this stuff doesn't last as it's wall switches (one is an actual 2 way setup).
Reply to
Neil Cherry
I agree. I thought X-10 might respond with something new to protect their market but, from Dave Rye's posts to one of the myriad of HA related forums, they appear to be content to rest on their laurels. Or maybe they've decided to just buy stock in Smarthome.
I think Insteon, with its low prices and fundamentally sound technology has a good chance to supplant X-10 if they don't continue shooting at their own feet. A few new third-party products are starting to appear.
And, the news that Square-D will be introducing Clipsal C-Bus here is good news for those building new where they can hardwire. They have a really broad array of devices.
Reply to
Dave Houston
A key to Insteon's success will be the RoZetta product. Not only will it allow "legacy" controllers to remain viable but the X10 mapping enables one to use a controller "on the fly" by simply allowing any controller to operate an X10 mapped Insteon module without registering it.
Reply to
BruceR
I saw the link the other day and that looks interesting.
C-Bus has an Open site which has not Open software. Sort of like Open VMS, not very open.
Reply to
Neil Cherry

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.