MWareman

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.

Firewall is disabled, so I don't think that is it. I'll try remote, by both name and ip and see if the symptoms are the same or not. Michael

I thought upnp was deprecated? Multiple tests I have done have shown the same as I have indicated above. If I access the ISY with http://ip.ad.dr.es I *reliably* only have to login to the GUI once only. If I start from a newly logged on session, accessing with *any* name (via dns, hosts file or other name resolution), I get multiple login requests by the GUI. I'd be interested to find out if others who get multiple logins continue to get them if they access the ISY by IP address rather than by name.

The request IMMEDIATELY before the second authentication prompt - there is a request to /desc: GET /desc HTTP/1.1 Host: isy.domain.com:80 HTTP/1.1 200 OK Content-Length: 1539 Connection: Keep-Alive WWW-Authenticate: Basic realm="/" Content-Type: text/xml; charset=UTF-8 Cache-Control: no-cache EXT: UCoS, UPnP/1.0, UDI/1.0 Last-Modified: Sun, 26 May 2013 12:32:15 GMT <?xml version="1.0"?>10http://10.1.1.20urn:udi-com:device:X_Insteon_Lighting_Device:1HomeUniversal Devices Inc.http://www.universal-devices.comX_Insteon_Lighting_Device:1ISY 994i 10241100uuid:{removed}uuid:{removed}urn:udi-com:service:X_Insteon_Lighting_Service:1urn:udi-com:serviceId:uuid:{removed}/services.wsdl/services/eventingUDIELKWebServicesuuid:{removed}-UDIELKWebServices/elkServices.wsdl/security/elkUDISEPWebServicesuuid:{removed}-UDISEPWebServices/sepServices.wsdl/sepServicesUDIZWaveWebServicesuuid:{removed}-UDIZWaveWebServices/zwaveServices.wsdl/zwaveServices/ Could it be that when the GUI receives a response - it is switching over the using that URL instead of the one the user supplied in the original request? The request to /desc use the hostname as the Host: header. The next request - to /services - used the IP address. This causes a second authentication prompt to appear to the user. You can repro in a broswer (new session) by visiting http://isy.domain.com/rest/config (URL of your ISY) - and authenticating. You'll see the config on the ISY. Then (same session) - visit http://10.1.1.20/rest/config (IP of your ISY). You'll get prompted for authentication again before the config displays. This is exactly what the Java GUI is doing - resulting in multiple authentication requests. Further confirmation. If I access my ISY with the IP (http://10.1.1.20/admin) - I do NOT get multiple auth requests at all. Michael.

Michel, Found something. After my first authentication, here is the request for /services from the GUI to the ISY: POST /services HTTP/1.1 Host: isy.domain.com:80 Authorization: Basic {REMOVED} Content-Length: 173 Content-Type: text/xml; charset="utf-8" SOAPACTION:"urn:udi-com:service:X_Insteon_Lighting_Service:1#Authenticate" usernamepassword Here is the response: HTTP/1.1 200 OK Content-Length: 207 Connection: Keep-Alive WWW-Authenticate: Basic realm="/" Content-Type: application/soap+xml; charset=UTF-8 Cache-Control: max-age=3600, must-revalidate EXT: UCoS, UPnP/1.0, UDI/1.0 Last-Modified: Sun, 26 May 2013 12:32:15 GMT <?xml version="1.0" encoding="UTF-8"?>200n/a Note the 'Host:' header in the request. It's the host name of the ISY - as I typed into the browser. Shortly in - I got a second authentication request. I captured the next request afterwards - also to /services: POST /services HTTP/1.1 Host: 10.1.1.20:80 Authorization: Basic {REMOVED} Content-Length: 173 Content-Type: text/xml; charset="utf-8" SOAPACTION:"urn:udi-com:service:X_Insteon_Lighting_Service:1#Authenticate" usernamepassword And the response: HTTP/1.1 200 OK Content-Length: 207 Connection: Keep-Alive WWW-Authenticate: Basic realm="/" Content-Type: application/soap+xml; charset=UTF-8 Cache-Control: max-age=3600, must-revalidate EXT: UCoS, UPnP/1.0, UDI/1.0 Last-Modified: Sun, 26 May 2013 12:32:15 GMT <?xml version="1.0" encoding="UTF-8"?>200n/a Note that the Host: header is NOW the IP address of the ISY. For some reason - the Host: header has changed. This causes the realm of authentication to change - so the browser requests authentication again (it thinks it's talking to a different host). The realm is a combination of the Host header and the value specified for the URL of the Realm. The GUI should ALWAYS use the Host: header of the URL - it should not switch to an IP address (unless the user first accessed thru the IP of course). This capture was actually against 4.0.5 - just so everyone knows. The problem is there as well - du to the change of the Host: header after the console opens. Michael.

I just downloaded https://isy.domain.com:1234/admin.jnlp to my desktop (SSL on a custom port directly to the ISY). I then ran it - it prompted me for the security setting (like above). I got an option to 'Always trust' - perhaps because I'm using a certificate from cacert - and they are in my clients trusted store. This created an icon on the desktop. Anyway, ran the icon and the ISY Finder came up (listing 'http://isy.domain.com/desc' - no SSL) - and the admin console opened prompting for authentication. I authenticated - and it prompted again etc... Eventually - I got in. Note, the console was NOT using SSL - the communication was on port 80 and in the clear (confirmed with wireshark). I then removed the entry from the ISY finder and manually added the https://isy.domain.com:1234 url. Closing everything out and reopening from the desktop shortcut - the console opened, prompted me (once) and I was in. So - despite using HTTPS (and a custom port) to access and download admin.jnlp - ISY finder still tried to connect with a HTTP url (and gave me multiple prompts). When I manually fixed the URL in ISY finder to use the HTTPS url with the custom port - no multiple prompts. Back to my original method - browser based. http://isy.domain.com/admin opens the console. I get multiple logon prompts before I can work. (This is how I usually work on my internal network) https://isy.domain.com:5228/admin opens the console - and only a single authentication prompt. (I will probably change to this!) Definitely an issue on the HTTP listner or HTTP authentication in the Java client - that does not show up when using SSL. I'll work to sanitize a wireshark dump for you if it will help. Michael.

Thanks for the clarification. Last time I tried it I was on 3.something. With I changed from HTTPS to HTTP (to sniff the interaction with wireshark) the traffic from Java to the ISY was still using HTTPS. I had to clear my cache before the communication changed. This was when I was working with you on the host header issue. I guess that has already been fixed (or it was a local issue to my machine - always possible). Wen I looked at the .jnlp file with notepad, the full ISY URL was there, with the protocol. Thanks.

In my experience (don't know if this is intended or not), when you change between http and https urls on a particular machine you also need to clear the java cache. The cached version seems to 'remember' the original URL used and persist it for future sessions. That would seem to be needed for clicking the shortcut icon to launch outside of the browser, but it sure would be nice if launched from inside the browser if the 'remembered' URL was updated. I discovered this a while ago when testing the SSL proxy solution I'm playing with (which I personally thought was the cause of the login issue for me... I'm glad this came up in a way). Anyway, in my case the multiple login issue happens with both SSL and plain text connections. 4.0.4 and latest Java on Windows 8 x64.

store the result of : x-y in z x+y in z Program conditions, If x-y > z then... Etc etc.. Especially where one or more operators came from module output from modules like weatherbug or irrigation - or even the current light level of a dimmer, light level etc etc.

Great to hear! I'll refrain from asking how long, I know better. Is this likely to include arithmetic on variables?

Yep. It's invalid when you update the ISY code, and a pain if you have multiple users on the same machine. I should mention, I got multiple logins when I tried the download method anyway. The Argo didn't make it worthwhile since it did not make the experience any better. Also, I launch from Chrome, not IE. I get the same multiple login issue with SSL or not. Been that way since 3.something. I've just grown to live with it - but the Java admin console of Cisco ASA firewalls don't do this, so I know it's not something broken in Java itself. It would be awesome to find out the cause and fix it though. Anything I can do? I'll try to get a wires hark capture of the non-SSL session connecting with multiple logins if you want. Michael.

Yep. See this all the time. Not sure why, but been seeing it for quite a few versions. Personally, I chalk it up to Java. I hate it, I really do...

Too many Michaels's here So, nightly calculation of irrigation requirement. Only gets decreased in between nightly calculations in response to 'irrigation complete' commands. Goes up every night at midnight in response to prior days ETo. Goes down each night at midnight in response to prior days rain total. Is this the correct current understanding? There are so many other criteria - best to look at the other thread on it though. To do what I need, I'm in the process of writing an external function to read the irrigation requirement and rain today (thru the API) to confirm that irrigation is still needed at 6pm - a full 18 hours after the calculation was done. I don't want the cycle to run if, for example, a storm blew thru earlier in the day. It sucks that I have to go external for this - hopefully we will eventually get first class variable handling in programs. It would be much easier to do something like: If (irrigation_requirement - rain_today) > 0.5 then Run irrigate (then) Truly, is it not possible to expose two irrigation_requirement variables? One that was calculated at midnight - and a second one with a different name but that tracks ET during the day as well as rainfall to allow it's use at any point in the day as better read on needs later in the day? It would be reset back to the nightly calculation at midnight, with the other variables? In response to the OPs question, since the irrigation variables are not really variables, its not possible (that I know) to trigger on them when they change. As far as I know. I just send an email at 4am and it seems to have the updated figure by then. Also, you cannot just subtract rain from the irrigation equipment. You have to account for absorption. So if only 80% of rain gets absorbed, then a 0.5" rain will only subtract 0.4" from the requirement. Michael.

My understanding is that the calculations are run at midnight, then static until he next run the next midnight, with the only exception being running an 'irrigate complete' command subtracts the configured amount from the irrigation needed variable. I've been asking for real time updated rain and et data to be applied to the irrigation requirement, but so far I've not seen any plan to integrate that. Michael.

I have that P-touch as well - but have not used it for ages. Thanks for the tip - I need to dig it out. If I remember correctly, they make clear tape for it as well (with black 'ink'). That would be perfect as an overlay on blank buttons. Thanks!

If you use a VPN and don't expose the ISY at all to the Internet, then there is no need for SSL at all on the ISY - as long as your internal network is secure (no guest wifi etc..). However, in my case at least, that would prevent effective use of products like MobiLinc, unless I dumb down the VPN choice to something that is easy to configure and automatic to use on both IOS and Android - like pptp (and I'm not willing to do that!).