Introducing ISYPortal

[Michel Kohanim]

CLOSED!

 

Hello everyone,

With 4.3.6, we are now ready to do full beta testing for our ISYPortal which allows seamless remote access without port forwarding in the router. We need 100 volunteers. If you are interested, please:
1. Send an email with subject ISYPortal Beta
2. Include your UUID in the body
3. Makes sure the email address is the one that will be used to access ISY

Highlights:
1. Account = billing account
2. Many ISYs per account - ideal for integrators and dealers
3. Many users per ISY each with different username/password combination
4. Subscriptions so that you can use Admin Console
5. Developers are welcome
6. Requires 4.3.6


Please note that this service will eventually be a paid service but beta testers will get it for free for 1 year.

Thanks so very much!

With kind regards,
Michel

[Xathros]

Hello everyone,

 

With 4.3.6, we are now ready to do full beta testing for our ISYPortal which allows seamless remote access without port forwarding in the router. We need 100 volunteers. If you are interested, please:

1. Send an email with subject ISYPortal Beta

2. Include your UUID in the body

3. Makes sure the email address is the one that will be used to access ISY

 

Highlights:

1. Account = billing account

2. Many ISYs per account - ideal for integrators and dealers

3. Many users per ISY each with different username/password combination

4. Subscriptions so that you can use Admin Console

5. Developers are welcome

6. Requires 4.3.6

 

 

Please note that this service will eventually be a paid service but beta testers will get it for free for 1 year.

 

Thanks so very much!

 

With kind regards,

Michel

Hi Michel-

 

Is it possible to access the admin console on my ISY from the portal?  I don't see it listed in the available tools there.

 

-Xathros

[Michel Kohanim]

Hi Xathros,

 

Yes, of course. Please go to the portal and in the drop down next to ISY choose ISY Information. You will see Admin Console URL listed there. Just copy/paste that into ISY Finder. The only difference is that you need to use your Portal's credentials to log into your ISY.

 

With kind regards,

Michel

[Xathros]

Hi Xathros,

 

Yes, of course. Please go to the portal and in the drop down next to ISY choose ISY Information. You will see Admin Console URL listed there. Just copy/paste that into ISY Finder. The only difference is that you need to use your Portal's credentials to log into your ISY.

 

With kind regards,

Michel

Awesome!  Thanks.

 

-Xathros

[paulbates]

Hi Michel

I'm trying to compare my requirements to the portals capabilities. A couple of questions:

• I access a single ISY remotely. I use port forwarding now, and looking changing that to using my routers VPN server capability, so that I can access other things on my network. I always use a well known, trusted system from the internet to do this. It doesn't sound like the portal does much for these requirements?
• Does the portal provide any V5 capability in terms of exposing nodes outside of the lan environment, any additional capabilities there?

Thanks

Paul

[Michel Kohanim]

Hi Paul,

 

The portal is basically a proxy to your ISY. So, whatever your ISY APIs are available locally they are also available through the portal. So, 5.0 features should be available (using the Admin Console through the portal).

 

With kind regards,

Michel

[Xathros]

Hi Paul,

 

The portal is basically a proxy to your ISY. So, whatever your ISY APIs are available locally they are also available through the portal. So, 5.0 features should be available (using the Admin Console through the portal).

 

With kind regards,

Michel

Does this mean I could address a /Rest command to my ISY's portal URL and have my ISY react?  Could this be done from the network module on one ISY to set a variable or control a device on a 2nd ISY using the 2nd ISY's portal URL?  If so, what would the authentication header need to look like in the network resource for that?

 

-Xathros

[Michel Kohanim]

Hi Xathros

 

Yes to all. Authentication header is the username and password for your ISY in the portal.

 

With kind regards,

Michel

[paulbates]

Hi Michel / Xathros

 

I would love a sample/example line to follow if that's possible.

 

Paul

[Xathros]

Hi Michel / Xathros

 

I would love a sample/example line to follow if that's possible.

 

Paul

Hi Paul-

 

I'm going to test this this morning when I get to the office.  I will post my test set up and results.

 

-Xathros

[Xathros]

Hi Xathros

 

Yes to all. Authentication header is the username and password for your ISY in the portal.

 

With kind regards,

Michel

Excellent!  I will try this out today!

 

Thanks.

 

-Xathros

[Xathros]

This works like a champ!

 

Here is what I have done:

 

Created 5 network resource rules on my home ISY. They are: Office KPL-G On, Office KPL-G Off, Office KPL-H On, Office KPL-H Off and Office KPL Beep.

 

Office KPL is on my Test ISY at my office.  The resource rules use the portal URL and portal credentials for my office ISY.

 

Here are two of these resources for reference:

 

On the Home ISY I created  2 programs to watch the status of my garage door sensors and call these resources with any change of state.  Here is one:

Dad-Update Office KPL - [ID 029A][Parent 0011]

If
        'Garage / Garage Door IOLinks / GD- Dad Garage Door Sensor' Status is On
 
Then
        Resource 'OFFICE - KPL Beep'
        Wait  2 seconds
        Resource 'OFFICE - KPL-H On'
 
Else
        Resource 'OFFICE - KPL Beep'
        Wait  2 seconds
        Resource 'OFFICE - KPL-H Off'

Now, whenever a garage door opens or closes, the corresponding KPL button changes at the office and the KPL beeps to get my attention.

 

Notes: 

• The secondary KPL buttons need to be in scenes since they cannot be directly controlled.
• If copying the portal URL from the "ISY Information" menu item in the portal, remove the /desc from the URL before adding the /rest... portion in your path box.
• The host should only contain my.isy.io  Place the isy/<your isy uuid> portion in the beginning of the path preceding the  /rest... portion.
• I had to bump the timeout up to 2500ms to avoid receiving a "TCP Client Read Response Failed" message.
• There is about a 1,500ms delay between running the resource and the reaction at the destination ISY.  This seems reasonable considering encryption overhead and round trip time from VT->CA->VT.

 

-Xathros

[Xathros]

Hi Michel-

 

Not sure if this is a portal bug or intentional but I discovered that I can access https://my.isy.io/isy/<my_uuid>/desc without any prior authentication and receive a significant XML response that reveals my ISY's name and some other data.  This seems like a bit of a security risk.  Removing the /desc from the URL does prompt for authorization.

 

Thoughts or comments?

 

Thanks.

 

-Xathros

[Michel Kohanim]

Hi Xathros,

 

Thank you.

 

The /desc is not protected in ISY and there is no sensitive information in it. i.e the is the same as the portal URL for your ISY and this URL is only used for ISY Finder. This said, I do not like anything being out in the open. I am going to talk to Benoit and see how we can make this protected.

 

With kind regards,

Michel

[Scyto]

Will you be likely to have second phase of betas?  I was AWOL earlier in the year.

[Michel Kohanim]

Hi Scyto,

 

Perhaps for specific features.

 

With kind regards,

Michel

[Xathros]

Hello Michel-

 

I noticed once again that the portal URLs have changed for both of my ISY's.  I had to remove the finder entries and recreate them using the new URLs.  In addition, I had to update the network resources that use the portal URLs to control the other ISY.  After update they are now erroring again with HTTP 423 (Locked).  Last time this was because I needed to unencode the portal URL before using it in the network resource.  This time I'm working with the un-encoded URL and still can't seem to get past the 423s.

 

I thought the portal URLs were going to remain static? 

 

I will continue to poke at the resources to see if I can't find my problem.

 

-Xathros

 

EDIT:  Solved the 423s again.  Two issues here.  First when I replaced the portal URL with the unencoded portal IURL, I forgot to unencode the device addresses.  Then I checked Encode URL which double encoded thed device address portion.  Second problem is that my unencoded URL contains 2 "/" characters that the ISY will not encode since it seems to think that they denote a path delimiter.  Had to go back to using the pre-encoded URL and manually encoding the device addresses. Not sure if this can be solved.  Only way I see would be to prevent the "/" character from being used in a portal URL token.

[Michel Kohanim]

Hi Xathros,

 

Thanks so very much for the update. I am concerned that your portal URL changed on its own. Let us check into it and get back to you.

 

With kind regards,

Michel

[Xathros]

Thanks Michel.

 

-Xathros

[bmercier]

Hello Michel-

 

I noticed once again that the portal URLs have changed for both of my ISY's.  I had to remove the finder entries and recreate them using the new URLs.  In addition, I had to update the network resources that use the portal URLs to control the other ISY.  After update they are now erroring again with HTTP 423 (Locked).  Last time this was because I needed to unencode the portal URL before using it in the network resource.  This time I'm working with the un-encoded URL and still can't seem to get past the 423s.

 

I thought the portal URLs were going to remain static? 

 

I will continue to poke at the resources to see if I can't find my problem.

 

-Xathros

 

EDIT:  Solved the 423s again.  Two issues here.  First when I replaced the portal URL with the unencoded portal IURL, I forgot to unencode the device addresses.  Then I checked Encode URL which double encoded thed device address portion.  Second problem is that my unencoded URL contains 2 "/" characters that the ISY will not encode since it seems to think that they denote a path delimiter.  Had to go back to using the pre-encoded URL and manually encoding the device addresses. Not sure if this can be solved.  Only way I see would be to prevent the "/" character from being used in a portal URL token.

 

Hello Xathros,

 

The portal URL for an ISY should not have changed. 

 

FYI, the current logic is that when an ISY connects to portal, portal will take the UUID and use HMAC encryption to generate a hash, and then updates a table if it has changed. The hash is what you see in the ISY URL. Technically it should never change if the UUID is identical and the encryption key has not changed. And I confirm it has not. So long story short, I don't know why it would have changed.

 

In an attempt to fix this, I just made a change where the hash is created/updated for a given ISY only if it is empty. So, the hash will be created when the ISY first contacts portal. This will be in production tomorrow.

 

Thanks,

 

Benoit.

[Xathros]

Thanks Benoit. The URL for both of my ISYs changed sometime in the last 2 weeks. This was the second time I noticed since the URL changed from the uuids. I will be happy if it stays static from here on out. Any thoughts about preventing the "/" in the hash string?

 

 

-Xathros

 

Sent from my iPhone using Tapatalk

[bmercier]

Thanks Benoit. The URL for both of my ISYs changed sometime in the last 2 weeks. This was the second time I noticed since the URL changed from the uuids. I will be happy if it stays static from here on out. Any thoughts about preventing the "/" in the hash string?

 

 

-Xathros

 

Sent from my iPhone using Tapatalk

 

Yes and No.

 

The issue is that the hash is in a base64 representation, and the / is a perfectly valid character. So this is why the admin console URL also url encodes it.

 

The alternative I could see is that I could use an hex representation of the hash instead. That would become a longer URL, but at least, it would be valid without the requirement to be url encoded.

 

Or, we could come back to a base url which is url encoded (The first part of the admin console URL).

 

Benoit.

[Xathros]

The problem is that the admin console doesn't encode the / but treats it as a path delimeter.

 

 

-Xathros

 

Sent from my iPhone using Tapatalk

[bmercier]

The problem is that the admin console doesn't encode the / but treats it as a path delimeter.

 

 

-Xathros

 

Sent from my iPhone using Tapatalk

 

Do you mean the admin console URL show in the ISY information tool is not valid sometimes?

 

Benoit

[Xathros]

If using the unencoded url from the isy information tool in a network resource then instructing the isy to encode the url, the / chars are not encoded by the isy as it treats them as path delimeters rather than part of the token. My workaround is to use the already encoded isy url minus the /desc and then manually encode the device address and leave encode url unchecked.

 

 

-Xathros

 

Sent from my iPhone using Tapatalk