rccoleman

I don't know which firmware version you're running, but if you follow step 4 here, it will download a standalone app to your desktop that you can double-click to run the admin console. No browser required. The same process works for the 5.0.x alpha versions, too.

The best option, and the one that UDI currently recommends, is not to use the browser at all to get to the admin console. You can follow the instructions in the release notes to install a standalone icon that runs a Java instance independent of the browser.

My Echos all stopped working last night around 9PM PDT, but they were working in the morning. Does the Echo work locally ('Alexa, what time is it?')? The portal doesn't complain to me when I follow that path.

For now, you can make an IFTTT recipe that uses Google Assistant to listen for a phrase and the Maker channel to issue a web request using the IFTTT action in the ISY portal. It's more complicated than setting up Alexa, but also seems to allow more freedom in what you can say. This method also doesn't require 'tell izzy'.

I just used "restore device" to fix a weird problem, too. There was clearly a bad link somewhere between a motion sensor and two SwitchLincs based on some erratic behavior, but dumping the device links and comparing them to the ISY showed no meaningful differences (all either Identical or Ignore). I did notice that there were several "ignore" links in the middle that I suspect were inactive entries, so I did a restore to rewrite the link table and it fix the problem. Luckily, it's usually quick and painless. Rob

My Kwikset locks can exert some force, and they have specially tapered bolts to help them slide in without binding. Still, you should make sure that everything's aligned for it to operate reliably. Mine will just stop and complain if they meet too much resistance. Rob

As long as that information is conveyed to the OS, as I believe is the case for all major OSs, yes. It usually comes as part of an OS update when changes occur in different countries or regions around the world, and as you would expect your Windows, Mac, or Linux box to reflect the change, it would also be reflected in the node because it gets its data from the OS. Unless I'm misunderstanding the concern. Obviously it would be nice to have all of the fields from ISYData native to the ISY, so I'm happy to hear that UDI is amenable to that. Rob

Since it's based on the date from a 'real' OS (RPi or other), I would say 'yes'.

The ISYData component of ioguy's NodeLink has a daylight saving time field. I asked for it and he quickly added the feature. You could use that variable as a heartbeat (detect a change) and trigger an email.

It was working this morning and it looks like it's still online now. If it happens again, I'll try some more surgical clearing of state information on the router.

My ISY dropped offline from portal again yesterday, shortly after I left for work. It's unfortunate that it's become flaky, given that it's been working for many months. I get a bunch of stuff like this in the ISY error log: Wed 2016/10/26 09:08:24 AM System -140005 ISY Wed 2016/10/26 09:50:15 AM System -100 [DHCP] state=RENEW Wed 2016/10/26 10:50:19 AM System -100 [DHCP] state=RENEW Wed 2016/10/26 11:50:26 AM System -100 [DHCP] state=RENEW Wed 2016/10/26 12:50:30 PM System -100 [DHCP] state=RENEW Wed 2016/10/26 01:50:36 PM System -100 [DHCP] state=RENEW Wed 2016/10/26 02:50:42 PM System -100 [DHCP] state=RENEW Wed 2016/10/26 03:50:47 PM System -100 [DHCP] state=RENEW Wed 2016/10/26 04:50:51 PM System -100 [DHCP] state=RENEW Wed 2016/10/26 05:50:55 PM System -100 [DHCP] state=RENEW Wed 2016/10/26 06:51:01 PM System -100 [DHCP] state=RENEW Wed 2016/10/26 07:51:05 PM System -100 [DHCP] state=RENEW Wed 2016/10/26 08:51:10 PM System -100 [DHCP] state=RENEW Wed 2016/10/26 09:51:18 PM System -100 [DHCP] state=RENEW Wed 2016/10/26 10:34:13 PM System -170001 [UDSockets] RSub:28 error:6 Wed 2016/10/26 10:34:18 PM System -170001 [UDSockets] RSub:28 error:6 Wed 2016/10/26 10:34:23 PM System -170001 [UDSockets] RSub:28 error:6 Wed 2016/10/26 10:34:28 PM System -170001 [UDSockets] RSub:28 error:6 Wed 2016/10/26 10:34:33 PM System -170001 [UDSockets] RSub:28 error:6 Wed 2016/10/26 10:34:36 PM System -5012 91 Wed 2016/10/26 11:36:22 PM System -100 [DHCP] state=RENEW Thu 2016/10/27 12:24:52 AM System -140000 my.isy.io Thu 2016/10/27 12:25:27 AM System -140000 my.isy.io Thu 2016/10/27 12:26:02 AM System -140000 my.isy.io Thu 2016/10/27 12:26:37 AM System -140000 my.isy.io Thu 2016/10/27 12:27:11 AM System -140000 my.isy.io Thu 2016/10/27 12:27:46 AM System -140000 my.isy.io Thu 2016/10/27 12:28:21 AM System -140000 my.isy.io Thu 2016/10/27 12:28:55 AM System -140000 my.isy.io Thu 2016/10/27 12:29:30 AM System -140000 my.isy.io Thu 2016/10/27 12:30:05 AM System -140000 my.isy.io Thu 2016/10/27 12:30:40 AM System -170001 [Network-DNS][Task=22] Failed DNS 11/rc=6 Thu 2016/10/27 12:30:40 AM System -140000 my.isy.io Thu 2016/10/27 12:31:15 AM System -170001 [Network-DNS][Task=22] Failed DNS 12/rc=6 Thu 2016/10/27 12:31:15 AM System -140000 my.isy.io Thu 2016/10/27 12:31:50 AM System -170001 [Network-DNS][Task=22] Failed DNS 13/rc=6 Thu 2016/10/27 12:31:50 AM System -140000 my.isy.io Thu 2016/10/27 12:32:26 AM System -170001 [Network-DNS][Task=22] Failed DNS 14/rc=6 Thu 2016/10/27 12:32:26 AM System -140000 my.isy.io Thu 2016/10/27 12:33:01 AM System -170001 [Network-DNS][Task=22] Failed DNS 15/rc=6 Thu 2016/10/27 12:33:01 AM System -140000 my.isy.io Thu 2016/10/27 12:33:36 AM System -170001 [Network-DNS][Task=22] Failed DNS 16/rc=6 Thu 2016/10/27 12:33:36 AM System -140000 my.isy.io Thu 2016/10/27 12:34:11 AM System -170001 [Network-DNS][Task=22] Failed DNS 17/rc=6 Thu 2016/10/27 12:34:11 AM System -140000 my.isy.io Thu 2016/10/27 12:34:46 AM System -170001 [Network-DNS][Task=22] Failed DNS 18/rc=6 Thu 2016/10/27 12:34:46 AM System -140000 my.isy.io Thu 2016/10/27 12:35:21 AM System -170001 [Network-DNS][Task=22] Failed DNS 19/rc=6 Whatever is failing, it doesn't seem to recover and I have to reboot my pfSense router to get the ISY back online. At the same time, I can obviously access the ISY and the portal, and my network access to the outside world is fine. I was using DHCP with an address registration and DNS address of my router, so I switched the ISY to a static address and DNS of 8.8.8.8. I hope that that improves the reliability, but it would be good to know what's actually going on. This morning, this was the end of the error log with the ISY offline at the portal. The "Start" was where the ISY rebooted after I gave it a static address: Thu 2016/10/27 12:59:16 AM System -170001 [Network-DNS][Task=22] Failed DNS 60/rc=6 Thu 2016/10/27 12:59:16 AM System -140000 my.isy.io Thu 2016/10/27 12:59:51 AM System -170001 [Network-DNS][Task=22] Failed DNS 61/rc=6 Thu 2016/10/27 12:59:51 AM System -140000 my.isy.io Thu 2016/10/27 01:00:26 AM System -170001 [Network-DNS][Task=22] Failed DNS 62/rc=6 Thu 2016/10/27 01:00:26 AM System -140000 my.isy.io Thu 2016/10/27 01:01:01 AM System -170001 [Network-DNS][Task=22] Failed DNS 63/rc=6 Thu 2016/10/27 01:01:01 AM System -140000 my.isy.io Thu 2016/10/27 01:30:25 AM System -140000 my.isy.io Thu 2016/10/27 01:31:00 AM System -140000 my.isy.io Thu 2016/10/27 01:31:35 AM System -140000 my.isy.io Thu 2016/10/27 01:32:10 AM System -140000 my.isy.io Thu 2016/10/27 01:32:46 AM System -140000 my.isy.io Thu 2016/10/27 01:33:21 AM System -140000 my.isy.io Thu 2016/10/27 01:33:56 AM System -140000 my.isy.io Thu 2016/10/27 02:21:30 AM System -100 [DHCP] state=RENEW Thu 2016/10/27 03:21:34 AM System -100 [DHCP] state=RENEW Thu 2016/10/27 04:21:38 AM System -100 [DHCP] state=RENEW Thu 2016/10/27 06:37:29 AM System -170001 UDQ: Queue(s) Full, message ignored Thu 2016/10/27 06:37:29 AM System -170001 UDQ: Queue(s) Full, message ignored Thu 2016/10/27 05:21:42 AM System -100 [DHCP] state=RENEW Thu 2016/10/27 06:21:42 AM System -100 [DHCP] state=RENEW Thu 2016/10/27 07:21:51 AM System -100 [DHCP] state=RENEW Thu 2016/10/27 07:41:13 AM System -10011 n/a Thu 2016/10/27 07:42:15 AM System -5 Start Thu 2016/10/27 07:42:17 AM System -110022 /CONF/INSTENG.OPT Thu 2016/10/27 07:42:17 AM System -110012 /CONF/INSTENG.OPT Thu 2016/10/27 07:42:18 AM System -110022 /DEF/F3/I1/NLS/EN_US.TXT hu 2016/10/27 07:42:24 AM System -7123 ID 0077 :err=0, tag='status', num=44, nest=4, o

My ISY was successfully connected to the portal last night, but dropped off just before 2AM PDT. The ISY thinks that it's registered, but the portal says that it's offline. Rebooting the ISY doesn't help. Edit: Weird. It's back up after rebooting my pfSense router. It looks like my cable modem freaked out around 1:30AM and rebooted, causing it to reacquire the WAN address. After that, everything seemed fine from my perspective (I could ping external sites and access my.isy.io), but the ISY was offline as far as the portal was concerned. I'll have to dig into it a bit to see if pfSense was dropping the ISY packets for some reason, but it was weird that the ISY thought that it was still registered with the portal (green flag). Rob

It looks like it should be http://isy.universal-devices.com/994i/4.5.1/dashboard.jnlp. Note the "994i" that was missing. Rob

No worries - thanks for taking care of it. I'll update when I get a chance.

This morning, just after midnight, the script again thought that I had briefly transitioned to Away based on a 0.9mile distance from a Cell location. I was pretty sure that I had told it to ignore those, but it looks like I said 'true' in the config file rather than 'True'. While I'll admit that that was my fault, it would be more user friendly if you ignored case for boolean values from the config file.

So, if I understand correctly, if my battery level is below 15% and I'm heading home, it's possible that it won't see that I'm approaching my house because it may be in the middle of a 1-hour waiting period? I think the maximum that I'd want in that situation is around 5 minutes, and that's close to what I get with the current distance multiplier and no battery checking. My office is about 15 mins away from my house, so I don't deal with significant times or distances on a day-to-day basis. I can't think of a better way to take the battery level into account without some sort of feedback from the device, though. Rob

Maybe you have an old UI? Here's a similar thread from earlier this year: http://forum.universal-devices.com/topic/18827-network-module-missing/?hl=%2Bportal+%2Bnetwork+%2Bmodule Rob

Did you go to "Help->Manage Modules" in the admin console? That will tell you if you have a module that isn't yet installed and will take care of it. I don't think I had to do anything else to get it to show up. Rob

Thanks, battery level awareness would be helpful. I'm trying to figure out if the declining battery performance of my 6s Plus is due to the march of time or the increased GPS checking. Rob

0.15 has been working well for me since last weekend with cell location updates ignored. Thanks for doing this! Rob

Thanks. Steve. I updated to 0.14 after I noticed the cell location problem and will do so again for 0.15.

I saw the same issue this morning at the same time, but it's been resolved. When I first noticed it, my ISY was showing that it was connected to the portal and I was able to get to my.isy.io, but the portal said that my ISY was offline. I rebooted the ISY and it came up and showed connected both both the ISY and portal, but then went offline in both places a minute or so later. I still had no trouble getting into the admin console or my.isy.io. It was better in the morning.

In the middle of the night tonight my ISY oscillated between Home and Away a couple of times. I checked the script log and I noticed that the location usually reports a PositionType of GPS, but those two times it unexpectedly reported "Cell" with a distance from home >=0.5miles (in one case it was 0.5, in the next it was 0.6). In both cases, the next sample was GPS, and the distance went back to being very near home (~0.01 miles). With a program that looks for >=0.5 miles as "away", that was enough to trigger "away", "home", "away", "home" at ~3:50AM. Ugh. This was with my phone sitting on a charger on my nightstand. I note that the logs say this: 2016-10-02 03:49:32,700 - rpi3 iPhoneLocation(v0.12)[23537]: DEBUG - RADIO_CHECK - Running... 2016-10-02 03:49:32,700 - rpi3 iPhoneLocation(v0.12)[23537]: DEBUG - RADIO_CHECK - Script is not set to check for WiFi proximity, continuing... 2016-10-02 03:49:32,700 - rpi3 iPhoneLocation(v0.12)[23537]: DEBUG - RADIO_CHECK - Script is not set to check for Bluetooth proximity, continuing... 2016-10-02 03:49:32,700 - rpi3 iPhoneLocation(v0.12)[23537]: DEBUG - RADIO_CHECK - the iOS device is not in radio range. 2016-10-02 03:49:32,701 - rpi3 iPhoneLocation(v0.12)[23537]: DEBUG - MAIN - iPhone is not in radio range or WiFi and BT checking is disabled, checking GPS... It looks like you're relying on a separate data source and a variable to indicate both of those states. How do you intend for that to work? Based on the apparently poor accuracy of Cell-type locations and the relative frequency of GPS-type locations, I'm tempted to completely ignore "Cell" reports. Rob

Other than the changes I mentioned, I didn't customize anything other than changing the update granularity. I'm running mostly a stock setup.

I'll check this out when I get home. What sort of trouble are you having with adding 2FA? I just imported the "click" module and added exactly the code at the link I mentioned earlier. That let me pick the device and enter the the code that I received over SMS. For what it's worth, the setup that I have now is working great! Rob