| Author |
|
Agent99
Newbie
Joined: April 05 2008
Location: United States
Online Status: Offline
Posts: 17
|
| Posted: April 13 2008 at 19:35 | IP Logged
|
|
|
I am just getting my feet wet using PowerHome & ELK. Currently I am using only X10 devices and the ELK as my controller via the PSCO5.
I am seriously considering the A migrating to Insteon. My problem is how to best configure control of Insteon. I would prefer to use the ELK as my controller and know that I would need to install an ELK M1xsp interface and use e smartlink 2414s PLC.
I could also just use PowerHome and a PLC but that would require that I leave my PC on 24/7 and I dont really want to do it that way. What are the pros or cons of doing it one way over the other. I would like to here from some more seasoned ELK/Powerhome users on there setups and why they chose there interface.
I also would like to know how if I use the ELK as my controller if I can continue to use my x10 rf remotes to trigger Insteon Devices. Can I just write rules in the ELK controler to do this. I know some of this is more ELK related than Powerhome but I really would like to use both and get the best of both functionality. I have many more questions about it all but will wait to see some responses and maybe the answers will be more obvious.
Thanks , Dave
|
| Back to Top |
|
| |
TonyNo
Moderator Group
Joined: December 05 2001
Location: United States
Online Status: Offline
Posts: 2889
|
| Posted: April 13 2008 at 23:10 | IP Logged
|
|
|
First, I don't have an Elk, so PH does everything. ;)
I do know people that use the Elk for the mission-critical stuff and PowerHome for doing the fancy stuff.
Also, I'm pretty sure you can connect a W800 to the Elk.
|
| Back to Top |
|
| |
Agent99
Newbie
Joined: April 05 2008
Location: United States
Online Status: Offline
Posts: 17
|
| Posted: April 14 2008 at 00:47 | IP Logged
|
|
|
TonyNo wrote:
First, I don't have an Elk, so PH does everything. ;)
I do know people that use the Elk for the mission-critical stuff and PowerHome for doing the fancy stuff.
Also, I'm pretty sure you can connect a W800 to the Elk. |
|
|
1.)
I am looking to see if there are limitations to using the ELK as the controller for Insteon and or is it better to use separate PLC's one each for the ELK and Powerhome.
2.)
I want to use the ELK for as much if not all that I can because it is already on 24/7 and using a PC to do the same seems redundant.
3.)
I already own a WGL 572rf32 Tranceiver setup for X10 and it works great. I am pretty sure that all x10 commands sent over the PL will be recieved by the 2414s PLC hooked to the ELK via the M1xsp interface. Using a w800 with the elk would require another M1XSP interface for it, adding more cost and complexity.
I want to use PowerHome for local monitoring and control via my PC when its on and to setup and configure Insteon devices and such. I am sure PowerHome can do a lot more fancy stuff than just using the ELK interface but I am not yet to the point where I need most of it. However I do have an open mind and feel that I may eventually wan t more than the ELK alone can do for me.
I guess my main concern is a smooth transition from all X10 to some Inteon and eventually virtually all Insteon. Without loosing the functionality I already have with my all x10 setup.
As a side note I do not have any major X10 problems with my current setup, I just dont care for how x10 implements things like dimming,preset levels,scenes and its lack of 2way monitoring.I am also aware of Insteons less than stellar track record for some.
|
| Back to Top |
|
| |
TonyNo
Moderator Group
Joined: December 05 2001
Location: United States
Online Status: Offline
Posts: 2889
|
| Posted: April 14 2008 at 07:39 | IP Logged
|
|
|
1) Someone with an Elk will need to respond to this, but, I do know people that have two Insteon PLC's: one for the Elk and one for PH. I also remember an Elk product (Ethernet-to-serial) that would let you share one PLC between the Elk and PH.
2) See #1. There are only so many rules that you can have.
3) You mentioned RF. I'm guessing, then, that your WGL is an RF-to-power line device. This should still work fine.
Quote:
| I guess my main concern is a smooth transition from all X10 to some Inteon and eventually virtually all Insteon. Without loosing the functionality I already have with my all x10 setup. |
|
|
Adding Insteon to an existing X10 environment will quickly kill the X10 (maybe as few as 4 Insteon devices). The Insteon signal stomps on X10. Be prepared for this. I noticed it mostly in areas with weak X10.
I have Insteon, like it more than X10, and have not had too many issues.
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: April 14 2008 at 12:00 | IP Logged
|
|
|
TonyNo wrote:
| Adding Insteon to an existing X10 environment will quickly kill the X10 (maybe as few as 4 Insteon devices). The Insteon signal stomps on X10. Be prepared for this. I noticed it mostly in areas with weak X10. |
|
|
That too is an interesting debate. I have 18 X10s and 21 Insteons and have not had any noticeable degradation in my already unstable X10 environment. With that said the Insteon modules are much more reliable and are easily recoverable. I don’t know if placement has anything to do with it except all my X10s are after the PLC and before any Insteon in the electrical path.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
TonyNo
Moderator Group
Joined: December 05 2001
Location: United States
Online Status: Offline
Posts: 2889
|
| Posted: April 14 2008 at 13:36 | IP Logged
|
|
|
Hmm. Good to know, Pete!
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: April 14 2008 at 15:01 | IP Logged
|
|
|
Agent99,
The biggest issue you'll have with using the ELK alone for Insteon is that the ELK treats Insteon as X10. Device to device links such as a SwitchLinc controlling another switchlinc *may* be missed by the Elk since the Elk does not understand or know anything about Insteon intra-device relationships (linking). When you crosslink a couple of Insteon devices or have a KPL button set to control a group of lights, the ONLY command that is guaranteed to be sent is the group broadcast command which Elk essentially ignores. I believe the Elk will listen for group cleanup commands, but these are not guaranteed to be sent and then again, the actual level the light would have been controlled to is stored in the Link database (which Elk is not aware of). Again, I believe the Elk *may* do an Insteon status command to get the actual level but that is assuming it heard the group cleanup command.
The Elk won't do any Insteon to X10 translation (or vice versa) for you unless you write rules. Since the 572rf32 converts X10 RF to powerline RF, the PowerLinc should be able to receive these commands into the Elk. To do an actual conversion though, you would need to have your actual Insteon devices configured as different addresses than the RF X10 because the ELK treats the Insteon as X10. You would then have a rule that when an RF X10 is received, send a command to the Insteon X10 address. Hmmm...Im not too sure of the above statement now that I think about it. The problem is Im not certain how the Elk handles X10 commands received by the PLC. Of course, you could just assign X10 addresses to your Insteon devices...but Im not sure if that will cause problems or not.
Of course, Im biased in my opinion  , preferring to have PowerHome running 24/7 since I use it also for IR control and a whole lot more.
Dave.
|
| Back to Top |
|
| |
Agent99
Newbie
Joined: April 05 2008
Location: United States
Online Status: Offline
Posts: 17
|
| Posted: April 14 2008 at 15:34 | IP Logged
|
|
|
dhoward wrote:
Agent99,
The biggest issue you'll have with using the ELK alone for Insteon is that the ELK treats Insteon as X10. Device to device links such as a SwitchLinc controlling another switchlinc *may* be missed by the Elk since the Elk does not understand or know anything about Insteon intra-device relationships (linking). When you crosslink a couple of Insteon devices or have a KPL button set to control a group of lights, the ONLY command that is guaranteed to be sent is the group broadcast command which Elk essentially ignores. I believe the Elk will listen for group cleanup commands, but these are not guaranteed to be sent and then again, the actual level the light would have been controlled to is stored in the Link database (which Elk is not aware of). Again, I believe the Elk *may* do an Insteon status command to get the actual level but that is assuming it heard the group cleanup command.
The Elk won't do any Insteon to X10 translation (or vice versa) for you unless you write rules. Since the 572rf32 converts X10 RF to powerline RF, the PowerLinc should be able to receive these commands into the Elk. To do an actual conversion though, you would need to have your actual Insteon devices configured as different addresses than the RF X10 because the ELK treats the Insteon as X10. You would then have a rule that when an RF X10 is received, send a command to the Insteon X10 address. Hmmm...Im not too sure of the above statement now that I think about it. The problem is Im not certain how the Elk handles X10 commands received by the PLC. Of course, you could just assign X10 addresses to your Insteon devices...but Im not sure if that will cause problems or not.
Of course, Im biased in my opinion , preferring to have PowerHome running 24/7 since I use it also for IR control and a whole lot more.
Dave.
|
|
|
I am getting the idea that there are not as many PowerHome/ELK users as I thought here. However the information you have given is helpful.
I have read somewhere that using the ELK for Insteon might limit some functionalities.
Are you suggesting or of the opinion that I might be better off using PowerHome as my primary lighting interface and connecting directly the PLC to my PC, The ELK already has a PCSO5 x10 conected so it can send or receive x10 and act as a bridge in that respect.
Since we are discussing using Powerhome as a 24/7 HA interface, what kind of load will going this put on my PC. I already have an HTPC server running SaGEtv and a Camera DVR program 24/7. would it be feasable to run Powerhome on the same server. I forget whether PH can run as a service or not too, since my Camera DVR can not It would be the only way to do it.
Thanks, Dave
Edit: I guess I could run PH with my Cam dvr if I loaded it first and just reduced it to the backround.
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: April 14 2008 at 16:48 | IP Logged
|
|
|
Dave,
I know there are a few Elk/PH users, but I would say they are in the minority. I think most people that use Elk with PowerHome are primarily using PH's Insteon linking ability and then downloading the link information to the Elk so the Elk can run standalone or they are even using another HA package with the Elk.
In my situation, I use PH as the main interface with the PLC (now the PLM) directly connected to PH for all lighting control. I use the Elk primarily as a security controller and as an interface to PH for all of my inputs/outputs, motion sensors, etc. I know most users will put critical functionality into the Elk with "nice but not necessary" functionality into a software based package. In my setup, the ONLY rules I have in the Elk to lock and unlock a wireless deadbolt via an access card or keyfob. Everything else goes through PH.
To have the best of both worlds...I would probably get a PLC for the ELK and a PLM for PH and run both. That way you could have as much or as little as you'd like in the Elk and then PH available for web access, TTS, etc.
PowerHome can be loaded as a service and I wouldnt expect alot of demand from any machine you place it on.
Dave.
|
| Back to Top |
|
| |
smarty
Super User
Joined: May 21 2006
Location: United States
Online Status: Offline
Posts: 728
|
| Posted: April 15 2008 at 21:15 | IP Logged
|
|
|
I am using PH 24/7 (with a USB Insteon conroller), and the Elk M1G with attached serial Insteon controller.
I still am in the "setting up phase" of all my Insteon lights (now up to 40+ devices), I have found that having two controllers just makes my work less "encumbering" (by not having to swap them back and forth).
Having Insteon controllers on both devices give you some options that neither can offer alone.
For example, PH is great for setting up Insteon links and groups, something that the Elk cannot do (and doing it manually is a real PITA). PH also has a much higher level macro and programing ability that the Insteon controller could trigger when needed.
However, the Elk is better suited to respond to sensor inputs (that's what an alarm system does). Lighting based on motion detection is an example (with the groups being set up via PH). Also, some lighting control is CRITICAL, and those controls might be best left to hardware controllers (like the Elk) rather than something that depends upon the stability of Microsoft.
Botton line (my opinion); if you can afford it, spring for two controllers, one for each system. I have never regretted it once.
__________________
Elk - Insteon - BlueIris - DMC1 - PowerHome - XLobby - HA_Bridge w/Dots - Brultech
|
| Back to Top |
|
| |
Agent99
Newbie
Joined: April 05 2008
Location: United States
Online Status: Offline
Posts: 17
|
| Posted: April 20 2008 at 21:39 | IP Logged
|
|
|
As I am getting more and more familiar with Powerhome and interfacing it with the ELK M1 gold I still have a few small things that I need to figure out.
How do I get the ELK alarm Status to show in the control Device/status screen. I can see all my zones using analog inputs but have not figured how to see the alarm status. Is the output for alarm status just another analog zone ?.
Also Is there a way to arm or disarm the ELk from within Powerhomme.
Dave
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: April 21 2008 at 11:55 | IP Logged
|
|
|
Dave,
Support for the Alarm and Arm status of the Elk will be built into the next beta. If you're adventurous, it's also available in the current alpha in the ANALOGIO screen as a couple of new device types. Otherwise, it can be done with macro's and triggers.
You can arm and disarm the Elk using a formula.
ph_ctlrsq("YOUR_ELK_CTLR_ID",121,"012345",1,1)
will arm away the Elk,
ph_ctlrsq("YOUR_ELK_CTLR_ID",121,"012345",2,1)
will disarm the Elk. Just be sure and replace "012345" with a valid 6 character arm/disarm code (if your codes are 4 digit, precede with 00) that you've previously defined in your Elk and the "YOUR_ELK_CTLR_ID" with the ID of the controller you assigned to your Elk within the PowerHome Setup|Controllers screen.
HTH,
Dave.
|
| Back to Top |
|
| |
Agent99
Newbie
Joined: April 05 2008
Location: United States
Online Status: Offline
Posts: 17
|
| Posted: April 21 2008 at 12:27 | IP Logged
|
|
|
Thanks, dhoward
I will probly wait for full support in the next alpha , I am glad to hear that you are working on full ELK support. That was basically my my last major concern before I converted my trial to paid user.
PH is a very complex and powerful program, I hope over time it will become a little more user friendly.I realize that in order to do all the complex things that PH is capable is not always easy to put in layman's terms. You and others on this forum have helped me get the basics and I am sure I will learn a lot more as time goes on.
Thanks again, Dave F 
|
| Back to Top |
|
| |
jaysonc
Newbie
Joined: October 21 2007
Location: United States
Online Status: Offline
Posts: 26
|
| Posted: May 07 2008 at 12:44 | IP Logged
|
|
|
Agent,
I use PH, Insteon, X-10 and an ELK M1 together and can give you some of
my experiences and opinions. Hopefully they will help.
First off I use PH as my primary automation controller. It manages my
Insteon PLC and is responsible for almost all all logic decisions. All data
points (IR, 1wire, alarm sensors, thermostats, etc) are pushed to PH as
the central database of record. I have PH integrated with my Elk via
ethernet to an ELK-M1XEP.
It is true that the ELK can drive an X-10 or Insteon PLC directly, but it is a
poor implementation in my opinion. The ELk only understands X-10
internally. As such it has 254 internal slots that can be used to send or
receive messages. If you use Insteon you are limited to 256 devices and
must "map" the ones you wish to use to these slots. No direct groups or
enhanced functionality beyond what X-10 provides.
I have tried connecting both an X-10 and Insteon PLC to the Elk directly,
but have not been happy with the results. It will work, but is very limiting
with Insteon. I find that using PH for the HA controller and providing it
with visibility of the Elk devices (zones, arm status, thermostat
information, etc) provides the most robust solution.
The PH to ELK interface does work in PH 1.03.4.12, but the connection
over ethernet to the ELk was unstable. In my setup it would loose its
connection every 4-5 days. Re-initialization of PH was the only was the
only fix. But this has been resolved in the new Alpha and the connection
seems to be very solid now. Thanks to Dave for reducing my wife's
complaints to a dull roar.
Dave has exposed almost all of the ELK interface specification. With this
and some PH formula magic you can have PH do just about anything you
want on the Elk. My PH can currently arm/disarm the system, monitor the
arm and disarm process in real time, receive instant notification of zone
changes, receive notification of alarm conditions, activate attached relay
controllers and query/update an attached thermostats. The only issue I
have run into is the aforementioned connection problem.
For me it comes down to this. The Elk is primarily an alarm panel, with
some automation functions. PH is primarily a home automation controller.
Use each for their core strengths. WIth the Elk/PH integration, even as it
stands today, you will be able to achieve a robust integrate between the
two.
I did hear your preference to not run an PC 24/7 for PH. This does not
have to be expensive or use a lot of power. I use an EPIA M9000 in a
headless (no monitor) configuration. I use VNC to access it. It was cheap,
makes no noise and uses very little power.
__________________
--
Jayson
|
| Back to Top |
|
| |
Agent99
Newbie
Joined: April 05 2008
Location: United States
Online Status: Offline
Posts: 17
|
| Posted: May 07 2008 at 15:13 | IP Logged
|
|
|
jaysonc,
I appreciate your feed back and since you deem to have a little better understanding of how ELK & PH work together I have a few questions that I hope you or anyone else might answer.
First let me tell you how my system is set up for reference.
I have and ELk M1 connected via a Serial connection to PH.
I also have an M1XSP/insteon interface connected to a PLC.
I just finished setting up PLC to PH using the Alpha7 (to be updated to Alpha8 soon)
ELK config
I have 19 insteon devices setup in the ELK/m1xsp (a1~B3)
I have 8 additional x10 devices setup on houscode D1~D8) in The Elk too.
PH config
I have the 19 Elk/insteon devices setup as A1~B3 + the 8 x10 devices using the ELK as the controller as X10 inputs.
I have 13 alarm zones setup as analog inputs and reporting status to PH as Elkinputs.
I also setup Keypad Temp to and analog input but so far its not functional ( need help configuring this)
When I installed the PLC and configured it for PH using the Insteon Explorer I set up duplicate Insteon devices using Insteon controller.
So now here are my questions.
I setup both the Elk M1XSP and Powehome/Insteon to Poll devices. This seemed to cause problems. I started to get false triggers and random lights coming on. So I disabled Polling in the Elk/Mixsp and that seemed to stop but I need to monitor it more to be for sure. I assume that using the polling feature on both the ElkcontollerPlc) an the PH/Insteon (PLM)was just causing to much Powerline traffic resulting in false triggers ?.
The problem with turning the Elk/M1XSP polling off is that now I get no updates to the ELK/x10 devices in PH and the ELK has no idea of the light status. This is a problem because I have a couple of Elk rules that rely on the light status to execute. I could write triggers in PH to address this I suppose but then I am relying on My PC/PH 24/7.
Now a few questons on PH/Insteon configuration setup.
Is it normal or proper to setup both X10 type devices in PH along with duplicate Insteon types.I did go into the Insteon devices and number the devices in the Other Controllers section but if I eliminate the x10/elk type. Should I delete the X10 types and just use Insteon, if so how will I get updates and status to/from the Elk.Perhaps I should have set up PH/Inston first and then uploaded them to the M1Xspw with the proper ID #'s ?.
Other Questions,
How do I set up a keypad temp to show in PH device status
How do I setup the alarm status and control in PH so they are available and visible.
I hope this all makes sense and appreciate any help offered, Dave F
|
| Back to Top |
|
| |
jaysonc
Newbie
Joined: October 21 2007
Location: United States
Online Status: Offline
Posts: 26
|
| Posted: May 07 2008 at 17:03 | IP Logged
|
|
|
Concerning your use of polling. If you had that setup to poll frequently or
with large blocks of items to poll, you could have been causing collisions.
Insteon added some acknowledgements to the protocol to prevent
collisions, but you can never completely remove them just minimize their
frequency. I have experienced similar results in heavy polling situations to
what you describe and always determined that heavy traffic on the power
line was the only common element to my communication problems.
I believe there was an Elk setting that determined whether the Elk pushed
status changes to PH or not. In effect, PH receives information from the
Elk by simply listening to the log the Elk outputs to the serial ports. You
can turn off this log on and off within the Elk. Specifically, I remember
that the XSP devices are somewhat different than the serial port on the
main board. It was related to the fact that the Elk uses the serial bus for
communication between the system expanders. As a result the Elk does
not send all of the messages over this internal bus that it send out the
main serial port. The ethernet expander (Elk-XEP) is different because it
does not connect to the internal serial bus, but rather connects directly to
the main serial output. I am traveling this week and can look into my
setup, but I will have to do it on Friday.
For communications in the other direction, I believe that there are some
data points in the Elk that you can update via the serial interface. You can
access custom values (see 'Change And Read Custom Values' and
possibly 'Power Line Carrier (PLC) Data' in the Elk documentation) and
have PH push data to the Elk. You are right though that this would
require PH to run 24/7. if you are going to do that, then you are better off
letting PH be the owner of data and current status.
I think your instincts may be correct about the duplicate ID's. I avoid all
of that by having PH manage all of the Insteon interaction. At this point i
do not even have a PLC connected to my ELk any more. it was too kludgy
for my taste. This is all Elk's implementation. I would be much worse if
Dave did not provide the tools he does to help upload the information.
To make a keypad temperature show up in PH, go to the elk
documentation. They reserve inputs for some items, like the keypad
temperature sensors. The input will be determined by the keypad
number. Once you have that input (it will be an analog input) you simply
set it up in PH just like your other 13 zones.
For the alarm status, I actually uploaded my code to the board previously.
It tracks both the arm status and the state of the panel. The status is
things like armed away, disarmed, armed night, etc. The state is more
detail such as ready, force armable, exit timer running, fully armed, etc. If
you want to trigger actions that happen when you leave or arrive, then
you will need to know both in your triggers to make sure things happen
when you want. This is all related to nuances in how the Elk works. If you
only trigger off of state, things will not happen when you think they
should. Here is the link to my previous forum post.
http://www.power-home.com/forum/forum_posts.asp?TID=1527&PN= 1
--
Jayson
__________________
--
Jayson
|
| Back to Top |
|
| |
jaysonc
Newbie
Joined: October 21 2007
Location: United States
Online Status: Offline
Posts: 26
|
| Posted: May 07 2008 at 20:40 | IP Logged
|
|
|
Agent,
I may have been incorrect in my previous email. I only find vague reference
to the temperature sensor and nothing about an associated zone.
Additionally the Elk API calls for temperature specifically separate keypads
from dedicated sensors and thermostats. Take a look at 'Request
Temperatures' and 'Request Temperature Data' method calls.
__________________
--
Jayson
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: May 09 2008 at 09:44 | IP Logged
|
|
|
Agent,
To setup keypad temps, go to the Analog I/O table and set the I/O type as "Temperature". Set the "Unit" as 2. Set the "Point" to the keypad zone. If you want to monitor the temperature on Keypad 1, then set the Point to 1. This should get the keypad temps working.
Do you have two PLC's? One for the M1XSP and one for PH? If you've got two, I would definately turn polling on PH off. PH doesnt need to use polling and primarily uses it to detect database (linking) changes. If you do all linking from PH, then PH will already know the links. Besides, if the Elk is doing the polling, then PH should also listen to and hear the Elk polls and update status accordingly (as long as you've told the PH PLC about the Elk PLC).
I'll also look into some better integration between the Elk X10 devices and the PH Insteon devices. Right now, the best way is to have the dual definitions in PH. X10 devices to see and control the devices using the Elk as a controller and Insteon devices for linking and/or direct Insteon control via PH.
Concerning Alarm State and Arm Status...check the latest alpha. It definately has support for these built in, but I may not have added the actual types in the Analog I/O table (if not, I'll whip up another alpha). If I did add it already, it will appear under the "I/O" column as "Alarm State" and "Arm Status" respectively. For zone 1, use 0 and 1 for Unit and Point.
HTH,
Dave.
|
| Back to Top |
|
| |
Agent99
Newbie
Joined: April 05 2008
Location: United States
Online Status: Offline
Posts: 17
|
| Posted: May 09 2008 at 15:53 | IP Logged
|
|
|
Dave,
You are incredible, Every time I ask a question or request help you are there with a solution. If PH doesn't do it yet you are there working in a solution.
Thanks to you I now have my KP1 temp status up and working along with my ELk Status and State displaying in the Device control panel.
I still need some help setting up arming and disarming though. I tried your previously posted formulas but some how they don't work for me ?
As Said before,originally I was not sure I would be able to grasp and use PH but as I get more and more into it I am sure it will all come to me in time. I am now sure I made a wise choice and even though I only use or understand maybe 50% of all that Ph can do I am very happy. Even 50% of Ph is 100% better than everything else I have seen.
Also what you call Alpha is better than most Beta software.
Lastly, I am now using both a PLC hooked to my ELK and a PLM connected to PH running Alpha8.
Thanks for everything, Dave F
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: May 09 2008 at 18:24 | IP Logged
|
|
|
Dave,
Wow, I like comments like those . Glad to be able to help and that the program is working well for you.
Concerning arm and disarm...Im not sure which formulas I had previously posted, but below is what Im currently using:
To Arm Away: ph_ctlrsq("ELK",121,"00XXXX",1,1)
To Arm Stay: ph_ctlrsq("ELK",121,"00XXXX",2,1)
To Disarm: ph_ctlrsq("ELK",121,"00XXXX",0,1)
Of course, you'll need to replace the XXXX with a valid 4 digit code that is currently accepted by your keypad. What Ive even done is created a virtual Digital I/O point (a standard digital I/O with a controller of "PowerHome Virtual") and created a trigger on the change of this virtual device. Depending upon if Im turning On or Off, my trigger action will send either Arm or Disarm. Maybe not the most secure method but makes it very convenient for me to arm and disarm direct from the Device Status screen.
I havent done this, but you could make this more secure by using a virtual Analog Output instead. You could then use the Analog output textbox to enter the actual 4 digit code instead of hardcoding it in. Hmmmm...I think I might just do that  .
Dave.
Dave.
|
| Back to Top |
|
| |
|
|
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome and Elk
Topic: Powerhome/Elk /Insteon Controler
