Premise Premise Universal Devices ISY-994i integration

Motorola Premise

georgejm

Active Member
Anyone interested in beta testing a new ISY driver for Premise?  I've got a fairly substantial Insteon deployment that I can test with, and a couple of Zwave devices.  I'd like to get a larger Zwave setup to test with if I can.  If you're interested in testing this, PM me with your email address.  I'll send you the bits...
 
I could be interested but can't find any information in the forum.

What HA hardware does it support? Is it open-source? Where do I find an SDK?

As much as I hated C++ I could muddle through it probably. I am not sure this tired old brain can handle reactivating this much logic again.
 
Larry...it supports a lot of HW. Lots of SW. Go to the stickies. You should be able to get a bunch of info there.
 
Thanks. That site was much more informative.


They show support for the Insteon protocol but no Insteon hardware to use with it. Would the lists be out of date or is this what the ISY to Premise thread about, attempting development?

What is the ISY to Premise interface discussion in this thread about?
Is the OP looking for
- ISY to update Premise,
- Premise to update ISY,
- Premise to use ISY/PLM as a modem for Insteon/Zwave/X10/ZigBee interface,
- or other?
 
I wrote two Insteon drivers for Premise.  One uses the now defunct PLC.  The current version (just posted an update in the Downloads section a few days ago) uses the Insteon PLM.
 
My goal with the ISY driver for Premise is to essentially (as you state in your third bullet) use the ISY as a "modem" for Insteon and Zwave.  I'm open to Zigbee, but don't have any hardware to test against.  I think X10 is very unreliable, so I don't think it's worth spending any time making the Premise driver for ISY work with it. 
FYI, my original PLC-based driver did support X10.
 
I had hopes that the ISY would abstract all these different device technologies and make it "easy" to add support for them in the Premise driver.  Unfortunately, Universal Devices didn't fully abstract Insteon, Zwave (or the other device types).  There are nuances about each technology that you need to account for in a driver that frankly shouldn't be necessary.  For example, it would be ideal if the ISY simply abstracted any dimmer (Insteon, Zwave, or Zigbee) as a dimmable device.  The current version of the ISY firmware represents Insteon dimmers and Zwave dimmers differently.  So the code in the driver needs to be different to implement each technology.  I'm sure the same is true for the other ISY supported technologies.
 
Once we get the basics going, we could look at doing some more interesting things with the ISY. 
 
Where does the ISY driver install?
Is ISY's REST interface being used with a batch of ISY programs to pass the controls through?

I guess I on't understand why one controller would want to control another smart controller to control it's modem when a direct link to the same PLM modem would control two HA protocols.
 
The driver installs on a PC that has network access to both the ISY and the Premise Server.   An XDO needs to be imported into Premise to create all of the ISY devices classes.  The driver itself uses the SOAP Web Services interface built into the ISY, and does not depend on any ISY programming. 
 
As to your question of why would one controller want to control another, that's bordering on philosophy  :blink:    ​ .​
 
The ISY is very good at low level communications with a variety of devices.  Premise has the ability to abstract low-level devices, and create very complex scenarios combining lighting, environmental, security, media etc.  For example, in my setup I can select a movie to watch within Premise and simply tell it to play in the living room.  Premise dims the lights, lowers the shades, allocates the resources necessary to play the movie, powers-up the devices, sets the devices to the appropriate inputs, and starts the media streaming.    The ISY only handles the Insteon devices (e.g. lighting).  Other Premise drivers handle the TV, UPnP Media server, etc.  Premise's built in abstractions for the various devices and media make it very easy to orchestrate all of this without writing a bunch of code. 
 
Hope that helps.
 
John in VA said:
The driver installs on a PC that has network access to both the ISY and the Premise Server.   An XDO needs to be imported into Premise to create all of the ISY devices classes.  The driver itself uses the SOAP Web Services interface built into the ISY, and does not depend on any ISY programming. 
 
As to your question of why would one controller want to control another, that's bordering on philosophy  :blink:    ​ .​
 
The ISY is very good at low level communications with a variety of devices.  Premise has the ability to abstract low-level devices, and create very complex scenarios combining lighting, environmental, security, media etc.  For example, in my setup I can select a movie to watch within Premise and simply tell it to play in the living room.  Premise dims the lights, lowers the shades, allocates the resources necessary to play the movie, powers-up the devices, sets the devices to the appropriate inputs, and starts the media streaming.    The ISY only handles the Insteon devices (e.g. lighting).  Other Premise drivers handle the TV, UPnP Media server, etc.  Premise's built in abstractions for the various devices and media make it very easy to orchestrate all of this without writing a bunch of code. 
 
Hope that helps.
Thanks for the explanation but your concept of the ISY sounds like many years out of date.

Currently ISY owners are interfacing natively with X10, Insteon, ZWave, ZigBee, Elk security, Weather sources, and via Node servers with Hue, Milights, Wink, CAO Tags, WC8, Amazon Echo, Kodi/XBMC, Infrared controllers, Thermostats( ecobee3, Honeywell, Nest, Venstar) and the list goes on. I can't tremember half of what people are doing with it. I use it as server for some java script and a logging database, and system, for my HVAC system. UDI was just granted $3.4 million in funds to develop more home ADR systems for residential energy saving systems.

I would have loved to write and have total control over my own HA system, myself, but when ISY994 does more than I could ever hope to do and grows more everyday, I can't be bothered to write more code, after 42 years of tiring from it. I would have used the Insteon Hub (without any advanced logic capability, and cheaper) for a one box interface but ISY994 supports so many well documented interface protocols to probably make your job getting to Insteon, and many other protocols, much simpler.

Perhaps the marriage can accompptlish some more powerful concepts not possible before.

Others have interfaced with ISY994 for a bridge but ended up dropping the original logic after seeing the capabilities of this little 3 watt box.
 
I'm pretty sure I'm up to speed with ISY.  I've been a developer on the platform for several years.   Premise was (and still is) way ahead of the other HA platforms with regard to media management.   If you haven't looked at it, you really should.   It's pretty cool. 
 
John in VA said:
I'm pretty sure I'm up to speed with ISY.  I've been a developer on the platform for several years.   Premise was (and still is) way ahead of the other HA platforms with regard to media management.   If you haven't looked at it, you really should.   It's pretty cool. 
Your comments towards ISY994 "The ISY only handles the Insteon devices (e.g. lighting)." seems to indicate otherwise.

People run their Sonos, Kodi, and many other media methods from their Echos with voice commands through ISY994. using iR, and various Ethernet protocols.
 
Back
Top