
Steven M Castano
Members-
Posts
216 -
Joined
-
Last visited
Everything posted by Steven M Castano
-
Ok, the initial code is pushed out to the github page, go ahead and download away... give it a shot and tell me what you think. Just do me a favor and any code related questions or issues that come up specific to the code itself, use the "Issues" section on github so I can track everything that needs to be done myself and so it might be consolidated and helpful to others in the future as well.
-
P.S. A comment on battery life... on my jailbroken iPhone with enhanced battery stats showing all the system deamons, the GPS services that respond to the iCloud API GPS calls, which is actually the Find My iPhone service, running over the course of an entire 9 - 10 hour day at work barely 10 miles from home, which means lookups every 3 - 5 minutes, so that's an average of about 150 lookups while I'm away from home, only shows it's using 6% of the total power my iPhone has used and since it starts with a full charge every morning and comes home, on average at about 50% - 60% charged, that means this services is barely using 2 - 3% of my battery all day. A simple tweak to check less frequently when I'm not home could lower that even farther, and since I am doing WiFi and Bluetooth proximity checking, when I'm home, the script doesn't even do a single iCloud lookup. I also went camping this past weekend for 3 days about 80 miles from home, which meant the script was only doing a single lookup once every 40 minutes. On those days the Find My iPhone services showed up as using less than 1% of my total battery usage and it still increased it's lookup frequency as a drove home and sure enough, just as I was passing the 7-11 near my house, my phone popped up it's notification that the ISY had marked me as home. I've been testing this for about a month now, there's really only 3 major roads to drive in and out of where I live and I can tell basically within a few blocks of where I should be getting the notifications that I'm home or away and it works every single time.
-
I've always been interested in how people were using Locative to make that work. I had been trying other geofence apps, including MobiLinc itself, Find My Friends, etc... and none of them really seemed to work. Sometimes after an iPhone reboot the app didn't restart, it might crash in the background and I never knew, etc... it was always very flaky. @jtara92101, as for your specific situation, I would think you could tell your ISY programs to only mark you away once you're 2 miles away or something and that would resolve the issue of the "jumping" that happens with GPS. Mine does that same thing from time to time, if WiFi based GPS fails, since I also live in a high-rise it switched back to cell based triangulation and sometimes shows me a few blocks away in one of 2 or 3 spots. They just happen to be inside the 1 mile radius I've set for myself. I could also write into the code that it doesn't consider a distance as changed when it's going from 0 miles, up until the distance is over 1 mile 3 times, that could eliminate a little bit of the noise... but also introduces some delay. I'm stuck at my desk at work right now, but should be living soon and one more quick cleanup of the code and I'll have it posted on github in just a few hours.
-
I've been working on a new project written in python that basically hits the Apple iCloud API (now support two factor authentication enabled accounts), grabs your iOS devices current location, computes it's distance from the GPS coordinates of your home, then uses the ISY API to store that distance as a variable. You can imagine all the options you can use this for from there!!! It's main features are: Reads an iOS device's GPS location, computes it's distance from home and stores it as an ISY variable It can report the distance from home in miles with up to 8 decimal points of precision (Can be done via an optional multiplier on firmware below v5.0.x that doesn't support variable precision) It's outputs a table of data showing its values, distances and updates to the screen as well as stores the data in a MySQL database for your own review later Optional: it can read other ISY variables to check to see if your device is present on WiFi or within range of a bluetooth sensor (this reduces battery drain by not checking the API GPS location when the script already knows your device is home) It varies the time between updates based on your distance from home, so the the rather you are away from home, the less often it attempts to read data, again to save battery life It can optionally read your location more often if it senses you are getting close to home to attempt to ensure your variable it updated all the way 0 before you actually walk in your door. The code is coming along nicely. There have been a few releases already and a few suggestions from this thread already incorporated. The code and write-up is on GitHub at: ISY iCloud Proximity *SMC From here on out, I will update this first post with all changes and releases as they're pushed to the public repo, but as always, you can use the link above to get to the GitHub page and get the latest code and read the latest release notes. Changelog: (If you want to see more of this info all the back to the first releases and/or the most current info if this post falls behind, be sure to check the GitHub releases page for this project) **11/14/2016 - Version 0.18.0 Released: Added: Auth config file integration: No more copying settings back and forth between .ini files when a new release comes out. The script now reads your current iphonelocation.ini file, backups it up for you, adds the new features needed, and restarts the script with all the correct previous settings. openHAB Integration: The script can now connect to an openHAB instance and report it's distance at full precision (8 decimal places). This new feature is turned off by default. Battery Level Reporting: Requested by a user, the script can now report the current iOS device battery level to the ISY in a variable. Settings are in the advanced area under the [general] section. This new feature is turned off by default. Bug Fixes: There was a condition missing from the "from_cell" data validation function that took a few tries to fix. The script reported a false warning if Cell location data was set to be allowed and the data did, in fact, come from a cellular triangulation. The script would continue, but with a warning. The erroneous warning message is now corrected. **11/14/2016 - Version 0.17.2 Released: Fixed: -- ***NOTE: Please make sure you run "pip install -r requirements.txt" again to catch added packages. Code to create pid files properly on Windows machines to avoid script crash. Code to check for script updates will continue after error to prevent script crash. Added the python mysql driver to requirements.txt (Needed for windows users) **10/25/2016 - Version 0.17.1 Released: Fixed: Added appropriate spacing to reflect the increase in precision of distance from home calculations. **10/25/2016 - Version 0.17.0 Released: Added: Forced GPS rechecks: This means that if you're using Wifi or Bluetooth checking, by default the app will now check your GPS location from the iCloud API once every hour even if your location radio systems can see the device. This is to catch crash local detection apps that have left your device in a "home" state. This can be disabled in the .ini file, and the frequency with which the forced checks occur is also configurable. Battery level retries: Previously the script would try to read your batter level once and move on. Now, by default the script will try to read your battery level from the API 3 times with 30 seconds between each try before moving on. Again, this check can be disabled and the number of retries and sleep time is configurable in the .ini file. *Version checking: Instead of just relying on forum posts and/or emails from github, the script will check once every 6 hours to see what the latest publicly availible version of the script is and let you know in your screen data table and debug logs. Fixed: Mismatched cell phone location rejection rules: The conditions to validate if location data came from Cell vs. GPS of Wifi had a small logic error that cause some cell locations when the API reported them as not being "old" to be used even before the max number of retries had expired. **10/18/2016 - Version 0.16.1 Released: Added: Code now outputs the raw data returned from the API when reading battery level if check is enabled to allow for better understand of percentage calculation if there is an error. Fixed: Added the proper code to read boolean values from the .ini conf file. Now any config item that can be turned on or off will accept (case insensitive) "true, false, yes, no, on, off, 1, 0" as acceptable values. **10/13/2016 - Version 0.16 Released: Added: Battery monitoring has been added. By default the script will check your battery level when it updates it's GPS data and if the battery is below 15% it will sleep for 1 hour, or however long the variable distance sleep time is, whichever is longer. This feature is turned ON by default. All configuration items for this feature have been added to the end of the .ini.sample file, if you'd like to turn it off, simply change the "battery_check" setting to "False" Fixed: Changed logging level for a few GPS validation checks, isOld warning now only appear if you exceed retried and old data must be used. **10/2/2016 - Version 0.15 Released: Added: You can now set in the .ini configuration file to ignore any GPS data that comes from cellular triangulation and only accept the more precise data that comes from Wifi, GPS or GPS-Course. This feature is turned OFF by default. All configuration items for this feature have been added to the end of the .ini.sample file. Fixed: Changed logging level for GPS data validation checks that are configured to be ignored from a warning to a simple debug message. **9/30/2016 - Version 0.14 Released: Added: Added code to api_login function to handle iCloud accounts with two factor authentication enabled Fixed: Added import for the python "click" module to use proper prompts for 2 factor authentication Added "click" version 6.6 or higher to the requirements.txt for install ** Notes: Be sure you either run a `pip install click` or a `pip install -r requirements.txt` to confirm you have all packages needed as at least 1 has been added by this release **9/29/2016 - Version 0.13.1 Released: Added: Added code to check data returned from the iCloud API for the "isOld" flag indicating that the data iCloud has from the device may not be current. By default the application will now retry 6 times, sleeping 30 seconds between checks and if current data isn't returned, it will proceed anyway with any valid date it all. All the options, the sleep time, the max number of retries and rejection of the "isOld" data itself is all configurable in the .ini file. **9/28/2016 - Version 0.12.1 Released: Added: Updated the onscreen table display to show a "*" after any ISY value that was sent to the ISY. (Only changes from the previous distance value are sent) Fixed: Moved reading location data from the iCloud API to it's own function and added error checking. The function now only returns data and an exit_code of 0 if a valid latitude and longitude are found. Moved the computation of the sleep time between update cycles to it's own function to clean up the main app code. Updated some DEBUG logging lines to be more descriptive. Removed redundant log lines after moving code out to its own functions.
-
Bluetooth Proximity: Another chapter...
Steven M Castano replied to Steven M Castano's topic in ISY994
The car one is a great idea... no idea how to make it work, but I'm sure it could. The question is, how you get the car to know the BT done is there, usually the connections go the other way around. As for my project with multiple sensors.... I'm having a TERRIBLE time getting it working. It seems like the original Raspberry Pi and RocketFish USB BT adapter work great. I'm able to take multiple RSSI readings per second, it's very accurate, picks up devices almost immediately and rarely disconnects. The new problem is that I can't seem to replicate that... I've now tried two different sets of BT adapters and I'm starting to see the same issues/pattern emerging. It seems like there may be some limit to the number of devices an iPhone can handle, or maybe some issues with channels and such... I honestly don't know enough about it to debug it properly. The first one worked so well I thought it would be EASY to deploy more. So, I've got two more raspberry pi's, both now with RocketFish BT adapters installed... I do get signal readings that are pretty consistent when working and I'm able to relate them to distances, so the "proximity" portion seems to work great. The problem is that with all 3 going, I eventually seem to lose to two new ones. Eventually they step accepting the "rfcomm" connections and I don't get any signal readings at all. At first it seemed like restarting the bluetooth service as well as "resetting" the USB connection would work to restart them. Also, it seems like it only didn't work after the iPhone had been disconnected for a while so I created a cron job to reset the USB and restart the bluetooth service every 15 minutes. That didn't end up working for very long either. It eventually got to the point where virtually no connections would work... except the original one I've had for a few weeks now seems to keep working.... and I would have to actually turn bluetooth on the iPhone off and back on again. What I've tried now is to use them all on different bluetooth channels. Since the original working one runs great on channel 1, I moved the other to channels 3 and 13... all which come up usable with a working "rfcomm" service listed in a "sdptool browse" command. Right now it seems like that's almost stable, but I wish there was some way of getting a clear understanding of what my problem is. Is there a max number of BT devices that can associate with an iPhone? Is it per phone? per channel? am I having hardware issues? incompatibility? BT version? I even did a ton of reading on how to look at "hcidump" to watch a lot of the traffic go by but that didn't prove to be very easy to figure out either. I can run the tool and capture the traffic, I'm just not sure what I'm looking at! -
Bluetooth Proximity: Another chapter...
Steven M Castano replied to Steven M Castano's topic in ISY994
I'm going to work on getting the code into SVN or git at some point soon as it's getting fairly complex. I didn't want to sacrifice speed or size of the entire system at all so I've gone a little rouge on the overall design. Originally it started with a single Raspberry Pi running a small bash script and has now moved over to all python. I just couldn't get what I needed out of bash especially when I started with moving averages, signal "sanity" checks and multiple "sensors"..... What's it's become now is a main python script built from multiple small functions I've been developing over time, but the point here is that I'm running a linux virtual server and using the python-paramiko package to have my python scripts actually SSH out to the raspberry pi's where the USB bluetooth adapters are installed and collection the raw signal data. There is currently one pi by my front door, one in my master bedroom and one in the living room. The main python script collects the raw data, stores the moving average and updates the ISY accordingly. Currently it's only telling the ISY if a device is seen by any of the bluetooth radios, but I'm working on storing and comparing the results from all three over the next few days. I've determined what signals values mean I'm "near" each sense based on some VERY basic mapping I did tonight. Basically, I connected a LED to the GPIO pins and set it so that an average signal strength of -10 or below turns it on, over 10 turns it off and I adjusted it from there.... seems like that part is working great so far. The part I'm working on right now, since I know how to tell if I'm "near" a device or not.... (and it still needs some fine tuning)... I'm creating ISY variables for each of my devices called: "Device1_BT_Location" So I'll set that variable to a different number depending on my signal states: 0 means the script has no idea where I am 1 means I'm in the living room 2 means I'm in the master bedroom So basically, I collect all the values and compare the results to my threshold... if only 1 value is "inside" the threshold, that's where I am and I will update the ISY.... if 2 values are inside the threshold, I'll elect to shoot the one with the best raw strength value and again update the variable. What I have noticed is that, at times, my average drifts a little bit and I wind up "outside" of the threshold for a few seconds before it comes back down... most of the time this seems to be when I've got the iPhone in my hand and I'm assuming is due to covering the internal radio. Now the "fine-tuning" I was referring to means I either have to make the average look at a longer set of raw values which could make the location resolution "lag" a bit.... i.e. when entering a room, even those the raw values may be WELL inside of the threshold, it make take 30 seconds or so before the average comes down appropriately. Either that or I have to tolerate these "bounces" outside the threshold and possibly not consider a device as "out of the room" either until it's found in another room, or been out of a room for 2 - 5 minutes. There is surely a lot that goes into this, and I've complicated it even farther by making the script totally multi-threaded so I can check all sensors simultaneously as well as adding at network server capable of listening via telnet on port 2323 so my monitoring systems can connect from time to time and get both health check results as well as momentary signal statics. -
So, I've been working for weeks if not months now on some bluetooth proximity options and I've made a TON of progress. So far I'm able to have a linux virtual machine reach out to a raspberry pi with a USB bluetooth adapter on it and get the RSSI signal value. With that I've created some basic math, thresholds and update times to compute a moving average of the last 30 values, which in my environment spans about 5 seconds. It works GREAT actually.... I'm able to keep the bluetooth connected throughout almost my entire apartment, monitor the connect status for changes and when it does disconnect or reconnect, the ISY is update via the REST API and I'm able to turn off computer monitors, front hallway lights, etc... It's also VERY responsive... while I've seen iphones disconnect from WiFi for almost 20 minutes at a time... I was forced to set my ISY to "delay" thinking nobody was home for 20 minutes after seeing the last device to ensure it wasn't just a temp disconnect. Also, there are times... after walking up to and into my door, wifi can take anywhere from 1 - 10 minutes to reconnect..... not very useful for throwing on the lights as you walk up to the door. That being said, bluetooth has been a star from that perspective... the longest disconnects I see are for anywhere from 5 - 25 missed updates, which at the date I'm checking (6 times a second), translates to only 4 - 5 seconds. So I'm able to update the ISY seconds after walking out, reliably.... and, when I return home, there is a bluetooth antenna right behind my front door... it picks me up from easily 30 feet away and has everything turned back on for me before I can even get my keys out. The situation I'm working on now is that, while this is all great for simple "home/not home".... I'm getting a little more ambitious now. I not only want to know if a device is anywhere in or near the apartment... but I want to know WHERE it is also. I've been working through the issues and have the python scripts fairly well written to at least give me one level of "near/not near". So I've got one setup under an end table in the living room and under a night table in the bedroom...... The problem I have is that the radios I've using don't seem to give me much leeway in signal strength ratings... the news one only show me a range of 0 to -10.... and even when basically putting the iphone right next to the bluetooth adapter, sometimes I only get a -1. Also, I stay around a ring of -1 to -5/6 when I'm in the same room, and even halfway across the apartment, but the drop off from -6 to -10 and then to disconnect is a very short distance. Has anyone out there tested bluetooth USB radios? Any that have given good RSSI or LQ readings? I have an old RocketFish USB BT adapter that seems to work fairly well... it gives me a useful range of about 0 to -30/35 and is pretty consistent as you get closer and farther away, but I'm having trouble locating them again. Any recommendations??
-
So I've got a scene called "All Lights" that has a few devices in it. Basically it's all the lights in my condo including the 4 that are motion controlled as well as 3 KeypadLinc Dimmers all using the "D" button as part of the scene. Most of the time I used the "All Lights - D" button to turn lights on when I wake up in the morning, when people come over in the evening, etc... The issue I have is that eventually my motion controlled lights will be triggered again and automatically shut off, then one by one as people leave rooms, most of the other lights are shut off also. The problem is that by the time people about the house and take care of things, we're down to a light or two left on, most of the time at a different level than 100% which is defined in the "All Lights" scene that turned them on.... HOWEVER, the "D" KeypadLinc lights are still on. There is where the problem comes in, if I push the button to turn them off, or even write a program to do the same... once the KaypadLinc "D - Buttons" scene gets turned off, it in turn sends an OFF command for the entire "All Lights" scene disturbing people. Ideally, what I'd like is that after a few of the lights are controlled independently, the "D" KeypadLinc buttons go off without disturbing the lights that were controlled independently. Has anyone else done something like this or have any pointers?
-
I would imagine its defective since its bee. Working properly for quite a while now with the same load attached. I'll do a little more testing, but I might have to return it.
-
Now it seems to be doing it again. It now seems to have updates in the ISY stuck that it can't write. I have a program that runs 15 minutes before sunset and set's the scene to turn on that LampLincDimmer at 50% instead of full. It also does the same thing for a SwitchLinc Dimmer and a 2nd LampLinc Dimmer that are all part of the same scene. It updated the other two devices, is stuck trying to write updates to the "malfunctioning" one and it's doing the light bouncing thing again. Also, it is no longer responding to scene "ON" commands like it was before. It now barely responds to even the "fast on" commands. It seems like it blinks anytime there is a little insteon traffic. When I hit "fast on" the module flashing on for a second then turns right off again. Sometimes it even comes up for a second before shutting off again. Here is a "fast on - fast off - fast on - fast off" and you can see only 2 of the three devices respond. Thu 04/04/2013 07:35:56 PM : [iNST-TX-I1 ] 02 62 00 00 15 CF 12 00 Thu 04/04/2013 07:35:56 PM : [iNST-ACK ] 02 62 00.00.15 CF 12 00 06 LTON-F (00) Thu 04/04/2013 07:35:56 PM : [ 21 85 AB 1] ST 255 Thu 04/04/2013 07:35:56 PM : [ 20 A7 A3 1] ST 255 Thu 04/04/2013 07:35:59 PM : [iNST-TX-I1 ] 02 62 00 00 15 CF 14 00 Thu 04/04/2013 07:35:59 PM : [iNST-ACK ] 02 62 00.00.15 CF 14 00 06 LTOFF-F(00) Thu 04/04/2013 07:35:59 PM : [ 21 85 AB 1] ST 0 Thu 04/04/2013 07:35:59 PM : [ 20 A7 A3 1] ST 0 Thu 04/04/2013 07:36:01 PM : [iNST-TX-I1 ] 02 62 00 00 15 CF 12 00 Thu 04/04/2013 07:36:01 PM : [iNST-ACK ] 02 62 00.00.15 CF 12 00 06 LTON-F (00) Thu 04/04/2013 07:36:01 PM : [ 21 85 AB 1] ST 255 Thu 04/04/2013 07:36:01 PM : [ 20 A7 A3 1] ST 255 Thu 04/04/2013 07:36:02 PM : [iNST-TX-I1 ] 02 62 00 00 15 CF 14 00 Thu 04/04/2013 07:36:02 PM : [iNST-ACK ] 02 62 00.00.15 CF 14 00 06 LTOFF-F(00) Thu 04/04/2013 07:36:02 PM : [ 21 85 AB 1] ST 0 Thu 04/04/2013 07:36:02 PM : [ 20 A7 A3 1] ST 0 Then after unplugging and re-plugging in the device I am able to write the updates to the device and now here is the log: Thu 04/04/2013 07:39:53 PM : [iNST-TX-I1 ] 02 62 00 00 15 CF 12 00 Thu 04/04/2013 07:39:53 PM : [iNST-ACK ] 02 62 00.00.15 CF 12 00 06 LTON-F (00) Thu 04/04/2013 07:39:53 PM : [ 1A E0 21 1] ST 255 Thu 04/04/2013 07:39:53 PM : [ 21 85 AB 1] ST 255 Thu 04/04/2013 07:39:53 PM : [ 20 A7 A3 1] ST 255 Thu 04/04/2013 07:39:54 PM : [iNST-TX-I1 ] 02 62 00 00 15 CF 14 00 Thu 04/04/2013 07:39:54 PM : [iNST-ACK ] 02 62 00.00.15 CF 14 00 06 LTOFF-F(00) Thu 04/04/2013 07:39:54 PM : [ 1A E0 21 1] ST 0 Thu 04/04/2013 07:39:54 PM : [ 21 85 AB 1] ST 0 Thu 04/04/2013 07:39:54 PM : [ 20 A7 A3 1] ST 0 Thu 04/04/2013 07:39:55 PM : [iNST-TX-I1 ] 02 62 00 00 15 CF 12 00 Thu 04/04/2013 07:39:55 PM : [iNST-ACK ] 02 62 00.00.15 CF 12 00 06 LTON-F (00) Thu 04/04/2013 07:39:55 PM : [ 1A E0 21 1] ST 255 Thu 04/04/2013 07:39:55 PM : [ 21 85 AB 1] ST 255 Thu 04/04/2013 07:39:55 PM : [ 20 A7 A3 1] ST 255 Thu 04/04/2013 07:39:57 PM : [iNST-TX-I1 ] 02 62 00 00 15 CF 14 00 Thu 04/04/2013 07:39:57 PM : [iNST-ACK ] 02 62 00.00.15 CF 14 00 06 LTOFF-F(00) Thu 04/04/2013 07:39:57 PM : [ 1A E0 21 1] ST 0 Thu 04/04/2013 07:39:57 PM : [ 21 85 AB 1] ST 0 Thu 04/04/2013 07:39:57 PM : [ 20 A7 A3 1] ST 0 I didn't change anything here... just unplugged the module, plugged it back in and everything is working again. Not sure how long it's going to last this time.
-
Yes, that was Infact what did it. It wasn't responding and it was doing that "light bouncing" thing where it would fade up to 20ish% then drop back off again. It wasn't at a consistent rate and appeared to be totally random and without an insteon traffic. (At least none that was shown in the event viewer)
-
I was using the MobiLinc slider for that... if that does the same thing, then yes that must have been it. I'll quit playing with it and see how it responds for a while now without changing any settings.
-
Ahh, good catch... that's strange.... As for the Firmware and UI level, both are v.3.3.10 As for the "On Level (applied locally)" slider, it was at 30%. I slide it up to 100% and the device came on. Now it would appear to all be working properly.... I wonder if it missed at update or something, I'm going to have to play around and make sure it keeps responding to things as it should.
-
Ramp rate is a negative, it's still doing the same thing at 2 seconds.... didn't work at .1 either. And here's another weird thing... if the fast on and fast off always work, brighten and dim always work.... if I press the "ON" button for the device in Mobi Linc is DOESN'T work, but the "OFF" button does.... then I noticed if I pull the slider all the way up to 100% it works, but when I pull it back down to 0 (all the way left) it doesn't work. It always works if I drag it to somewhere in the middle though. This just keeps getting weirder.
-
That actually is an incandescent.... two of them (1 - 100W and 1 - 60W). I'll try adjusting the ramp rate now though.
-
and, last posts for a bit... here is the log entry from a "fast on" from Mobi Linc to the device itself that DID work: Thu 04/04/2013 05:22:13 PM : [iNST-TX-I1 ] 02 62 1A E0 21 0F 12 00 Thu 04/04/2013 05:22:13 PM : [iNST-ACK ] 02 62 1A.E0.21 0F 12 00 06 LTON-F (00) Thu 04/04/2013 05:22:13 PM : [iNST-SRX ] 02 50 1A.E0.21 1E.80.B1 2B 12 00 LTON-F (00) Thu 04/04/2013 05:22:13 PM : [std-Direct Ack] 1A.E0.21-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 04/04/2013 05:22:13 PM : [ 1A E0 21 1] ST 255 and here is a normal "on" to the device that now does NOT work: Thu 04/04/2013 05:23:06 PM : [iNST-TX-I1 ] 02 62 1A E0 21 0F 11 00 Thu 04/04/2013 05:23:06 PM : [iNST-ACK ] 02 62 1A.E0.21 0F 11 00 06 LTONRR (00) Thu 04/04/2013 05:23:06 PM : [iNST-SRX ] 02 50 1A.E0.21 1E.80.B1 2B 11 00 LTONRR (00) Thu 04/04/2013 05:23:06 PM : [std-Direct Ack] 1A.E0.21-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
-
Here is the results of a scene test: Thu 04/04/2013 05:16:51 PM : [GRP-RX ] 02 61 15 13 00 06 Thu 04/04/2013 05:16:52 PM : [iNST-SRX ] 02 50 1A.E0.21 1E.80.B1 61 13 15 LTOFFRR(15) Thu 04/04/2013 05:16:52 PM : [std-Cleanup Ack] 1A.E0.21-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Thu 04/04/2013 05:16:52 PM : [iNST-SRX ] 02 50 21.85.AB 1E.80.B1 61 13 15 LTOFFRR(15) Thu 04/04/2013 05:16:52 PM : [std-Cleanup Ack] 21.85.AB-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Thu 04/04/2013 05:16:52 PM : [CLEAN-UP-RPT] 02 58 06 Thu 04/04/2013 05:16:52 PM : [iNST-SRX ] 02 50 20.A7.A3 1E.80.B1 61 13 15 LTOFFRR(15) Thu 04/04/2013 05:16:52 PM : [std-Cleanup Ack] 20.A7.A3-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 ----- Master Bedroom Test Results ----- [succeeded] MBR-FloorLamp (1A E0 21 1) [succeeded] MBR-SwitchLincDimmer (20 A7 A3 1) [succeeded] MBR-TableLamp (21 85 AB 1) ----- Master Bedroom Test Results ----- It looks like everything is fine... and the device is on the same circuit as the PLM, so I can't imagine its a coms issue.
-
I'm not sure if this is a communications issue, a faulty device or something in the ISY.... but here is a copy of the logs: Thu 04/04/2013 05:02:47 PM : [iNST-TX-I1 ] 02 62 1A E0 21 0F 14 00 Thu 04/04/2013 05:02:47 PM : [iNST-ACK ] 02 62 1A.E0.21 0F 14 00 06 LTOFF-F(00) Thu 04/04/2013 05:02:51 PM : [ 1A E0 21 1] ERR 1 Thu 04/04/2013 05:02:57 PM : [iNST-TX-I1 ] 02 62 1A E0 21 0F 12 00 Thu 04/04/2013 05:02:57 PM : [iNST-ACK ] 02 62 1A.E0.21 0F 12 00 06 LTON-F (00) Thu 04/04/2013 05:03:09 PM : [iNST-TX-I1 ] 02 62 1A E0 21 0F 19 00 Thu 04/04/2013 05:03:09 PM : [iNST-ACK ] 02 62 1A.E0.21 0F 19 00 06 LTSREQ (LIGHT) Thu 04/04/2013 05:03:18 PM : [iNST-TX-I1 ] 02 62 1A E0 21 0F 19 00 Thu 04/04/2013 05:03:18 PM : [iNST-ACK ] 02 62 1A.E0.21 0F 19 00 06 LTSREQ (LIGHT) Thu 04/04/2013 05:03:27 PM : [iNST-TX-I1 ] 02 62 1A E0 21 0F 19 00 Thu 04/04/2013 05:03:27 PM : [iNST-ACK ] 02 62 1A.E0.21 0F 19 00 06 LTSREQ (LIGHT) Now for the odd behavior.... most of the time, until this morning, the device was working with no issues. Then, it stopped responding to commands... almost. Anytime I turn on the device via a program or a scene, it starts to come up a bit but then quickly shuts off. From then on, it basically just bounces a little on and right back off again without any insteon commands being issued. Looking at the device physically, the green status light is not steadily blinking green on and off... but seems to have nothing to do with the light being on or off itself. In the admin console, any attempt to query the devices fails. Also, the buttons on the side don't respond anymore. Then, after unplugging the device and plugging it back in.... the local buttons work, it responds to "scene" on and off commands, but won't respond when you try to control the device itself. If I click on it in the management console and issue an "on" or "off" command it doesn't work, however "fast on" and "fast off" as well as "brighten" and "dim" work fine. Then, if the light is on.. the normal "off" command works. It stays like this for a few minutes, then goes back to flashing its green status light and that odd intermittent blinking again. I have already factory reset and restored the device, but the same behavior continued. So, what do we think? Bad device? noise on the line? It's very weird.
-
Can the ISY look for and read a WOL that is sent to it?
Steven M Castano replied to G W's topic in ISY994
Thank you for taking the time to answer. Is this something that could be added to the ISY with little effort? I know ROI has to be considered. Gary I think what you might be looking to do is "Proximity Detection" i.e. for your ISY to know when you're home... or when any one of a number of people are home by detecting whether or not one of their wireless devices is on WiFi or not. Correct? There is a long running thread on this and quite a few of us have gotten exactly that up and running without problems. Check it out: http://forum.universal-devices.com/viewtopic.php?f=51&t=9854 -
So, I realized I don't have to be home for ALL of this... here is the log output from turning the SCENE on via the admin console: Fri 02/08/2013 02:42:54 PM : [iNST-TX-I1 ] 02 62 00 00 1B CF 11 00 Fri 02/08/2013 02:42:54 PM : [iNST-ACK ] 02 62 00.00.1B CF 11 00 06 LTONRR (00) Fri 02/08/2013 02:42:54 PM : [ 20 84 56 1] ST 255 Fri 02/08/2013 02:43:05 PM : [iNST-TX-I1 ] 02 62 00 00 1B CF 13 00 Fri 02/08/2013 02:43:05 PM : [iNST-ACK ] 02 62 00.00.1B CF 13 00 06 LTOFFRR(00) Fri 02/08/2013 02:43:05 PM : [ 20 84 56 1] ST 0 This appears to work and turn everything on/off EVERY time as expected Here is turning the SwitchLinc Switch on and off itself: Fri 02/08/2013 02:43:56 PM : [iNST-TX-I1 ] 02 62 20 84 56 0F 11 FF Fri 02/08/2013 02:43:56 PM : [iNST-ACK ] 02 62 20.84.56 0F 11 FF 06 LTONRR (FF) Fri 02/08/2013 02:43:57 PM : [iNST-SRX ] 02 50 20.84.56 1E.80.B1 27 11 FF LTONRR (FF) Fri 02/08/2013 02:43:57 PM : [std-Direct Ack] 20.84.56-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 Fri 02/08/2013 02:43:57 PM : [ 20 84 56 1] ST 255 Fri 02/08/2013 02:44:02 PM : [iNST-TX-I1 ] 02 62 20 84 56 0F 13 00 Fri 02/08/2013 02:44:02 PM : [iNST-ACK ] 02 62 20.84.56 0F 13 00 06 LTOFFRR(00) Fri 02/08/2013 02:44:02 PM : [iNST-SRX ] 02 50 20.84.56 1E.80.B1 27 13 00 LTOFFRR(00) Fri 02/08/2013 02:44:02 PM : [std-Direct Ack] 20.84.56-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 Fri 02/08/2013 02:44:02 PM : [ 20 84 56 1] ST 0 From the looks of it... the on/off commands are sent, received and confirmed very quickly and on the first try. The comms seem to be consistent too, with there always being 1 Hop left. It seems like as I repeat the command, it goes through EVERY time.... once in a while it tells me Hops Left = 0, but it still works. So I would think triggering either the SCENE or the DEVICE from the program should work, no? (I can't test with the motion sensor yet as I'm not home and doing this remotely)
-
That's a good point. I'm going to try both and run a log the whole time. I'll dig through it myself (which I'm getting fairly good at now) and I'll post it here also.... for a second set of eyes!
-
I totally agree.... the program ran, set thr scene on..... but the lights never came on. Then, just to make sure I wasn't crazy, I manually turned the scene on from the admin console and it worked great. Let the MS timeout, and tried again.... still the same behavior.... Then, just to be double sure, I turned the scene on and off through MobiLinc and via the ISY built in web interface. They all worked fine, just not when the program ran.
-
So, set the program to turn on the DEVICE, not the SCENE? Ok, I can try that.... I'm actually pretty sure I did. That was when the ISY said the light was one, but it wasn't. I'll try it again.
-
Ahhh... ok, that def explains some of it. So I'm back to resolving some coms issues..... I wonder if I can write in a little something in the program to retry, query, etc.... Any ideas? Or just start working on network problems?
-
I will have to check everything again and document EXACTLY what I'm seeing, but from memory: With the MS and the SWL both as controllers of the scene.... lights come on and off exactly as expected, from motion detection, and when triggering the scene from the ISY or MobiLinc. With the MS NOT in the scene, and the SWL as a controller and the only device in the scene.... it would seem all the on/off commands are received from the MS, and the program operates as expected, however... the status of the SWL in the ISY switches to ON, but the lights have not come on. Then, when it goes to turn them off... I get the communications error. I will change the scene around tomorrow during the day and take log captures of everything.