krafty Posted August 15, 2008 Posted August 15, 2008 How difficult would it be to get the ISY to control a global cache GC-100? This would add a huge level of flexibility to the ISY. You could add IR Out, Contact closures, etc. I know there are insteon products that do the contact closures, but they are less than ideal.
Michel Kohanim Posted August 15, 2008 Posted August 15, 2008 Hello krafty, It would not be trivial but it's not that difficult since one can talk to Global Cache over TCP/IP. The main issue would be writing programs to send data over tcp/ip and not an HTTP payload. With kind regards, Michel How difficult would it be to get the ISY to control a global cache GC-100? This would add a huge level of flexibility to the ISY. You could add IR Out, Contact closures, etc. I know there are insteon products that do the contact closures, but they are less than ideal.
siegeld Posted February 25, 2009 Posted February 25, 2009 I second the motion for interfacing to this device. I entirely agree that it would be very useful. More generally, and to make it possible for users to add their own devices to ISY, it would be cool if you could define virtual devices in ISY that send data and received responses from a TCP port. This would permit a user to write their own gateway software, that would function as a device in an ISY program. Does this make sense? With this sort of capability someone could write, for example, a global cache interface program.
Michel Kohanim Posted February 25, 2009 Posted February 25, 2009 Hello siegeld (welcome back), We all agree. It's just the matter of time and resources and, more importantly, ROI for us. For instance: 1. HTTP GET is not difficult 2. HTTP POST is a little more difficult because we have to somehow store and post the body. And, then, I am sure we'll be asked to update the body based on some of the events in ISY which makes this a full and a non-trivial project 3. Listening to TCP connection is even more difficult since a. TCP connections are expensive ... UDP is much less expensive b. We would have to have the means of understanding the stream. i.e. let's say device A sends AAA and device B sends BBB, we would have to be able to parse (or at least do some pattern matching) each and figure out what they mean So, assuming that we implement all these features, how many more units can we sell? Or, if we made them into modules, how many modules can we sell? Based on our historical data, I really do not see any ROI. I would be delighted to hear your thoughts. With kind regards, Michel
siegeld Posted February 25, 2009 Posted February 25, 2009 Sadly, I agree that ROI would make this not worth doing. You're totally right. That's why I was wondering if there would be some way to expose enough of the API to make it possible for someone as a hobby project to write such code - and then even contribute it back to you. Ideally - if you provide a way that users could add support to devices for ISY I think you'd have a big win. You'd get people like me contributing back to you code that you would never develop on your own for lack of a business case. This user contributed code, though, would create a more vibrant commununity around ISY, helping you to sell units. So, I agree that it is not worth your effort to write GC-100 code, but it might be worth your effort to provide some plugin support to make it possible for a user to write GC-100 and other device code.
Michel Kohanim Posted February 26, 2009 Posted February 26, 2009 Hi siegeld, I totally agree. As a matter of fact, we are working on a network appliance solution which should give developers the ability to add support for other devices. Still in design phase though. With kind regards, Michel Sadly, I agree that ROI would make this not worth doing. You're totally right. That's why I was wondering if there would be some way to expose enough of the API to make it possible for someone as a hobby project to write such code - and then even contribute it back to you. Ideally - if you provide a way that users could add support to devices for ISY I think you'd have a big win. You'd get people like me contributing back to you code that you would never develop on your own for lack of a business case. This user contributed code, though, would create a more vibrant commununity around ISY, helping you to sell units. So, I agree that it is not worth your effort to write GC-100 code, but it might be worth your effort to provide some plugin support to make it possible for a user to write GC-100 and other device code.
tazal Posted March 4, 2009 Posted March 4, 2009 Is there a way to get the ISY to perform an HTTP GET to a user configurable URL? If so that would allow users to write a gateway of sorts to fill some gaps. For instance, I own interfaceGO which allows you to configure a network camera widget. The URL for the camera is user-definable so I have defined it to point at a CGI script on a linux box and I use the QUERY_STRING to parse arguments that were passed as part of the URL and then run some program on the linux box. In this case I dynamically create a jpg from text, such as "command X successful" or "command X failed" and return that so the interfaceGO software shows that picture as the camera image since that is what it expects. It's clunky but so far it works reliably. If there was a way in ISY to perform a user-defined HTTP GET I could write a similar gateway for that. I could work with most anything, formatted text return for status would be fine or even nothing at all. With this I could have the ISY control IR via a GC100, control my RCS thermostats, whatever I want. It requires a web server to handle the HTTP requests but for most of the people looking for this functionality that isn't a problem and it almost infinitely enhances the flexibility of this already great product. Thanks! Hello siegeld (welcome back), We all agree. It's just the matter of time and resources and, more importantly, ROI for us. For instance: 1. HTTP GET is not difficult 2. HTTP POST is a little more difficult because we have to somehow store and post the body. And, then, I am sure we'll be asked to update the body based on some of the events in ISY which makes this a full and a non-trivial project 3. Listening to TCP connection is even more difficult since a. TCP connections are expensive ... UDP is much less expensive b. We would have to have the means of understanding the stream. i.e. let's say device A sends AAA and device B sends BBB, we would have to be able to parse (or at least do some pattern matching) each and figure out what they mean So, assuming that we implement all these features, how many more units can we sell? Or, if we made them into modules, how many modules can we sell? Based on our historical data, I really do not see any ROI. I would be delighted to hear your thoughts. With kind regards, Michel
nstein Posted March 4, 2009 Posted March 4, 2009 Post removed: Sorry , somehow I posted my reply to the wrong thread, I have reposted in the correct one.
siegeld Posted March 5, 2009 Posted March 5, 2009 I agree, having a GET as an action option would be perfect, and probably not so hard to do. It would also be cool if as an action you could set variables, and then as a condition you could test the state of a variable...
Michel Kohanim Posted March 5, 2009 Posted March 5, 2009 Hi Nick, thank you. I was not aware of it ... I will check it out. siegeld, the more complex the requirements the lower the priority. i.e. A simple Get is trivial. Adding variables and testing them is NOT. Perhaps we can stick with the trivial and then add other features. With kind regards, Michel
siegeld Posted March 5, 2009 Posted March 5, 2009 Yes, of course. For my current need, the simple GET is pleanty. Thank you for your consideration.
MikeB Posted May 20, 2009 Posted May 20, 2009 ISY-99 firmware 2.7.4 and its Network Resources feature (available with the optional Networking Module) can now interface with the Global Cache GC-100 (and more): http://www.universal-devices.com/mwiki/ ... _Resources
AnthemAVM Posted October 4, 2009 Posted October 4, 2009 Could you easily use the GC-100/ISY?InterfaceGo and Nokia N810 to controll my TV in mt bedroom? Thanks
MikeB Posted October 4, 2009 Posted October 4, 2009 Not currently because the interfaceGO NK8 does not support running ISY programs. You could do this with dummy INSTEON devices (turn the devices on/off with the NK8, then have ISY programs send IR commands based on those devices). I do hope to support future ISY variables in the NK8, which would alleviate the need for dummy INSTEON devices.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.