dpower

Proximity app is up and running on two devices right now and I have it triggering programs to flash lights and send a text message when my wife is within striking distance. (NB: Nothing untoward here. Just a warning so I have time to stop doing geeky stuff before she opens the door.) In terms of at-home Bluetooth monitoring, does anyone know of an hcitool equivalent for Windows? It would make sense that someone, somewhere has developed one but I've yet to locate it. Thoughts, anyone?

Steven... Permissions to the C: drive was the issue. I changed the path on line 75 so the .pid file is now being created in a permissioned location. I'll check to see if there are other references and update them accordingly. Happy to report the script is working fine. I was out to the gym this morning and it tracked my trip out and back. Next... onto the ISY program. Thanks for your help.

Steven... Everything's gone exceptionally-smoothly on Windows 10... up to the point of running iPhoneLocation.py, at which point it generates the following error: Startup: Your current operating system is windows Startup: PID=488 Startup: Failed to load logging settings, ABORTING! Traceback (most recent call last): File "iphonelocation.py", line 75, in <module> f_out = open('c:\{}.pid'.format(application_logging_name), 'w', 0) IOError: [Errno 13] Permission denied: 'c:\\iPhoneLocation.pid' It seems Python has a permissions issue writing to disk. Before I spend too much time unpacking this, do you have any advice? Thanks.

Haven't started yet. Wanted to ensure I wasn't headed down a deep, dark hole before I begin. Cheers!

Steven... This may be an ignorant question but is there any reason your script wouldn't run on a Windows 7 box?

Thank you, Michael. That combination of steps solved my problem. Cheers, dp

I'm experiencing the same problem -- a system that's been functioning well for several years. Now, when I load the Programs page, it's completely blank. This has happened only since updating to v3.2.6 (i.e both UI and firmware report the same version.) Any thoughts on what might be causing this? Thanks, dp

Took delivery of this device earlier this week. Plugged it in and proceeded to link it through the conventional method (i.e. clicking "New INSTEON Device") The LampLinc appeared to link with the ISY however it did take longer to link than I recall it taking with other devices. The device showed up under "My Lighting" and I proceeded to adjust the Ramp Rate -- no problem. Right click and "Query" device -- no problem. Turn the attached lamp on or off locally -- no problem. From the device page, click "On" or "Off" and I get "Cannot Communicate With... Please check connections." I'm running ISY firmware v3.1.17. The LampLinc's device page indicates v.00 -- which is suspect. The device is plugged directly into a wall outlet -- the same outlet an older 3-pin LampLinc was removed from. I'm stumped. Any thoughts? Thanks, dp

After several back and forth's with Digi Support, I've reached a resolution I'd like to share with the population here. My PortServer TS 2 is a legacy OEM version for which official support expired in mid-2010. Being an OEM version, its web interface isn't the same as that referenced in the Digi documentation -- it doesn't expose a method of creating a "Port Profile" and specifying "TCP Sockets". When configured as type "Terminal", the device refuses TCP and/or Telnet connections on port 210X. I was able to create a RealPort connection to the device -- and that worked fine -- but it means you always need a PC in the chain -- you can't communicate with the PortServer directly over the network. After much searching and experimentation... by configuring a port as type "Printer", you can connect and send messages via TCP / Telnet. You'll need to relinquish any existing connections (i.e. RealPort) to the PortServer in order to make this work but I can confirm it does in fact work. Thanks to Digi Support for suggesting this solution. Hoping this benefits anyone else experiencing similar issues. Thanks, dp

Bump. Hoping someone can give me a few quick hints to get me up and running. Thanks, dp

I appreciate that, iostream. I've procured the July 2011 version of the ISCP specification so I'm Ok on that front. I'm also comfortable with wiring, configuration of the serial port, specifying a static IP address, etc. All these things are relatively straightforward. Where I'm running into questions / issues at the moment is in the following areas: - For what "device type" should the PortServer be configured (e.g. Terminal, Printer, Modem, etc.)? - How do I specify a TCP port over which to communicate with the PortServer? (i.e. the only place I see an option to configure port is under "Autoconnect" -- which I'm almost certain I don't want as I'd like to send distinct TCP messages to the receiver from different devices on the network.) - Once these things are worked out, how do I send a simple message to the PortServer from the ISY? Should it not simply be a matter of creating a network resource of specifying TCP, Host, Port, etc. and sending a properly terminated ISCP string (e.g. !1PWR01)? I've done this but upon sending a message, I receive one of: a) a pop-up dialog indicating "Subscriber didn't respond to event: 1" with sub-codes 63 and 64 on my first attempt, Request Failed (i.e. second attempt) or c) standard "N/A" response on third and all subsequent attempts. Once, I've even seen a "Mail server failure" message which makes no sense at all in this context. I acknowledge these are more Portserver-related questions rather than pure ISY-99i issues. But I'm hoping someone with a UDI-centric home automation solution has encountered and overcome similar issues. Again, I appreciate any advice or guidance you can offer. Thanks, dp

I received a Digi Portserver this weekend -- my plan being to use it to interface with my Onkyo AVR via RS-232. I do have some programming experience and have recently integrated an iTach IP2IR device into my system (i.e. thanks to member GPG for this viewtopic.php?t=5087) but I have yet to configure and control anything over a serial port. I've searched the net but haven't found anything I can use as a reference (eg. sample code, tutorial, etc.) to get me up and running. I gather there are at least a few members here who have successfully integrated a Portserver with their ISY / Insteon network. Are any of you willing to spare a moment or two to help a fellow UDI fan get off the ground? I appreciate any advice or help you can offer. Thanks, dp

Lee... It's a v63. I bought a developers package a few years back -- I was reminded because the address on the PLM is AA.AA.AA. Can PLM firmware be updated? Is it generally necessary? Thanks, dp

Lee, Resetting the PLM did it. I can now see all RL key presses and related events. Valuable lesson learned. Thanks for your help. dp

Lee... Those are solid ideas and I just tried them both. Still no go. I still don't see any RL traffic in the Event Viewer. I see all the INST-SRX and INST-ACK's as the device is linking. I see device status changes when I send a REST command. But -- and I just clued into this now -- I see neither RL key presses NOR status changes initiated by RL key presses. I'm fairly certain I have my phases coupled. If they weren't, the ISY wouldn't be able to link the RL to anything, correct? And it does that without problem. Is there anything else that would create the symptoms I'm seeing? I'm stumped. Thanks, dp

I'm attempting to trigger ISY programs based on RemoteLinc 1 keypresses (i.e. Control Status in ISY parlance) but the ISY isn't seeing them. My Insteon devices sees (or is it "hears") RL keypresses reliably so I know the signal's strong. But no luck on the ISY. I've gone so far as to plug an Access Point directly into the PLM. Still no love. I now have 3 AP's and a dual-band dimmer in my setup but the ISY isn't seeing RF buttons. Are there any hints or tips anyone can offer? Thanks, dp

K, Since my last post, I went ahead and created an EventGhost plugin of my own. Managed to get it in service within a few days thanks to the UDI's REST interface. That said, your plugin is quite slick and very helpful. Your event subscription implementation is a huge asset. I haven't been able to get your SetDevice or SetGroup actions working yet -- I'll have to troubleshoot my environment this weekend. But all-in-all, a great and useful plugin. Thank you for sharing. Questions: 1) I've noticed you've opted to create explicit SOAP headers / messages rather than using the ISY's REST interface. I've found the REST GETs far easier to code (i.e. a single line rather than 7 or 8 ) and fairly responsive -- no noticeable delay. I'm wondering, is there a specific reason you took the SOAP route? Performance? Control? Other? 2) Your plugin uses some elaborate string parsing to pull apart XML responses. While you've obviously do this very well -- as evidenced by the fact that it works! -- I'm curious as to why you chose to parse them yourself rather than using minidom functions (for example) to do the heavy lifting for you? Thanks again, dp

Michael... Is it correct to assume the only way I can reliably ensure the ISY hits its UDP or multicast target is to assign fixed IP addresses to those targets? If so, would it follow the only way a remote machine could reliably hit ISY via REST would be to assign a fixed IP to the ISY? Thanks, dp

Thanks, Michael. I appreciate the distinction. I am, however, confused by the fact that the ISY's multicast implementation requires a host as well. Why would this be the case? Thanks, dp

Thanks much, Tom. It's great to hear you're having success integrating the ISY and EventGhost. Sounds like you're doing some interesting work as well. I'm curious as to why you chose HTTP over UDP or TCP. How's the responsiveness of HTTP? I ask because -- as a protocol -- it has a tremendous amount of overhead versus UDP/TCP. Had you experimented with the other protocols at all? Just this week, I've had success in integrating the ISY and EventGhost over UDP. It seems to be reliable and fast. The only odd thing I've noticed is the UDP screen insists I specify a "host" IP. As my network -- which has numerous PC's, routers, switches and other devices -- currently runs on DHCP, I'd prefer not to assign static IP's if I don't have to. Unless my understanding is inaccurate, UDP is a broadcast protocol (i.e. sends an IP-agnostic packet across the network). I don't understand why it's necessary to supply an IP address to a broadcast packet. Is there a way to get around having to specify a host on the ISY's UDP resource screen? Thanks, dp

Greetings all, I've just started to investigate the ISY-99i's Network Module capabilities and would like to know other people's experiences -- especially as they relate to integration with EventGhost and/or Girder. I've searched high and low -- on this forum, EventGhost's and elsewhere -- but haven't yet found anything definitive regarding how to make the ISY talk to EventGhost. I gather EventGhost's Network Receiver Plugin isn't going to work in this context as it requires elaborate handshaking and hashing. But I'd expect the Broadcaster Plugin -- which is a simple UDP listener -- should work. Has anyone had success with this or any other network communication methods? Would you mind sharing? Thanks, dp