Multiple Plug'n Play devices

I'm trying to work on a thing that has multiple Plug'n Play devices on one system. Some of those will receive a signal, some will send, and some will do both. I'm wondering how I should approach this. Here's the specs:

  • Will receive a signal and activate a load.
  • Will initiate a connection to a receiver and send data.
  • Will do the same as #2, but will receive from other #2s.

The thing is, some will be randomly disconnected and switched with another of the same thing, with multiple of those.
I'm trying to make it so that a connection is reversible, so I'd like to minimize pins. Here's what I've looked at:

  • I2C: 2 pins, but many devices will be the same model, so many devices would have the same ID, which wouldn't work.
  • Serial: takes up too many pins, and each sender would need separate wiring.
  • SPI: Same as serial.

I2C is not plug and play. The ATmega chips can go a long way, but the Arduino library does not support that.
SPI as plug and play ? I have not heard of that before. I don't know what will happen.

Serial can be plug and play. Use a protocol with a checksum, and use a start and end byte (for example 'stx' and 'etx').
It is possible to cascade serial, or some other trick.
A single TX can be connected to the RX of many modules.
When extra hardware is added, it can be changed into an open-collector bus.

What about wireless ?
How many data do you want to transmit ? 1kbyte of data per second ? or only a few commands now and then ?
How many modules will there be ?
Do you have a single Master or central control unit ? Or is every modules equal ?

Why is serial a problem? You just need to make someone a bus master to regulate all traffic...

  • Wireless: Well, that could get quite expensive (every module needing a radio chip) and I'd prefer not to do it.
  • Data: A command every time a device got added to the system, plus whenever a user sets a value 0-100.
  • Modules: As little as 2 and as much as 200
  • I could have a central unit, but every device would need to receive from/send to it.

Also, about Serial: how would I do that so that every device wouldn't send data at the same time (i.e. powerout)?

I can't visualize your project yet. How are the modules added ? with connectors or wires and to what ?
Up to 200 modules is a lot, every normal solution (I2C, RS-485) can not be used. Cascading is possible, but if a single module fails, then the modules after that faulty module will no longer communicate.

Can you tell what you are going to make ? Without knowing that, our suggestions are just butterflies in thin air.
If you, for example, want to make an art project with RGB leds, and it is fixed to a wall, then it could be possible to combine for example 16 modules with a semi-central-module, and have a single overall central unit.
Or if they will be intelligent building block to learn children about programming, then that is something that has already been done (but I don't know how).

lights0123:
I'm trying to work on a thing that has multiple Plug'n Play devices on one system.

Will this be one at a time, or a several (how many) at a time?

How many different types will there be?

How often (number per hour or day) will there be a change of device?

...R

Sorry for not explaining this well. I'm planning to have magnetic connectors (NOT just a copy of MagSafe) that are reversible for a lighting system. I want each magnetic port to fit either a lightbulb or a switch. There probably wouldn't be RGB bulbs (that's a little too fancy to start off). I think the hard part would be that bulbs would have to be replaced, and that means getting an entirely new circuit to control it. But, if there was a powerout, then every bulb would think it would have just been unplugged. Then there would be switches. They would be user-controlled switches that would be used to control one or more lightbulbs. There would be one network controller, that would talk to the internet. So, here's a list of what will happen:

  • Plugged in: talk to the power supply: will I use too much power? Yes: Turn off, send a message to a network controller. No: If I am a switch, send a message to a network controller to get paired. If I am a lightbulb, turn on.
  • Switch flipped: tell every lightbulb that is specified to turn on/off.

Is this really complicated, or is it (somehow) possible?

I would like to know so much more !
Is a 'module' only connected to that magnetic port ? or can a 'module' connect to an other 'module' ?
How many wires are available for a single module for control ? Are three wires (RX,TX,GND) possible ?
How long is the cable from the network controller to the modules ?
The protocol can be a collision-proof protocol, or with some kind of interrupt line. Is it possible that 200 interrupt lines go to the network controller ? Reading 200 interrupts can be done with a mux.
How many switches can be switched at the same time ? What delay between the switch and the light is allowed ?

The network controller could control every module. Every module should have an unique identifier. The identifier can be a 16-bit number writting in EEPROM.

Perhaps the RadioHead RF_ASK protocol (or VirtualWire) can be used on a single wire. Everyone can transmit at any time. By repeating the transmission a few times with a random delay, the collision trouble can be avoided in most cases. It won't be a professional solution since it is not fail-safe. Extra hardware is needed to filter the signal and protect the Arduino against spikes.

That's an interesting idea. I'm still having difficulty how it might work. Let's say you have a couple of switches and a couple of lights. One switch turns on or off the kitchen lights. Now we plug in a new light. How does this new light know that it's a kitchen light?

Maybe there's a programming period where a new light plugged in listens for 60 seconds and the first switch switched in that time becomes that light's switch? But after 60 seconds, it won't reprogram, so it stays linked to its previous switch, taking care of power outages.

Since you seem to want a plugged system, do you allow branches or are all lights and switches daisy-chained in a long line? I'm thinking each module should have 3-4 ports so you have more flexibility than a long line. Even if it is electrically a simple 2-port daisy chain, it is always going to be better to physically wire it as a hub-and-spoke, so all the wires come back to a central hub and then branch out from there. Power the line from both ends so breaking the chain to add a new item doesn't power off all the downstream devices.

Have you looked into the Moteino system, particularly their SwitchMote? That is wired for power but the communication is wireless. That simplifies a lot of these issues.

lights0123:
Is this really complicated, or is it (somehow) possible?

I suspect the project will not be too complicated once you have figured out how to explain it. And it may be that when you get around to writing a clear description you will also see a solution yourself.

I have no idea what this means or how it relates to your original question.

I'm planning to have magnetic connectors (NOT just a copy of MagSafe) that are reversible for a lighting system.

It certainly does not answer the questions I asked in Reply #5

Maybe it would help if you draw a diagram and post a photo of the drawing.

...R

Sorry for the late reply. Here's a photo:

I'd like not to do radio because of cost. (the whole point of this is cost: I'm not interested in buying $20/bulb plus a hub for smart lights) I could do daisy-chaining, but if someone unplugged a lightbulb/switch, then everything else doesn't get a signal (I could have a controller in the plug, though. It would connect the data lines when something isn't plugged in).

Peter_n:
I would like to know so much more !
Is a 'module' only connected to that magnetic port ? or can a 'module' connect to an other 'module' ?
How many wires are available for a single module for control ? Are three wires (RX,TX,GND) possible ?
How long is the cable from the network controller to the modules ?
The protocol can be a collision-proof protocol, or with some kind of interrupt line. Is it possible that 200 interrupt lines go to the network controller ? Reading 200 interrupts can be done with a mux.
How many switches can be switched at the same time ? What delay between the switch and the light is allowed ?

The network controller could control every module. Every module should have an unique identifier. The identifier can be a 16-bit number writting in EEPROM.

Perhaps the RadioHead RF_ASK protocol (or VirtualWire) can be used on a single wire. Everyone can transmit at any time. By repeating the transmission a few times with a random delay, the collision trouble can be avoided in most cases. It won't be a professional solution since it is not fail-safe. Extra hardware is needed to filter the signal and protect the Arduino against spikes.

And have 200*2 (for reversible) connections on the connector?!? A module would only connect to a plug (or an extender).

MorganS:
That's an interesting idea. I'm still having difficulty how it might work. Let's say you have a couple of switches and a couple of lights. One switch turns on or off the kitchen lights. Now we plug in a new light. How does this new light know that it's a kitchen light?

Maybe there's a programming period where a new light plugged in listens for 60 seconds and the first switch switched in that time becomes that light's switch? But after 60 seconds, it won't reprogram, so it stays linked to its previous switch, taking care of power outages.

Since you seem to want a plugged system, do you allow branches or are all lights and switches daisy-chained in a long line? I'm thinking each module should have 3-4 ports so you have more flexibility than a long line. Even if it is electrically a simple 2-port daisy chain, it is always going to be better to physically wire it as a hub-and-spoke, so all the wires come back to a central hub and then branch out from there. Power the line from both ends so breaking the chain to add a new item doesn't power off all the downstream devices.

Have you looked into the Moteino system, particularly their SwitchMote? That is wired for power but the communication is wireless. That simplifies a lot of these issues.

How much is a Moteino SwitchMote? Also, the Yun (showed above) would act as a network bridge that would allow you to add new lightbulbs to a group.

How far apart are these devices and how much power? Eg. you want to switch 60W household bulbs on 240V and you want the whole house wired and one of those lamps is in the shed 100metres away? Or are you switching regular little LEDs like the Fritzing diagram and it all fits on your tabletop model railroad layout?

You could just google "Moteino" and find their website and their online prices. The SwitchMote may seem expensive but it's able to switch real power and may be overkill for an LED lamp.

Radio modules can be cheaper than a hundred metres of wire.

My plan is to have LEDs running at 3-20W @ 3V3 (Yes, I know, a cheap 2N3904 transistor couldn't do that). Also, I could have higher voltage (maybe 12-24V) and high-efficiency regulators at the end. Ideally, (fine, power loss would probably be too big for this) I would have around ~100 feet (~30 meters) of wires, and then a booster of some sort (If needed), and then more wires. Would this be possible? I'd prefer not to use silver wiring (that would be expensive). And with the Moteino SwitchMote, it definitely would be overkill ($35? Really? And then you need the actual bulb) when Philips Lux are $20 plus a hub.

OK, so you want an active node approximately every 30m but the total length from power source to the last bulb could be much more than 30m. Pick a wire from your electronics retailer's catalog and then do the voltage-drop calculations on it. You can calculate a voltage required for the power transmission, if you pick an efficiency or specify what power loss you will accept. (50% might be a good number.)

I suspect that you aren't going to get this wire from eBay for $5 with free shipping. It will not be cheap.

The 30m specification also rules out a few of the simpler/cheaper data transmission options. You can push RS232 over this distance but you will need to convert it to proper RS232 levels with a $5 MAX232 chip at each node. Then RS232 is not really suited to multi-drop. RS485 is designed to solve both of these problems, I don't know what RS485 transceivers cost; they must be at least $5.

lights0123:
I'd like not to do radio because of cost. (the whole point of this is cost:

The picture you posted does not conjure up my idea of "plug n play" - for example the automatic recognition of different devices (e.g a hard disk or mouse) when it is plugged into a PC.

Your requirement just seems to be a collection of devices under control of a "master" device with the option of removing or adding devices without affecting the others.

It seems to me that the simplest and probably cheapest way to do that would be with a series of NRF24xx 2.4GHz transceivers. They can be bought cheaply on EBay.

The master can be programmed to send commands which include an ID number that you have allocated to a slave. While all the slaves will hear the message only the correct one will respond. If one of the slaves is removed none of the other slaves will know.

You could also easily arrange for the slaves to acknowledge commands so the master would know they are working if that matters.

To make things easy, the programs for all the slaves could be identical apart from each being given its own ID number.

...R

So, my view of it is that you are suggesting a I2C-ish system. How would each slave get an ID number? Again, there would be many of the same type of device. Maybe a serial port on the cable itself that each device talks on to get an ID number? Also, why wouldn't hardwired work instead of wireless? Would it be that the signal would be too hard to amplify?

Store an ID number in EEPROM.

Assigning an ID number completely automatically might go wrong. I prefer to press a button for that. That means you have to press 200 buttons one by one.

My idea to use VirtualWire (or RadioHead RF_ASK) on a wire doesn't need a lot amplification. The signal is AC and could be entered into an input pin with a capacitor. As long as it is large enough to read as a valid '0' or '1', then its okay. The output stage could be two transistors (complementary emitter followers) and a base resistor.

P.S.: Could you change your signature ? I have to cover my ears, every time I read it.

Yeah, sorry about my signature. For IDs, it would be a single press for each one? I'm okay with that (If it's out of reach, install it somewhere else, press the button, and then install it). What if it is switched to a new network? Just have users hold the button when installing? I'm assuming I should just play around with my non-polarity (Yeah, I know that isn't the term) capacitors. What are complementary emitter followers? For RadioHead RF_ASK, I'm thinking RHDatagram. So you think it would be important to use RHReliableDatagram? What driver should I use?

Slow down please :o
The RHReliableDatagram could require more memory than a normal Arduino has. That is also designed for a net, in which a module can see a few of its neighbours, but not all modules.
In your project, everyone can see everyone.

The ideal would be protected shortcut-proof drivers, like RS-485 drivers, but they are ment for 32 per net.
A RS-485 does not allow a lot of noise, but the VirtualWire (or RadioHead RF_ASK) is ment to work with mostly noise. Therefor the signal and the circuit can be simpler.

I don't know how much speed can be achieved. Perhaps only 1000 bps or maybe 200 kbps.
In the old days, a terminal with 2400 baud could have very long wires.
It depends a lot on your cables and wires, how the circuit should be build and how safe and protected against spikes it should be.

Complementary emitter followers are like this : a picture somewhere on the internet

lights0123:
So, my view of it is that you are suggesting a I2C-ish system. How would each slave get an ID number? Again, there would be many of the same type of device. Maybe a serial port on the cable itself that each device talks on to get an ID number? Also, why wouldn't hardwired work instead of wireless? Would it be that the signal would be too hard to amplify?

I said nothing about I2C.

In my mind you could give the slave its number when you are programming it. But you could also have an automatic system in which the master allocates a number to a slave that does not have one and the slave could store it in its EEPROM memory.

Another option might be to have an 8 position DIP switch on each slave and use the switch to set any of 256 ID values - but that might use up 8 Arduino I/O pins so it would not be my first choice.

I have no idea where the idea of pushing buttons to give ID numbers has come from. I don't see any need for that.

I don't say that hard-wired would not work. Just that wireless would probably be much the same price and alot more convenient.

...R