Print

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

[hackware]

Hi all, new to this forum and have old but basic x10 setup with AH and CM11A a few wall switches and remotes.  Forgive my newbie transgressions please.  My question could not be answered with 30 minutes of searching here so I apologize if it's a re-hash.  Also, this is quite lengthy because I don't know the knowledgebase of the members so I spewed out more theory than specifics. 

Here's my goal  - I would like to build a better integration between my custom electronics and the x10 world so I can take advantage of the common off-the-shelf solutions of x10 and PLC systems in general.  I need to be able to read data from the outside world via my custom circuits into my x10 software and react to it by sending x10 commands and/or data to the outside world back through my custom circuits again.  This must all occur seamlessly to x10's native environment and must use a small percentage of the resources/capabilities of the x10 system to maintain maximum potential for x10 system growth. 

IE - I want to read and or write 8 to 16 bits of data to/from at least 256 different IO ports (prefer 1024) using only x10 software like AHP, simple custom or ready made hardware, and use only one range of device codes in a single house code.  If a solution exists already or this has been done already, please direct me to the answer and don't bother to read further.  Otherwise if you would like to offer suggestions or comments, please continue and read the more detailed information below. 



Here's my present X10 setup - The system includes all "safety" lighting - IE all exterior & a few key interior lights.  I have a centralized rack for all home electronics.  All relevant lighting circuits have been re-routed to source from this point.  I have a variety of master x10 wall switches located in their original remote location and have added related slave switches at the rack and at additional remote locations in typical x10 3/4 way wiring.  The result is the last switch in the chain is at my rack so that I can connect it to the feed to the light circuit.  All my x10 devices are on 120V circuits from a subpanel I installed on that rack at which my transceivers are located for each house code and for my CM11A and the AH PC.  (improved communications reasons).   The whole system operates in basic mode - x10 switches & remotes function as simple switches or dimmers (this is for simplicity sake for wife who knows the UR TV remote functions only - press x10 then 2 for LR, 3 for MBR, etc etc).  I rarely use the AH setup other than a couple of obscure macros. 

My electronics curve balls - At this rack I have custom circuits that control all my x10 lights as well as much else.  The x10 devices are default in control but my custom stuff takes command over the circuits by individual relays for each lighting circuit.  A variety of analog and digital sensor signals are the input to a control circuit and with boolean logic the varied A&D outputs are controlled without PC supervision.  The reasoning for this is the extreme control over conditional actions as well as the unlimited variety of sensor input.  For example I've built and installed multiple moisture sensors and flow meters to detect unwanted water and whether it's a leaking pipe or a guest with bad aim in the bathroom.

My needs - I need the ability to easily integrate my x10 software to use my sensor system as input and be the supervisory command center over my non-x10 output control circuits.  I could build my own PC  IO card and software that could integrate into AHP, but the quantity of detailed work to do this makes x10 upgrade/expansion a bad choice.  For x10 to be the option I need an OEM option or an easily built custom solution that will function directly with x10 software.

My idea - A circuit behind a single x10 house/device code that will take the dim commands as input to an address counter which could then be decoded to select 1 of many input or output ports built to simulate a standard x10 device.  The theory is that a series of dim commands is sent to an x10 address where a counter circuit is incremented.  Any subsequent status request or on/off command to that x10 address will be sent to the circuit selected by decoding the counters value.  Can't recall # of steps possible but say there are 100.  An off command followed by 50 bright commands will reset the counter to 0 then step to 50.  An immediate status or on/off command gets/sets the binary value at address 50.  An on command would send a logic 1 to address 50 where a circuit exists that might start a car by remote or actuate a relay that directs an audio or video source to a certain room.  Potential is unlimited when you incorporate registers for addresses, commands, and flags.  Each bit of those registers would reside at a unique address selected by the dim command process.  You could write a 16 bit address, an 8 bit command word, and a 32 bit data value into bit registers at 56 consecutive addresses  then set a combination of status flags at the next few addresses which trigger your output circuit to process the entire 56 bit data string.   It sounds very cumbersome, but anyone who has programmed a microcontroller with paged memory or paged IO space will recognize this common IO interface where hardware constraints limit the number of wires to the real world.  The fact that CPU speeds far outpace real time events USUALLY makes moot all the overhead involved.

Problems -
First is the reliability of PLC.  Can I always be 100% sure the same number of bright/dim commands I send are received by the counter circuit?  If you've quit laughing yet, we can state the obvious - we don't know the address produced by counting dim commands will be accurate.  Not sure how this could be overcome but possibility is averaging of multiple transmissions and address ranges (6-15 selects 10, 16-25 selects 20, etc)

Second issue is the USUALLY just above.  PLC data speed compared to CPU speed is like sound vs light speed.  A complete execution cycle of one paged IO address & command could take many seconds and maybe tens of seconds to occur, something any x10 user has experienced as the delay between flipping the switch and the light turning on.  OK for lights, but unacceptable for real time control of motorized or mechanical functions. 


I bought white papers years ago to build the PLC interface circuits that could accomplish my needs.   I just don't want to put that much effort into something with such a narrow an application.  I could also easily build an IO card as noted above.  However, that would require some custom PC programming which require more resources than I can devote right now, financially or time.  Using a bit mapped logic  interface to my custom circuits with a software front end means my custom circuitry won't become obsolete or require major changes due to new or improved future technologies.  Custom circuits needed to interface to x10 software  are my safest bet since it is unlikely the command structure of the current x10 plc systems will be obsolete anytime soon.  At least not before my kid graduates and I spend her inheritance on an RV at which point all my projects become recycling material.  Also, x10 software is easily customized with simple macro's and vb-scripts are an easy way to integrate my circuits to PC software via x10.

I would appreciate any feedback of any kind.  From pros & con's of my plans, suggestions for changes or warnings of pitfalls I may encounter, to public humiliation by pointing out a glaring rookie mistake.   I always prefer brutal honesty without regard to word choice as long as the messengers intentions are sincerely constructive.    Also, in the unlikely event this is a new situation or one without a good solution yet,  this project could produce results that benefit others in the x10 community.  I pledge to freely share here any success I have and to assist others with similar goals or projects.  This is something most take for granted as the spirit of a user forum but it needs to be acknowledged now & then, especially since I am a newbie here.

[JeffVolp]

Have you considered using the already defined X10 Extended Command?  That tacks an addendum onto the command that can contain any kind of data.  Leviton uses it for their pre-set dim commands.

Jeff

[hackware]

I remember reviewing it quite a qhile back.  not sure of the reasoning I had for not wanting to use it at the time.  I think I was contemplating x10 versus custom electronics in general and the prospect of communicating with the plc interface (523???) using my newly emerging discrete device circuits was more than I wanted to tackle in the beginning stages.  Might be worth another look since my goal is to use the generically available x10 software.  I'll look it up, but I'd appreciate if anyone has suggestions on a decent "free" reference source about extended x10 command definitions  and it's function/capabilties.

Thanks Jeff.  I'd totally forgotten this one. 

[gil shultz]

Multi IO at one house/device code

What you want to do is not really feasible because of the inherent un-reliability of the x-10 system on the power line. ZigBee may be a solution.

What you are suggesting could work but it becomes fully custom and very difficult to operate for the user.  The basis of the X-10 system is 256 control channels.  If you take a trick from the telecom people and subnet your system you can easily get what you want with standard parts but it will require some work on your end. 

Your home has two subnets already (if in the US), that is each phase of the power line.  With that by putting your X-10 units on separate circuits and isolate those circuits from the rest of the house at the X-10 carrier level with traps etc you can generate as many subnets as you like.  This is very expensive to do and will need support from your local electrical inspector.  I would not recommend doing this for the faint of heart or if you do not have a lot of time which you indicate you don’t.

My solution was to go to a 24VDC control system and a dedicated PC (an old windows 95) box.  The control software runs under dos and windows gives me the networking I need.  I was using a Lynx-10PLC for the power line interface but could never get it to operate reliably.  As for custom I/O cards I used Acrosser AR-B2201 I/O Boards.  Each has 64 I/O.  There have been no problems with the I/O boards.  I used the outputs of this to drive a ULN2003 type of device (7 500 ma outputs) per chip.  I then wired LEDs with a parallel resistor in series with each relay.  This was for trouble shooting and would only light if current was actually flowing through the relay coil narrowing any problems to either the 115V or 24V side.

Note for safety and code requirements the insulation of the low voltage must meet the requirements of the highest voltage in the relay box.

There are commercial programs such as HP’s VEE that can do the software part for you.  I use a custom software program I wrote myself any years ago along with an old fossil drive from my BBS (007’s Runway).

Hopefully this helps.
Gil Shultz

[hackware]

Hey Gill thanks for some great alternative ideas.  That's what I was seeking.  I have currently alot of custom control circuitry, mostly 12 & 24 VDC relays that I originally located in the Jbox of each light.  Originally used SPST, and switching to SPDT w/2 120VAC sources - photo controlled on NO and relay controlled area source on NC allowing all lights in a group or area to be turned on simultaneously. The SPDT relays need an additional "hot" to each fixture/relay location so it was more efficient to centralize my relays and reroute the "hot" for each lite to the central location.  Doing this opened the door to all sorts of options so I created an overall project plan under which this project is just one in a series.  Otherwise I would never complete anything.

Funny you mention the old pc system.  I do/did have a 286 that used to run the basic system.  I had standalone Z80 boards supervising real time I/O that had RS232 ports hooked to a 4 port digiboard on the 286.  I wrote a custom menu interface with Turbo Basic that supervised a mess of IO routines, a mix of 8086 ASM, .COM files supplied with the digiboard, and creative use of DOS interrupts and batch files. I had an internal Hayes 2400 (smoking hot at the time) and ran Procomm scripts for remote control which was later upgraded to PC Anywhere.    Ahhhh, those were the fun days .... errrr well maybe I should re-think that - adding 256K of RAM by piggyback soldering 36 ram chips and a decoder IC wasn't so easy.  Might take a year & a megawatt to upgrade to 1 Gb of RAM.   

But as you can tell I am an old DOS and discrete component guy and am fluent in machine level coding on several platforms.  I love this stuff and my #1 priority is enjoying my hobby, not to become the ultimate couch potato, so any project must incorporate these things in a major role.  The time consumption is not my barrier to going the all custom route that would be the most fun for me, but the real issue is in the final goal I established for the plan noted above.  That goal is 100% automation of every electric & mechanical device with integrated whole house multimedia all under a central control system that is accessed by a range of  hardware & software interfaces - IE a multimedia GUI using RF, IR, wired devices, video, voice, internet, etc.
Much of this is too complex or expensive to build in light of all the existing cheap hardware & software out there today.  The electronic control of electric or mechanical items is the area I will custom build, but the rest will incorporate commercial products that can be intergrated easily.  X10 has software packages that meet some of these software and user interface capabilities and that's why I want to review it's possibilities to integrate my custom electronics.  It may be the worst choice out there but with my existing X10 hardware, I thought it worth a looksie.

Your suggestion about subnetting my X10 setup is quite interesting to me.  The difficulties you mentioned are not issues for me.  I live in unregulated area as for codes, but I am quite skilled in basic residential electrical and I tend to go overboard related to meeting safety and capacities.  For example all my wiring is in conduit with every strand of wire and jbox color coded and labeled to standard practice.  So I already know on which phase every wire I've installed is on.  My X10 reliability is also fairly high as a result of my wiring practice.  All my X10 devices source power from it's own subpanel which I've isolated with blocking filters from the main panel.  I also use multiple receivers, extended antenna's, odd house codes, etc, all of which has resulted in nearly perfect performance. 

My only issue was the pc integration and software.  Can't remember the device model of the transceiver, but it had batteries and locally stored macros that ran independent from the pc.  Had 2 of them and both had spurious operation if they operated at all, thus my original questioning of the reliability for accurately reading or writing data to devices.   My concern about the limitation of addresses was based on 1 bit per address relating to one IO line.  However, your subnet suggestion noting the 256 addresses put my mind into hexadecimal mode.  Using 8 X10 addresses I could write an IO address register that decodes to 256 devices and could read/write to that device at a 9th X10 address.  That avoids the reliability issue using the dim/bright commands I thought of before. 

For example,  I can access 1000+  address by writing an address bit to 10 unique X10 addresses & read them back for near 100% reliability.  Using a few more X10 addresses for status & control registers and 16 more X10 addresses for data lines, I would have a 16 bit wide I/O bus with 1024 addresses with just 2 full X10 house codes.  Cumbersome software process but a viable one if I use X10.  This process might be very familiar to others who remember the pre-386 days of the pc and the use of expanded memory.

Last comment in my novel here - what is Zig-Bee?  likely another plc system but I've never dealt with it.  I'll google it, but would like your input as we seem to have similar experience and tendency to creative re-engineering of stuff to fit our needs.

[gil shultz]

Good Afternoon,

Simply stated Zigbee is a wireless RF system that retransmits every signal it sees.  This way all you need is one module in range of another.  If there are more the robustness and reliability of the system increases exponentially.  It is not the cheapest kid on the block but is supported by several microcontroller manufacturers.  I believe Renesas has or will have a micro with all of it on a single chip.

AS for I/O the Acrosser AR-B2201 I/O boards give you 64 I/O at a very low cost.  The I/O is TTL but that is easy to convert to relays with a ULN2002 or similar chip.  Then with Basic you can “peek” and “poke” or whatever it is now-a-days and controls the I/O.

You probably know that when putting relays in a box the insulation for all the wiring must be rated for the higher voltage according to our local building inspector and the version of the NEC I have.

Enjoy
Gil Shultz

[hackware]

thanks again Gil for the follow up.  always like to see how others wire their pc's to the real world, especially those that give an old dog something to do besides become another boat anchor.

I've decided it's just not worth the effort to try and use x10 in this manner and am just going to utilize a control pc with custom I/O boards and control cards.   And for the remote access I've decided at this time not to setup a real time interface via the web (part of the desire to use x10 software and it's remote ability).  In the meantime I'll use a "near time" interface.  I'll use a couple text files on my website and use polling scripts to access them from my control pc - upload status & event logs and maybe some graphics and download a command file that is created via a remote web connection.  Crude but simple and absolutely un-restricted potential to do what I want - the very reason we build it & not buy it.

PS - my plans for the centralized relays includes a dual voltage box arrangement to satisfy the insulation issues.  the relays will all reside in the HV side, likely socketed or on a pcb with properly sized copper foil.  the LV coil circuit will be connected via a multipin socket, where the coil circuits on the HV side are hardwired to a socket in the physical divider of the enclosure using the proper HV wiring .  On the LV side, the output of the coil circuits on my PCB's will be wired to the mated plug and allow me a quick disconnect for complete voltage isolation when I remove or work on the LV side.  Also it lets me use a cable length to locate the LV side remotely since the relay panel won't have easy access.

[gil shultz]

Good Evening,

I took the less expensive way as I currently have about 140 active channels.  I used standard electrical boxes (4” square) etc depending on how many relays I needed at that point.  I used a foam double sided tape to fasten the relays to the box.  I also cleaned the area where the tape would be with lacquer thinner because of the oil left on the metal from the manufacturing process.  I used all metal boxes and they are all grounded with the ground wire.  By design your control voltage will probably be grounded through the PC interface.

Since I have everything in the basement; I would fish a piece of Romex from the existing switch etc to the electrical box and connect the wire to the normally open contact.  I actually soldered a short piece of very flexible stranded wire to the relay and then used wire nuts to connect to the romex wire.  I originally used the festoon connectors but they were not that great with the solid wire.

I then ran Cat 5 (600V rated but hard to find) from the box to my computer.  This gave me a maximum of seven relays on one cable.  This met my insulation requirements and did not need a barrier to separate them.

I then invented a device called a “Shunt LED”. The Shunt Let is nothing more then a LED with a 39 ohm soldered across it (I used SMD devices).   My relays were 24VDC coils that drew about 55MA.  The Shunt Led was placed in series with the 24V control feed; note this is polarity sensitive.  Now I can tell at a glance if the LED is lit the relay is closed if not it is open.  The Shunt led makes it simple to isolate the problem to either the control or power side.

I am using a 28 Volt DC power supply.  I lose about 2.5V through the Shunt Led and about 1.5V through the driver chip; this gives me 24VDC at the coil minus the line losses.  I also built the interface with the driver chips and each one is fused with a 1 amp 250V fuse to protect against a short to the power system.

Some of the functions are more involved and those have a special cover plate.  I simply took the standard metal cover and put a piece of paper (printed with the labels etc) on the lid with spray adhesive and then covered it with a piece of book binding tape (about 6” wide); makes a nice looking package.

Be careful as you are working with lethal voltages and enough power to set your home on fire.

Have Fun
Gil Shultz

[hackware]

wow Gil that is an impressive setup.  Nice to talk to someone else who gives a .... about the extra details that make a good job a fanatastic one and unfortunately also allow shysters to make a horrible job look good enough to get paid and out the door.  obvious which version you are.  I noted the shysters as it is a pet peeve of mine that can't be fully appreciated without your viewpoint of the details.   I believe my own finish work to be on par with yours, but I follow a different drummer during my developmental phases.  That's because I spend alot of time in the theoretical twilight zone since that is what I enjoy most.  I incorporate alot of surplus equipment and build very modularized & often minimalized prototype hardware to weave them into a final product.  The cost is substantial for 140 channels no matter how you design it. 

My reason for centralizing mainly is for the vast possibilities it allows for control, function, usefull life, and upgrade paths.  However, another and equally important parameter was aquiring several surplus relay boards. On a whim I grabbed 5 ($10ea or $40/5).  The pcb's had 8 SPDT relays w/12V coils and 10A contacts.  At $10/board (5 for $40) it was worth desoldering those relays.  When I got home I checked the boards a bit better and discovered a real treasure.  Each board was in a static bag and sealed in a sized padded box.  The circuitry includes a basic logic interface separated in 2 banks of 4, a 4 bit input latch with input enable tied to 1 of 4 select lines via microswitch.  The latch feeds a ceramic DIP driver IC (a ULN200?)  that sinks the coil current via an enable/disable slide switch and indicator LED.  DC power and all logic signals tie to a 1 row multipin header for ribbon cable.  The relays directly connect to the +12VDC rail and the neg side is in series w/indicator LED & Resistor then the slide switch, and finally to the current sink driver IC.  The HV relay pins (C,NC,NO) are individually connected via short wide foil lands to a pcb mounted 24 pin screw terminal strip.  The term strip and all HV components are physically and electrically isolated from the LV components and foil patterns. 

The only drawback I found was physical size.  The PCB was designed to be mounted directly on the back of a display or control panel with the slide switches and indicator led's exposed for access.  So the pcb size was dictated by the panel's size and layout and has a lot of unused area on a footprint measuring about 6"x14".  I'll build a custom logic PCB as a backplane of sorts. On that PCB I could use some latches, decoders, a couple tranceivers, a few logic gates, and a simple 555 clock circuit for a single common interface.  Then I could do all the IO and do a soft config for every board and latch using just one or two bytes of I/O to the LPT port on the pc.   

I agree the expense of a centralized AC wiring plant is the expensive route, but it is something I have been working towards anyway.  Every new light or rework of an existing one has included running a single source conductor to every fixture with a common neutral for all source conductors at each jbox.  ie - a 3 bulb floodlight on the corner will have 3 blacks, 1 white, and 1 ground.  All the conductors terminate at my central panel.  The final stage of any switch circuit is also routed to this panel and cross connected to it's related fixture source feed.  Neutrals are all isolated to their related branch circuit to maintain overload protection from the branch circuit breaker.

The potentials for this arrangement is vast.  At the very least, every bulb could reside on a unique control channel allowing individual control of each bulb in a fixture with 2 or more bulbs.  Advantage of this is obvious on outdoor flood lights.  If each corner fixture has 2 bulbs, each aimed on a different side, you could lite up only the side you needed.  Why lite up the fence on the side of the garage every time you lite up the driveway?  In my case I have several 3 bulb fixtures covering 3 different areas and arranged so that each area has at least 2 lites from 2 directions.  With camera lighting you don't want shadows and invisible areas that obscures the view.  Large areas are poorly lit by multiple bulbs in one place.  Three bulbs at one end of the driveway give less coverage than 2 bulbs placed at opposite ends.  The glare blindness looking into 3 lites or the poor visibility in the low light your shadow causes with them at your back are both greatly reduced or eliminated by using less lite from multiple directions.

Another advantage that is not so obvious but has far more "fun" potential is the routing and control of the source power.  Using a centralized plant gives much greater manipulation of the system without the huge costs of altering the wiring infrastructure to accomplish any major changes.  Also,  I'd be more likely to try something that I otherwise might not because of the cost. 

PS - In answer to your cautions, I am fully aware of the dangers at these voltages and that 120VAC is deadlier than higher voltage levels.  Higher voltages will often jolt you hard enough to break contact with it but 120VAC doesn't have that kick but instead will likely keep you in contact with convulsed muscles - a true death grip.

[gil shultz]

Good Evening,

You got it.  The number is actually 1024.  Add a bit and it goes to 2048 and keeps doubling with each bit you add. 

You can use your parallel port on the old PC and treat it like a micro buss or a serial bus, either works.  Be sure you put the I/O chip in the proper mode.

In the parallel mode label one of the control lines Address Latch Add 0, the Second as Address Latch Add 1, multiplex that into some latches and you have 4X8 or a 32 bit address buss.  Now the trick, in order to read data (yes read it) write a 0FFH to the port which is by definition TTL compatible consequently it does not have very much drive but a lot of sink capability.  This makes it easy to drive zeros into the port and 1 are easy as well, use a TTL driver at least on the first one.  There are capacitors on each of the parallel port bits so they have an upper speed limit.

As you have figured it out, you have used almost all of the control lines but we have R/W and strobe or Read and Write available as well from the remaining control lines. These either latch data into the external latches or read data back into the interface. 

This will give you the ability to control 65K x 65K x 8 individual bits.  This buss will also interface directly into memory devices especially the older cheeped stuff.  You can read and write the memory but not execute from it.

The same game could be played with shift registers or shift register chips such as allegro makes.  These can be 8 bits wide and ad deep as you like.  I did it with serial in parallel out and parallel in and serial out.  I then simultaneously shifted data into the serial in parallel out and read data from the parallel in serial out shift registers (this cut the clocks in half). Nice thing about these designs is they are not speed critical and you can code in basic, assembler, “C” or whatever you like.

We now have a lot of I/O capability.  I have built both and they do work very nicely.

Enjoy
Gil Shultz