First off, if this isn't the best place to post this please feel free to move it!

 

It seems like there is a lot going on with integration and new enhancements which is exciting but also frustrating! I am at a point where I am trying to determine the best path to take but I am having trouble finding clear descriptions of what features 5.0 and the isy portal bring to all of this.

 

Here are my questions, maybe someone here that is closer to evertything going on can help?

 

1. What exactly are the new features in 5.x and how do they compliment or compete with other options like echo integration using hue bridge and a "mapper"?

2. Does the isy portal add significant capability to the isy outside of not having to setup port forwarding (which I am doing today with mobilinc and it works fine)

3. I hear significant changes are coming to network module in 5.x, does most of the benefit come only if you also purchase the isy portal? Can I control my nest natively? Can I integrate with my echo natively?

 

Basically I am making some shifts in hardware and I am trying to figure out the right direction?

 

I have a nest which I have "sort of" integrated with my isy by using IFTTT, I am simulating away mode based on geofence so I basically have all the fancy features of the nest turned off so I can control with the ISY. This sort of defeats the purpose of the nest so I am thinking of swapping it out for an insteon thermostat(which I have two of and they work pretty good)

 

I just bought an echo which I have integrated using the hue bridge and a mapper but I have it running on a Windows 7 machine, again thinking about getting a pi to run this on but if this functionality is coming to the isy natively then maybe that would be the right path.

 

Just looking for some detailed product roadmap direction

 

Thanks in advance

Jim

First I know nothing about portal or nodes stuff.

 

V5 has brought variable substitution to Network resources.

 

What this means to me is that using Hue coloured bulbs I don't need 30 different colour resource statements to call.

   Set Hue.colour = $cCOLOUR.RED (value set in Integer page)

   Set Hue.Brightness = 70

   Set Hue.Saturation = 254

   Run Network resource 'Set Hue'

 

I can change the Hue.colour variable and use on Network resource call to do anything. Inside I have statements like "Bri":${var,1,156}, "Sat":${var,1,157} that get converted to text versions of the variable values.

 

This feature eliminates huge banks  of various colour, brightness, and saturation combinations which would have taken one Network resource for each combination.

 

That's one of the biggies of v5 for me.

Edited December 6, 20159 yr by larryllix

Hi 502ss,

 

I am so very sorry for the confusion.

 

Here's the background:

1. 5.0.x is dedicated to Variable enhancements (as larryllix posted above), Virtual Nodes, and Z-Wave Multi Channel. These are major surgeries in the code and, as you may have seen, it has taken a long time. Since a) 5.0x will be beta quality and we cannot just wait and see when 5.0.x becomes GA, we decided to continue to have a parallel path in 4.3+

2. 4.3+ is stable and pretty much GA quality. We added needed features and bug fixes (such as Font size, intermediate certificates, etc.) to both 4.3.x and 5.0.x (dual maintain). This way, we can have a stable release without 5.0x things while we work on 5.0x

3. ISY Portal is available on both and Echo should be available on both. In short, whatever is in 4.3+ will be available in the next code drop for 5.0x

 

If you have a mission critical application and you don't care about virtual nodes and variable enhancements, I suggest staying on the 4.3+ branch.

 

With kind regards,

Michel

First I know nothing about portal or nodes stuff.

 

V5 has brought variable substitution to Network resources.

 

What this means to me is that using Hue coloured bulbs I don't need 30 different colour resource statements to call.

   Set Hue.colour = $cCOLOUR.RED (value set in Integer page)

   Set Hue.Brightness = 70

   Set Hue.Saturation = 254

   Run Network resource 'Set Hue'

 

I can change the Hue.colour variable and use on Network resource call to do anything. Inside I have statements like "Bri":${var,1,156}, "Sat":${var,1,157} that get converted to text versions of the variable values.

 

This feature eliminates huge banks  of various colour, brightness, and saturation combinations which would have taken one Network resource for each combination.

 

That's one of the biggies of v5 for me.

Good info, so It sounds like I will be able to embed variables in network resources? This will be a nice feature!

Hi 502ss,I am so very sorry for the confusion.Here's the background:1. 5.0.x is dedicated to Variable enhancements (as larryllix posted above), Virtual Nodes, and Z-Wave Multi Channel. These are major surgeries in the code and, as you may have seen, it has taken a long time. Since a) 5.0x will be beta quality and we cannot just wait and see when 5.0.x becomes GA, we decided to continue to have a parallel path in 4.3+2. 4.3+ is stable and pretty much GA quality. We added needed features and bug fixes (such as Font size, intermediate certificates, etc.) to both 4.3.x and 5.0.x (dual maintain). This way, we can have a stable release without 5.0x things while we work on 5.0x3. ISY Portal is available on both and Echo should be available on both. In short, whatever is in 4.3+ will be available in the next code drop for 5.0xIf you have a mission critical application and you don't care about virtual nodes and variable enhancements, I suggest staying on the 4.3+ branch.With kind regards,Michel

Thanks for the information.

 

maybe you can help me answer these questions? I think answers to these will help point me in a specific direction.

 

1. What does the Alexa skill being developed by UDI get me that a hue bridge and a mapper doesn't? This will make the difference of whether I add a PI to my environment or use the skill for native integration.

 

2. With the changes in certificates will this allow me to talk directly to my nest via a network resource? I don't believe this is possible today because of some https issue or url redirect?

 

Thanks

Jim

Nest needs the client to support oAuth. ISY won't support that for quite a long time, if ever. The portal can, but UDI is prohibited from working with Nest without giving up a substantial income. Doubt that's ever going to happen, unless Google change their policies.

 

As far as Alexa, UDI is making two interfaces. Native 'Connected Home' and a skill (Izzy).

 

The first will be exactly like the Hue emulator (or a native Hue bridge). Same command set - and same limited vocabulary.

 

The skill will allow many more command types, but has a requirement to invoke the skill by name (Alexa, tell Izzy to...), with the advantage that you can have arbitrary commands after that, not limited by the connected home vocabulary.

 

Both will need an ISY Portal subscription.

 

The certificate changes (ability to add an intermediate certificate) will allow the IFTTT Maker channel to send triggers to ISY (as well as unchecked 'trust all certificates' in Tasker... - I can't wait for this!), and Alexa can trigger IFTTT (Alexa, send ....). So, you will be able to trigger ISY programs from Alexa using this method, without the portal (if you are comfortable having your ISY password configured at IFTTT). There may be a change in the future to allow the Maker channel to make ISY REST calls without needing the ISY password - by using a security token instead. Hopefully, this change comes quickly on the heals of the cert change.

Edited December 7, 20159 yr by MWareman

Nest needs the client to support oAuth. ISY won't support that for quite a long time, if ever. The portal can, but UDI is prohibited from working with Nest without giving up a substantial income. Doubt that's ever going to happen, unless Google change their policies.

As far as Alexa, UDI is making two interfaces. Native 'Connected Home' and a skill (Izzy).

The first will be exactly like the Hue emulator (or a native Hue bridge). Same command set - and same limited vocabulary.

The skill will allow many more command types, but has a requirement to invoke the skill by name (Alexa, tell Izzy to...), with the advantage that you can have arbitrary commands after that, not limited by the connected home vocabulary.

Both will need an ISY Portal subscription.

The certificate changes (ability to add an intermediate certificate) will allow the IFTTT Maker channel to send triggers to ISY (as well as unchecked 'trust all certificates' in Tasker... - I can't wait for this!), and Alexa can trigger IFTTT (Alexa, send ....). So, you will be able to trigger ISY programs from Alexa using this method, without the portal (if you are comfortable having your ISY password configured at IFTTT). There may be a change in the future to allow the Maker channel to make ISY REST calls without needing the ISY password - by using a security token instead. Hopefully, this change comes quickly on the heals of the cert change.

Thank you, thank you, thank you!!!

 

That's exactly what I was looking for!

 

So for me I think I am going to abandon the nest and go with another insteon thermostat! This will allow me to do more controls then I have today with the nest and avoid me dumbing down the nest to satisfy my need. I can also avoid a PI(at least for now) as part of my arsenal since it sounds like all the integration I will want with Alexa will be available soon enough with the isy and a portal subscription!

 

One last thing, is there a thread or any discussion of exactly how the isy skill will work and what options/flexibility it will have or is UDI keeping it a surprise until launch?

 

Oh and another last thing . Do you know if the skill will work with 4.3.x or will we need to upgrade to 5?

 

Thanks

Jim

I know the nest offers a compelling use case, but I also sold my Nest (came with the house from the builder as a promotion) and switched in a Trane zwave stat. Much happier! Nest is fantastic, unless you want to integrate it with third party systems....

 

UDI are not keeping the details of the Alexa integration secret - its just that the information is somewhat spread around the forum, and mixed in other threads. I'm just waiting for Amazon to approve the skill and connected home submission, then will be able to speak with first hand knowledge... Should be any day now, I hope!

 

Shouldn't need a 5.x upgrade - the integration point is the ISY Portal, and this works on the latest 4.3.x.

Hi,

I'm still very confused as to what the portal is meant to do and why I should possibly need it. I'm quite happy with doing my external access through port forwarding on my router and using VPN connections.

 

Why will the Alexa integration only work with the portal?

Hi,

I'm still very confused as to what the portal is meant to do and why I should possibly need it. I'm quite happy with doing my external access through port forwarding on my router and using VPN connections.

 

Why will the Alexa integration only work with the portal?

Native integration? Yes. It's been said this will require the portal. This is part of Amazons requirements and, I believe, a deciding element for UDI to develop the portal at all. More services will likely come - native IFTTT for example.

 

You can also do Alexa integration via the Maker channel, if you want to hack it yourself.

 

You can also use one of several 'Hue' emulators to link to Alexa without the portal.

I'm still very confused as to what the portal is meant to do and why I should possibly need it. I'm quite happy with doing my external access through port forwarding on my router and using VPN connections.

Same here. Port forwarding seems to be no problem, so still can't figure out this portal business. Haven't spent much time on it, admittedly, but much of HA seems to operate in this space of few clear explanations, and much chatter between members. Confusing for those of us with much interest but little time to follow along.

I believe the portal also solves the problem of your WAN IP address changing.  The communications through the portal is not dependent on your WAN IP address.

 

Although both port forwarding and changing IP address can be addressed in other ways, they are not very easy for most people.

I believe the portal also solves the problem of your WAN IP address changing.  The communications through the portal is not dependent on your WAN IP address.

 

Although both port forwarding and changing IP address can be addressed in other ways, they are not very easy for most people.

Are these really two of the big selling points? A service like dyndns.org (for a little money each year) solves the changing ip issue (pretty easily also) and port forwarding is also pretty straight forward! I would think if you have an ISY and you are leveraging home automation you could configure port forwarding?

 

Maybe not?

Are these really two of the big selling points? A service like dyndns.org (for a little money each year) solves the changing ip issue (pretty easily also) and port forwarding is also pretty straight forward! I would think if you have an ISY and you are leveraging home automation you could configure port forwarding?

 

Maybe not?

 

It's never been clear to me how much of ISY business is from "integrators", who build systems for others to use.  That's where the ease of the portal pays off, but I'm not sure if that is a real business case for UDI.

 

Someone elsewhere also mentioned the portal being more secure than port forwarding, with the claim that you don't need to have your ISY credentials out there ... but I assume the portal also requires credentials, so I don't understand this point.

Remember all, the features in the portal are still under development, and (to my knowledge) more functionality is forthcoming.

 

The value proposition is only going to go up.

 

In addition to what was just mentioned, the speed of establishing an SSL connection from clients like Mobilinc and Tasked is orders of magnitude faster that establishing an SSL connection directly to the ISY, due to the computational expense of new connections. Portal has a hardware crypto accelerator I believe to make this really fly.

 

Portal supports more than one credential, and you can turn off a credential if you want without breaking others. Direct ISY access only has one account - and that account is fully administrative. So, use a portal credential in you Mobilinc and lose your phone: just disable that credential. Lose your phone with direct Mobilinc, change your ISY password then spend hours fixing up all the places you used it.

 

There is an even easier token based authentication on its way as well - for better, secure authentication to ISY Portal from services like the Maker IFTTT channel.

 

Plus we can feel good continuing to support UDI, who are working hard to bring us all this goodness...

Good info on the credentials, I wasn't aware of that feature.

 

I'll probably purchase portal just for the speed of connection.  Mobilinc is painfully slow for me when used remotely.

 

Plus we can feel good continuing to support UDI, who are working hard to bring us all this goodness...

 

Shhh ... don't tell UDI, but this is probably the real reason I'll purchase the portal.    I've "donated' more money to other companies that have done a lot less for me.

Hi KMan,

 

Thanks SO very much!
 

With kind regards,

Michel

Still don't see how going via some cloud based gateway can ever be faster than the direct connection. I control my system via the admin console and mobilinc and both respond almost instantaneously. I even run 12 cameras over the mobilinc at the same time with no issues.

 

I really haven't seen anyone come up with a real benefit of the portal where it adds real value. Credential management is a non issue as usernames and passwords are easy to change if necessary. Dynamic DNS solves any issues with having to use an IP address. Where I need secure connections I just use VPN and so I don't need to bother running everything with HTTPS.

 

What I don't understand is why Alexa needs to run via the portal. Can someone explain?

What I don't understand is why Alexa needs to run via the portal. Can someone explain?

 

My understanding is the portal allows ISY to connect to cloud based services (among other things.)  UDI's Echo App will require that connection because this is a "certified" app through Amazon.

You could use the Hue Emulator and avoid the portal but I believe the official app will offer greater functionality and better integration with ISY.

 

 

Jon...

Still don't see how going via some cloud based gateway can ever be faster than the direct connection. I control my system via the admin console and mobilinc and both respond almost instantaneously. I even run 12 cameras over the mobilinc at the same time with no issues.

 

I really haven't seen anyone come up with a real benefit of the portal where it adds real value. Credential management is a non issue as usernames and passwords are easy to change if necessary. Dynamic DNS solves any issues with having to use an IP address. Where I need secure connections I just use VPN and so I don't need to bother running everything with HTTPS.

 

What I don't understand is why Alexa needs to run via the portal. Can someone explain?

Not everyone has the skills or the patience/time to setup ddns/port forwarding/SSL certificates/VPN.

 

Clearly, your using HTTP within a VPN. That's why you don't see the SSL performance penalty.

 

I for one don't want to use a VPN. Many others don't. A proxy (such as the portal, or my personal Apache based proxy) with a SSL accelerator chip will be orders of magnitude faster than SSL termination directly on ISY, especially with 2048+ bit certificates. I get instant response using my SSL accelerated proxy, and 5-6 second response using SSL directly to ISY.

 

Alexa needs the portal because Amazon requires the service Alexa is connecting to to be a cloud service. It cannot connect to thousands of individual devices - they must have a single API for accessing all devices. That what the portal provides, and is why its required.

Edited December 9, 20159 yr by MWareman

...Alexa needs the portal because Amazon requires the service Alexa is connecting to to be a cloud service. It cannot connect to thousands of individual devices - they must have a single API for accessing all devices. That what the portal provides, and is why its required.

 

Why does the ISY require a cloud service when the Insteon Hub, Wemo, and Hue do not? Why would Amazon require Universal Devices to do things differently from the others?

Edited December 23, 20159 yr by madmartian

The Hub does require a cloud service to create scenes. Manually created scenes are not recognized by the Hub. I don't know about Wemo and Hue. Amazon is not requiring anything from UDI that they don't require from any device using the Echo. It's the Echo that requires a cloud service, even for the Insteon Hub (i.e., Connected Home).

The Hub does require a cloud service to create scenes. Manually created scenes are not recognized by the Hub. I don't know about Wemo and Hue. Amazon is not requiring anything from UDI that they don't require from any device using the Echo. It's the Echo that requires a cloud service, even for the Insteon Hub (i.e., Connected Home).

 

Well that's disappointing. My current setup is a Hub for devices and a Wemo emulator with ISY for scenes and a couple older modules that the Hub doesn't support. I guess that's what I'll stick with going forward. Odd  that an emulator would do something that the hardware it's emulating won't allow me to do.

 

 

Why does the ISY require a cloud service when the Insteon Hub, Wemo, and Hue do not? Why would Amazon require Universal Devices to do things differently from the others?

Don't know about the others, but the Hub uses an online proxy that Amazon connects to. Everyone Hub connects, and Amazon only has to connect to Smarthome proxy.

 

This is how the ISY works with the Portal.

First I know nothing about portal or nodes stuff.

 

V5 has brought variable substitution to Network resources.

 

What this means to me is that using Hue coloured bulbs I don't need 30 different colour resource statements to call.

Set Hue.colour = $cCOLOUR.RED (value set in Integer page)

Set Hue.Brightness = 70

Set Hue.Saturation = 254

Run Network resource 'Set Hue'

 

I can change the Hue.colour variable and use on Network resource call to do anything. Inside I have statements like "Bri":${var,1,156}, "Sat":${var,1,157} that get converted to text versions of the variable values.

 

This feature eliminates huge banks of various colour, brightness, and saturation combinations which would have taken one Network resource for each combination.

 

That's one of the biggies of v5 for me.

Larry - based on this post are you now saying it would be possible for me to link a KPL button (or switch) to a program that would call a network resource to turn on the HUE bulbs to a direct color of my choice?

 

The reason I returned the HUE strips were because they always turned on at the 2700k value, then I would have had to go into the app adjust to the pure white color range I wanted which was not reasonable each time I turned them on. However if I can turn them always on at 5000k/6000k (or a color like red blue etc) each time via the network command I may change back to this and get them again.

 

Can you please confirm?