
rccoleman
Members-
Posts
737 -
Joined
-
Last visited
Everything posted by rccoleman
-
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
-
Fair enough on the first part. Regarding 2FA, once I added the code from the link I mentioned, it asked me for the authentication code the first time and hasn't since. I suppose that it now sees this rpi as "trusted", but it may time out at some point in the future. I reverted back to the original distance_home_delta calculation and it's now working fine. Rob
-
I thought that I'd be able to create an app-specific password for your script, but it's not accepting the one that I created. That's supposed to be the answer for third-party apps, and I'd expect it to work just fine. The more I look at this, I'm wondering if it's just a bug in the loop. I get this in the log: 2016-09-25 09:48:42,519 - rpi3 iPhoneLocation(v0.12)[11999]: WARNING - MAIN - Reading the iCloud iPhone location from API failed! Sleeping for 30 seconds. Traceback (most recent call last): File "./iphonelocation.py", line 586, in <module> distance_home_delta = distance_home - distance_home_previous TypeError: unsupported operand type(s) for -: 'float' and 'str' on this line: ### Determine the change in distance: distance_home_delta = distance_home - distance_home_previous I suspect that "distance_home" should be "distance_home_precision", and that's causing the loop to fail on subsequent executions, but changing that isn't enough. I suspect that the error message that I'm seeing is not really accurate. Edit: Got it working. I changed "distance_home" to "distance_home_precision", as described above, and also added "float(xxx)" around the expression on 578. Otherwise, it evaluates to a string and the delta calculation fails. I think the "float(xxx)" change is the only one that's really needed, but I also wanted to do the delta calculation with equivalent significant digits. Edit 2: See here for info on 2-factor authentication with pyicloud. I added the code and it seems to work, but for some reason it doesn't seem to matter. I can just leave this code out, ignore the 6-digit code that pops up on my Macs and it works fine. I can't seem to make app-specific passwords work for this, unfortunately. Rob
-
Hmm.. After updating to v0.12, the first iCloud request succeeds and any after that fail. I worry a bit that it's because of the two-factor authentication that I have turned on. When I first run the app, I get the normal "someone is trying to access your account - accept/deny" popup, I hit "accept", it gives me a six digit code to enter on the client, and I ignore it. The app continued to be able access my account forever yesterday, but now it's failing after the first query. Do you have two-factor authentication enabled?
-
Sounds good, Steven. Thanks! It's working well enough for me that I switched my triggers to it and deleted my Locative geofence.
-
I set this up today and it looks like it should work for me. I had to install some additional requirements (PyMySQL was one), but nothing too complicated. It was also my first attempt to use MySQL, so that may prove helpful in the future. One quick comment is that having the distance in whole miles is a bit coarse for me. I'm using v5.0.4 on my ISY, which allows you specify variable precision, and it would be great if I could get at least 1 decimal place. I'd like to be able to arm my alarm when I'm 0.5 or 0.25 miles away from my house, for instance. I quickly hacked that by changing exit_code, isy_status = isy_variable('set', 'state', device_conf['ISYDistanceVAR'], int(distance_home)) to exit_code, isy_status = isy_variable('set', 'state', device_conf['ISYDistanceVAR'], round(distance_home,2)) Now, to drive around a bit a try it out! Edit: It looks like there are few more things that need to change, but I think I got them all now. Back to testing! Rob
-
I'm excited about this! I've been trying to find a reliable geofence mechanism it's been harder than I expected. For some reason, IFTTT doesn't trigger for me most of the time unless I start the app (despite having "background app refresh" and location "always" allowed), so that's out. Locative works much better, but I still routinely get multiple triggers upon crossing the geofence (either all the same, or sometimes is oscillates). I'll give this a try and see if it works better for me. Rob
-
The ElkRP software is Windows only, but runs fine in Parallels, VMWare Fusion, and (I suspect) VirtualBox. After configuration, I rarely need to use it, though. I control my M1 through my phone (currently eKeypad) and ISY programs.
-
If you hit the circled "x" in your screenshot, it clears the notifications for that particular day. I like to use the notification center for notifications that I haven't read yet, so I regularly clear it out. That's curious, because the way I described it is exactly as it works on my phone. I just had an unread email in the notification center, I went to the iOS mail app and read it, and it was gone from the notification center when I reopened it. I honestly think the intention of the iOS notification center is to keep track of things that you haven't yet attended to.
-
He's saying that they disappear from the iOS notification page when you open the app, and he'd prefer that they stayed there. It doesn't bother me (I just open the app to see historical messages), but I also clean out the iOS notification page on a regular basis. Notifications usually disappear when you read them in the originating app (like email), so I think it's consistent behavior.
-
Oops, perhaps that's why I had it set up as an email instead of a network resource . It was a while back and I couldn't remember why I had to do it that way, only that it was the only easy way to do a arbitrary text substitution that I could find. Sorry for the misinformation.