MWareman

Awesome! Thanks Lee. That perfectly explains what is going on, and I can now put this into a program as you suggested. Do we wiki-ize the peculiar devices?

Sounds good! Thanks Lee and Michel for the info. Extremely helpful as always! I never really though of 'Control On OR Control Off' - but it does make sense for, in effect, 'any change'. I'm a little confused with Michel's affirmation of my initial thought of the heartbeat though. Does the heartbeat status only change if the heartbeat is missed for 24 hours (as I initially thought) - or does the heartbeat flip-flop on/off with each 'pulse' from the sensor? Or is it something else - like a change to Off followed by a change to On each 'ping'? If the status only changes if something bad has happened due to a missed heartbeat - I would not want the program on the ISY to have to wait another 25 hours before alerting. Hence my question. There appears to be a bit of a lack of documentation for this device out there.

Hi Michel, Just bought 2 leak sensors - sorry to post to this thread again but one question is unanswered, and I need to know the answer as I setup my program: In your scenario where the leak happened during an outage of the ISY - the status will not be known by the ISY. In this state - if the leak sensor triggers a leak again - will the ISY know right away (I suspect this is the case)? Or will it have to wait for the heartbeat before leaks will be detected? As secondary question I have - the 'heartbeat' node has a status 'On'. How would I utilize this? Does the ISY status change to 'Off' if the heartbeat is not received in 24 hours? Or do I have to trigger a program on 'Off' and wait 24 hours to see if it changes back to 'On' - and sent a notification if not? Thanks! Michael.

Because when your program turns off the hot water (then condition step 1), it no longer satisfies your run condition (hot water status becomes 'Off') - so the program aborts without ever getting to step 3. You need 2 programs. One with your action and no condition - your then clause in the conditional program would simply run the then clause of your second 'action' program. That way - the wait won't get aborted once the heater turns off at 1am. Michael.

Even if the ISP does block port 80 and port 443 you could just change the setting in the ISY to use a different port number. Is there another way how an ISP can block you from running a server? Sent from my SPH-D710 using Tapatalk 2 Yes - but it does not happen very often. Two possible ways in fact. They can block any TCP packet heading to your router with 'SYN' set and 'ACK' not set. It would stop your server from working no matter what port it was listening on (breaks the 3 way TCP handshake - only in one direction). The other way is if your ISP does not give you a real IP - and NATs you to the Internet. This is starting to happen more and more now that the IPv4 pool is nearing exhaustion.

Such as with a keypad button (which, I submit, is the most common of "clients"). Perhaps, someday, we can have a means to easily duplicate a configurable keypad function on a tablet, and use them in place of a keypadlinc. In my mind, we are not quite there yet. Ahh - I don't do that.

It matters to me, where I use scenes to control status displays, and prefer "ON" to indicate open. I almost exclusively use MobiLinc - and I can override 'On' to actually say 'Open' or 'Closed' as necessary. My irrigation does not actually say 'On' - rather 'Running' or 'Off' on each zone. I guess if you cannot arbitrarily rename the status on your chosen client it does matter thou.

Arguably not - at least entirely. If this were completely true, the result of the query would also be reversed. Changing the magnetic switch from NC to NO does both. I do agree with you though - it's not a bug. I think it was a design flaw that nobody noticed until there was critical mass of deployed devices, and which point the 'if we fix this we break everybody's implementation' became a valid argument. At the end of the day though, does it *really* matter if 'ON' = 'OPEN' or 'ON' = 'CLOSED' as long as it's always the same? Trigger reverse breakers this. Just disable it, and reverse the program logic. To me, that's the easiest solution.

Yes, it works with the 994 (that's what I use it with) and on cellular and external you need to do one of 2 things: 1) Configure your NAT router at home to port forward he SSL port to your ISY (only works if your ISP does not block you from running a 'server' at home, as some do) Or 2) Subscribe to MobiLinc Connect

MobiLinc on Android does programs. MobiLinc HD on IOS does programs. I don't know about regular MobiLinc on IOS.

Michel, Sounds good. Thanks. Michael.

How about a simple variation on .htaccess..... If there is a .anon file in the directory that the file being requested is in, allow anonymous access. Otherwise, require authentication. It's then up to us to create the .anon file if we choose to allow anonymous to that folder and all files within. Should be easy to implement, and shouldn't break anything (since default would be to require auth). Gives more than 80% I think. And does not need a full revamp. Now, password-less access to the REST interface I agree is a bit more challenging. I would think the ISY could store one or more 'authorization' strings - and if one of the strings is supplied as a REST parameter, authentication is bypassed. Simple enough.. A bit like API tokens are generated and used by NotifyMyAndroid, Prowl and Pushover (all do this exact thing). ISY is easier because its a single user system.

Possible then? (with the weather revamp hinted)

I'm able to get data from WUnderground by signing up for a personal API key and using that in my script. As long as I don't poll the API faster than every 5 mins, I stay within the free use API tier. You could support WUnderground by providing a place for us to enter our own API key - and you would not have to become a partner. The API is public ally documented. An alternative is to allow us to push weather data into the ISY thru the REST interface. Is that what you are intending to do? That way, if we have our own rain gauge, for instance, we could push rain data into the ISY relatively real time. That way, you avoid ALL licensing issues. Michael.

Maybe a per-folder 'Allow Anonymous Access' attribute that can be set - in case we don't want to allow the full /user/web to be accessible? Default it to 'Off' on each folder (so there are no nasty security surprises for anyone). So, for example, I could write log files to /user/web/logs, and authentication would be needed, but an 'index.html' could be served without authentication from /user/web Just my $0.02. I'd make much better use of the user web space on the ISY with this feature.

That would be sweet. I *far* prefer Weather Underground personally - they have a reliable station about 20 yards from my house. Currently, the closest station is about 2 miles away with the current provider. I'd like to think that the new solution could pull data directly from local sensor hardware as well? Give the option to completely remove the Internet dependency from the equation. Pretty please?

Of course, the ELK module already does this. What has been teased is generic, user definable but more formalized bidirectional IP communications with a richer feature set.

No. You do not need the networking module just to allow external access to your ISY. If the auto enable does not work, chances are you do not have a router that is compatible, or you have upnp turned off on the router. You will have to configure your router manually - the wiki page referenced (http://wiki.universal-devices.com/index ... o_Your_ISY) should give you the ISY specific info needed. The rest should come from the manual to your router. Or you can buy MobiLinc Connect.

Update. In all of these tests, 'Verify' was off. Changed SSL Client to 'TLS 1.0' 'Low' Sun 2013/06/16 13:24:58 System -5 Start Sun 2013/06/16 13:25:06 System -170001 [Network] Established Sun 2013/06/16 13:26:17 System -170001 [TCP-Conn] -256/-140002, Net Module Rule: 56 Changed SSL Client to 'TLS 1.1' 'Low' Sun 2013/06/16 13:28:34 System -5 Start Sun 2013/06/16 13:28:42 System -170001 [Network] Established Sun 2013/06/16 13:29:41 System -170001 [TCP-Conn] -256/-140002, Net Module Rule: 56 Changed SSL Client to 'TLS 1.2' 'Low' Sun 2013/06/16 15:37:42 System -5 Start Sun 2013/06/16 15:37:50 System -170001 [Network] Established Sun 2013/06/16 15:39:06 System -170001 [TCP-Conn] -256/-140002, Net Module Rule: 56 Changed SSL Client back to 'TLS 1.2' 'High' It worked! Changed to 'SSL 3.0' 'High' It worked! Changed to 'SSL 3.0' 'Medium' It worked! It seems that having the strength set to 'Low' causes the failure. Not sure why - since thru openssl I can tell that www.notifymyandroid.com supports all the weak cipher suites (as well as the strong ones). bleepblorp, try going into the dashboard (isy.universal-devices.com/99i/dashboard.jnlp) and setting: 'HTTPS Client Settings' 'Protocol' SSL 3.0 'Strength' Medium 'Verify' Off This works for me to go direct. Michael.

According to the settings in the dashboard, I have 'SSL 3.0' selected, 'Low' and Verify is NOT checked. I'm going to try the other TLS settings to see if they make a difference. Michael.

I'll follow up - I changed one of my rules to go direct to https://www.notifymyandoid.com (instead of via my proxy), and I am getting "Error Request Failed" on a dialog when I test, and "N/A" in the response window. Strange thing is, the error happens almost immediately, despite having a 4000ms timeout in my settings. I wanted to make sure that www.notifymyandroid.com allows the cipher types that ISY is limited to. I used a quick script to fire every cipher type supported by OpenSSL at their server - and not one combination was rejected. There is no way the cipher type is not supported in my opinion - even the 56 bit ones (heck, they even accepted NULL-MD5). So, back to the failure to connect. I pulled the error log and I see: System -170001 [TCP-Conn] -256/-140002, Net Module Rule: 56 (56 is my test rule trying to talk directly to NMA) On the "Errors and Error Messages" wiki page, -170001 is not defined. Clearly, it's a new network module specific error - I am also getting this error from the "Portal-Dispatch" module. I also have seen -170001 occasionally when trying to connect to a non-SSL resource on my LAN - it's wifi connected so can I assume this is a timeout error? -140002 shows up - "HTTP_CLIENT_CONNECTION_TIMED_OUT". Not encouraging - especially since I have a 4000ms timeout on the network resource rule and the error is clearly being returned faster than 4 seconds. Given that my SSL reverse proxy has no issue connecting, I think that this has to be an issue in the networking module on the ISY not observing the specified timeout that is configured with the resource. ..but I've been wrong before.

Wanted to make sure. The non-pro units do not support the cipher types needed for the strong crypto needed for accessing SSL sites. Personally, I had NMA going before I upgraded to pro. To enforce SSL, I have a SSL forward proxy running on an internal server - so the ISY does plain HTTP and the SSL is done by the proxy. This has been reliable for me, so have not needed to change it. The only suggestion I have (other than having pro) is to make sure cert checking is disabled in the dashboard. You say you have done that already though.

Do you have an ISY Pro?

That would be extremely useful for me. I know the ISY is able to get the current on level (it shows on the admin console). It would be nice to have a command that can be put in a program that get current level and store it in a variable. I've tried to be a champion of that myself for a while.

io_guy Good to know. I'm going to try from an external connection tomorrow (to eliminate a secondary upnp broadcast causing the issue as Michel asked) - but (at least initially) it seems my experience is repeated with your test. I find it very hard to believe that a rogue 'disconnection' would cause this - especially since the 'authorization' header is still intact. A disconnect shouldn't matter. The GUI connection to the IP after the initial connection and authentication was against the host name would cause it though. I'll follow up again tomorrow when I have done more testing. Michael.