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

[Bumbershoot]

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}

[GlowingHair]

You might want to block userID/password on fourth image.

[Bumbershoot]

You might want to block userID/password on fourth image.

Good catch, and thanks!  The image is modified.

[MWareman]

Interesting.... username:password@ never used to work at all. Can anyone else confirm that CAO have updated the tag manager code to allow this now?

[larryllix]

Interesting.... username:password@ never used to work at all. Can anyone else confirm that CAO have updated the tag manager code to allow this now?

It works in kumoapps (your code proves it) but I thought the trend was to get away from it for security purposes. Most browsers won't allow it anymore.

 

It would be odd CAO would install it but maybe for simplicity of implementation??

[MWareman]

Maybe..  I just looked again at URL calling - and the issue id they have combines temp and humidity updates into a single rule. And you cannot add more than one instance of a rule. So, when you add temperature updates, you cannot add humidity. Etc.

 

So, even if they have added the authentication support to URL calling, I'm (personally) going to stick with the KumoApp method..

 

Michael.

[Bumbershoot]

The KumoApp method is certainly more versatile.  I wasn't terribly impressed with the performance of the kumoapp host server(s) last week, so I'm running the two methods in parallel to see if there's any difference in reliability.  I'm only looking for humidity/moisture updates at this point, so I can easily manage with URL calling.

 

If I can discern any reliability difference, I'll post what I find.

[larryllix]

The KumoApp method is certainly more versatile.  I wasn't terribly impressed with the performance of the kumoapp host server(s) last week, so I'm running the two methods in parallel to see if there's any difference in reliability.  I'm only looking for humidity/moisture updates at this point, so I can easily manage with URL calling.

 

If I can discern any reliability difference, I'll post what I find.

Great!

 

I would be particularly interested if the notifications actually update on parameter changes or just on trigger point crossings.

[Bumbershoot]

Great!

 

I would be particularly interested if the notifications actually update on parameter changes or just on trigger point crossings.

I'm not sure what you mean by notifications, but the variables (I'm using INTEGER variables for URL calling, and STATE variables for the kumoapp) seem to be updated by each process identically and simultaneously whenever the values change.  No difference so far.  I'll write a little program to notify me if the variables from the same device differ, so I'll know.

[larryllix]

I'm not sure what you mean by notifications, but the variables (I'm using INTEGER variables for URL calling, and STATE variables for the kumoapp) seem to be updated by each process identically and simultaneously whenever the values change.  No difference so far.  I'll write a little program to notify me if the variables from the same device differ, so I'll know.

Nice!

 

I always got the impression the URL calling only notified anybody when the parameter crossed the limits set. Then there would be no analogue value updates between the set limits, or over/under the limits.

[MWareman]

Nice!

 

I always got the impression the URL calling only notified anybody when the parameter crossed the limits set. Then there would be no analogue value updates between the set limits, or over/under the limits.

You certainly can use a rule that has thresholds and reports only when the threshold is crossed.

 

There is also a rule that fires on any update, and provides the temp and humidity as parameters that can be substituted.

[larryllix]

You certainly can use a rule that has thresholds and reports only when the threshold is crossed.

 

There is also a rule that fires on any update, and provides the temp and humidity as parameters that can be substituted.

I only see one rule that could possibly do this. (At the very top. This seems new)

 

• When tag sends a temperature/humidity/brightness update - {0}: Tag name, {1}: Tag ID, {2}: temperature in °C, {3}: humidity/moisture (%), {4}: brightness (lux)

I am not sure what the Tag ID is or where to find it, as opposed to the "Tag Name" but we should be able to write a formula to access REST variables in ISY, provided the variables are structured in an exact and orderly manner. eg. Tag ID+58.

 

I only see one parameter being transmittable for all Tags, using this technique, since there is only one rule. I don't see a way to assign a numeric substitution value (field number) to each parameter, in order to get temp, humidity, and brightness into different ISY variables.

 

Did you have some other idea for this?

[Bumbershoot]

• When tag sends a temperature/humidity/brightness update - {0}: Tag name, {1}: Tag ID, {2}: temperature in °C, {3}: humidity/moisture (%), {4}: brightness (lux)

I am not sure what the Tag ID is or where to find it, as opposed to the "Tag Name" but we should be able to write a formula to access REST variables in ISY, provided the variables are structured in an exact and orderly manner. eg. Tag ID+58.

 

 

I'm using this rule to update variables for humidity/moisture. 

 

For fun, I substituted the Tag ID {1} for humidity/moisture {3} in two of my tags, updated them, then looked at the respective variables.  The variables changed to the values 1 and 6, with 0 precision (INTEGER variables).  I don't know what that's useful for, but there you have it.

[larryllix]

I'm using this rule to update variables for humidity/moisture. 

 

For fun, I substituted the Tag ID {1} for humidity/moisture {3} in two of my tags, updated them, then looked at the respective variables.  The variables changed to the values 1 and 6, with 0 precision (INTEGER variables).  I don't know what that's useful for, but there you have it.

Thanks Bumbershoot.

 

I figured that one would work but the problem is to get more than one parameter from more than one Tag.

 

Simple arithmetic could be done with the Tag ID number to arrive at different variable numbers to match ISY's variable number locations. I don;t see a parameter number, though, to send different variables into different ISY variable locations.

 

Unfortunately this appears that only one parameter from any number of Tags can be sent to ISY variables, with only one Tag rule available.

[MarkJames]

So I've got my tag manager in and my tags talking but for some reason the replacement variables arent' getting passed.  

 

If I put this into the URL calling field 

When tag sends a temperature/humidity/brightness update - {0}: Tag name, {1}: Tag ID, {2}: temperature in °C, {3}: humidity/moisture (%), {4}: brightness (lux)

Call URL:http://user:pass@192.168.0.171/rest/vars/set/2/1/3   More HTTP settings 
 This URL uses private IP address (Call from Tag Manager)

 

 

 

Then state variable 1 gets set to a value of 3 when the tag updates - as expected.

 

But if I put this into the URL calling field instead

 

http://user:pass@192.168.0.171/rest/vars/set/2/1/{3}   or {4} or {2}

 

Then the state variable gets assigned a value of 0.  Is this a float to integer problem?

 

Thanks,

 

mark

[larryllix]

So I've got my tag manager in and my tags talking but for some reason the replacement variables arent' getting passed.  

 

If I put this into the URL calling field 

When tag sends a temperature/humidity/brightness update - {0}: Tag name, {1}: Tag ID, {2}: temperature in °C, {3}: humidity/moisture (%), {4}: brightness (lux)

Call URL:http://user:pass@192.168.0.171/rest/vars/set/2/1/3   More HTTP settings  This URL uses private IP address (Call from Tag Manager)

 

 

 

Then state variable 1 gets set to a value of 3 when the tag updates - as expected.

 

But if I put this into the URL calling field instead

 

http://user:pass@192.168.0.171/rest/vars/set/2/1/{3}   or {4} or {2}

 

Then the state variable gets assigned a value of 0.  Is this a float to integer problem?

 

Thanks,

 

mark

Strange. Your URL shows what looks proper in the post but the URL shows some coding when I view the underlying text with a smart cursor view. (android)

[MarkJames]

Strange. Your URL shows what looks proper in the post but the URL shows some coding when I view the underlying text with a smart cursor view. (android)

 

That's probably the browser encoding the  curly braces....

[MarkJames]

I only see one rule that could possibly do this. (At the very top. This seems new)

 

• When tag sends a temperature/humidity/brightness update - {0}: Tag name, {1}: Tag ID, {2}: temperature in °C, {3}: humidity/moisture (%), {4}: brightness (lux)

I am not sure what the Tag ID is or where to find it, as opposed to the "Tag Name" but we should be able to write a formula to access REST variables in ISY, provided the variables are structured in an exact and orderly manner. eg. Tag ID+58.

 

I only see one parameter being transmittable for all Tags, using this technique, since there is only one rule. I don't see a way to assign a numeric substitution value (field number) to each parameter, in order to get temp, humidity, and brightness into different ISY variables.

 

Did you have some other idea for this?

 

I haven't tried it but I don't see why you couldn't use the math functionality in the tag manager to send all the values from the tag.

 

<% {3}*1000000 + {4}*1000 + {5} %>  Just multiply the first tag by 1000000, the second tag by 1000 and then add 3 tags together.  That's assuming you even need 3 digits for each one.

 

 A bit of math on the ISY end should be all it takes to parse these values back into 3 variables.  

 

 

mark

[larryllix]

I haven't tried it but I don't see why you couldn't use the math functionality in the tag manager to send all the values from the tag.

 

<% {3}*1000000 + {4}*1000 + {5} %>  Just multiply the first tag by 1000000, the second tag by 1000 and then add 3 tags together.  That's assuming you even need 3 digits for each one.

 

 A bit of math on the ISY end should be all it takes to parse these values back into 3 variables.  

mark

Nice!

 

I use that concept in my kumoapp code for the XYZ axis transport.

 

I do some compaction inside my ISY also for date and times, MM.DD and hh.mm. It's works well for programs to make wild card year filters.

 

If they offered a field number variable, some simple arithmetic could send all the fields from multiple tags in one URL call formula. You may have a solution until they implement multiple (array?) event triggered URL rules.

 

I think Kumoapps are easier. Especially once you get into decimal transmission with v5.+

[MarkJames]

I think Kumoapps are easier. Especially once you get into decimal transmission with v5.+

 

I'm just sitting here trying to figure out the kumoapps thing.

 

I've been unsuccessful in getting a lux reading sent to either state or integer variables through the rest interface with custom calling.  I think it's because lux is a float but I haven't checked - I guess I could just multiply it by a thousand and see what it sends....

 

More crap to learn with kumoapps.  Sheesh.  Between java, some python, the ISY, Homeseer with vb.net, and now this I'm starting to question my sanity.

 

mark

[Scottmichaelj]

I question my sanity everyday

[larryllix]

I question my sanity everyday

So do I when it comes to HA.

 

I was trying to back up my system but I just can't get the beeper to work.

[MarkJames]

I was trying to back up my system but I just can't get the beeper to work.  

 

Just get someone to stand behind you to control network traffic  

[Bumbershoot]

I'm not sure what you mean by notifications, but the variables (I'm using INTEGER variables for URL calling, and STATE variables for the kumoapp) seem to be updated by each process identically and simultaneously whenever the values change.  No difference so far.  I'll write a little program to notify me if the variables from the same device differ, so I'll know.

Update on the reliability of URL calling vs. Kumoapp variable updating: I wrote a simple program that triggers off a change in a STATE variable updated by a Kumoapp, comparing that value to an INTEGER variable updated by the URL calling of the same tag for the same condition (humidity, in this case). 

 

The result is that I noticed occasional wobbling and discrepancies between the STATE and INTEGER values, but this could easily be the result the way that my programs were written and the use of INTEGER variables instead of all STATE variables.  These incidents are infrequent, and have all disappeared within a half hour of when they began.  I'm satisfied that there are no gross dependencies between the two methods.

 

In order to achieve a more precise answer to the question, I've created a second set of STATE variables that the URL calling process will update, and I'll compare the two variables for the same device whenever one of the STATE variables change.  I'm delaying the comparison for three seconds to account for any latency differences between the two methods (I hope that's adequate).

 

So far, I feel comfortable saying that there are no gross differences in the methods, but I'll report again here if my new test turns up anything interesting.

[Bumbershoot]

 

In order to achieve a more precise answer to the question, I've created a second set of STATE variables that the URL calling process will update, and I'll compare the two variables for the same device whenever one of the STATE variables change.  I'm delaying the comparison for three seconds to account for any latency differences between the two methods (I hope that's adequate).

 

 

FWIW - it turns out that three seconds isn't quite enough time to account for the network latency introduced when using the Kumoapp.  I've had a handful of updates already where the Kumoapp takes from 1 to 4 seconds longer to update the variable than the URL calling method.  I have no idea if there is a TTL value set in these packets (there has to be, right?), but I'll keep watching to see if times venture outside of that range.