This is ideally what I would like to be able to do. It might take a bit longer vs. automated discovery but at least all the Insteon devices would be part of the network as an app.
I like your HAM Bridge, seems to do what it’s supposed to . My only concern with that is that it seems to need an Apple computer running at all times as the middle-man. I don’t really want to have a device running just to bridge the hubs. I do have 1 Unraid server (that does run 24/7) in my household but that’s the only computer that’s always on.
Here is my VERY basic code for controlling a light.
I haven’t touched in a very long time… so I believe that status does not work. To get status you have to send two commands, but pause between them a bit. With my knowledge of smartthings at the time I wasn’t able to make it work and didn’t spend much effort on it. It works well enough for me to turn it off at night if i accidentally leave it on
The fanlincs are neat. I considered them when I was starting down the Insteon path. I only have two light switches and an outlet control… Don’t plan on moving forward with any more Insteon. It’s unfortunate because the have had devices for a long time that nobody else has created with zwave or zigbee… But they are a far too closed ecosystem.
On that note, I am pretty certain I could get the fan portion working quickly… And probably the lights. Everything in Insteon can be controlled via http commands to the hub. It’s just figuring them out
It would be nice to have some “higher end” looking dimmers available. The GE one looks pretty cheap and tacky on walls when compared to the look of the Lutron dimmer for example. Insteon makes a pretty decent looking product - see here. http://www.insteon.com/2477-wall-switches.html - would love to get proper support for this device or something similar looking (sleek looking with LED lights). Thoughts?
Insteon makes a smoke bridge to connect First Alerts OneLink smoke detectors to home automation. They seem to be the only company that makes such a device. First Alert makes the zcombo which is z-wave but I have like 8 OneLinks so I would really like to connect them to my ST hub without spend the money to replace.
I also want Insteon integration. I have it throughout my house because Insteon has too many affordable devices that others just don’t. For me it’s the keypadlincs that give me feedback and more control of my whole house, but i also have fanlincs, LEDs, IO, Open/Close sensors, etc.
With that, i’ve been wanting to build something for smartthings to work with insteon but I am not sure if developers have access to local LAN control yet. Does anyone know? If so I might be able to build something. I’ve already reverse engineered insteon and created SW that allows me to control my whole insteon network. I would love to implement this on ST so it can actually control my whole house.
Insteon also has a development program that allows someone to understand how their network works, it’s not an open API but it does exist.
Actually you really want the Insteon Hub which replaces the smartlinc. The smartlinc had issues of dieing after about 1-2 years. The while not as well documented, the hub gives you the same control as the smartlinc had for local control.
I’m using a smart hub and EventGhost with some python code I wrote that uses the hidden port. This allows me to see everything going on within the Insteon network for real time events. Of course I can also send broadcasts and direct messages to the insteon devices. I currently use HouseLinc to setup the devices then shutdown HouseLinc to let EG take over. It would be ideal if ST could use the hidden port to get real time events from the insteon network, but it would have to be an always open connection which i’m not sure if ST can handle or not. If it did work, ST could have full two way communication to the Insteon network and all devices on it.
I am using an ISY994 for all the INSTEON control. With its REST API it is easy to push simple state changes Like Home and Away. I am doing ALL lighting scenes through the ISY and Insteon, with the advantage that the scenes ALWAYS work - internet or not, cloud or not. Cant have it for the lighting to be flaky just because a cloud service is unresponsive.
@fxstein do you have any more detail on how you are using SmartThings to ‘poke’ the REST API of the ISY994i? I just got ISY as I have abandoned revolv, I am not a programmer so any dumb-ass guides to doing this you may have would be appreciated
Did you get a solution for this?
If you’re just wanting to send a command to turn the fan on, off, med, high low, etc. This should be doable within smarththings with either the example linke given above or using the hidden port in the hub. I have not done this my self with smartthings but have wrote code to do it on other platforms. I haven’t focused on a solution like this because I need more itegration with smartthings which the current hub can’t support.
I’m actually working on some more integrated control and a SmartApp for Insteon devices using a PLM instead of a hub. The SmartLink is no longer sold so it wasn’t an option - which was disappointing. I decided against the Insteon Hub as it requires using the cloud - and although the smartthings also does, I want to limit cloud connection - and the Hub was also more expensive.The hub also has a terrible api (so I’m told and from what I’ve seen). Oh, and there’s also the lack of two way communication back to a ST app as well. The downside is that i needed a way to expose control of the PLM(usb version) via IP - so rasberryPi to the rescue.
I’m working on a service that connects control of the PLM to a LAN connected rPi serving up a nice REST client. So far my proof of concept works. It’s nothing magic, and unfortunately requires additional hardware. I’m coming from the revolv world with a lot of insteon devices - so I need the option - as do several others I’m sure. The other benefit is that I can receive messages from the PLM directly into a SmartApp.
There will be limitations of course. Biggest one IMO so far is that a smartapp can’t define deviceTypes. You’ll still be required to define deviceTypes in the web UI for any insteon device. Secondly, I’ve not yet determined if the ST ui can handle “finding” devices. I can set the PLM into discovery mode from the smartapp and handle any notifications of new devices - but not sure how to expose to user (yet).
That all being said, I think there is great possibility here, especially with the ability to handle two way communication. There’s a lot of work to be done, but I’ve got proof of concept completed with a single insteon switch. If anyone wants to help on either side of the puzzle, PM me. I am using mono on the rPi as I’m a c# developer and it’s just the easiest and fastest route. I have no time to bother with any other language - it’s enough dealing with ST groovy and lack of documentation.
I would be willing to help if I get some time. I’ve already reversed engineered a lot of the insteon protocols and have written a plugin for a different platform. I’m just not sure how much of the code I could write using C# though. In my case i’m using the Insteon hub but instead of using the cloud platform i’m using the hidden IP port that allows you to interact with it as though it’s a PLM (it actually is the PLM).
Yeah, the insteon code i’m using allows for this “back door” connection to the hub as well… although I’ve not verified as I don’t have one. I’m only going by the insteon documents. But, help on the ST side if you’re more comfortable there would be great. I’ve only had my ST hub for a week, and this lack of documentation is really slowing me down.
@tracstarr - When coding this, also remember that @Ben has said that Hub v2 will have a USB port on it. That might make it easier? Don’t know enough about INSTEON to know if the USB adapter would be workable through the Hub and if you could discover devices through it.
Yeah, it would depend if they allow low level access to serial port drives via fdti which is what you need to connect to the PLM. Also, I’m doubting there would be the ability to keep that port open with a service running - which you would need to receive communication FROM the PLM to update status of devices manually triggered or otherwise. It sure would be nice though… but until we know more…