How can we bring ISY closer to Control4

[RaginBajin]

Control4 is really nice. Since you pay for it, they have obviously put a lot of great time and effort into integration.

 

I'm curious what others think would be necessary to bring the ISY platform on par with a Control4 platform. 

 

For me, three of the biggest things that I see that hold it back are:

- Mobile Application - Yes, we have MobliLinc, but I seem to have problems with network resources not showing up as they should or being able to reclassify items if necessary. 

- LCD Panels - May sound meh, but I'd like to have a lot of system in a few nice LCD panels that integrate with the system.  Maybe this is solved with a good Mobile platform. 

- Certified or at least approved Drivers - There are a lots of great add-ons making their way out here, but I feel like its completely up to others to get it working. I do a lot in the OpenSource area, and I know that most work is only done specifically to the designs of those building it or using it.  It takes Project Leads and others to help enforce a generic thinking when building features and functions so that it can work for the majority and not that one specific person. 

 

What do other think?  I'm not completely bashing on ISY. I like my ISY and I think its actually one of the most flexible platforms out there, but with all that flexibility does come too many options/choices. When people have too many options/choices, they become overwhelmed and no progress gets made. 

[larryllix]

Agave seems to be the closest project to possibly become a future control panel screen. I do not know where that is at because other than the testing of the freebie trial I have not pursued it. I have not had any need for it.

I previous thought a control panel was my supreme accomplishment but now I have lost interest in them with the voice recognition tech jumps out there.

 

Driver and software standardisation is always good.

 

Please don't tell me we have to quintuple the ISY price and get rid of all public information about it, then have somebody else change my software, though!

[RaginBajin]

Agave seems to be the closest project to possibly become a future control panel screen. I do not know where that is at because other than the testing of the freebie trial I have not pursued it. I have not had any need for it.

I previous thought a control panel was my supreme accomplishment but now I have lost interest in them with the voice recognition tech jumps out there.

 

Driver and software standardisation is always good.

 

Please don't tell me we have to quintuple the ISY price and get rid of all public information about it, then have somebody else change my software, though!

 

 

The last thing would be to have the ISY jump in price.  I guess I'm curious to know what the long term objective for ISY is then.. I've watched a lot of ideas come and go, but I don't get a feeling for where it is envisioned to be in the market place. 

 

Being second or even third place to the Control4's and the Creston's is fine.  I just want to see the ISY get to that level. 

[ScottAvery]

the biggest cost is PLM replacement!

[Scottmichaelj]

As an owner of an AV company, the ISY and Insteon fit perfectly with RTI remote control systems. I stopped a long time ago trying to make the ISY a “whole house hub” and keep the ISY as it’s own platform that’s linked into the RTI system. This allows me the best of both worlds, which also makes ISY so great (being open). I am very happy with my setup and RTI allows me to customize the mobile apps to work and show anything I want. Granted RTI is not open to the DIY crowd or cheap.

 

Resources of UDI are small due to it being a small business. I rather see the UDI team focus on making the ISY the best it can be and not try and do too much. Plus the costs for new custom hardware is expensive. UDI is working hard on version 5.x.x and have their energy contract, so unless they get some huge influx of cash flow I don’t see UDI making any huge changes in direction anytime soon. IMHO the ISY is still THE BEST Insteon controller on the market and Node Servers/v5 will just make it that much more powerful. Hopefully 2018 brings us a final v5 and many other exciting things. I can’t wait to see what UDI has in store for us!

[RaginBajin]

As an owner of an AV company, the ISY and Insteon fit perfectly with RTI remote control systems. I stopped a long time ago trying to make the ISY a “whole house hub” and keep the ISY as it’s own platform that’s linked into the RTI system. This allows me the best of both worlds, which also makes ISY so great (being open). I am very happy with my setup and RTI allows me to customize the mobile apps to work and show anything I want. Granted RTI is not open to the DIY crowd or cheap.

 

Resources of UDI are small due to it being a small business. I rather see the UDI team focus on making the ISY the best it can be and not try and do too much. Plus the costs for new custom hardware is expensive. UDI is working hard on version 5.x.x and have their energy contract, so unless they get some huge influx of cash flow I don’t see UDI making any huge changes in direction anytime soon. IMHO the ISY is still THE BEST Insteon controller on the market and Node Servers/v5 will just make it that much more powerful. Hopefully 2018 brings us a final v5 and many other exciting things. I can’t wait to see what UDI has in store for us!

 

I could fully accept that ISY isn't going to be the total product like RTI or Control4.  I think as long as its users could be helped down a path that doesn't involve so locked in choices like RTI or Control4.  I'd like to know more about how RTI is being integrated with your ISY. That sounds pretty cool 

 

It makes sense that they can't focus on everything and all options. I guess as a supporter for quite a while, I'd like to hear more from UDI.  I've gone through a some posts that are recent and I see arguments from admins towards users as they are making recommendations.. I'm hoping that 5.x makes a final appearance in 2018 and we see where it can take us.. 

[lilyoyo1]

 

Control4 is really nice. Since you pay for it, they have obviously put a lot of great time and effort into integration.

 

I'm curious what others think would be necessary to bring the ISY platform on par with a Control4 platform. 

 

For me, three of the biggest things that I see that hold it back are:

- Mobile Application - Yes, we have MobliLinc, but I seem to have problems with network resources not showing up as they should or being able to reclassify items if necessary. 

- LCD Panels - May sound meh, but I'd like to have a lot of system in a few nice LCD panels that integrate with the system.  Maybe this is solved with a good Mobile platform. 

- Certified or at least approved Drivers - There are a lots of great add-ons making their way out here, but I feel like its completely up to others to get it working. I do a lot in the OpenSource area, and I know that most work is only done specifically to the designs of those building it or using it.  It takes Project Leads and others to help enforce a generic thinking when building features and functions so that it can work for the majority and not that one specific person. 

 

What do other think?  I'm not completely bashing on ISY. I like my ISY and I think its actually one of the most flexible platforms out there, but with all that flexibility does come too many options/choices. When people have too many options/choices, they become overwhelmed and no progress gets made. 

 

To bring the ISY to parity with Control4 is what you mentioned first. Money. Control4 systems (and comparable systems) arent cheap. All that you mention costs money. Much more than most would be willing to spend. 

 

I agree with ScottMichaelj as I use RTI as well. You get the best of both worlds though its not cheap. You can semi achieve that custom look with IPADS and software such as ekeypad or command fusion. 

 

When I built my first command fusion app a few years ago, I gained an appreciation for what companies such as Crestron and Control4 go through to have these all in 1 systems like they do. UDI pursuing the same would either be a waste of money/resources for them or price the ISY out of many peoples pockets.

[lilyoyo1]

I could fully accept that ISY isn't going to be the total product like RTI or Control4.  I think as long as its users could be helped down a path that doesn't involve so locked in choices like RTI or Control4.  I'd like to know more about how RTI is being integrated with your ISY. That sounds pretty cool 

 

It makes sense that they can't focus on everything and all options. I guess as a supporter for quite a while, I'd like to hear more from UDI.  I've gone through a some posts that are recent and I see arguments from admins towards users as they are making recommendations.. I'm hoping that 5.x makes a final appearance in 2018 and we see where it can take us.. 

Its hard for UDI to control a path without locking users in since there are so many variables to choose from. For example, both ScottMichael and I (there are others on here as well) who use the ISY with RTI. Yet, if any of us were to post how we run our homes, you would probably see a huge difference to our approach. For them to wade into something even more open, would require more resources than they could spare for potentially very low return (if any). 

 

The forums are a great resource to help you achieve what you are going for. Whether its using something like command fusion on tablets through out, or mobilinc on tablets, there are plenty of people here who has done work like that who would be willing to assist. Reality is, the ISY in its current form is the jack of all trades. Want a custom look without the associated costs, it can be done. If you have the finances and don't want the work, it can be done. 

[paulbates]

ISY's sweet spot is the back end integration. I'm not sure that there's a strong business case for UDI to enter the crowded, highly competitive remote control solution market. A more direct path/suggestion is for vendors of the higher end systems to develop their own ISY "drivers" on UDI's open standards They could charge for it back through their channels to their buyers. They could keep control and could manage the integration within their sometimes strict NDA/contract structures.

Another view is that the touch screen remote control aspect is not always and end in itself for all HA users.  The ISY is an expert platform for creating fully automated, "hands off" solutions. Where needed, remote control is able to be handled by progressively improving smart speakers (echo/home), which are easy to integrate and inexpensive.

Paul

 

 

[Scottmichaelj]

I...

Have you looked into the Logitech Harmony integration with the ISY? It’s not a complete package however it might fill the gap your looking for at a reasonable price point and it’s more DIY. Then using ISY programs with MobiLinc or Agave might fill the gaps.

 

It’s not going to be a “pro” system but others here have done a lot. You could customize a KPL to control things too. Just a suggestion if you weren’t aware of it.

[RaginBajin]

ISY's sweet spot is the back end integration. I'm not sure that there's a strong business case for UDI to enter the crowded, highly competitive remote control solution market. A more direct path/suggestion is for vendors of the higher end systems to develop their own ISY "drivers" on UDI's open standards They could charge for it back through their channels to their buyers. They could keep control and could manage the integration within their sometimes strict NDA/contract structures.

 

Another view is that the touch screen remote control aspect is not always and end in itself for all HA users.  The ISY is an expert platform for creating fully automated, "hands off" solutions. Where needed, remote control is able to be handled by progressively improving smart speakers (echo/home), which are easy to integrate and inexpensive.

 

Paul

Paul, 

 

That was just an example of one of the things that I thought would level set it with something like a Control4.  I think I could go and list a lot of them, if we are looking to be specific, but that wasn't necessarily the point of the post. 

 

I think your recommendation is another good one that I'm wondering is even being considered.  I want to see the ISY succeed, so how does that happen?  

Have you looked into the Logitech Harmony integration with the ISY? It’s not a complete package however it might fill the gap your looking for at a reasonable price point and it’s more DIY. Then using ISY programs with MobiLinc or Agave might fill the gaps.

 

It’s not going to be a “pro” system but others here have done a lot. You could customize a KPL to control things too. Just a suggestion if you weren’t aware of it.

I haven't, but that's a great idea that I'm going to explore. I didn't think about it that way.   

 

That's a good idea about using the KPL to help control particular functions. 

[larryllix]

Have you looked into the Logitech Harmony integration with the ISY? It’s not a complete package however it might fill the gap your looking for at a reasonable price point and it’s more DIY. Then using ISY programs with MobiLinc or Agave might fill the gaps.

 

It’s not going to be a “pro” system but others here have done a lot. You could customize a KPL to control things too. Just a suggestion if you weren’t aware of it.

My six button KPL controls the local lights connected, as well as my security system as a combination keypad, resets my well pump lockout, my washing machine lockout, and my MS low battery list. I use keypad sequences for each function giving me over 256 functions.Longer sequences could be implemented, but reliability decreases and increases operator frustration.

 

Not ideal for some functions, but good for resetting problems with the reset codes included in the notifications.

[carealtor]

Have you looked into the Logitech Harmony integration with the ISY? It’s not a complete package however it might fill the gap your looking for at a reasonable price point and it’s more DIY. Then using ISY programs with MobiLinc or Agave might fill the gaps.

 

It’s not going to be a “pro” system but others here have done a lot. You could customize a KPL to control things too. Just a suggestion if you weren’t aware of it.

 

Are you referring to the "Polyglot Harmony Hub NodeServer"?  

[Scottmichaelj]

Are you referring to the "Polyglot Harmony Hub NodeServer"?

That’s one option. Another is direct IR control to the ISY (if you have the IR version) from the Harmony. If the ISY is in another location you can use something like the Global Cache devices in each room that then wirelessly can trigger commands too. Just look around the forum and you’ll find some examples of both. Also there’s the Insteon IR Transmitters too, then in conjunction with a button press can send a IR signal.

 

That’s the beauty of the ISY being so open and versatile, your not limited to just one option and as newer devices come out you can easily incorporate them.

[paulbates]

One other method is integration with Alexa. You can add the Alexa smarthome skill (things that you have defined in harmony already work well. "Alexa, turn on netflix")

 

Then, put ISY devices (lights) and Harmony devices in the same alexa smarthome group, turn that group on and off. Definitely not as seamless as the high end solutions; but simple things are functional and very easy to setup. Also there is the harmony app which can be configured and run on a smartphone or tablet for more fine grained control of TV.

 

Probably you can get back to the ISY from Alexa with IFTTT. I've never tried.

 

Paul

[Goose66]

Are you referring to the "Polyglot Harmony Hub NodeServer"?

That’s the wrong end. Node Servers provide ISY control of third party devices. What seems to be discussed here is RTi and Control 4 control interfaces of the ISY. This capability is enabled by ISY’s WSDK and REST interfaces.

[kck]

If you want to go the DIY route you are also welcome to look at the code I made available for my softconsole.  Turns an RPI with touchscreen into a very general screen interface to UDI.  I have console mounted and wall mounted version in my house.  Also, since the code is all on the web in Python it would be reasonable to add additional screen types to it as well as to generalize to support larger displays (currently it is optimized for 3.5 and 2.8" touchscreens but probably would work on a larger screen as is - just haven't tried it).  A few other folks here have installed it on their own systems so it is usable by a less than fully expert user (plus I try to support folks playing with it upon request).

[kck]

Another thought to the more general conversation here.  It does seem like UDI might want to make the ISY a more native player in some standard ecosystem like MQTT.  Ultimately, as others here have indirectly pointed out, any home is going to have a number of different subsystems doing various sorts of automation.  What is needed is a standard software protocol backbone that allows all those systems to play together as needed.  MQTT is one example of such - there are others.  The benefit of becoming a better player on such a backbone is that you don't need to know much about other automation subsystems nor they about you in order for a user (or installer) to integrate the overall home.  I could see the ISY being an MQTT client both publishing and subscribing to things in it, or even providing an MQTT broker function (though that might tax its storage capabilities given the age of the hardware design at this point). I do think this would be a pretty low cost path for UDI to take to get a lot of integration bang for their buck once they get v5 under control.

[G W]

I'd rather bypass the broker and use a websocket.

[mwester]

I'd rather bypass the broker and use a websocket.

 

A websocket is a communications channel for arbitrary streams of data.  MQTT, REST, Node Servers, etc, are all communications protocols that run ON TOP OF a communications channel.

 

I'm not aware of any MQTT implementations that run on top of a websocket, but there's no technical reason that can't be done.

 

The point is that websockets and what's being described here are at completely different layers in the protocol stack -- they're not incompatible or even in competition with one another.

[G W]

A websocket is a communications channel for arbitrary streams of data. MQTT, REST, Node Servers, etc, are all communications protocols that run ON TOP OF a communications channel.

 

I'm not aware of any MQTT implementations that run on top of a websocket, but there's no technical reason that can't be done.

 

The point is that websockets and what's being described here are at completely different layers in the protocol stack -- they're not incompatible or even in competition with one another.

There are several that use a websocket. Do a search on Google.

[mwester]

Here you go Gary:

 

https://en.wikipedia.org/wiki/MQTT

 

https://en.wikipedia.org/wiki/WebSocket

 

But if you have something specific that wanted Google to find that would justify your position that somehow WebSockets is similar to MQTT, then post your link...

 

(Edited, after re-reading the past several posts, and scratching my head to make any sense of it(!):  or, if your argument is that you don't care what the API or higher layers are as long as the lower layers use WebSockets, well, then perhaps you might add a few more words to your original post to make that clear!)

[G W]

 

 

Here you go Gary:

 

https://en.wikipedia.org/wiki/MQTT

 

https://en.wikipedia.org/wiki/WebSocket

 

But if you have something specific that wanted Google to find that would justify your position that somehow WebSockets is similar to MQTT, then post your link...

 

(Edited, after re-reading the past several posts, and scratching my head to make any sense of it(!): or, if your argument is that you don't care what the API or higher layers are as long as the lower layers use WebSockets, well, then perhaps you might add a few more words to your original post to make that clear!)

I never said they were similar. Where did you get that idea?

[RaginBajin]

Well, I think we are kinda talking apples and oranges about using MQTT or Websockets. 

 

My vote would be to move away from XML at the very least and into a much smaller and lightweight framework. The idea that I could open a single connection and pull messages or push messages on to a bus is the way most IT systems are looking to go.  Have your application to constantly open, handshake and then close connections constantly is heavy on both the client and server side. 

However it needs to be done to make it fast should be the goal. 

[G W]

Well, I think we are kinda talking apples and oranges about using MQTT or Websockets.

 

My vote would be to move away from XML at the very least and into a much smaller and lightweight framework. The idea that I could open a single connection and pull messages or push messages on to a bus is the way most IT systems are looking to go. Have your application to constantly open, handshake and then close connections constantly is heavy on both the client and server side.

However it needs to be done to make it fast should be the goal.

I agree. I would much rather use JSON. We can hope that once 5.X is official that UDI will look at adding the option to send and receive data in JSON.

 

To your second point, that's why I like a websocket. Having the ISY send events vua UDP would be even nicer but some might see that as a security concern.