CAO Tags - Custom URL Calling - another method for ISY Rest injection

[MWareman]

round() is a JavaScript function. That's why it works in a Kumoapp (it's JavaScript).

 

Although math works in in URL calling, I doubt very much that JavaScript functions do...

[larryllix]

round() is a JavaScript function. That's why it works in a Kumoapp (it's JavaScript).

 

Although math works in in URL calling, I doubt very much that JavaScript functions do...

I haven't heard what anybody gets into their ISY variables from the URL calling method yet.

What happens to the decimals when ISY doesn't support them?

 

I thought maybe CAO might support the round() function to accommodate other system precisions.

[Bumbershoot]

I haven't heard what anybody gets into their ISY variables from the URL calling method yet.

What happens to the decimals when ISY doesn't support them?

 

I thought maybe CAO might support the round() function to accommodate other system precisions.

I seem to recall that I got nothing in the variable for voltages until increased the precision to 3 (this is from a Kumoapp).  There is a rule for crossing a threshold of battery voltage on the URL calling page, so I'll fuss with it a little to see if I can get a variable populated with some decimals...

 

Interestingly, the wirelesstag web page shows battery voltages with a precision of 2 (2.96), while it populates the ISY variable with a precision of 3 (2.959), so the values on the web page are rounded.

 

Edit:  This will take a while to get any results (days, weeks... I dunno) as the low voltage threshold for triggering the rule in URL calling has a precision of 1.  It will be called on one of my tags when the voltage reaches 3.0, and it currently stands at 3.010.  I don't know how long this will take, but I'll report here when I see the variable get a value (provided I can remember...).

[larryllix]

I seem to recall that I got nothing in the variable for voltages until increased the precision to 3 (this is from a Kumoapp).  There is a rule for crossing a threshold of battery voltage on the URL calling page, so I'll fuss with it a little to see if I can get a variable populated with some decimals...

 

Interestingly, the wirelesstag web page shows battery voltages with a precision of 2 (2.96), while it populates the ISY variable with a precision of 3 (2.959), so the values on the web page are rounded.

I rewrote the (mwareman) kumoapp script precision to stuff three decimal places into ISY.

Scott only wanted two decimal places for v4, so we left it multiplied by 100 and then rounded off before sending with no decimals.

 

His V4 logic has to work like this:

If

...$sTag.voltage <= 270 (=2.70Vdc)

[Scottmichaelj]

I rewrote the (mwareman) kumoapp script precision to stuff three decimal places into ISY.

Scott only wanted two decimal places for v4, so we left it multiplied by 100 and then rounded off before sending with no decimals.

 

His V4 logic has to work like this:

If

...$sTag.voltage <= 270 (=2.70Vdc)

 

Larry is correct. I am on v4.5.4 and my variables numbers are not decimals. Not a big deal for me. The battery shows up as 3 digits which is easy to know 267 = 2.67volts - the temp is just 2 digits and fine with me.

 

Here is my Kumo app math, which also changes the temp to "Fahrenheit" rather then "Celsius"

 

var tag_temp = Math.round((tag.temperature *1.8 +32));

KumoApp.Log("Temp for "+cur_name+" ("+isy_variable_temp+") updated to "+tag_temp);

KumoApp.httpCall(isy_RESTcall+isy_variable_temp+"/"+tag_temp, "GET");

 

var tag_moisture = Math.round(tag.moisture);

KumoApp.Log("Humidity for "+cur_name+" ("+isy_variable_humi+") updated to "+tag_moisture);

KumoApp.httpCall(isy_RESTcall+isy_variable_humi+"/"+tag_moisture, "GET");

 

var tag_battV = Math.round(tag.batteryVolt * 100);

KumoApp.Log("BatteryV for "+cur_name+" ("+isy_variable_battV+") updated to "+tag_battV);

KumoApp.httpCall(isy_RESTcall+isy_variable_battV+"/"+tag_battV, "GET");

[LFMc]

There's a second method for inserting CAO Wireles Tag properties into variables on your ISY called "Custom URL Calling".  This is a useful option if your Tag Manager and ISY are on the same network, and if the conditions that would update your variables are available in the "URL Calling" dialogue page.  Additionally, it may be easier than creating a kumoapp, as the syntax is a simple URL.

 

The following URL will update the INTEGER variable 8 with the third value available to the URL (humidity/moisture in this case).  See screenshots.

http://username:password@YOUR.ISY.IP.ADDRESS/rest/vars/set/1/8/{3}

To adjust the syntax to update a STATE variable:

http://username:password@YOUR.ISY.IP.ADDRESS/rest/vars/set/2/8/{3}

 

Guys, I am pulling out my few remaining hairs over URL calling to plug a temperature into an ISY state variable (#3). I have read this thread and several others about URL calling and cannot even get the URL input into the Tag app without getting the exact same error over and over.  To give some info, I have  about 8 tags and they have been working great for about a year or more.  I can make rest calls to input and retrieve variables from my ISY and do so all the time (from a browser). So I understand the format. 

 

I am using the "URL call" format exactly as Bumbershoot shows it above in the Tag App on the device I want to retrieve the temperature from. I have input the URL multiple different ways and get the same error every time.  "The URL ........  cannot be parsed" .   Attached is a screen capture of the error and the URL. This occurs when I press the "save" button. Yes, my ISY is on port 80 and I am local to it. I have tried with and without the port number. with and without the Name:password, etc. 

 

Any help figuring this out would be appreciated.

 

--Leon

 

 

[larryllix]

The tag handler may not support that method security credentials any longer. That method has been dropped by most major browsers as an illegal or improperly formatted URL.

 

Kumoapps work very well for this and update on every data value change and are set up to be able to be modified by  medium-low level techie installers.

I am not sure the URL calling ever worked to send data to ISY, other than the threshold crossings. It's been a while since this conversation, but I don't remember any conclusive demonstration of results.

[Bumbershoot]

 

Guys, I am pulling out my few remaining hairs over URL calling to plug a temperature into an ISY state variable (#3). I have read this thread and several others about URL calling and cannot even get the URL input into the Tag app without getting the exact same error over and over.  To give some info, I have  about 8 tags and they have been working great for about a year or more.  I can make rest calls to input and retrieve variables from my ISY and do so all the time (from a browser). So I understand the format. 

 

I am using the "URL call" format exactly as Bumbershoot shows it above in the Tag App on the device I want to retrieve the temperature from. I have input the URL multiple different ways and get the same error every time.  "The URL ........  cannot be parsed" .   Attached is a screen capture of the error and the URL. This occurs when I press the "save" button. Yes, my ISY is on port 80 and I am local to it. I have tried with and without the port number. with and without the Name:password, etc. 

 

Any help figuring this out would be appreciated.

 

--Leon

 

Capture.JPG

This is working here, locally to my ISY.  The screenshot should provide the details/syntax for a STATE variable. The HTTP verb is "GET".

 

When I put the URL into a browser (Chrome), I get this response:

 

<RestResponse succeeded="false">

<status>404</status>

</RestResponse>

 

I doubt you need to set a port number if this is local to your network and you haven't changed your ports on the ISY.  Make sure to check the box if you're on a private, non-routable network: "This URL uses private IP address (Call from Tag Manager)" 

[LFMc]

 

This is working here, locally to my ISY.  The screenshot should provide the details/syntax for a STATE variable. The HTTP verb is "GET".

 

When I put the URL into a browser (Chrome), I get this response:

 

<RestResponse succeeded="false">

<status>404</status>

</RestResponse>

 

I doubt you need to set a port number if this is local to your network and you haven't changed your ports on the ISY.  Make sure to check the box if you're on a private, non-routable network: "This URL uses private IP address (Call from Tag Manager)" 

 

 

Yes the verb is "GET". Yes, the private IP is checked (and tried unchecked).  Yes, my URL format is identical to yours. 

 

New piece of information, when I remove the the "#" sign from my ISY password, it works. Figure that out!  But now that is going to force me to change the password on the ISY and my other commands that are automatically authenticating to it. if I want to use the URL calling feature.  :-/ 

 

So apparently there are some extended ASCII characters that the app doesn't want in the url.  Can any one verify that using KumoApps using # in the password will not have the same effect? 

 

Is ISY V5 going to allow you to have multiple login credentials by any chance??

[Bumbershoot]

Yes the verb is "GET". Yes, the private IP is checked (and tried unchecked).  Yes, my URL format is identical to yours. 

 

New piece of information, when I remove the the "#" sign from my ISY password, it works. Figure that out!  But now that is going to force me to change the password on the ISY and my other commands that are automatically authenticating to it. if I want to use the URL calling feature.  :-/ 

 

So apparently there are some extended ASCII characters that the app doesn't want in the url.  Can any one verify that using KumoApps using # in the password will not have the same effect? 

 

Is ISY V5 going to allow you to have multiple login credentials by any chance??

Have you tried replacing "#" with "%23" in the URL (no quotes)?  It might work with the current password.

[LFMc]

Have you tried replacing "#" with "%23" in the URL (no quotes)?  It might work with the current password.

Thanks, that worked. But still no change in the ISY variables.  I can change the variable from a browser command line with no issues. I guess there is no way to see any troubleshooting info for a URL CALL is there?  I have the tag updating once a minute and there is a change in the temperature value. 

 

I tried a stock KumoApp also, no errors in the Kumo Logs and no results. See attached.

[Teken]

 

Is ISY V5 going to allow you to have multiple login credentials by any chance??

 

Hello Leon,

 

I've seen multi-login in the 5.XX branch. I haven't actually tried to create a second user though to confirm it works!

[Bumbershoot]

Thanks, that worked. But still no change in the ISY variables.  I can change the variable from a browser command line with no issues. I guess there is no way to see any troubleshooting info for a URL CALL is there?  I have the tag updating once a minute and there is a change in the temperature value. 

 

I tried a stock KumoApp also, no errors in the Kumo Logs and no results. See attached.

 

 

Just guessing here, as I don't log temperature values, so I'm not sure what temperature data the tags try to export.  If the tag tries to append a Fahrenheit of Celsius symbol to the temperature value, then the values will fail as USY variables only support numeric data.  If you're running ISY firmware 5.0.x, then your variables might need to have the precision set to something other than 0.

 

 

Also, you might check that your syntax is correct for the proper type of ISY variable.

 

To adjust the syntax to update an INTEGER variable:

http://username:password@YOUR.ISY.IP.ADDRESS/rest/vars/set/1/8/{3}

To adjust the syntax to update a STATE variable:

http://username:password@YOUR.ISY.IP.ADDRESS/rest/vars/set/2/8/{3}

 

My variables are updating, but I'm only using moisture/humidity and voltage, both of which are numeric data.

 

Alas, I haven't found any error logs for the URL Calling method.

[MWareman]

Make sure the {3} (or whatever) substitution is a simple number ONLY. No decoration like C or F or % etc etc. ISY cannot accept a string at all - only a simple integer number.

[LFMc]

 

Just guessing here, as I don't log temperature values, so I'm not sure what temperature data the tags try to export.  If the tag tries to append a Fahrenheit of Celsius symbol to the temperature value, then the values will fail as USY variables only support numeric data.  If you're running ISY firmware 5.0.x, then your variables might need to have the precision set to something other than 0.

 

 

Also, you might check that your syntax is correct for the proper type of ISY variable.

 

To adjust the syntax to update an INTEGER variable:

http://username:password@YOUR.ISY.IP.ADDRESS/rest/vars/set/1/8/{3}

To adjust the syntax to update a STATE variable:

http://username:password@YOUR.ISY.IP.ADDRESS/rest/vars/set/2/8/{3}

 

My variables are updating, but I'm only using moisture/humidity and voltage, both of which are numeric data.

 

Alas, I haven't found any error logs for the URL Calling method.

 

 

 

Make sure the {3} (or whatever) substitution is a simple number ONLY. No decoration like C or F or % etc etc. ISY cannot accept a string at all - only a simple integer number.

Thanks, but as stated and shown in my prior post's attachments, I am using exactly the format you mention above. I am not running 5.x. and the "{2}" for temperature is as shown also. 

 

I think this stems back to the password containing a # sign. I replaced it with the %23, but I don't think it is getting me into the ISY.  Is there a log in the ISY that sees failed attempts to login by URL's? Maybe that would show me a failed attempt to login or not. I checked the event viewer and logs but couldn't find anything to tell me if the Wireless Tags were trying to login or not. But I could see that my other URL calls from scripts I have written are in the Event Viewer when they fire. 

[larryllix]

Thanks, but as stated and shown in my prior post's attachments, I am using exactly the format you mention above. I am not running 5.x. and the "{2}" for temperature is as shown also.

 

I think this stems back to the password containing a # sign. I replaced it with the %23, but I don't think it is getting me into the ISY. Is there a log in the ISY that sees failed attempts to login by URL's? Maybe that would show me a failed attempt to login or not. I checked the event viewer and logs but couldn't find anything to tell me if the Wireless Tags were trying to login or not. But I could see that my other URL calls from scripts I have written are in the Event Viewer when they fire.

You may want to look up the URL definitions on wikipedia. I think # (octathorpe) may be a reserved character.

 

Sent from my SGH-I257M using Tapatalk

[LFMc]

You may want to look up the URL definitions on wikipedia. I think # (octathorpe) may be a reserved character.

 

Sent from my SGH-I257M using Tapatalk

Thanks!  Great feed back.  I was so used to my password working via Curl without any issues. 

[MWareman]

Yep # has a specific meaning in a URL. Curl takes the username and password and creates an 'Authorization' header, so a # would work there. Move the password to the URL line and it will not work due to the special meaning # has in URLs.