REST commands to ISY via Portal?

[apostolakisl]

I'd like to send a REST command to the ISY through the portal.  I have two ISY's at different locations and they send some info back and forth.  Currently using my self-signed certificate to do this.  But now that I have portal, I would like to close the port forwarding and go through the portal.  The only way I see to do this is via IFTTT (though I'm not even positive on that since I haven't actually tried it), but that just adds a whole other step and confusion.  I can turn the GeoFence nodes on/off via a URL that the portal generates.  I would very much like URL's that can control other nodes/variables/programs/etc.

Edited August 18, 2018 by apostolakisl

[bmercier]

It's easier than that.

Use Select tools | ISY Information, look at the "URL to ISY".

Just use this URL, and add regular rest commands to this URL.

You need to pass your ISY Portal Credential.

Benoit

[apostolakisl]

50 minutes ago, bmercier said:

It's easier than that.

Use Select tools | ISY Information, look at the "URL to ISY".

Just use this URL, and add regular rest commands to this URL.

You need to pass your ISY Portal Credential.

Benoit'

So on an ISY network resource from one ISY to another that currently works,  I copy and paste the "URL to ISY" into the "Host" section, and leave all else the same?  Including the "authorization"?

Is this in the wiki?  I didn't see it, but that doesn't mean it isn't there.

[bmercier]

2 minutes ago, apostolakisl said:

So on an ISY network resource from one ISY to another that currently works,  I copy and paste the "URL to ISY" into the "Host" section, and leave all else the same?  Including the "authorization"?

Is this in the wiki?  I didn't see it, but that doesn't mean it isn't there.

You have to:

Set the host to my.isy.io

Set the protocol to HTTPS (if not already set to HTTPS)

Change the URL to include the ISY Key (What you see in the URL to ISY after the host name).

The authorization will be different. When going through ISY Portal, you have to use an ISY Portal user and password, not your regular ISY credentials)

Not sure this is in the Wiki.

Benoit

[TJF1960]

Sorry to horn in but I have been trying to do this as well. The issue I see is the port number. From firefox I can set a variable using the portal url with no port number but in the ISY network resources I do not see how to send without specifying a port number.

[apostolakisl]

16 minutes ago, bmercier said:

You have to:

Set the host to my.isy.io

Set the protocol to HTTPS (if not already set to HTTPS)

Change the URL to include the ISY Key (What you see in the URL to ISY after the host name).

The authorization will be different. When going through ISY Portal, you have to use an ISY Portal user and password, not your regular ISY credentials)

Not sure this is in the Wiki.

Benoit

Not working.  I started with my working network resource and copied it.

I was already using https, so no change.

Changed host to:

my.iso.io 

Added to the path all the info preceding the /rest . . .:

/isy/lotsofrandomlettersandnumbers/rest/vars/set/2/1/${mod.weather.temp.current}

Changed authorization to:

logon username for portal (my email)

logon password for portal

 

And it gives me an error, tcp client read response fail

Edited August 18, 2018 by apostolakisl

[bmercier]

4 minutes ago, TJF1960 said:

Sorry to horn in but I have been trying to do this as well. The issue I see is the port number. From firefox I can set a variable using the portal url with no port number but in the ISY network resources I do not see how to send without specifying a port number.

In the ISY network resource, if you choose https, you don't have to supply a port number. It's implicitly 443.

[apostolakisl]

Just now, bmercier said:

In the ISY network resource, if you choose https, you don't have to supply a port number. It's implicitly 443.

I left my port as 443, which is what I was already using for https

[bmercier]

2 minutes ago, apostolakisl said:

Not working.  I started with my working network resource and copied it.

I was already using https, so no change.

Changed host to:

my.iso.io 

Added to the path all the info preceding the /rest . . .:

/isy/lotsofrandomlettersandnumbers/rest/vars/set/2/1/${mod.weather.temp.current}

Changed authorization to:

logon username for portal (my email)

logon password for portal

 

And it gives me an error, no response.

The host name is my.isy.io

Other than that, it seems to be correct.

I would suggest to try it first from a browser to help troubleshooting.

Benoit

[apostolakisl]

1 minute ago, bmercier said:

The host name is my.isy.io

Other than that, it seems to be correct.

I would suggest to try it first from a browser to help troubleshooting.

Benoit

That was a typo (in the forum only).  It is set to my.isy.io

Edited August 18, 2018 by apostolakisl

[TJF1960]

No wonder it didn't work. I had changed the ISY port number years ago and just assumed it would still be the same. Thanks, it is working perfectly now.

[bmercier]

@apostolakisl, to facilitate troubleshooting, I would suggest the following;

Go to ISY Portal, choose the ISY Access. Open up the developer console with F12.

Whenever you do something, you can see the URL used in the network tab (If using Chrome). Those are calls to your ISY through ISY Portal. You can cut & paste the URL and try it in a browser directly, then adapt it to the network resource.

Benoit

[apostolakisl]

5 minutes ago, bmercier said:

@apostolakisl, to facilitate troubleshooting, I would suggest the following;

Go to ISY Portal, choose the ISY Access. Open up the developer console with F12.

Whenever you do something, you can see the URL used in the network tab (If using Chrome). Those are calls to your ISY through ISY Portal. You can cut & paste the URL and try it in a browser directly, then adapt it to the network resource.

Benoit

Sorry, not sure exactly what you mean by the above.

This is what the ISY network resource lists in the "actual" box.  Again, this all works using my port forwarding directly to ISY.

GET /isy/randomlettersandnumberscutandpastedfromportal/rest/vars/set/2/1/${mod.weather.temp.current} HTTP/1.1
Host: my.isy.io:443
User-Agent: Mozilla/4.0
Connection: Close
Content-Type: application/x-www-form-urlencoded
Authorization: Basic thenumbers/lettersgeneratedbyencoderusingmyportalusername/password

Note:I do use a special character in my password, if that matters.

 

Below is what actually works using port forwarding

 

GET /rest/vars/set/2/1/${mod.weather.temp.current} HTTP/1.1
Host: myurl.no-ip.biz:443
User-Agent: Mozilla/4.0
Connection: Close
Content-Type: application/x-www-form-urlencoded
Authorization: Basic thenumbers/lettersgeneratedbyencodeusingmyregularuser/password
 

[bmercier]

4 minutes ago, apostolakisl said:

Sorry, not sure exactly what you mean by the above.

This is what the ISY network resource lists in the "actual" box.  Again, this all works using my port forwarding directly to ISY.

GET /isy/randomlettersandnumberscutandpastedfromportal/rest/vars/set/2/1/${mod.weather.temp.current} HTTP/1.1
Host: my.isy.io:443
User-Agent: Mozilla/4.0
Connection: Close
Content-Type: application/x-www-form-urlencoded
Authorization: Basic thenumbers/lettersgeneratedbyencoderusingmyportalusername/password

Note:I do use a special character in my password, if that matters.

 

Below is what actually works using port forwarding

 

GET /rest/vars/set/2/1/${mod.weather.temp.current} HTTP/1.1
Host: myurl.no-ip.biz:443
User-Agent: Mozilla/4.0
Connection: Close
Content-Type: application/x-www-form-urlencoded
Authorization: Basic thenumbers/lettersgeneratedbyencodeusingmyregularuser/password
 

I understand you expect me to find the problem, but I don't see anything wrong here.

Please try if from a browser first.

[bmercier]

@Michel Kohanim , could there be an issue with the path length?

Benoit

[apostolakisl]

10 minutes ago, bmercier said:

I understand you expect me to find the problem, but I don't see anything wrong here.

Please try if from a browser first.

It works from a browser.  I did not include the authentication in the url, I entered it into when requested afterwards.

[bmercier]

1 minute ago, apostolakisl said:

It works from a browser.  I did not include the authentication in the url, I entered it into when requested afterwards.

I'm suspecting an issue with the path length.

I would try the network resource, but use a fixed value instead of a variable.

[apostolakisl]

4 minutes ago, bmercier said:

I'm suspecting an issue with the path length.

I would try the network resource, but use a fixed value instead of a variable.

Yes, putting the number "1" works (in place of the variable).

[bmercier]

Just now, apostolakisl said:

Yes, putting the number "1" works (in place of the variable).

Ok, so it's either an issue with variable substition (probably not), or the path length.

Either way, we need help from Michel.

Benoit

[apostolakisl]

1 hour ago, bmercier said:

Ok, so it's either an issue with variable substition (probably not), or the path length.

Either way, we need help from Michel.

Benoit

See, you did figure it out.  ?

[Michel Kohanim]

All,

Path length is 128. What's the timeout?

With kind regards,
Michel

[apostolakisl]

3 hours ago, Michel Kohanim said:

All,

Path length is 128. What's the timeout?

With kind regards,
Michel

10 seconds.

I count 115 characters in just the "path" section when counting all the characters needed to put in ${mod.weather.temp.current} variable.  So maybe the 128 includes some other characters that aren't actually listed in "path"?

It works just fine when I put in a plain number or a much shorter variable name.  I tried ${var.1.1} which worked just fine.  So I don't think time out is involved here.

 

EDIT:  I did a workaround.  I have a network resource that writes the weather module temp to a local variable (just using my lan ip, not the super long portal path), then I use that variable to send to the other ISY.  Unless someone knows of a better way to convert the weather module temp/humidity to regular variables I'm having to use a network resource to loop the value back into the isy.

Edited August 19, 2018 by apostolakisl

[MWareman]

Not working.  I started with my working network resource and copied it.
I was already using https, so no change.
Changed host to:
my.isy.io 
Added to the path all the info preceding the /rest . . .:
/isy/lotsofrandomlettersandnumbers/rest/vars/set/2/1/${mod.weather.temp.current}
Changed authorization to:
logon username for portal (my email)
logon password for portal
 
And it gives me an error, tcp client read response fail

The issue is that ${mod.weather.temp.current} gets converted to something like “86 F”.

Two issues.

First, you can only set variables to a numeric value. The ‘ F’ (or ‘ C’) will break this.

Second, the space needs to be encoded. Encoding on ISY happens at time of saving, not at time of sending.

Some values allow the use of adding .raw (as in ${mod.weather.temp.current.raw} - but it appears this does not work for values from the weather module.

In short - you will need to use a script running somewhere else to do the conversion.

[apostolakisl]

4 minutes ago, MWareman said:

 

The issue is that ${mod.weather.temp.current} gets converted to something like “86 F”.

Two issues.

First, you can only set variables to a numeric value. The ‘ F’ (or ‘ C’) will break this.

Second, the space needs to be encoded. Encoding on ISY happens at time of saving, not at time of sending.

Some values allow the use of adding .raw (as in ${mod.weather.temp.current.raw} - but it appears this does not work for values from the weather module.

In short - you will need to use a script running somewhere else to do the conversion.

 

No, it just sends a number.  It works fine when not using the super long security key in the pathway that portal requires.  I have been using it for more than a year when just going https direct using my self-signed cert.  Now I got around the problem by network resourcing from my isy back to my isy and storing it as a regular variable which I can then send using portal since a regular variable has a much shorter name.

Edited August 19, 2018 by apostolakisl

[MWareman]

No, it just sends a number.  It works fine when not using the super long security key in the pathway that portal requires.

Not on my ISY... It sends the F or C as well....