Jump to content

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

Bumbershoot

By Bumbershoot
in Wireless Sensors

Recommended Posts

MarkJames Advanced

MarkJames

Posted
Posted

I haven't found a HA solution for motion detection that works as well as a purpose built one.

 

I bought my tag manager and sensors with two purposes in mind - one that works - light detection - and the other that 'works' (in quotes).

 

I have a corridor to my bedroom.  At the bedroom end is a motion detector for the security system.  I use it to turn the light on in the corridor via my Elk.  It responds very fast BUT the motion detector doesn't 'see' me till I'm already in the corridor.  At the other ends are 3 stairs up which I can't see when it's dark.  I got the tag PIR to trip the light from that end. 

 

Problem is you're moving when you come around the corner to the corridor.  The PIR sees you but the latency is such that by the time the light turns on you're already struggling with the stairs.  I have to either walk slower or stand and wait.  

 

It's tough being too lazy to turn on a switch :wink:

 

mark

Scottmichaelj Advanced

Scottmichaelj

Posted
Posted

It's tough being too lazy to turn on a switch :wink:

Can't imagine how they did it in the "old days"! Life must have been hard pushing a three way switch up hill both ways in the snow. LOL  :-P  :shock:

MarkJames Advanced

MarkJames

Posted
Posted

Can't imagine how they did it in the "old days"! Life must have been hard pushing a three way switch up hill both ways in the snow. LOL  :-P  :shock:

 

What are we?  Animals?  

larryllix Advanced

larryllix

Posted
Posted

 

It's tough being too lazy to turn on a switch :wink:

 

mark

My dad was a part time electrician.

He would always tell me "Boy! Go out to the shed and get me a switch!"

Bumbershoot Advanced

Bumbershoot

Posted
  • Author
Posted

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.

Okay, one more trip down this path:

 

For 4 out of the 5 moisture sensors that I have deployed, there have been only small differences in the variable update times between the URL calling and the Kumoapp methods, mostly simultaneously or within 1 - 2 seconds.  I have one, however, that seems erratic and the variable values get catawampus once or twice a day, for over the 10 second period that causes my programs to run which sends me a notification.  This particular device also shows relatively wide swings in soil moisture content when I would expect there to be very little variation  -- no rain, irrigation, heat, wind, high evapotranspiration or other factors being present.  This device is also the most distant from the tag manager (-96dBm signal strength, about 150 feet).  This device may be defective, but I suspect that if I disassociate, reassociate and recalibrate it, it will behave like the others.  I'll continue to watch it.

 

All in all, I don't see much difference between the URL Calling and Kumoapp methods for reliability.  An interesting point: I'm reporting for two values in the Kumoapp, humidity and voltage.  When either value is updated, it seems the sensor sends the entire data payload through to the Kumoapp, so the variable timestamps in the ISY that the Kumoapp updates show identical update times, even though only one variable might be actually updated.  This makes me think the sensor fires off a complete data package anytime it reports in the tag manager.

 

I wouldn't try to run a railroad with these things, but for a consumer device on public spectrum, they seem adequate where some inherent latency isn't an issue.  So pick your favorite update method...

 

Below is just for reference (please keep in mind, this ain't real science).

 

Kumoapp:

var tags = <#tags_[32]_N#>;
var isy_ip=<%ISY IP Address%>;
var isy_user = <%ISY username%>;
var isy_password=<%ISY password%>;
var isy_RESTcall = "http://"+isy_user+":"+isy_password+"@"+isy_ip+"/rest/vars/set/2/"

tags.forEach(
function (tag) {
    tag.updated = function () {
        var cur_name = tag.name
        var valid_device = true
        switch(cur_name) {
            case "HerbPlanter":
                var isy_variable_humi = 27
                var isy_variable_battV = 28
                break;
            case "EastPlanter":
                var isy_variable_humi = 13
                var isy_variable_battV = 29
                break;
            case "FrontMaple":
                var isy_variable_humi = 14
                var isy_variable_battV = 30
                break;
            case "EntryPine":
                var isy_variable_humi = 25
                var isy_variable_battV = 31
                break;
            case "FrontPlanter":
                var isy_variable_humi = 26
                var isy_variable_battV = 32
                break;
            default:
                var valid_device = false
        }
        if(valid_device==true){

            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 * 1000)/1000;
            KumoApp.Log("BatteryV for "+cur_name+" ("+isy_variable_battV+") updated to "+tag_battV);
            KumoApp.httpCall(isy_RESTcall+isy_variable_battV+"/"+tag_battV, "GET");
            
        } else {
            KumoApp.Log("Data from non-configured device: "+cur_name);
        }
    };
}
);

ISY apps (all variables are STATE variables except for i.Humidity which is INTEGER):

Planter Humidity - SetVar - [ID 007A][Parent 000F]

If
        $s.EastPlanterHumidity is not $s.EastPlanterHumidity2
     Or $s.EntryPineHumidity is not $s.EntryPineHumidity2
     Or $s.FrontMapleHumidity is not $s.FrontMapleHumidity2
     Or $s.FrontPlanterHumidity is not $s.FrontPlanterHumidity2
     Or $s.HerbPlanterHumidity is not $s.HerbPlanterHumidity2
 
Then
        $i.Humidity += 1
        Wait  10 seconds
        Run Program 'Planter Humidity - Notify' (If)
 
Else
        $i.Humidity  = 0


Planter Humidity - Notify - [ID 0079][Parent 000F]

If
        $i.Humidity > 0
    And (
             $s.EastPlanterHumidity is not $s.EastPlanterHumidity2
          Or $s.EntryPineHumidity is not $s.EntryPineHumidity2
          Or $s.FrontMapleHumidity is not $s.FrontMapleHumidity2
          Or $s.FrontPlanterHumidity is not $s.FrontPlanterHumidity2
          Or $s.HerbPlanterHumidity is not $s.HerbPlanterHumidity2
        )
 
Then
        Send Notification to 'Bumbershoot' content 'Humidity Variables out of Sync'
        $i.Humidity  = 0
 
Else
   - No Actions - (To add one, press 'Action')

Notification body:

 

EastPlanter: URL variable 54 - Kumoapp variable 54

FrontPlanter: URL variable 65 - Kumoapp variable 65

FrontMaple: URL variable 57 - Kumoapp variable 66

EntryPine: URL variable 51 - Kumoapp variable 51

HerbPlanter: URL variable 45 - Kumoapp variable 45

  • 2 weeks later...
roblombardo Member

roblombardo

Posted
Posted

I am having zero luck getting this working by either method. I've copied the URL calls with my data, nothing. I then tried the Kumo apps method, nothing. Its probably something simple, so frustrated. Any suggestions?

MarkJames Advanced

MarkJames

Posted
Posted

I am having zero luck getting this working by either method. I've copied the URL calls with my data, nothing. I then tried the Kumo apps method, nothing. Its probably something simple, so frustrated. Any suggestions?

 

I wrote a stripped down version of a kumoapp that just does battery.  I haven't tested it but it should work. 

 

Don't forget to start the app running.  And if you edit an app you have to stop it, edit it, remove the old version,  and start the new version.  It's a bit of a weird setup but there you go.

 

Depending on your tag type you may have to edit the var tags line to include your tag type.  Those types are listed on the kumoapps page - but here they are too.  Find yours and add it to the tag list separated by a | character.  As it is it will work for 26 (wireless tag pro) and 72 (pir).  So if you wanted to add the water/moisture(32) you would change the 26|72 to 26|72|32

 

    Motion/Temperature (12)

Motion/Temperature/RH (13)
Wireless Tag Pro (21)
Wireless Tag Pro ALS (26)
Water/Moisture (32)
Reed/RH (52)
Thermostats (62)
PIR (72)
WeMo switches (82)
Dropcam (92)

 

[edit] sorry - I had this open in two windows and overwrote my changes.  I'll try to put it back

 

You need to edit 

 

isy_RESTcall to have your username, password, url and port.  

This assumes you're using state variables (that's what the vars/set/2 means).  Change the 2 to 1 for integer variables

You'll need to change the YOURSTATEVARIABLEID to whatever your isy variable ID is

you'll have to change YOURTAGNAME to whatever your tag name is

 

This *should* put your batt level in the specified state variable and write an entry to the kumo app log.

 

Lemme know if you try it and how it works for you

 

mark

 

var tags = <#tags_[26|72]_N#>;
 
tags.forEach(
function (tag) {
    tag.updated = function () {
   var cur_name = tag.name
   var valid_device = true
 
   var isy_variable_battV = 0
 
 
   switch(cur_name) {
        case "YOURTAGNAME":
                     var isy_variable_battV = YOURSTATEVARIABLEID               
                     break;
        default:
                     var valid_device = false
     }
   if(valid_device==true) {
           var tag_battV = Math.round(tag.batteryVolt * 1000)/1000;
           KumoApp.Log("BatteryV for "+cur_name+" ("+isy_variable_battV+") updated to "+tag_battV);
          if (isy_variable_battV>0 ){
         KumoApp.httpCall(isy_RESTcall+isy_variable_battV+"&value="+tag_battV, "GET");
}
} else {
KumoApp.Log("Data from non-configured device: "+cur_name);
}
    };
}
);
roblombardo Member

roblombardo

Posted
Posted

Thanks for the response MJ. I think the code is good, It's Bumbershoots for temperature. The Kumo log says it sent fine. I'm using a reed switch (52) with remote temp probe. Your response is the first I've seen about including the port. I added :8040 which is my http port # to the URL call with no success. I'm not sure how to include the port in my Kumo app code though?

larryllix Advanced

larryllix

Posted
Posted

This thread was suposed to be for URL calling, not kumoapps. Not a bog deal but you may find more info on the other kumoapp thread.

 

The port is the port your Admin Console connects to your ISY with. If one is not specified, port 80 is assumed and usual.

 

Variables have to be set up inside your ISY with proper decimal precision, before you can stuff data into them or bad things may happen.

 

If your log is recording things then triggers are happenning and data is being sent somewhere.

 

If you do not have ISY v5.++ then the decimal variable injection is not going to to work and some code modification will be needed. Remove all the "/1000" "/10" etc..

 

Each time you edit a kumoapp script and run it the previous one needs to be stopped and aborted.

 

Tag style numbers must be included properly in the first line or those tags will not be serviced.

MarkJames Advanced

MarkJames

Posted
Posted

If you want to check if it's working you can simply hardcode a rest call that changes a variable to a specific value.  That might be your best bet next just to make sure you're writing when you think you're writing.

 

I included a port in my example because I use a FQDN to access my ISY and need the port for forwarding.  I wasn't sure how you used yours.  If you're within your LAN and using 80 on your ISY then you can leave it out.

 

I've not used decimal variables so can't speak to that.  

 

mark

Bumbershoot Advanced

Bumbershoot

Posted
  • Author
Posted

I am having zero luck getting this working by either method. I've copied the URL calls with my data, nothing. I then tried the Kumo apps method, nothing. Its probably something simple, so frustrated. Any suggestions?

If you have the appropriate variable already established in you ISY, then the URL calling method is fairly straightforward.  This code would put a temperature value into STATE variable 39 (using the default port 80 on the ISY).

http://User:Password@192.168.xxx.xxx/rest/vars/set/2/39/{2}

Putting a temperature value into an INTEGER variable 20 would look like this:

http://User:Password@192.168.xxx.xxx/rest/vars/set/1/20/{2}

Edit: This assumes that the Tag Manager is on the same local network as your ISY, which is why the checkbox "This URL uses private IP address (Call from Tag Manager)" is checked. 

 

I'm not sure how the syntax for a non-standard http port would look, but here's a guess:

http://User:Password@192.168.xxx.xxx:8040/rest/vars/set/1/20/{2}

post-7363-0-14854000-1493728919_thumb.png

roblombardo Member

roblombardo

Posted
Posted

This thread was suposed to be for URL calling, not kumoapps. Not a bog deal but you may find more info on the other kumoapp thread.

 

The port is the port your Admin Console connects to your ISY with. If one is not specified, port 80 is assumed and usual.

 

Variables have to be set up inside your ISY with proper decimal precision, before you can stuff data into them or bad things may happen.

 

If your log is recording things then triggers are happenning and data is being sent somewhere.

 

If you do not have ISY v5.++ then the decimal variable injection is not going to to work and some code modification will be needed. Remove all the "/1000" "/10" etc..

 

Each time you edit a kumoapp script and run it the previous one needs to be stopped and aborted.

 

Tag style numbers must be included properly in the first line or those tags will not be serviced.

My intention is to use URL calling. I'm only exploring Kumo apps as a troubleshooting step to this end.

 

 

If you have the appropriate variable already established in you ISY, then the URL calling method is fairly straightforward.  This code would put a temperature value into STATE variable 39 (using the default port 80 on the ISY).

http://User:Password@192.168.xxx.xxx/rest/vars/set/2/39/{2}

Putting a temperature value into an INTEGER variable 20 would look like this:

http://User:Password@192.168.xxx.xxx/rest/vars/set/1/20/{2}

Edit: This assumes that the Tag Manager is on the same local network as your ISY, which is why the checkbox "This URL uses private IP address (Call from Tag Manager)" is checked. 

 

I'm not sure how the syntax for a non-standard http port would look, but here's a guess:

http://User:Password@192.168.xxx.xxx:8040/rest/vars/set/1/20/{2}

I am using these exactly. I believe I have tried it with the port specified as above as well. I don't believe that should be required on LAN. I am on 4.5.x though, I wonder if it is a decimal issue. Maybe some math to remove the decimal can be integrated into the URL call (*10)? But, the Kumo app code above multiplies  the Fahrenheit conversion by 10 to remove the decimal, and that doesn't work either.

larryllix Advanced

larryllix

Posted
Posted

My intention is to use URL calling. I'm only exploring Kumo apps as a troubleshooting step to this end.

 

 

I am using these exactly. I believe I have tried it with the port specified as above as well. I don't believe that should be required on LAN. I am on 4.5.x though, I wonder if it is a decimal issue. Maybe some math to remove the decimal can be integrated into the URL call (*10)? But, the Kumo app code above multiplies  the Fahrenheit conversion by 10 to remove the decimal, and that doesn't work either.

Not sure if the round() function will work in the URL calling. I don't believe there is any Foreignheat used for the Tags. It's all C.

Tim Wilson New

Tim Wilson

Posted
Posted

I don't have any of these tags yet, but I'm interested. It looks like using the URL calling works on the LAN, and the KumoApp approach would require exposing my ISY to the Internet in order to receive the REST requests. Is that correct? If so, it would be nice to have this integrated through the ISY Portal instead of opening up a hole in my firewall.

roblombardo Member

roblombardo

Posted
Posted

Well, I'm totally lost on this one. I've added math to multiply by 10 in the URL call, no dice. I've added the port taken the port away. I've made the call from the LAN and from the WAN no dice. Just completely at wits end. Oh well, makes the wireless tags much less compelling if they can't update the why the ISY.

Bumbershoot Advanced

Bumbershoot

Posted
  • Author
Posted

Well, I'm totally lost on this one. I've added math to multiply by 10 in the URL call, no dice. I've added the port taken the port away. I've made the call from the LAN and from the WAN no dice. Just completely at wits end. Oh well, makes the wireless tags much less compelling if they can't update the why the ISY.

As long as the Tag Manager and your ISY are on the same subnet, then this ought to work.  I can only imagine that there's a firewall or routing issue involved, but I'm not very good with networking anymore, so I can't be much help.

Bumbershoot Advanced

Bumbershoot

Posted
  • Author
Posted

I don't have any of these tags yet, but I'm interested. It looks like using the URL calling works on the LAN, and the KumoApp approach would require exposing my ISY to the Internet in order to receive the REST requests. Is that correct? If so, it would be nice to have this integrated through the ISY Portal instead of opening up a hole in my firewall.

I don't have any holes in my firewall.  I think the Tag Manager offloads the data to the Kumoapp for processing (I dunno, maybe through a VPN tunnel or something), retrieves it and ships it over to the ISY.  The IP address I put into the Kumoapp is a non route-able private IP address (192.168.0.30), which would be impossible for the Kumoapp to find without the Tag Manager handling the communications (I think!).

larryllix Advanced

larryllix

Posted
Posted

The Tag manager talk directly to your ISY via you LAN. No outside exposure is done.

 

However... at some point there is a permissive thing between the Tag manager and the cloud that allows it to do this.

 

@Ronlombardo. The parameters handed to you are decimal values. They are not going to like being shipped to ISY via REST unless you have a decimal parameter reception such as in ISY v5.*.

 

Try the round(voltage * 1000) or just round(voltage) function to get the integer of the value in your URL calling.

 

Previously most of us just gave up, due to lack of success with updates via ISY REST from the URL calling. They didn't appear to ever support continuous value updates but rather just threshold crossing triggers. That may have changed. With the kumoapps working so well, I never looked back.

roblombardo Member

roblombardo

Posted
Posted

OK, I found the problem. I like to report back on this stuff in case someone is experiencing the same thing. So, I found that I could loop back from WAN using a Kumo app and it would work. So, I went digging deep into my network settings. I found my ISY had a static IP set at the device, which I rarely do. I prefer to have the devices Static IP addresses assigned by the router based on Mac address. I had one number in the Mac address wrong in my DHCP reservation table, and because the IP address was set static at the device, the device did not show up on the DHCP table. Apparently that makes it inaccessible from another DHCP device on the same LAN. This is all Apple Airport hardware. This doesn't really make sense to me, but as soon as I change the ISY to DHCP and fixed the Mac address in the DHCP table on the router, it works via URL calling. So, chalk this one up as "PEBKAC" (problem exists between keyboard and chair). Thanks to all for the brainstorming help.

larryllix Advanced

larryllix

Posted
Posted

OK, I found the problem. I like to report back on this stuff in case someone is experiencing the same thing. So, I found that I could loop back from WAN using a Kumo app and it would work. So, I went digging deep into my network settings. I found my ISY had a static IP set at the device, which I rarely do. I prefer to have the devices Static IP addresses assigned by the router based on Mac address. I had one number in the Mac address wrong in my DHCP reservation table, and because the IP address was set static at the device, the device did not show up on the DHCP table. Apparently that makes it inaccessible from another DHCP device on the same LAN. This is all Apple Airport hardware. This doesn't really make sense to me, but as soon as I change the ISY to DHCP and fixed the Mac address in the DHCP table on the router, it works via URL calling. So, chalk this one up as "PEBKAC" (problem exists between keyboard and chair). Thanks to all for the brainstorming help.

Nice!

You have any hair left? :)

roblombardo Member

roblombardo

Posted
Posted

Nice!

You have any hair left? :)

 

Genetics took care of that a while back. BTW, rounding does not seem to work in the URL call unless I'm not formatting it properly. Thanks for your help.

Bumbershoot Advanced

Bumbershoot

Posted
  • Author
Posted

Genetics took care of that a while back. BTW, rounding does not seem to work in the URL call unless I'm not formatting it properly. Thanks for your help.

I've never seen a round() function used in URL calling, but the math is simple enough.  Glad you got it straightened out.

larryllix Advanced

larryllix

Posted
Posted

I've never seen a round() function used in URL calling, but the math is simple enough.  Glad you got it straightened out.

Just a note.

I noticed this at the top of the URL calling page.

 

"Hint: You can use math expression enclosed between <% and %>. For example, write in URL <% {2}+5 %> and it will be replaced with the temperature + 5 assuming {2} is temperature. "

 

This replaced the generic instruction once page activity was detected.

 

I assume you guys have tried or have been using this syntax already for the round() function.

Archived

This topic is now archived and is closed to further replies.

Go to topic listing

  • Recently Browsing

    • No registered users viewing this page.

  • Who's Online (See full list)

  • Forum Statistics

    • Total Topics
      37k
    • Total Posts
      371.3k
×
×
  • Create New...