Jump to content

Using 2 Separate Controllers in One System


tpolito

Recommended Posts

I posted this over on Smarthome’s forum , and got a little bit of help, but I thought I may get a little more information on this forum.

 

I currently have about 40 Insteon devices installed in my house, as well as an HAI Omni alarm panel, a Rain8 serial sprinkler controller, and an Ocelot. I currently use a software program (that many here may be familiar with) to control and interface all of those devices. It is a very powerful program, but is very lacking in it’s support of Insteon. I understand they are working diligently to fix these issues, but with no estimate for when they will be complete, I am getting a little impatient. I have been reading a lot about the ISY, and think I am ready to try it for a couple of reasons. One, all of the scenes and groups are stored in the software, not the switches, so if my PC is off for some reason, they do not work. And two, I am tired of having spent all of this money, only to have some of it not work consistently.

 

What I am hoping I can do is leave my software (and USB PowerLinc Controller) in place, AND install an ISY with a Powerline modem. My thinking is that the ISY can keep most, if not all, of the Insteon control, while my software still handles the interface to the Omni and Ocelot. What problems will this cause? I was thinking I could handle it the following way:

 

• Still allow Insteon signals to initiate the software to be able to control my alarm, Ocelot, etc. For example, I have a “Goodnight†scene that turns of my lights, sets my alarm, and adjusts my thermostats. Currently, I press a Keypadlinc button, and my software recognizes that the button was pressed and then turns off a “Goodnight†group of Insteon devices and also sends a signal to my Omni to set the alarm and adjust the thermostats. I am thinking I could create the scene “Goodnight†in the ISY to link all of the devices to that Keypadlinc, and remove that step from the software, but still allow the software to recognize the Keypadlinc was pressed and adjust the alarm and thermostats.

 

• The next thing I need to do is turn on/off lights based on arming/disarming my alarm. Or turn on my garage light based on the garage door opening (which is connected through my Ocelot). I guess this is where I could either use an X10 output from the alarm panel (or Ocelot), or possibly use the REST interface, although I will have to get more familiar with that.

 

My software can output serial commands if there is a way to have the ISY receive them. Does this sound reasonable? What are the pitfalls?

 

Thanks,

 

Tom

Link to comment

Hi Tom, thanks so very much for your interest.

 

There are very many problems with having two controllers in our specific configuration one of which is that all the configurations made by one is not scene by the other and it may even overwrite the configurations in the other.

 

For instance, for you to be able to use your software to sense INSTEON signals, the USB PLM on your controller MUST be a responder for those specific devices. This may cause major synchronization issues between the two.

 

The questions I have for you are:

1. Can you send X10 signals for communications purposes between the two controllers (instead of INSTEON)?

2. Can your Alarm Panel be activated by X10?

3. Can your Alarm Panel send and X10 when armed/disarmed?

 

If so, then, you will be OK. If not, then - and as much as I want us to sell you an ISY - I think you will have a much more complicated system than is worth.

 

With kind regards,

Michel

Link to comment

Thanks for the response, I figured there would be some issues with it. I can't say for absolute sure, but I am almost positive I can send and receive X10 commands from my software, the alarm panel, and the Ocelot, so I do think it would work that way. My only hesitation is that in my current system, all of those devices are connected serially, and I feel like that is a much more reliable connection than changing to X10 would be. I never had any X10 devices, so I don't really know that for sure. But I would hate to take all of those things that are working very well now, and change them over to X10 and start having problems.

 

I am not up to speed on the Network module and REST interface. Is there any way I could use those (or just a serial interface to my PC) to communicate with my software, so that if an Insteon button is pressed, the ISY could tell my software over the network module, and if my alarm was activated, the software could tell the ISY to run a scene via the REST interface? I'm sure this depends on the capabilities of my software. What features would it need in order to make this work, if it is even possible?

 

Thanks for all of your help.

 

Tom

Link to comment

Michel

 

Does the ISY support adding a PLC as any other Insteon device?

 

Both 2414 variants are listed in the New INSTEON Device, Device Type pulldown. If the PLC is supported as any other powerline connected Insteon device it could be added to ISY created Scenes as a Responder for those paddle/button presses the other software needs to be aware of. The PLC would receive the Group On/Off messages from those Insteon device interactions, needed by the other environment as it does today, but NO Insteon device or Scene management would be performed by the other environment. All Insteon device and Scene management would be done by the ISY. This is all dependent on whether the PLC is supported as any other Insteon device communicated with over the powerline.

 

I tried a test when the post showed up on the other forum but my last PLC is so dead its LED would not stop flashing just by plugging in the device. I had no way to test adding the PLC using New INSTEON Device.

 

tpolito

 

If the PLC is supported by the ISY as just another powerline connected Insteon device then the ISY would do ALL Insteon device and Scene management. The PLC would be just another Responder in some ISY created Scenes. This would give your other environment the awareness of a paddle/button press and you would continue to interface to your other non Insteon devices the same way you do today. You would have all the power and features the ISY provides for Insteon device support with the other environment responsible for everything else. Just depends on Michel’s answer regarding the ability to add a PLC as any other Insteon device.

 

I believe the Network Module is one way communication so that would not be an alternative.

 

Lee

Link to comment

Thanks Lee, that is what I was originally trying to ask, but you wordrd it a lot better than I did.

 

If I understand you correctly, and IF the PLC is supported, then that would take care of actions like setting my alarm based on a keypad button press. But it wouldn't take care of turning on Insteon devices based on a change in the status of my alarm, correct? I may still have to use X10 for that?

Link to comment

That is correct. You would need an ISY Program that reacts to an X10 message from your other environment and controls the appropriate Insteon devices. The other possibility is the REST interface. That can be used to tell the ISY to turn On/Off Insteon devices or ISY managed Scenes.

Link to comment

Hi LeeG,

 

It's supported as ONE node ... what we need is to somehow figure out how many groups the PLC is supporting (just like a keypad). This way, things would be more or less like dealing with a keypad (but with more buttons). It's certainly doable but it's not something I look forward to!!!

 

Hi tpolito,

 

If your software can listen to network sockets and then issue commands, then you can use the Network Module to basically control all the facets of your software that are accessible via network.

 

REST is to control ISY (the reverse of above). So, if your software is capable of sending HTTP requests, then you can have it initiate a REST command on ISY and thus control your devices from your software.

 

With kind regards,

Michel

Link to comment

Thanks again for the responses. I am not very familiar with netwwork sockets or http requests, so I don't really know the answer to those questions. I am going to go ahead and get one anyway and give it a shot. Worst case, I will just use X10 commands to communicate between the ISY and my other devices. Or very worse case, I will just use the ISY as an expensive way of managing the links on my Insteon devices instead of the tap method 100 different times to set up all the scenes I want. From what I understand, I could use it to set up the scenes, and then even if I disconnect the ISY, the scenes would still work.

Link to comment

Michel,

 

Thanks for the effort and answers. I was thinking in terms of the fact that the PLC has a "linked list" type link database rather than the "linear" link database in all the other Insteon devices. Did not know if the ISY had code to handle that unique type of link database. Was not thinking about the way the ISY looks at the world regarding defining large number of nodes.

 

As far as a responder a single node works fine. Just like a SwitchLinc can be a responder to many different Scenes the PLC could be a responder to many different Scenes. I think the PLC is a non starter unless the ISY really does have support for a "linked list" style link database. Might be time to remove the 2414 from the Device Type list.

 

I then got the idea of using a PLM. That would require tpolito to switch from PLC to PLM which might be a problem. Actually added a Dual Band PLM to the ISY successfully. Then made it a responder to a KeypadLinc button as controller. That physically worked but the link record in the PLM is not functional because of the different memory size. The ISY would have to adopt the same logic for determining PLM memory size now being used for SHN devices. Again likely a non starter as that only resolves the responder side and not the issue of what to do with potentially 254 controller nodes (one for each Group number possible). In addition that would expand the number of link records used in the ISY PLM significantly for each user PLM installed.

 

tpolito

 

I think the idea of defining your PLC or even a PLM (assuming you could switch from a PLC to a PLM) to ISY is not an option. If you can receive network messages Michel's suggestion of using the Network module to send messages to your environment and use REST to control the Insteon devices and ISY Scenes seems the only option at this point. Sure did sound like an interesting possibility in the beginning. Perhaps the ISY will support a PLM in the future but I doubt there is much call for that support compared to other requirements on the wish list. I had hoped to use a PLM when I first got my ISY as I have them in use with other software but I can see the difficulty using predefined nodes.

 

EDIT: just saw your last post. The ISY should still be on the powerline even if only used for link management. Every Scene that the ISY creates has a link back to the ISY PLM so that it is aware of device state changes. Removing the ISY PLM would cause unwanted Insteon message retry as the Insteon devices were manually turned On/Off.

 

Lee

Link to comment

Hi Lee,

 

You are so very correct. I had not even considered the fact that PLCs use linear database. So, that rules out PLC.

 

We can certainly use PLM and then the same method as EZxx devices. But, we really have to support multiple nodes otherwise it would be difficult for the software attached to the PLM to know which scene is being activated.

 

With kind regards,

Michel

Link to comment
  • 3 weeks later...

I guess there isn't a way for the ISY to periodically query switches for their device status? In other words, if my home automation software turned on a light, I understand that the ISY may not recognize that. Could I have the ISY poll all devices at a given time interval to sync back up with the device status?

Link to comment

Just thought I would post an update of how my setup is going. I set-up my ISY, and I am also still using HAL 2000 with a USB PLC. HAL still receives Insteon commands, and controls my Ocelot and Omni panel, but the ISY handles the Insteon control. For example, at night, I press a button on my keypad. HAL sees that and adjusts my thermostats, and sets the alarm, but I used the ISY to create a scene which is controlled by that same keypad button to turn off all of my lights. I have only had the ISY for a couple of days, but this seems to be working fine.

 

When I want to control Insteon devices based on events from the Ocelot, or Omni, I have HAL send an X10 command to the ISY, and the ISY controls the devices accordingly. I have my dual-band PLM plugged into the pass-thru plug on my PLC, so I expect the X10 to be pretty reliable. Time will tell how reliable this ends up being, but limited testing so far seems to indicate that it should work well.

 

I loved the ease and flexibility of HAL2000, and was pleasantly surprised that the ISY was equally easy to get started with. I have only begun to tap the potential of it, and look forward to doing so. Thanks to Michel and LeeG for helping me out with ideas on how to make these systems work together! I still would love to figure out a way to get away from the X10 signals between HAL and the ISY, but for now, I think it will do.

Link to comment
I still would love to figure out a way to get away from the X10 signals between HAL and the ISY, but for now, I think it will do.

 

This is where I wish the ISY would support other PLMs, the SmartLinc and the SeriaLinc similarly to how it currently supports the IRLinc Transmitter. If it only learned a group at a time, you wouldn't tie up 240 links per supported device and it would give the ISY a way to exchange messages with external hardware and software like HAL using a reliable two-way protocol.

Link to comment
  • 3 weeks later...

So far, so good (knock on wood). I have only had it up and running for a couple of weeks, but it has been reliable so far. It requires a few more steps for programming to interface the two systems, but not too bad. It still would be ideal to only have one system, but since neither does everything I am looking for, it will do.

Link to comment
  • 3 months later...

I have been running ISY and Hal2000 concurrently now for a few months. In my case, I moved all control and programming to the ISY. Hal only sees Insteon devices as sensors and reacts to them with voice announcements, playing sounds (dog barking when outside motion detected) and executes PC programs (initiates Active Webcam software on inside motion which in turn takes pictures on motion in camera view and emails it).

 

This set up seems to work ok. The ISY is the heart that Hal lost years ago.

Link to comment

I have been running ISY and Hal2000 concurrently now for a few months. In my case, I moved all control and programming to the ISY. Hal only sees Insteon devices as sensors and reacts to them with voice announcements, playing sounds (dog barking when outside motion detected) and executes PC programs (initiates Active Webcam software on inside motion which in turn takes pictures on motion in camera view and emails it).

 

This set up seems to work ok. The ISY is the heart that Hal lost years ago.

Link to comment
  • 1 year later...

I posted this in another thread, but thought it should go here as well:

 

I finally came up with what I feel is a working solution for an interface between my ISY and Omni panel. I use an EZIO8SA module from Simplehomenet and hardwired it to inputs and outputs on my Omni panel. I programmed individual outputs in the Omni to represent an alarm status: (Output 1 turns on when the alarm is disarmed, Output 2 turns on when the alarm is in away mode, Output 3 is turned on when the alarm is in night mode). The EZIO8SA reads those inputs, and I programmed the ISY to respond based on those inputs.

 

Similarly, I wired a few outputs from the EZIO8SA to spare inputs on my Omni panel. I programmed the Omni to arm in a certain mode when one of those outputs is closed. I use this to arm my alarm when I leave the house by pushing a Keypadlinc button. The ISY sees the button press and closes the EZIO output that then prompts the Omni program to arm the alarm.

 

It was actually very simple, and seems to be reliable so far (fingers crossed).

Link to comment

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...