telljcl Posted February 3, 2011 Posted February 3, 2011 I posted this over in the general questions/answers - not sure which is a better fit. I had what I thought to be a smoothly running ELK/ISY install until I noticed this. I can control ISY/Insteon lights just fine via the ELK, but the ELK does not show the current status of those devices if they are changed from anything other than by ELK. The status basically just shows the last status the ELK set it to. ISY shows ELK in the admin console, and I have exported the .xml etc... - all the "normal" stuff works fine. I've reset ISY and ELK numerous times, re-imported device list, and made sure the "option" tick box is checed in ELKs lighting page. I have "serial Expander" as the type of device (which I assume is correct) for each insteon device. Is there some other setting I've missed? I can't figure it out, and I can't make any ELK programming that depends on an Insteon status. Thanks for any help.
gatchel Posted February 4, 2011 Posted February 4, 2011 I think that's the way it works. Elk has never had much for keeping an accurate status on lighting control. I think you can turn on polling with x-10 but I have heard mixed reviews about the benefits of doing so (That doesn't help insteon though) It's one of the few downfalls of the elk system, IMHO.
Michel Kohanim Posted February 4, 2011 Posted February 4, 2011 Hi gatchel, I do not think that is true: ELK should reflect the status of devices as they change in ISY (as long as they are imported in ELK). With kind regards, Michel
dlamb Posted February 4, 2011 Posted February 4, 2011 Hi telljcl, The ELK will show and can act on the Insteon state changes it receives from the ISY. It sounds like you have the settings correct and have downloaded the account configuration into the ELK from ELK-RP. The ELK must be disconnected from the ELK-RP program before the lighting commands can be transmitted and received on the network. Basic things to look for on the ELK side: 1. M1XEP has a static IP address assigned and port 2101 enabled. 2. The ISY xml file has been imported and downloaded into the ELK. 3. The ELK has been disconnected from ELK-RP so that lighting commands can be transmitted/received by the ELK-M1XEP. What is the firmware version of the ELK-M1G and ELK-M1XEP? Regards, Don Lamb ELK Products
gatchel Posted February 6, 2011 Posted February 6, 2011 Hi gatchel, I do not think that is true: ELK should reflect the status of devices as they change in ISY (as long as they are imported in ELK). With kind regards, Michel Interesting. I have never noticed this to work. Maybe It was because of the fact that I was configuring and testing with RP open...I'll have to check this out. I thought it was an issue from the "Elk control direct to the PLC using an XSP" days that was never fixed. I guess I stand corrected...
gatchel Posted February 6, 2011 Posted February 6, 2011 I just tried to control my Living Room Table Lamps scene using the elk web interface built in to the XEP. If I turn the Scene off and on using the Elk the status is correct. If they are off and I turn them on with my remotelinc Elk never shows them turning on. RP was disconnected this time, 100% sure of it. Elk M1 4.6.2 XEP 1.3.24 ISY 2.8.11
Michel Kohanim Posted February 6, 2011 Posted February 6, 2011 Hi gatchel, Does the status get updated in the Admin Console? And, if so, are you sure you have the latest configuration for your system exported and then imported to ELK? With kind regards, Michel
telljcl Posted February 7, 2011 Author Posted February 7, 2011 I've got the latest FW in both the M1G and XEP units, as well as xxxx.13 in the ISY (things didn't work with .11 either). I also seem to have a on again / off again issue with Conductor / ISY whereby my droid phone controls things immediatly on the ISY and console, but feedback to Conductor as to the status after the command fires is slow. This involves scenes mainly, as it may be a keypad controlling a lamplinc. I fire the scene via phone, and it shows "1" device triggered, when it should show 2. Both devices (keypad light and lamplinc) actually trigger instantly, but it takes sometimes more than a minute to get the "2" in Conductors scene to light up. I don't know if these issus are related, but it seem to be status related on both fronts. In my case ISY console ALWAYS shows exactly what is happening, instantly. This with control by the ELK or Conductor. Its just that Conductor, and ELK, don't seem to get feedback as to ISY's status somehow. A bit of other info: When I use this link to access my ISY: http://www.universal-devices.com/99i/ I get a different ISY admin console than I do when I use this address: http://local.ip:port number Is this normal? I'm really not into Java etc.... maybe I'm missing something. I normally use the local address to access. The first one does not show the ELK being connected. Also, do I need a password in the ELK setup? I've put one in, but it doesn't seem to matter and always returns to blank. I can control ISY lights by ELK no matter what it seems, but as usual, I can never get current status from ELK (unless I actually turn something on or off - then its correct until something else non-ELK changes it). I'd love to get this resolved - what can I do on my end? Thanks
dlamb Posted February 7, 2011 Posted February 7, 2011 ELK-RP software version 2.0.8 and greater has a built-in diagnostics utility for the ELK-M1XEP (firmware 1.3.24). It will allow you to monitor the data passed from the ELK-M1 to the ELK-M1XEP and network data sent to the M1XEP. Procedure: 1. Open ELK-RP version 2.0.8 2. Open the ELK's account. You do not need to connect to the ELK. 3. With the mouse pointer in the Account Details (left side frame of ELK-RP) together press the "Ctrl and F7" keys. 4. You should see a monitoring window open up labeled "M1XEP Debug Trace". 5. For the lighting data to be captured, check the "TCP" and "Serial" check boxes. 6. Turn on and off lights manually from the Insteon wall switch and ASCII data strings should be sent from the ISY to the M1XEP and captured by the utility. 7. Please copy and paste the data from the utility and I'll be glad to review it. Regards, Don Lamb ELK Products
telljcl Posted February 8, 2011 Author Posted February 8, 2011 Don, Thanks for helping with this. Below is what I pasted from the diagnostic utility as instructed. It basically shows actions from 2 keypad button pushes on a keypad (each one controls a scene which includes the button itself and the actual lamp module that turns on/off the light). I pushed one button, waited a few seconds, then the other. Waited a minute or 2 and then turned them both off with a pause in between. Hope this tells you what is going on here. Thanks a bunch. Begin paste: 20:04:02 From M1: 16XK02042020702110100080 20:04:02 TCP SendUnkPkt 16XK02042020702110100080 20:04:31 From M1: 16XK3304202070211010007C 20:04:31 TCP SendUnkPkt 16XK3304202070211010007C 20:05:02 From M1: 0AZC008900C1 20:05:02 TCP SendUnkPkt 0AZC008900C1 20:05:02 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:05:02 From M1: 1EAS000000000111111100000000000F 20:05:02 TCP SendUnkPkt 1EAS000000000111111100000000000F 20:05:02 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:05:02 From M1: 16XK0305202070211010007E 20:05:02 TCP SendUnkPkt 16XK0305202070211010007E 20:05:05 From M1: 1EAS000000001111111100000000000E 20:05:05 TCP SendUnkPkt 1EAS000000001111111100000000000E 20:05:05 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:05:05 From M1: 0AZC008200C8 20:05:05 TCP SendUnkPkt 0AZC008200C8 20:05:05 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:05:18 From M1: 0AZC008900C1 20:05:18 TCP SendUnkPkt 0AZC008900C1 20:05:18 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:05:18 From M1: 1EAS000000000111111100000000000F 20:05:18 TCP SendUnkPkt 1EAS000000000111111100000000000F 20:05:18 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:05:21 From M1: 1EAS000000001111111100000000000E 20:05:21 TCP SendUnkPkt 1EAS000000001111111100000000000E 20:05:21 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:05:21 From M1: 0AZC008200C8 20:05:21 TCP SendUnkPkt 0AZC008200C8 20:05:21 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:05:27 From M1: 0AZC008900C1 20:05:27 TCP SendUnkPkt 0AZC008900C1 20:05:27 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:05:27 From M1: 1EAS000000000111111100000000000F 20:05:27 TCP SendUnkPkt 1EAS000000000111111100000000000F 20:05:27 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:05:29 From M1: 0AZC008200C8 20:05:29 TCP SendUnkPkt 0AZC008200C8 20:05:29 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:05:30 From M1: 1EAS000000001111111100000000000E 20:05:30 TCP SendUnkPkt 1EAS000000001111111100000000000E 20:05:30 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:05:33 From M1: 16XK3305202070211010007B 20:05:33 TCP SendUnkPkt 16XK3305202070211010007B 20:06:02 From M1: 16XK0306202070211010007D 20:06:02 TCP SendUnkPkt 16XK0306202070211010007D 20:06:33 From M1: 16XK3306202070211010007A 20:06:33 TCP SendUnkPkt 16XK3306202070211010007A 20:07:02 From M1: 16XK0307202070211010007C 20:07:02 TCP SendUnkPkt 16XK0307202070211010007C
telljcl Posted February 8, 2011 Author Posted February 8, 2011 In playing with this utility, I seem to see no record of button presses. I don't know what the info in the above post shows, but what I'm posting below is what I see if I clear the box and press 4-5 keypad buttons with a few seconds or more between presses (on - off etc..) It appears to be unrelated to the lights, as it seems every 30 seconds the same info more or less goes through this utility - I don't think my button pushes are even registering. It sure doesn't spit out anything immediately upon my pressing a keypad button - only in these 30 second intervals it seems... 20:31:02 From M1: 16XK0331202070211010007F 20:31:02 TCP SendUnkPkt 16XK0331202070211010007F 20:31:33 From M1: 16XK3331202070211010007C 20:31:33 TCP SendUnkPkt 16XK3331202070211010007C 20:32:02 From M1: 16XK0332202070211010007E 20:32:02 TCP SendUnkPkt 16XK0332202070211010007E 20:32:32 From M1: 16XK3432202070211010007A 20:32:32 TCP SendUnkPkt 16XK3432202070211010007A I pressed at least 5 keypad buttons during about 30-40 seconds during the above time period.
gatchel Posted February 8, 2011 Posted February 8, 2011 Hi gatchel, Does the status get updated in the Admin Console? And, if so, are you sure you have the latest configuration for your system exported and then imported to ELK? With kind regards, Michel The admin console works fine. I can't remember exactly when the Elk configuration file was exported. It may have been 2.8.8 or somewhere in between. Does the Export need to be redone every time the ISY is updated? Here is my copy of the RP XEP tool: 20:43:24 TCP SessionRead received: 10027F0000A5100373D4 20:43:24 ProcessTCP RP msg: 10027F0000A5100373D4 20:43:24 RpComms for control 20:43:24 From M1: 20:43:39 TCP SessionRead received: 10027F0000A5100373D4 20:43:39 ProcessTCP RP msg: 10027F0000A5100373D4 20:43:39 RpComms for control 20:43:39 From M1: 20:43:54 TCP SessionRead received: 10027F0000A5100373D4 20:43:54 ProcessTCP RP msg: 10027F0000A5100373D4 20:43:54 RpComms for control 20:43:54 From M1: 20:44:09 TCP SessionRead received: 10027F0000A5100373D4 20:44:09 ProcessTCP RP msg: 10027F0000A5100373D4 20:44:09 RpComms for control 20:44:09 From M1: 20:44:24 TCP SessionRead received: 10027F0000A5100373D4 20:44:24 ProcessTCP RP msg: 10027F0000A5100373D4 20:44:24 RpComms for control 20:44:24 From M1: I turned on and off two different lights during the timeframe of this capture. Looks like some sort of polling and not much else.
telljcl Posted February 8, 2011 Author Posted February 8, 2011 Some more info: After resetting M1XEP / ISY: M1 Java control screen up simultaneously with M1XEP debug screen: Turning light (same light I'm using for simplicity) OFF from M1 Java screen gives this: 20:46:53 TCP SessionRead received: 30397066473033303042370D0A 20:46:53 ProcessTCP msg: 70 66 20:46:53 From M1: 0BPCG03000091 20:46:53 TCP SendUnkPkt 0BPCG03000091 20:46:53 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:46:53 TCP SessionRead received: 313170634130353034303030303030313034300D0A313170634130393034303030303030313033430D0A 20:46:53 ProcessTCP msg: 70 63 20:46:53 From M1: 0BPCA05001094 20:46:53 TCP SendUnkPkt 0BPCA05001094 20:46:53 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:46:53 From M1: 0BPCA09001090 20:46:53 TCP SendUnkPkt 0BPCA09001090 20:46:53 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:47:04 From M1: 16XK04472020702110100077 20:47:04 TCP SendUnkPkt 16XK04472020702110100077 Turning light ON via M1 Java gives: 20:49:44 TCP SessionRead received: 3039706E473033303041460D0A 20:49:44 ProcessTCP msg: 70 6E 20:49:44 From M1: 0BPCG03010090 20:49:44 TCP SendUnkPkt 0BPCG03010090 20:49:44 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:49:44 TCP SessionRead received: 313170634130353033303130303030313034300D0A313170634130393033303130303030313033430D0A 20:49:44 ProcessTCP msg: 70 63 20:49:44 From M1: 0BPCA05011093 20:49:44 TCP SendUnkPkt 0BPCA05011093 20:49:44 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:49:44 From M1: 0BPCA0901108F 20:49:44 TCP SendUnkPkt 0BPCA0901108F 20:49:44 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 Now turning light OFF from Insteon keypad gives: 20:51:01 TCP SessionRead received: 313170634130353034303030303030313034300D0A313170634130393034303030303030313033430D0A 20:51:01 ProcessTCP msg: 70 63 20:51:01 From M1: 0BPCA05001094 20:51:01 TCP SendUnkPkt 0BPCA05001094 20:51:01 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:51:01 From M1: 0BPCA09001090 20:51:01 TCP SendUnkPkt 0BPCA09001090 20:51:01 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:51:04 From M1: 16XK0451202070211010007C 20:51:04 TCP SendUnkPkt 16XK0451202070211010007C
dlamb Posted February 8, 2011 Posted February 8, 2011 telljcl, You're right, from the data that you've posted there are not any commands being sent to the M1. That tells me that the ISY is not communicating with the M1XEP. If you open the ISY admin console does is show the M1's correct arm/disarm status? And if so, can you arm/disarm from the ISY admin console? Is your M1XEP assigned a static IP address? Also you might try resetting the power to the Insteon PLM. By the way, the command that start with 16XK.... is the time stamp which is transmitted every 30 seconds from the M1. Don Lamb ELK Products
telljcl Posted February 8, 2011 Author Posted February 8, 2011 Well the ISY has to be at a minimum receiving info from the ELK in order to turn off the lights etc... I cannot arm the ELK via the ISY, but the ISY does show the proper armed status, instantly, just like the Insteon status. Soon as I change the arm/disarm status, it changes on ISY. If anything is changed via the ELK, the ISY shows it instantly. Its just that the ELK does not seem to know anything the ISY is doing. Did you notice that I did a few more "tests" of the buttons in my last few posts right before your above reply? They appeared right after keypadlinc button pushes - don't know what they signify, though. It seems like one-way communication somehow. Thanks for looking into it.
dlamb Posted February 8, 2011 Posted February 8, 2011 Hi telljcl, Apparently when I posted my reply last night I didn't see your 3rd data capture post. That data does show the lighting commands being sent to the M1. When you see a line that has "TCP SessionRead received:", it is followed by the ELK RS232 ASCII protocol data. In regards to your comment: Now turning light OFF from Insteon keypad gives: 20:51:01 TCP SessionRead received: 313170634130353034303030303030313034300D0A 313170634130393034303030303030313033430D0A Converting the captured data HEX to ASCII, the M1XEP actually received the command: 11pcA05040000001040 followed by a second command: 11pcA0904000000103C The commands cause the M1 to turn Light A05 OFF and Light A09 OFF. This is reflected by the M1 sending the captured data strings: (20:51:01 From M1: 0BPCA05001094) and (20:51:01 From M1: 0BPCA09001090). It appears to me that the M1 got the lighting command and broadcasted the light's change of status. You should be seeing the corresponding light(s) change on the M1 Java display. If you don't mind, please capture a few more rounds of data while manually pressing the Insteon wall switch or keypad. And also observe if any of the lighting icons change on the M1 Java display. Thank you, Don Lamb ELK Products
telljcl Posted February 9, 2011 Author Posted February 9, 2011 Thanks Don, Scene turned ON via Java app: 20:18:44 TCP SessionRead received: 3039706E473033303041460D0A 20:18:44 ProcessTCP msg: 70 6E 20:18:44 From M1: 0BPCG03010090 20:18:44 TCP SendUnkPkt 0BPCG03010090 20:18:44 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:18:44 TCP SessionRead received: 313170634130353033303130303030313034300D0A313170634130393033303130303030313033430D0A 20:18:44 ProcessTCP msg: 70 63 20:18:44 From M1: 0BPCA05011093 20:18:44 TCP SendUnkPkt 0BPCA05011093 20:18:44 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:18:44 From M1: 0BPCA0901108F 20:18:44 TCP SendUnkPkt 0BPCA0901108F 20:18:44 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 --> Turned off scene, cleared debug window... Scene turned ON via Insteon Keypad in Wall: 20:20:35 TCP SessionRead received: 313170634130353033303130303030313034300D0A313170634130393033303130303030313033430D0A 20:20:35 ProcessTCP msg: 70 63 20:20:35 From M1: 0BPCA05011093 20:20:35 TCP SendUnkPkt 0BPCA05011093 20:20:35 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:20:35 From M1: 0BPCA0901108F 20:20:35 TCP SendUnkPkt 0BPCA0901108F 20:20:35 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:20:38 From M1: 0AZC008200C8 20:20:38 TCP SendUnkPkt 0AZC008200C8 20:20:38 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:20:38 From M1: 1EAS000000001111111100000000000E 20:20:38 TCP SendUnkPkt 1EAS000000001111111100000000000E 20:20:38 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:20:38 TCP SessionRead received: 30366173303036360D0A 20:20:38 ProcessTCP msg: 61 73 20:20:38 TCP send 1EAS000000001111111100000000000E Scene turned OFF via Insteon keypad in wall: 20:22:07 TCP SessionRead received: 313170634130353034303030303030313034300D0A313170634130393034303030303030313033430D0A 20:22:07 ProcessTCP msg: 70 63 20:22:07 From M1: 0BPCA05001094 20:22:07 TCP SendUnkPkt 0BPCA05001094 20:22:07 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 20:22:07 From M1: 0BPCA09001090 20:22:07 TCP SendUnkPkt 0BPCA09001090 20:22:07 StoreData - iCSect: 11 iCSub: 0 iCNum: 3 ------------------------------------------------------------- Insteon is controlled perfectly by ELK - that has always worked. Its when Insteon is controlled by Insteon (or ISY controls Insteon) that ELK is unaware of status changes. I can leave the ELK java app up and change lights from an Insteon keypad and nothing changes on the ELK screen. I can turn lights on or off from that ELK java screen and it works, and status within ELK chages accordingly. Its when I press a wall button in the home (or ISY fires a command via automation) ELK is unaware of a change. Hope this helps.
dlamb Posted February 9, 2011 Posted February 9, 2011 telljcl, Sorry, I'm at a lost. The M1XEP utility is reporting that it received the lighting data when the Insteon Keypad scene button was pressed. Both for On and Off. I can see from the data that the scene consists of M1 Lighting device #5 (A05) and #9 (A09). That being the case the Lighting Icons in the M1 Java Virtual Keypad should also change state. For a test, please try adding a couple of M1 rules that are based on triggering whenever Light # 5 changes state. Such as: 1. Whenever Light5 (5[A05]) Turns ON, Then Speak voice message "Time of day". 2.Whenever Light5 (5[A05]) Turns OFF, Then Speak voice message "Time of day". Activate the same scene you tried before from the Insteon Keypad. If you hear the ELK speak the time then the ELK is receiving the commands from the ISY. The next thing to figure out is why your M1XEP's Java lighting display is not reflecting the changes. I may have to consult the XEP Engineer. Thank you, Don Lamb ELK Products
telljcl Posted February 9, 2011 Author Posted February 9, 2011 Thanks Don, Well I've discovered that the ISY / ELK relationship is very fragile - I've got to reset power on both frequently, and certainly after changing ANYTHING. I have found this, based on your suggested "Speak Temperature" test: Its Insteon "scenes" that are not being recognized by the ELK. Individual devices are in fact working properly (!) The scenes include more than one device, but should still have an "on" or "off" state (or at least they do within ISY and Insteon in general). I've got within ELK both the individual devices as well as scenes which include them. As another simple test, I checked "show" only on 2 lighting devices within ELK: A specific device, and a scene which includes that device. Watching the ELK java app, pressing a wall keypad which fires that scene (and the individual device that is in it) makes the individual device slider go "on" or "off", but the one signifying the "scene" does not change. Note that ISY shows the status of both the device and the scene it is included in both changing. This particular test scene only has 2 devices in it: The lamp module itself (which status is now working within ELK) and the keypad button LED of the button that fires it. The reason I never saw any of this as working is because that all "lighting" that I am monitoring within ELK is scene-based. I had no individual Insteon modules with the "show" box checked. So, I guess the issue is since most of my automation involves scenes, what do I need to do? I am making the assumption that ELK / ISY is able to resolve the status of a "scene". Possibly related, but I still have been unable to arm the ELK via the ISY99i. I have only 2 user accounts set up in ELK, and neither one has the "access" box checked. Don't know which account the ISY uses or if it matters... Thanks for your help
dlamb Posted February 9, 2011 Posted February 9, 2011 telljcl, I'm glad to hear it's working. In your Insteon "scene" scenario the M1XEP received commands from the ISY reporting that 2 lighting devices changed state. Related to ELK they are M1 Lighting devices # 5 and # 9. In order for the M1XEP Java web server, ELK Touchscreen, smart phone app, etc. to indicate the status the "show" option must be selected. In your case, if #9 is what you're referring to as a scene and you want to see it's status displayed, then M1's lighting device # 9 needs the "show" box checked. When you imported the ISY "XML" file into ELK-RP Lighting form, it should have by default filled the name, format, type, OPT, and the "show" option for each Insteon entity and mapped it to correspond with the M1 lighting numbers. With regards to not being able to arm/disarm using the ISY Admin console, you're right about it not allowing arming if the ELK User Codes have the "access" attribute assigned. So if you don't have "access" assigned the User Code should work from ISY. If you arm or disarm from the ELK keypad does the ISY reflect the correct arming state? Make sure that the ELK-M1 is disconnected from ELK-RP. Regards, Don Lamb ELK Products
telljcl Posted February 9, 2011 Author Posted February 9, 2011 Thanks - the ELK has an entry in the exported (from isy) list for the scene (2 devices) and all the individual devices. Can't I just choose "show" for the scene and expect that when that scene is switched on or off the status will follow? It seems to me that somehow ELK is not getting status of the scene or does not know the definition of the scene (which devices are in it) even though the scene xml file imported into elk shows the scene and the devices associated with it. You may recall in an earlier post that I checked "show" for the scene and a device in it. When I fire the scene from outside elk, elk only reflects individual devices going on or off, the scene status remains unchanged even if all 2 devices in the scene go from on to off or vice versa.
dlamb Posted February 9, 2011 Posted February 9, 2011 telljcl, From your test, the captured data that you posted shows that the ISY only reported 2 state changes (A05 and A09) when the Insteon button was pressed. That's all that the ELK has to go on in this case. If you open up your ISY "XML" file in a browser, can you find the data group with the name of your scene? If so, does it have an ELK-ID associated with it? Regards, Don Lamb
telljcl Posted February 9, 2011 Author Posted February 9, 2011 Don, The scene contains the A09 and A05 devices, and only those devices, and has an ELK ID, which is G03. Below is the "Scene" in question in the xml file: - 41367 Den Iron Floor Lamp 27 G03 F 75 E2 1 ----This one is the A05 in ELK F 1C D3 4 ----This one is the A09 in ELK These are the A05 and A09 entries: F 75 E2 1 Den (Iron Lamp) 1.0.51.0 true A05 F 1C D3 4 Den Keypad - D F 1C D3 1 1.12.45.0 true A09 These 2 devices show status / changes - just not the scene G03 above, which contains only those 2 devices as you can see. Keep in mind that I can control G03 scene perfectly FROM elk (Java app, Android phone, etc..), and both devices come on or go off instantly. ELK just can't tell when G03, as a whole, changes, if the change happens outside of ELK. Somehow there must be a difference in the way the ELK is processing the scene or multiple devices - maybe you can spot it in the xml entries or is there a different "check box" I need to check in ELK lighting setup for "scenes" as opposed to "devices"? Thanks for your time figuring this out.
Sub-Routine Posted February 10, 2011 Posted February 10, 2011 Hi telljcl, I'm not very familiar with the Elk but this is on our Wiki: To make secondary switches and keypad buttons correspond to a device status: * Create a scene with all the responders. Do not include the load device. * Create a program that controls that scene in response to changes in the load device. ISY-99i/ISY-26_INSTEON:ELK_Configuration Rand
telljcl Posted February 10, 2011 Author Posted February 10, 2011 Thanks for the info. This is a little confusing to me, as it basically seems to imply that you need to re-make all your scenes, and then have a "flag" device to trigger the scene. I can't believe that would be required for strictly Insteon control. Now I know integrating Insteon/ELK rules and status is tricky, and might require some ingenuity or extraneous steps like that. ISY, because it is exporting the scenes as well as individual devices, clearly assumes the ELK can turn on/off a scene just like an individual device - just like ISY or any Insteon unit can. My ELK can do it too, only problem is that it only can issue the commands - doesn't seem to recognize when someone / something else has done it. While I can see a few different ways to circumvent the problem (make scenes again, use ELK rules that are complex such as "if this light is on" AND "this light is on" etc..., but that could get really old quick. At any rate, your point is well taken. I think I'm missing something simple, or there is a problem in my setup somewhere. Thanks!
Recommended Posts
Archived
This topic is now archived and is closed to further replies.