Multiple Devices with the Same Network ID?


(Convinced ST will never be unbroken…) #1

Is this a no-no? I have a server that commands a number of things in my house that SmartThings can’t. I would like to set up several device types for this that would have different On/Off capabilities within SmartThings i.e. Device 1 = Whole House On/Off, Device 2 = Media Playback On/Off, Device 3 = Entertaining Scene 1 On/Off, etc.

But the device for each of these types would of course have the same networkID. Will this confuse SmartThings or does it not care?


(Patrick Stuart [@pstuart]) #2

Responses to that device id would not know which device to route too.

It is a big limitation if you ask me… But only for a small number of situations. For example, connecting to another HA system.

You have to program ALL device functionality within that one device, or at least separate it across ports or multiple IP’s bound to that device.

Not an ideal solution.


(Convinced ST will never be unbroken…) #3

What if I am not interested in responses? only sending commands.


(Geko) #4

One possible solution to your problem is a “Service Manager” app that handles all communication with your server. I believe this is a “proper” way to integrate 3rd party systems that include multiple devices behind a single IP address. The app creates slave devices dynamically and devices don’t talk directly to the server. Instead they call the parent app to do all the talking. This is how my X10 bridge works.


(Convinced ST will never be unbroken…) #5

Well, it really is only one device; a GC iTach. But I would prefer to map the controls of each IR controlled component in separate devices rather than mapping the controls of all 8 of them to a single device.

Never wrote a service manager before, but the last time I looked into it I gave up.


(Geko) #6

iTach is not an end-device in this case. It’s a gateway to multiple IR end-points. It’s the same with X10. The X10 transceiver is a gateway to multiple X10 switches.

Writing service manager wasn’t trivial, but I looked at other options and all of them sucked, so I bit the bullet. Next time it’ll be easier. :smile:


(Convinced ST will never be unbroken…) #7

But all of the devices for an x10 SM would be similar right? The devices I am trying to manage would be very dissimilar. Maybe I should reconsider the great big honkin’ all IR A/V gear device.


(Geko) #8

So what? You need to create ST device types for each device you’re going to control anyway. Your service manager app should allow user to choose what type of slave device to instantiate. Writing SmartApp UI is the biggest challenge for me, because it’s so wonky. :smile:


(Convinced ST will never be unbroken…) #9

Really don’t need much of a UI; I use iRule to control this stuff day to day. Plus a UI in SmartThings for an HT pre/pro with dozens of functions would be a nightmare.

Just need to map the functions I want automated control of so I can use SmartThings events and get endpoints to mute/pause for things like Tasker to hit when the phone rings, etc. For me, the big honkin device type is doable; but I am afraid I’d run out of tooth enamel long before I got a service manager working.


(Geko) #10

Sure, it would work, but what if you want to control multiple devices, like TV and receiver. Both of them have mute() function. How do you differentiate which device you want to mute, assuming that you implement capability.musicPlayer in your device? I guess you could use custom commands and attributes, but then they would only be known to custom apps. A generic app would not be able to take advantage of your device type. Just a thought…


(Convinced ST will never be unbroken…) #11

TV’s have no audio controls to map. All audio controls are via a pre/pro or AVR’s; problem is there are three of them, so I would have to come up with a logical naming schema.

I’ll have a look again at service managers as I get your concerns. Any pointers on an example that isn’t all clouded up with a lot of hardware discovery?