DriveFi: An application to prevent "Drive-by WiFi connections"


#21

that’s an interesting idea - if WiFi+ was written with Tasker extensions, its behavior could be modified not just by DriveFi but by any Tasker script an enterprising RW user might write up. That could prove to be very useful


#22

Pretty new to RW (and loving it!), so pardon my question if it’s a bit naive. I understand the issue here (random wi-fi connections on the road that don’t last), and I’ve added plenty of wi-fi hot spots already so do I see it in action. But, if I understand RW service correctly, once a call is started on cell, doesn’t the call stay on cell regardless of wi-fi availability? If so, then this app wouldn’t be needed most of the time, right? It seems like it would only be a problem when someone just happens to start a call while stopped someplace AND a random wi-fi connection is made, which would seem like two fairly rare events while driving, making the combination even more rare? (On an average 25 minute drive across town, I’m likely to start only one or two calls, and starting a call takes only about 5 seconds; and I’ll hit maybe 3 or 4 wi-fi hot spots, lasting for maybe on average 30 seconds; so some great mathematician can figure out the odds therein…!) Or maybe I’m wrong about RW keeping me on cell if wi-fi is available?

Regardless, I think it’s very cool what bitflung has done, and makes me feel, once again, really happy to be in the RW community.

Thanks!


#23

Mark,

Calls go both ways …you drive by the HomeDepot and stop at the light. Your spouse calls and because its available it will be routed cheapest first (ie WiFi). Now of course you have been to HomeDepot and it ‘knows’ you so the call is routed properly via the WiFi. Light changes, call drops, spouse aggravated well you get the picture


#24

It’s not charity so no reason to feel odd about it. Its a matter of people liking your application and wanting the improvements.


#25

Not to mention the drain on your battery as your wifi radio detects, connects, and disconnects from dozens of APs every day.


#26

Bug Report:

Took two trips today. First one was a six mile round trip with no opportunity to diagnose why I was not getting any WiFi status voice messages. Second trip was 10 miles through the boondocks with opportunities to stop along the road. Drove two miles with no voice reports. Stopped. Status was “not driving.” Played with the very confusing Autolocation and it’s three separate start/stop monitor toggles. Drove another two miles with no messages. Went back to Autolocation, Advanced, and removed red checkmark from “Exit Geofence when…” and a half mile later got the "WiFi Off enunciation. Arrived at destination and after about a minute got the WiFi On enunciation.

2nd Bug: Will sitting around visiting with friends I got the WiFi Off enunciation. A couple of minutes later I got the WiFin on enunciation.

3rd Bug: Drove home and app worked normally until I arrived. After being home for about 5 minutes WiFi was still disabled and status was still “driving”. I manually turned WiFi on. After a few seconds the app shut it back off. Status was still “driving.” Noticed phone was in airplane mode. Maybe I touched that when I manually turned WiFi on, I’m not sure. Manually turned WiFi back on and airplane mode off. This time WiFi stayed on even though status was still “Driving.” I went into DriveF1 app and manually toggled it to “not driving.”

Later… 4th Bug: Can’t get Drive F1 working again. Status toggles between WiFi Manually Enabled and WiFi Manually disabled.

End of bug report. We need a link to the bug report. I didn’t want to type this on my phone.


#27

Maybe Republic Wireless will use your functionality in their next build of their WiFi+ app. Just something to consider.

It just may make the community better and we wouldn’t need to buy the AutoLocation app.


#28

Bug Report:

(thanks for reporting bugs!)

[…] Drove two miles with no voice reports. Stopped. Status was “not driving.” Played with the very confusing Autolocation and it’s three separate start/stop monitor toggles.

AutoLocation is a little buggy it seems. I’ve had issues when starting/stopping the plugin manually (outside the DriveFi app). Haven’t been able to reproduce them reliably yet, so I haven’t submitted a bug report to the developer, but in all of my testing prior to releasing new version of DriveFi I tend to start/stop a LOT and sometimes AutoLocation just won’t work right again until I reboot. It does look like new versions of AutoLocation are in the pipeline (with fixes also in place for licensing issues).

Drove another two miles with no messages. Went back to Autolocation, Advanced, and removed red checkmark from “Exit Geofence when…”

DriveFi doesn’t use Geofences - it only uses 'Activities". A GeoFence would be a user defined are (a circle on a map) such that the status of the geofence monitor toggles when you cross between inside/outside the circle. DriveFi just monitors whether you are actively driving or not and so doesn’t use this feature (my code never starts or stops it).

and a half mile later got the "WiFi Off enunciation. Arrived at destination and after about a minute got the WiFi On enunciation.

interesting that toggling the geofences monitor caused DriveFi to behave better. I’ll have to test with that monitor turned on to see if there is another bug with AutoLocation.

2nd Bug: Will sitting around visiting with friends I got the WiFi Off enunciation. A couple of minutes later I got the WiFin on enunciation.

What version of DriveFi were you running? Version 1.5 includes a fix for a bug I’ve found in AutoLocation: the plugin was calling my code for unregistered activities (e.g. i have set a callback so when driving the “wifi off” code is executed, but AutoLocation was running “wifi off” for other activities too, like ‘tilting’, ‘unknown’, etc.)

my fix involves verifying the reported activity when my code executes. it shouldn’t be needed but it seems AutoLocation doesn’t do well with 2 registered activities monitored at the same time (in our case, ‘driving/biking’ is one, and ‘walking/standing still’ is the other).

3rd Bug: Drove home and app worked normally until I arrived. After being home for about 5 minutes WiFi was still disabled and status was still “driving”. I manually turned WiFi on. After a few seconds the app shut it back off. Status was still “driving.” Noticed phone was in airplane mode. Maybe I touched that when I manually turned WiFi on, I’m not sure. Manually turned WiFi back on and airplane mode off. This time WiFi stayed on even though status was still “Driving.” I went into DriveF1 app and manually toggled it to “not driving.”

interesting - would be godo to associate this bug with a particular version of DriveFi so i can try to reproduce it with the same code. if it occured on version 1.4, though, it was very likely the same bug in AutoLocation that i mentioned above.

Later… 4th Bug: Can’t get Drive F1 working again. Status toggles between WiFi Manually Enabled and WiFi Manually disabled.

perhaps related to manually turning AutoLocation monitor(s) on/off? sounds very much like the first issue you reported above; i see the same behavior when i manually toggle AutoLocation on/off during my testing of new versions. what version did you see this with and have you been able to reproduce it reliably?

End of bug report. We need a link to the bug report. I didn’t want to type this on my phone.

great idea, i’ll do that now!

thanks so much for the bug report

-bit


#29

skeeter wrote:

Maybe Republic Wireless will use your functionality in their next build of their WiFi+ app. Just something to consider.

It just may make the community better and we wouldn’t need to buy the AutoLocation app.

Interesting idea.
For what it’s worth, I’d gladly provide RW with the source code for DriveFi. In fact, I’d be happy to share it with any who requests it (latest version only, as a Tasker XML file).

As for AutoLocation: I’ve been rather disappointed with it. I did find an alternative, but it also costs about a dollar. I’m considering just writing my own Activity Recognition plugin and have started reading up on the process of writing Tasker Plugins. Can’t promise anything yet though


#30

Jared,

Rats, this bug report is for version 1.4. Don’t know how I missed 1.5 but will install it now.

I really like the idea of having our own Tasker plug-in but you have a full time job and a new kid at home. :slight_smile:

I don’t mind investing a few bucks in this effort. Heck, you are doing all the work.

Update: Installed V5.1 and DriveFi started working again. Here is your first V5.1 bug report:

On the DriveFi home screen the top line reads “DriveFi%Version” instead of DriveFi V5.1.

If you are eventually going to add this to the Play store, it might help to give it a somewhat descriptive name to facilitate search resolves. If RW isn’t going to incorporate your idea in WiFi+ you might consider WiFi+1 or WiFi+Sensor.

Bill


#31

you should see a link to the most recent version right in the online help screen. that should at least alert you to a new version being available.

download and install from there doesn’t seem to be working with the WebView UI element i’ve used for the help screen. i’m looking into an alternative method to download/install updates.


#32

I had a notification for an update to AutoLocation and updated it this morning via Google Play … hopefully they haven’t presented you with more bugs did @brandon.smith ever reach out to you from Republic


#33

The link in help requires Flash in order to work so I use my PC. No big deal. Ben, thanks for telling my about the update to Autolocation. Mine is now updated.


#34

jbenbennett wrote:

I had a notification for an update to AutoLocation and updated it this morning via Google Play … hopefully they haven’t presented you with more bugs did @brandon.smith ever reach out to you from Republic

autolocation update: here’s hoping it helps. what version are you on? i’ve recently signed up to beta test new versions, these are distributed as updates via Play Store, so i’m no longer certain of which version is ‘official’ and which is ‘beta’. latest version on the beta track is 1.1.14 and is primarily meant to fix licensing issues.


#35

Loaded after got the notification this AM…but can not find ver number … where did I not look?


#36

check here:

Settings -> Applications -> Manage Applications -> AutoLocation


#37

Well I got the “where did I not look?” part right

The version made made available 7/22/13 was 1.1.14 so users should update to be in sync with you


#38

Way back, I tried similar thoughts of using movement, or location differentials (30 second polling) to determine I was moving and turn WiFi off. Then I slapped my forehead. My solution was to use Tasker to disable WiFi and background updates (to keep cell data down - don’t need email while driving) whenever it connects to the car’s bluetooth. And re-enable them when connection to the car’s bluetooth is lost.

I leave my bluetooth always on, but if you really want to save the battery that last little bit, you can also set tasker to enable bluetooth when WiFi connection is lost, and turn bluetooth off when WiFi connection is made. However, your car’s bluetooth won’t connect until you drive a little away from your home/work WiFi then. This makes it so things happen like this:

  • WiFi connection lost -> enable Bluetooth
  • Bluetooth connection made -> disable WiFi & background data
  • Bluetooth connection lost -> enable WiFi & background data
  • WiFi connection made -> disable Bluetooth

#39

That is an interesting idea but it won’t do the job for me. My phone makes a BT connection to both my home phone system and car stereo/phone system.


#40

Tasker allows you to specify the id (by name or MAC) of the bluetooth connection (same for WiFi connection) if you need it to only react to the car’s bluetooth and not the home’s bluetooth.