MWareman

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.

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?