So the short of it is that the CM11A doesn't like brown outs.
--
Linux Home Automation Neil Cherry nch...@linuxha.com
http://www.linuxha.com/ Main site
http://linuxha.blogspot.com/ My HA Blog
http://home.comcast.net/~ncherry/ Backup site
> 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.
>
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.
--
Regards, 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
--
Wanted: Omnibook 800 & accessories, cheap, working or not
sdbuse1 on mailhost bigfoot.com
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.
You had posted earlier detailing the symptoms and expressing your
frustrations. I alluded to your earlier post in the above thread.
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.
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)..
> 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. :)
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.
http://www.zbasic.net/forum/about271.html
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. ;)
> 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.
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
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.
>
>>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. ;)
>
>
> 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.
>
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?
Thanks I may need that info later on. First I'm going to get things
working under Linux! :-)
No! ;-)
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.
> 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. ;)
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.
> Neil Cherry <n...@cookie.uucp> wrote:
>
>>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.
>
I'm hoping that I can forget it someday.
--
Bill Fuhrmann
>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).
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.
>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.
So, what have you published lately? ;)
Of course, you'll be remembered longer if you made some serious errors. ;)
>> 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.
>>
>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.
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.
>>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).
> 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."
I agree whole heartedly, very ambiguous! I'd like to see a clear
license that allows the Open Source community access to the
documentation.
> 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.
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.
> 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.
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.
>>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.
>
> So, what have you published lately? ;)
Well not published but I'll be on The Linux ink Tech Show on Oct
11th. ( http://www.tllts.org/ :-) 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
http://linuxha.sf.net/ ). 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.
> Of course, you'll be remembered longer if you made some serious
> errors. ;)
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.
> 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.
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).
>> 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.
>
>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.
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.
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.
I saw the link the other day and that looks interesting.
> 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.
C-Bus has an Open site which has not Open software. Sort of like Open
VMS, not very open.
>On Fri, 22 Sep 2006 19:53:33 GMT, Dave Houston wrote:
>
>> 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.
>
>C-Bus has an Open site which has not Open software. Sort of like Open
>VMS, not very open.
As I understand it they allow personal use of their ASCII protocol with an
NDA. They require a license (probably with a hefty fee) for commercial use.
I'll have to do more work on that then. If that's the way they are
handling it I should give them a fair chance.
Back on the issue of Insteon. I've made a proposal to Insteon to
provide a support forum to the Open Source community:
http://www.linuxha.com/FD/phpBB2/viewforum.php?f=11
I'll be supporting any effort but not getting support from
Insteon. I'm not going to limit it to just Linux. Lets see how well
this works. I've asked Insteon very specific questions that I won't
detail here. I also need to look at their most recent Developers
Licence Agreement.
Hmm, this will be interesting my contact at Insteon is no longer
there. Looks like I have more work to do.
>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?
Yes, and HPIB (aka IEEE-488) continued and continues to quietly make money
for HP, NI and others for years. I expect that the fact that it did not
become a commodity was and is quite to their liking. Ditto for HPIL (although
HP-specific). Factoid: Used, current model GPIB USB interfaces sell for ca
$300 on eBay.
... Marc
Marc_F_Hult
www.ECOntrol.org
>
>>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?
>
>
> Yes, and HPIB (aka IEEE-488) continued and continues to quietly make money
> for HP, NI and others for years. I expect that the fact that it did not
> become a commodity was and is quite to their liking. Ditto for HPIL (although
> HP-specific). Factoid: Used, current model GPIB USB interfaces sell for ca
> $300 on eBay.
>
Sure they do but there is no market volume to speak of. I vividly
remember a discussion at Tektronix when nearly all attending users
(myself included) voiced something loud and clear: Get us a regular
run-of-the-mills method for data output and not GPIB. Then they did that.
BTW, in the days when I had to use GPIB there were ways to get around HP
and NI's high prices. I forgot the name of the company (Plug-In or
something similar, out of Taiwan) that sold PC-mount HPIB interfaces.
For the slower grade which was fine for everything I did we paid around
$60. In the early 90's that wasn't much more than we had to pay for a
regular multi-IO card. So the cost issue could be circumvented but I
really had it when one of those garden hose type GPIB cables slipped out
of the socket a bit fast and flung my favorite coffee mug to the ground.
Coffee and shards all over the lab. Luckily I drink mine sugarless.
Nowadays you can buy a GPIB converter kit or assembled board from
someone in eastern Europe. It has a uC (MSP430, IIRC) on board, resides
in the connector shell and converts to USB. That gets rid of the bulky
cables. But we don't use GPIB in the lab anymore.
>BTW, in the days when I had to use GPIB there were ways to get around HP
>and NI's high prices. I forgot the name of the company (Plug-In or
>something similar, out of Taiwan) that sold PC-mount HPIB interfaces.
I used some Ziatech ISA IEEE-488 ca 1987. So there have been lower-priced
work-arounds from the git-go. The hassle was the drivers which allowed
software vendors to dictate the interface hardware.
> NI's high prices
FWIW, they are almost _giving_ away ISA DAQ hardware on eBay, with PCI prices
not much higher. 16-input, 16-bit resolution ISA ADC/DAC/DIO and
96-input/output DIO PCI boards for $50, and so on.
One feller had about fifteen like-new National Instruments 64-input ADC (+
DIO + DAC) that went without any takers at $40. He was begging for offers.
Plenty of single-board ISA and PCI computers (SBC's) usually too.
I'll be having a porch sale soon at www.ECOntrol.org to clean out the junk
box/room.
... Marc
Marc_F_Hult
www.ECOntrol.org
>
>>BTW, in the days when I had to use GPIB there were ways to get around HP
>>and NI's high prices. I forgot the name of the company (Plug-In or
>>something similar, out of Taiwan) that sold PC-mount HPIB interfaces.
>
> I used some Ziatech ISA IEEE-488 ca 1987. So there have been lower-priced
> work-arounds from the git-go. The hassle was the drivers which allowed
> software vendors to dictate the interface hardware.
>
>
>>NI's high prices
>
>
> FWIW, they are almost _giving_ away ISA DAQ hardware on eBay, with PCI prices
> not much higher. 16-input, 16-bit resolution ISA ADC/DAC/DIO and
> 96-input/output DIO PCI boards for $50, and so on.
>
Thanks for the hint. That sure is a better deal than a Labjack although
those are quite universal and useful. Different league though.
> One feller had about fifteen like-new National Instruments 64-input ADC (+
> DIO + DAC) that went without any takers at $40. He was begging for offers.
> Plenty of single-board ISA and PCI computers (SBC's) usually too.
>
> I'll be having a porch sale soon at www.ECOntrol.org to clean out the junk
> box/room.
>
Let us know when that happens.
Nice house. I really like that winter picture. My grandmother in Germany
wouldn't have considered 1821 to be that long ago. Her house (still
there) is a lot older. The church where we got married was dedicated in
1019 but rebuilt several times because of lots of wars, fires and
lightning hits. But even that ain't old. There are lots of building from
the Romans still intact or even in use. The ones I saw were mostly about
1800 years old. These guys sure knew how to do a top quality job.
>> FWIW, they are almost _giving_ away ISA DAQ hardware on eBay, with PCI
>> prices not much higher. 16-input, 16-bit resolution ISA ADC/DAC/DIO and
>> 96-input/output DIO PCI boards for $50, and so on.
>>
>
>Thanks for the hint. That sure is a better deal than a Labjack although
>those are quite universal and useful. Different league though.
>
>
>> One feller had about fifteen like-new National Instruments 64-input ADC (+
>> DIO + DAC) that went without any takers at $40. He was begging for offers.
>> Plenty of single-board ISA and PCI computers (SBC's) usually too.
>>
>> I'll be having a porch sale soon at www.ECOntrol.org to clean out the junk
>> box/room.
>>
>
>Let us know when that happens.
>
>Nice house. I really like that winter picture. My grandmother in Germany
>wouldn't have considered 1821 to be that long ago. Her house (still
>there) is a lot older. The church where we got married was dedicated in
>1019 but rebuilt several times because of lots of wars, fires and
>lightning hits. But even that ain't old. There are lots of building from
>the Romans still intact or even in use. The ones I saw were mostly about
>1800 years old. These guys sure knew how to do a top quality job.
Here's a url of a picture taken (literally) from the upstairs of the house I
grew up in and still own and visit on the Mediterranean island of Mallorca,
Spain:
http://www.valldemossa.com/vallde.htm
That's the new (18th century?) church in the picture. The terraces built on
the mountainside were built by the Moors ca 1000. Our house is contiguous
with the palace of the Kings of Mallorca begun in 1390-something and finished
about 1405 IIRC. Famous too for a monastery also built in the 13-14th C's,
also contiguous with our house.
My first HA project involved chiseling in the meter-thick stone walls of my
bedroom to embed wires ... Folks what complain about the 'difficulty' of
pulling CAT5 through hollow stud walls in US and Canada have no idea how easy
they have it ;-)
... Marc
Marc_F_Hult
www.ECOntrol.org
>
> Here's a url of a picture taken (literally) from the upstairs of the house I
> grew up in and still own and visit on the Mediterranean island of Mallorca,
> Spain:
>
> http://www.valldemossa.com/vallde.htm
>
> That's the new (18th century?) church in the picture. The terraces built on
> the mountainside were built by the Moors ca 1000. Our house is contiguous
> with the palace of the Kings of Mallorca begun in 1390-something and finished
> about 1405 IIRC. Famous too for a monastery also built in the 13-14th C's,
> also contiguous with our house.
>
Nice! The Maurs were also great builders, as were the Egyptians and
Chinese. Just imagine who it must have taken just to get all the stuff
there. No trucks, no roads to speak of, no Home Depot in those days.
> My first HA project involved chiseling in the meter-thick stone walls of my
> bedroom to embed wires ... Folks what complain about the 'difficulty' of
> pulling CAT5 through hollow stud walls in US and Canada have no idea how easy
> they have it ;-)
>
Yep, done that, too. In Germany. Drilling a hole from first floor to
second could take a whopping 15 minutes. Or a lot more if you hit a
pebble in the concrete. In my days there I did not have a Bosch Bulldog
so it was all hand-chiseling.