apostolakisl

With the io linc, you can use the GRI sensors. GRI is a security system "industry standard" Very well respected. Just make sure you have good com with your io linc since they are not dual band. Maybe consider putting a lamplinc on the same outlet with it if there is any question about it. The iolinc only has a single input, so you will not be able to independently monitor more than one sensor at a time (with only 1 iolinc). Though you can have multiple sensors that run in parralel or series (depending on if you get the NO or NC leak detector). If you want power outage protection, you'll need to put it on a ups and then you will have to have a dual band device since the ups will block the power line com.

The absolutely easiest solution is this https://www.smarthome.com/insteon-2852-222-water-leak-sensor.html Mount this in the well at a level above which you would like to be notified. No wires, no power, no nothing. Just link it to your isy and write some programs. You can even get 2 or 3 and mount them at different locations as redundancy. I don't have any ground water issues (my well is 800 feet deep!) and have no sump, but to mitigate any pipe/appliance leakage I put gri2600 http://www.grisk.com/images/product_pdfs/liquid_detection/2600_12volt_dc_water_sensor.pdf water monitoring all over my house, about 20 sensors maybe more. They are all wired directly into my Elk. GRI also makes a submersible water presence sensor. http://www.grisk.com/images/product_pdfs/liquid_detection/2808_absence_water_sensor.pdf This would be ideal to put just below the pump shut off level. If that sensor goes dry, it would either indicate drought, or a pump that has failed to shut off. These sensors will require that you get an io linc or wire into a security panel or similar. The GRI unit saved me huge already. I had a slow leak behind the dishwasher that was running water under the hardwood floor. The leak detector sensed it even though there was no water evidence at all. I cursed the water sensor as having failed and reluctantly pulled the dishwasher out. And then, I stopped cursing it and started cursing the plumber.

There are a bunch of off-the-shelf float switches out there. Just do a nice secure installation and you should be good. From there, you can hook the float switch to an i/o linc and program ISY to do whatever you want. You can also wire it up to a siren directly so if for whatever reason the i/o linc/ISY/email thing failed, you would still have that whining siren. Other fun options include using an ultrasonic range finder and wiring that up to a cai webcontrol. There is a node server for cai webcontrol posted by ioguy which will allow easy isy integration. This will tell you exactly where the water level is. Basically, it outputs a voltage based on the distance between the device and the reflection surface (the water). ISY would show the voltage and then you would need to scale that number to inches or whatever. And another thing is to use an synchrolinc on your sump pumps electric plug. From this you can be notified if there is too much or too little run time. EDIT: It seems that synchrolincs are no longer a thing. Anybody know anything about that? Is there going to be a new device replacing it or is this just never to be a thing again?

Seems like a flow chart diagram is warranted here. And in the wiki. I am in a similar situation with two ISY's. I did manage to get it all straight. While I'm only using Alexa at one of them, I'm using Agave at both. I had to have two user profiles and set one ISY as primary for one and the other profile as primary for the other ISY. I believe the Agave relationship with the portal is the same as the Alexa with regards to that. EDIT: Check that, I actually created two separate portal accounts. Perhaps I didn't need to do that.

Two problems with this. 1) At least on my phone, the app goes to sleep. It does not update the geo fence unless you open the app, except every once in a while seemingly at random hours after I had already entered the geofence. This is despite me giving it every permission I could find that might undo limits on its background wakes/batter usage. 2) There is a good reason that Android might want to shut it down. GPS geo-fencing is battery intensive. Tasker plus wifi status is nearly a zero battery kill. It is also extremely quick and accurate. If you want to keep your GPS drainage down, you need to limit it to say every 5 or 10 minutes (if it works at all, which in my case it does not). Even at that, the phone will continue check every x minutes 100% of the time. Going on a vacatoin? You'll get a gps check every x minutes even if you are 1000 miles away. Using Tasker only requires that you keep your wifi on. Which for most people is standard. Of course it also depends that at all geo-fenced locations, you have wifi.

Did you setup the node in ISY for occupancy? I would use this over a variable. It does not require authentication aside from what is in the post itself and it is a node, much nicer than a variable (intuitive and easily accessible for programs and status checks). Did you copy and paste into Tasker as a "post" the https://my.isy.io/api/occupancy2/ . . . /in(or out) that the portal lists as the trigger for changing your occupancy node status? I also put a "wait" command into Tasker on the exit from wifi of 5 seconds to allow my phone enough time to establish its data connection upon dropping the wifi. It is worth noting that my wifi connection is my geo-fence indicator. This has been working flawlessly for me.

I actually didn't say that any behavior was "correct" or "incorrect" I only said what the behaviors were. I'm also not sure why you are making a distinction between the "load balancer" and "the portal", the whole thing is "the portal", they are inseparable. Furthermore, there is nothing incorrect about saying the portal is not truncating the string variable into a numeric variable. This is a very important observation because of the fact that a REST to an ISY DOES. I did say that including units is more than just useless. It would be a crippling blow to the usefulness of the weather module if not for this "error" of the ISY REST handling. I also said that in its current form, you have to do a crazy workaround to use weather module data in anything more than the most basic and simple comparison (ie is temp greater than 80) Again, units are completely useless. You can add the units if you want to a notification email or text using isy's standard notifications format, or at the target device in a more generic sense. I have been using weather module data for a very long time via REST only and just always assumed it was only a numeric value, because 1) it made sense and 2) that is how it worked in that context. EDIT: I would also like to point out that UD is pushing their luck with the 128 character limit on path. The encryption string is huge and pushes very close to that limit. If memory serves, I was at 115 characters with the path using variable substitution.

I tried two REST commands that set a variable, one ISY to ISY, one ISY to portal to ISY. First off, I just sent a single integer value to confirm all my settings, no problem on either setup. Second, I tried appending that same REST command with a space and letter. ISY to ISY it truncated off the letter and worked fine, ISY to portal to ISY gave error. In summary, it appears the portal does process the REST command and does not truncate and therefore fails. Seems like an unnecessary thing for the portal to do (process the REST command rather than just forward it on through). But my workaround does fix it (the workaround being to first network resource the weather module value back to yourself so that it becomes a normal variable) TAKE HOME POINT: The knowledge that you can network resource a weather module variable back to yourself and clear out the useless units and open it up for using as a comparative value or do math on it, or send it to another isy via the portal is worth something. To the best of my knowledge, looping a weather module value via a network resource is the only way to use a weather module value as something to compare to anything but a fixed value. For example, if inside temp (from a thermostat) is higher than outside temp (from weather module).

No, I tested this and posted it a couple posts ago. I just did simple REST commands ISY to ISY and added %20 followed by random letters to an otherwise functioning REST command. ISY returned error every time. ISY to ISY using the weather module variable substitution does not.

Except F and % sign apparently are part of ${mod.weather.temp.current} and ${mod.weather.humidity} YET, they still work direct ISY to ISY REST to a var. The exact same thing through the portal does not work. So I don't know what code is in there that tells the receiving ISY to ignore the string and just use the integer. And why this is lost with the portal? Whatever code it is, it is not %20. %20 seemed like a good candidate since in the email that seems to be the only thing separating the integer from the F or % sign.

A percent sign does show up in the email for humidity. None-the-less, it works. I tried test REST commands to my isy putting a %20 after a number (url for "space") thinking maybe isy truncates at a space, but it does not, it gives an error. For example, http://192.168.1.9/rest/vars/set/2/26/8%20 So there must be some other character there that tells it to truncate . . . cause it works when you use variable subsitution for temp and humidity. I would expect that the portal is not "understanding" the REST command, but rather just truncating all credentialing since it has already established a session with the target isy. There really would be no need to understand or interpret the command at the portal level.

Unless humidity puts a % sign, then it is not that. Humidity also fails via the portal. I would not expect the portal to pay any attention to the content of the message but rather simply act as a forwarder. And humidity works fine direct from isy to itself or isy to another.

I don't know how that is possible. There are no options that I am aware of to change that and mine is sending a number right now. It updates every time the number changes. I have a state variable for both humidity and temp that just updated with a 94 for temp and 43 for humidity at 8:31:37 (about 15 minutes ago). I have been running this network resource now through quite a few firmware versions, probably starting in the 4's through the present 5.0.13c. The only difference is that now I'm on the portal so I'm having to first have to loop it back via a LAN network resource to the originating ISY, then once I have it as a standard variable I can send it to the other ISY without exceeding the allowable number of characters.

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.

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.

The new firmware is not the reason the programs aren't working. The reason is, as you seem to be suspecting, that this major firmware update reset the "disabled" status. Normally, a firmware update does not reset that status, but the huge changes between 4 and 5 did. You just need to figure out which programs need to be disabled again. Typically, when you write programs like this, you organize them into folders so it is easy to see which ones work together, or at least have used a naming convention that makes the association obvious. If neither of these situations were true for you, you can use the "find" function and search for any program that references these programs. If everything worked before, you should not need to write any new programs or change current programs, aside from disabling the correct ones. Also, you may be able to go back to the old firmware and restore the backup I'm hoping you made prior to the upgrade. Then you can go through and make a note of what programs were disabled. Then you can update again knowing what to disable. I am suggesting this based on my belief that the disabled/enabled status is preserved in a backup, though I'm not 100% on that.

Both of those programs have "then" clauses which change the status of a device which is in the "if" clause. So the program will re-trigger itself and trigger the other program, possibly back and forth. If you want to check the status of a device in the "if" and based on that status change that status in the "then", then you must disable the program and have an additional program which does a "run if" on that program. The key here is to understand triggers. STATUS is a trigger upon ANY change in the device. CONTROL is a trigger only upon execution of THAT SPECIFIC command (ie switched on).

the red left edge means the last time the program did something, it was the "else" clause. disabling a program means it won't spontaneously run. In other words, the "if" clause will only check its own conditions when something else tells it to "run if". Typically another program or less likely from an outside REST command or by someone manually telling it to "run if/then/else".

See, you did figure it out. ?

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

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

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

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

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

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