Powerline to IP; IP to Powerline

[apostolakisl]

I'd like to put two buildings at my church on the same ISY.  They each have their own power system so PLC is not possible.

 

I might be able to get radio range from the using dual band devices, not sure haven't tried.

 

But I was thinking.  The PLM's go from PLC to serial.  Why can't they do PLC to IP?  Then you can have two IP PLM's at each end of an internet connection and you could transfer PLC from one location to another.

 

Thoughts?  Maybe you could even do it by using a serial adapter plugged into a PLM.

 

Just to be clear, I'm going to do my best to use radio here, but I was just thinking.

[MWareman]

There are some serial to IP convertors out there. You could pair two of them (one in server more, one in client) and extend the serial over full Ethernet distance.

 

Problem is, each ISY can talk to exactly one PLM. You cannot have two on a single ISY.

[Tim Wilson]

So, presumably, REST is the preferred method to make the two ISYs coordinate with one another. Correct?

[apostolakisl]

There are some serial to IP convertors out there. You could pair two of them (one in server more, one in client) and extend the serial over full Ethernet distance.

 

Problem is, each ISY can talk to exactly one PLM. You cannot have two on a single ISY.

 

I'm thinking that you would have a total of 3 plm's.  Two of them would be just for converting PLC to Serial and vice versa and would not have any links table.  They just would be modems.  The other one would be the one that ISY talks to.

 

 

Location 1

PLM building 1 picks up PLC on power line and converts to Serial

Serial to IP converter sends to IP

 

Location 2

IP to serial converter in building 2 converts to serial

PLM in building two converts serial to PLC

PLC goes into wires of building 2

 

And vice-versa.

 

This is all based on my assumption that PLM's convert all PLC to serial, even if it is from an address not in the links table.  This could be wrong.  If not, I guess you would need to link all of your devices with the PLM?  Maybe have a record of all scenes as well?   That would be a PITA for sure.  Perhaps you could plug each of the 3 plms into ISY and do a "restore plm" so that all 3 have the same set of tables.

[giesen]

I bet someone with enough time on their hands could write an ISY node server, that is to make a slave ISY's nodes appear as native nodes on a master ISY...

 

Sent from my SM-N910W8 using Tapatalk

[MWareman]

I bet someone with enough time on their hands could write an ISY node server, that is to make a slave ISY's nodes appear as native nodes on a master ISY...

 

Sent from my SM-N910W8 using Tapatalk

I believe that is a stated feature of ISY Pro running 5.x (when finalized), that a PRO until can act as a node server to another PRO unit...

 

I don't know if it's already there or not, but I do not think so...

[apostolakisl]

I believe that is a stated feature of ISY Pro running 5.x (when finalized), that a PRO until can act as a node server to another PRO unit...

 

I don't know if it's already there or not, but I do not think so...

 

That would work.  The issue is that you would want to make it seem like everything was on the same network so you didn't need to duplicate all sorts of tasks and get confused about what was controlled where.

 

It seems like a bit overkill to require both units to be pro units.  I can understand the primary unit, but the slave unit shouldn't need very many resources since it is pretty much just a node server.

[apostolakisl]

So, presumably, REST is the preferred method to make the two ISYs coordinate with one another. Correct?

 

At present, yes.  But you have to write lots network resources and programs to trigger them and you couldn't use scenes on ISY one to control devices connected to ISY 2, it would have to programs.  All of the integration between the ISY's would have to be managed by programs.

 

Now, possibly, someone like ioguy could write code like he did for a bunch of other things to produce a node server for ISY to ISY comm (assumes 5.x firmware).  But this would be much more complex than for say, DSC alarm since the nodes on an ISY are not fixed, they are determined by how many devices and scenes.

[apostolakisl]

I was thinking about this a little more.

 

I think the PLM conversion to serial isn't really the right thing.  It is not converting PLC to serial verbatim.  It isn't just converting the exact PLC signal to a matching serial command, it is "understanding" it and telling the connected device what is going on.

 

What you would want is something that just verbatim copies the PLC signal to a digital signal that can be put into IP and vice versa.  Or, if you had a radio receiver, one that listens in the dual band frequency, digitizes what it hears, then delivers it via IP to a device at the other end that puts it back to a RF.  Effectively copying all radio sounds in the dual band device frequency from one location to another.

 

Sort of like you put the two buildings on speaker phone.  You would need a duplex filter just the same as with speaker phone. 

[mwester]

...

What you would want is something that just verbatim copies the PLC signal to a digital signal that can be put into IP and vice versa.

....

 

This is commonly done with many other protocols -- for example, I wrote software that did exactly this for ham radio AX25 data years ago.  Basically, it would convert the AX25 digital data coming in from a ham radio digital transceiver, encapsulate it in an IP datagram, send to across the internet to another station, where the AX25 data would be extracted and put back on the airwaves.

 

Alas, since the Insteon protocol is largely proprietary, this is a lot harder than it seems.  It would require a lot of reverse-engineering since the published specs are all rather dated.

[apostolakisl]

This is commonly done with many other protocols -- for example, I wrote software that did exactly this for ham radio AX25 data years ago.  Basically, it would convert the AX25 digital data coming in from a ham radio digital transceiver, encapsulate it in an IP datagram, send to across the internet to another station, where the AX25 data would be extracted and put back on the airwaves.

 

Alas, since the Insteon protocol is largely proprietary, this is a lot harder than it seems.  It would require a lot of reverse-engineering since the published specs are all rather dated.

 

Not an expert in this, but I wouldn't think simply "recording" and "play back" the radio signal would require any knowledge of what the radio signal is encoding.  I suppose you could have algorithms that try to clean out noise and if you didn't know the Insteon protocol you wouldn't necessarily know what is signal and what is noise.  But hopefully you wouldn't need to do that.

 

Just conjecture here.  Like I said, I'm not going to actually do this.

 

I suppose you could play around if you had the right equipment by just recording an Insteon transmission and then playing it back at a later time and seeing if the device responds.  If that works, you could try recording, digitizing, then back to analog and playback and see if it works.  At that point, you would just need to work out your duplex filtering.