The Zenwatch and the Digital Dash

In my last post about my Slide Wear project, I mentioned that I was having trouble coming up with any kind or practical application for my Zenwatch 2 in conjunction with the Digital Dash project.  Well, I still haven't found anything practical, but I did come up with something kind of fun.

The other day when I was browsing G+ communities related to my watch, I came across a custom face that some guy had created based on his fondness for BMW motorcycles.  The logo caught my eye and got me thinking that I could probably make my own themed watchface as well.  He mentioned that he had made his in an app called "Watchmaker".  I started doing a bit of research into that app and found some truly amazing faces that people had created.  The app not only has incredible flexibility in design, but also includes a focused version of the Lua programming language; it's pretty much like Tasker for your watch.

I went to the Google Play Store and saw the app was currently 50% off.  That pretty much clinched the deal right there, but when i saw this in the feature list:

• Tasker - Full tasker integration to set watchface, change variables, run tasks

I was hooked. I had the app on my phone within minutes.

The watchfaces in this picture (shown in both their bright and dimmed states) are the first things I did with Watchmaker.

Can you guess where I'm going with this?

If you're one of the 26 people who read my post entitled "A Few More Changes" you know that I added a feature to the Digital Dash that allows it to know which vehicle it's connected to and display the appropriate logo on the tablet's main interface.  Given that I already had that code in place, it wasn't hard to add a single line that sent an AutoRemote direct message to the phone with the formal XXX=:=Face (where XXX is either BMW or JAG).

A Tasker profile on the phone recognizes this command and uses the parameter to call an appropriate task that sets my watch to full brightness and activates the proper face so that my watch is themed appropriately to the vehicle I'm driving.

I thought about adding an exit routine that would automatically revert back to my regular watchface when the Digital Dash shut down, but decided against it.  I'd rather have the watch stay themed if I stop for lunch or something during a roadtrip and shut the system down.

Instead, I used Watchmaker's "Tap" function to set up a manual reversion.  If I touch the vehicle logo on the watchface, it sends a command to run a Tasker task.  That task uses AutoWear to create a simple confirmation screen:

If I truly do want to revert to my normal watchface, I have five seconds to touch the AutoWear icon.  In that case, it runs another task that sets my display brightness back to normal and loads my regular watchface.

If, however, I don't touch the icon, the screen will dismiss itself automatically after five seconds without making any changes.  I did it this way to avoid accidentally changing face with an inadvertent touch.

The one other thing I did was extend the system's brightness control to include the watch.  Now if I dim the tablet screen for night driving, it also dims the watch as well as the phone.  Setting the tablet back to full brightness restores that setting to the other devices as well.

I realize that this is a pretty pointless enhancement, but it's also kind of fun and I'm glad I did it.

Physical Controls for the Digital Dash, Part 3

After careful thought and consideration (Yes, I'm serious.) I've decided to retire my gamepad side-arm controller in favor of my original scheme of using a Flic to control app access on the Digital Dash.  There are a couple of reasons for that:

1) The Flic is simply more reliable and easier to use.  It doesn't require recharging, connects automatically, and handles it's sleep mode more elegantly.  It also responds more quickly than the gamepad.

2) Many of the functions that the gamepad controls are either no longer necessary or are otherwise handled.  I don't need to download A-GPS data since I'm using the "Device Only" mode for GPS and I've brought the external temperature reading to the main screen, eliminating the need to pull up the Weather Channel app just to get that information.  And, of course, by installing a Flic dedicated to music control, I no longer need those functions on the gamepad.

3)  Finally, on our last few drives I kept closer track of just exactly how I was interacting with the system.  By far, the thing I did most often was to switch over to Google Maps to see the next turn information.  And that didn't happen very often.  I used to switch over more often to see the ETA information, but since bringing that to the main screen as well, it's available without any interaction.  The second most common thing was to check MyRadar to see incoming weather, but again, that was relatively rare.  Other things, such as switching music sources or setting a navigation destination simply didn't happen during the drive; I tended to do that at the beginning of a trip and never needed to change it en-route.

Taking all that into account, I decided to set up a second "App Control" Flic with the following functions.

When the main screen is showing:

• Short Click - Launch Google Maps
• Long Click - Launch MyRadar
• Double Click - Launch GasBuddy
  
  

When on any screen EXCEPT the main screen:

• Short Click - Return to the main screen

When on the Google Maps screen:

• Long Click - Toggle Voice Navigation Guidance on or off

That seems like a pretty short list, but it represents all the things I'm likely to do while driving.  Of course, if I need to I can map a few other functions to the button, either by manipulating profiles (adding a triple click, for example) or by taking more contexts into account (such as a double click launching the navigation panel only when the Maps screen is showing).  I also have three other Flics that I could dedicate to controlling certain subsystems.

Time will tell what, if any, changes need to be made.

Physical Controls for the Digital Dash , Part 2

Well, it took a bit longer than I expected (about six months longer) but I finally got my Flic Bluetooth buttons.  And I like them; see my full review here: 
http://mikesgeneralblog.blogspot.com/2015/09/flic-bluetooth-button-review.html

I'm not quite sure what I'm going to do with all of them (I have five), but I have added one on the right-hand side of the center console in the Z3 as a music control.

I also thought about mirroring its functions to another button on the back of the steering wheel, but I've found that the car's cabin is small enough that I can reach the button while driving without even shifting position, so I've dropped that idea for the moment.

Here are the functions the button performs.

When the main screen is showing:

Short Click - Next (random) track when PowerAmp is the music source.  When Pandora is playing instead, Skip the current track.

Double Click - Replay the Previous Track (PowerAmp only; no function for Pandora).

Long Click - Display the Favorite Songs menu with a cursor used to highlight selections.

Triple Click - Toggles pause for the currently playing track.

When the Favorite Songs Menu is showing:

Short Click - Cause the music cursor to step down the list to the next entry.  If the bottom of the list is reached, the cursor wraps around back to the top of the list.

Long Click - Select the song under the cursor and have PowerAmp begin playing the track. This causes PowerAmp to display the album art for the song.  After about 5 seconds, the system returns to the main Digital Dash screen automatically.

Double Click - Cancels the Favorite Song menu and removes it from the screen without selecting any track.


If you read the first part of the physical controls documentation, you might recognize those functions as also being performed by the Bluetooth Gamepad that I've re-purposed into a sidearm controller.

In fact, I just reused the same code I wrote for that.  In order to make the Flic perform those functions, all I had to do was create the profiles that caught the various activations.  Once I had done that, I just linked to the existing tasks.  I don't think that it took me 10 minutes to get everything working.

We've taken a few drives and tried out the Flic and it has worked beautifully.  It's much easier (and safer) to click the button than it is to try hit the on-screen controls.

Navigation ETA Information Revisited

The display of ETA information that I talked about in my last entry about the Digital Dash project was (I thought) pretty neat, since it expanded on the philosophy of bringing as much useful information to one screen as possible.  It was also, unfortunately, very short-lived.

I got to use the feature on exactly one trip.  Then, after we returned home, I made the mistake of upgrading my tablet to Lollipop.  I figured it had been out awhile and had had a couple of point releases, so it was probably safe.  Wrong.

In the first place, it completely messed up my GPS.  After upgrading it took more than five minutes to get a lock, and even when it did, it had an error of up to 900 feet and would drop out every couple of minutes.  I was on the verge of flashing back to KitKat when I saw a post where someone mentioned the "GPS Status Test & Fix - No Ads" app as a possible solution.  Fortunately, installing it did the trick and my GPS is working normally again.  At the same time, the original "GPS Status" app that I was using wasn't working at all, so I've uninstalled that one.

The other thing that Lollipop broke was Google Maps notifications.  Well, maybe not broke, exactly, but it did change things to the point where AutoNotification can't return the ETA data any more.  The information is still there, and AN can actually respond to it, but it can't report it back to Tasker as a variable.  I've reached out to the AN developer and he's investigating, but I haven't heard anything back from him yet.

There's no guarantee, of course, that he'll be able to fix it or that it won't break again, so rather than waiting, I decided to see if there was any other way to get the information I wanted.

Turns out, there is.

I originally started out looking to see if there was an intent that I could call or monitor for this information.  I didn't find one, but I did find plenty of discussions from developers wanting to create different types of navigation apps, particularly for geocaching.  It seemed like they were always directed to check out something called the "Google Maps DistanceMatrix API".

A little more research turned up that this was a web-based service that can be called via a simple HTTP Get command.  You simply create a query string with a starting point, a destination point, and few settings and ship it off to the server.  You get back a data block (either xml or json) that contains, among other things, the distance to the target and the estimated travel time.  Just what I needed.

I played around with it a bit and came up with the code I needed.  I added a couple of lines to my V3_Compass routine to save the current latitude and longitude, added one line to the V3_StartNavigation task that saved my chosen destination to a new global variable, and added one more line to the V3_TimeAndTorque task to call my new routine so that it gets executed about every 30 seconds.

Here's that new task: 

APIQuery (113)
A1: Variable Set [ Name:%dayhalf To:AM Do Maths:Off Append:Off ] 

We start off by assuming that we will be arriving at our destination during the morning hours.  Later, we'll test this assumption and modify this variable if necessary.

A2: Variable Set [ Name:%uri To:/maps/api/distancematrix/xml?origins=%V3_Lat+%V3_Long&destinations=%V3_CurrentDestination&mode=driving&units=imperial&key=My Google Key Do Maths:Off Append:Off ] 
A3: HTTP Get [ Server:Port:https://maps.googleapis.com Path:%uri Attributes: Cookies: User Agent: Timeout:10 Mime Type: Output File: None Trust Any Certificate:Off Continue Task After Error:On ] 

This is the heart of the routine.  We use variables from other parts of the system to construct a properly-formatted query string and ship it off to the Google Maps DistanceMatrix API.  Although anyone can call the non-secure version of the API, I signed up for a free Google Developer Account and obtained a Key so that I could use a secure connection and be able to monitor performance.  This query will return a consistently formatted block of xml data containing the information I need and put it in Tasker's built-in %HTTPD variable.  Much of the rest of this task is devoted to extracting the relevant pieces.

A4: Variable Split [ Name:%HTTPD Splitter:text> Delete Base:Off ] 
A5: Variable Split [ Name:%HTTPD2 Splitter:< Delete Base:Off ] 
A6: Variable Set [ Name:%timeleft To:%HTTPD21 Do Maths:Off Append:Off ] 
A7: Variable Search Replace [ Variable:%timeleft Search:hours Ignore Case:Off Multi-Line:Off One Match Only:Off Store Matches In: Replace Matches:On Replace With:hr ] 
A8: Variable Search Replace [ Variable:%timeleft Search:mins Ignore Case:Off Multi-Line:Off One Match Only:Off Store Matches In: Replace Matches:On Replace With:min ] 

The first thing I obtain is the travel time remaining.  It's almost in the format I want, but to shorten it up a bit for display, I replace "hours" with "hr" and "mins" with "min".

A9: Variable Split [ Name:%HTTPD4 Splitter:< Delete Base:Off ] 
A10: Variable Set [ Name:%distance To:%HTTPD41 Do Maths:Off Append:Off ] 

The next piece is the distance to the destination.  This is already formatted as I want, so I just have to split it out.

A11: Variable Split [ Name:%HTTPD1 Splitter:value> Delete Base:Off ] 
A12: Variable Split [ Name:%HTTPD12 Splitter:< Delete Base:Off ] 
A13: Variable Set [ Name:%durationvalue To:%HTTPD121 Do Maths:Off Append:Off ] 

For the first two pieces of information above, I extracted the "text" versions.  That is, the information as presented in a human-readable format.  However, the xml contains "values" for this information as well: the distance is also sent as meters, and the travel time is also sent in seconds.  Because the API does not return an ETA, I need to calculate it myself, and it's easier to do by manipulating a single block of seconds rather than individual hours and minutes.  Accordingly, I grab the travel time value to use in that calculation.  

A14: Variable Split [ Name:%TIME Splitter:. Delete Base:Off ] 

This line grabs the system time from Tasker's built-in variable (which is in 24-hour format) and splits it into separate hours and minutes variables.

A15: Variable Set [ Name:%eta To:((%TIME1*3600)+(%TIME2*60))+%durationvalue Do Maths:On Append:Off ]

The line above converts the hours and minutes into a single variable that represents the seconds since midnight.  It then adds the number of seconds left to travel to that value.  The result is the ETA expressed in seconds.

A16: Variable Set [ Name:%hours To:floor(%eta/3600) Do Maths:On Append:Off ] 
A17: Variable Set [ Name:%minutes To:floor(((%eta/3600)-%hours)*60+.5) Do Maths:On Append:Off ] 

The above two lines simply convert the seconds back into hours and minutes.

A18: Variable Set [ Name:%dayhalf To:PM Do Maths:Off Append:Off ] If [ %hours > 11 & %hours < 24 ]

Now it's time to revisit that %dayhalf variable.  If %hours is greater than 11, then we will be arriving at our destination in the afternoon and need to set %dayhalf to "PM"; unless %hours is also greater than 23.  In that case, we will be arriving sometime after midnight of the next day, which is morning again so we leave %dayhalf alone.

A19: Variable Subtract [ Name:%hours Value:12 Wrap Around:0 ] If [ %hours > 12 ]
A20: Variable Subtract [ Name:%hours Value:12 Wrap Around:0 ] If [ %hours > 12 ]

I prefer the 12-hour time format, so these two lines take care of converting 24-hour time back to what I want.  The same action is used twice just in case our trip will take us past midnight.

A21: Variable Set [ Name:%V3_ETA To:%timeleft (%distance)ETA: %hours:%minutes %dayhalf Do Maths:Off Append:Off ] 

The final step is to take all the information we've derived and put it into a variable which is linked to a text box display on the main screen.

Once again, here's what that looks like:

To test this, we took the Z3 out for a little drive this weekend.  We drove over a neighboring town and when we got ready to come back, I called up my navigation panel and chose "Home" as the destination.  In about 15 seconds, the ETA display showed up on the main screen and began tracking the trip.  I watched it pretty closely and it seemed to work perfectly.  The ETA that it showed turned out to be exactly right and it counted down time and distance very accurately.

Later, I logged on to my Google Developer account and checked the stats for usage on the Distance Matrix API.  It showed 44 calls, which was exactly correct for the 22 minute trip, and every call was successful.  I also checked my cellular data usage and showed that my Bluetooth tethering app went through just under 8Mb for the day.  I have no way of knowing just how much of that was for Distance Matrix calls, but even it accounted for all of it, I'm no danger of running over my 10GB monthly allowance even if I use navigation heavily.

Update:  I tried this again today.(The weather here has been beautiful this weekend.)  Same idea, but this time it was a longer test.  On a 49-minute trip, I can see that the system handled 98 successful events and the info tracked perfectly.  My phone showed data usage of about 5MB, so it is using even less than I had previously thought.  It looks like I could run this system 24 hours per day all month and not even use half of my monthly data allowance.

A New Digital Dash Feature

It's been a long time since I've really added a new feature to the system.  Most things I've done over the last year have been tweaks and enhancements.  But just in time for our unofficial-end-of-summer road trip last weekend I did add something new.

I had seen a tutorial showing how to use AutoInput and AutoVoice to create a system that could grab the ETA information from Google Maps and send it as a text message to someone to let them know when you would be arriving.  It looked pretty good, but, A) I really don't ever need to do that, and B) I know for a fact that voice commands are ...ineffective in a convertible with the top down cruising along at 70 with the stereo blasting.

If you're one of the 22 people who have read the first installment of this adventure "Adding Tech to a Z3 Using an Android Phone", you might remember that I ended that by saying that I really wanted a fully voice controlled interface.  Well, I actually did have that at one point.  I spent a good deal of time during the first few months of 2014 building it.  I used AutoVoice in continuous mode on my phone to create an always-listening system that could capture and interpret voice commands and send them off as AutoRemote messages to the tablet to be executed.  It was really pretty full-featured and could switch apps, start navigation, control music, search for and play specific songs, and so on.  All in all, it recognized about 30 different commands.  And it worked perfectly...in my home office, where I created it.

In the car, however, it was another matter.  The first warm spring day that I could get the car out, I backed into the driveway, fired up the system, and began testing.  Even with a good Bluetooth headset and the car not even moving, my commands were recognized about one out of every ten times when the stereo was on, even when I was speaking quite loudly.

There's a nice elderly lady in our neighborhood who still brings me cookies once in a while because she feels sorry for me.  She had seen me sitting in the car yelling "Torque!", "Maps!", "Torque!", "Damn it!", and became convinced that I have Tourette Syndrome.  Needless to say, I abandoned voice control in favor of what I'm using now.

Anyway, although I didn't take away anything directly from that tutorial, it got me wondering if there was some other way to catch and use the ETA information. Turns out, there is.

In addition to displaying that info on its own screen, Maps also creates a notification that contains essentially the same thing.  By using AutoNotification I'm able to capture it, massage it into a more compact format, and display it on the main screen.  Like this:

Even though this might not seem like that big of a deal, it's very useful for me since 90% of the time when I flip over to the Maps app, it's to see this information.

You see, I live in one of the fly-over states and most of my road trips include directions like: "...Continue straight for 87 miles, then turn right and continue straight for 64 miles...". I don't really need to check those directions very often.  About the only time I actually use the turn-by-turn information is when I'm skirting the edge of a city.  (Defined as any place with a population of more than 5000.)

So having this on-screen all the time keeps me from switching apps as often, which is safer and doesn't annoy my wife as much.

I'm not necessarily thrilled with how it looks at the moment.  It seems a bit crowded and messy, but I think if I were to have it switch places with the connection icons, it would look better.

Something to do this winter while I'm eating cookies.

More Tweaks and Tuning

Before and after our last roadtrip, I made a few changes to the Digital Dash system.  Nothing major, but I did address a few long-standing issues that have proven to be worth the effort to correct.

The first has to do with the Destinations panel.  If you've read some the previous entries, you know this is a pop-up panel that holds five preset destinations; all I have to do is pick one and the system starts navigating to it.

Normally it has an entry for Home, three places that we visit fairly often, and a slot for an ad hoc destination that's just called "Current".  Usually, I just edit the address for that last entry and don't bother changing the on-screen name.

However, for our last trip I needed to change everything except for the Home designation since we were going to be visiting several places in an unfamiliar area.  Changing the addresses was easy; all I needed to do was change the entry list in the "%V3_Destinations" variable.  However, to get the right names on the screen, I was going to have to manually edit the pop-up scene.  I wasn't too wild about doing that because I was just going to have to change it back after the trip and there's always the chance that I'd end up slightly moving the position of one of the elements.  And since the process that chooses the navigation destination relies on precise screen positioning, a small change would stop it from working.

So instead, I made a new variable in the Startup task: "%V3_DestinationNames" and turned it into an array.  It, of course, holds the onscreen names that I want to have displayed.  I also added a small loop in the Startup task that reads that array and uses Tasker's "Element Text" to change the names in the scene.  That way there's no risk of accidentally moving something and it makes future changes much easier to do.

I actually have two copies of both "%V3_Destinations" and "%V3_DestinationNames" in the Startup Task.  One holds my normal, default values and the other can be used for future trips.  I just disable the pair that I'm not using.

The second thing I did was go through and re-balance all the task priorities.  I admit I hadn't paid much attention to this before, even though I should have.  Before I did this, I would get occasions where the interface would be slow to respond; I'd hit the Next Track button and nothing would happen, so I'd hit it again and all of sudden it would jump two tracks.  Or it would take several seconds to pause the music.

To fix that, I went into every profile that dealt with user interaction and bumped the launched task priority up to around 40.  I also tweaked other tasks while I was at it, and the result is that the system is now very responsive to user input and there's never any confusion about whether the screen (or Bluetooth controller) tap has registered.

The last thing I did on the tablet was to fix an annoyance that has been around for quite some  time.  Every once in awhile the overlay scenes on Torque would "blink"; disappearing for a second before they would pop back on.  When this first started happening, long ago, I did a little investigation, but somehow came to the conclusion that it was something inherent in either Tasker or the Android OS.  After all, I was displaying four overlays, each with many elements and possible interactions and I figured I was just pushing the limits of the systems and it was something that I would have to live with.  And since was an annoyance rather than an actual problem, I just let it go.

But when I began to look at it a little deeper, I realized that it was actually my profile and task that was removing the displays.  I still don't really know why this is happening; the profile is triggered by Torque being in the foreground and none of my code is changing that condition when the problem manifests itself.  For some reason, Torque just loses focus for a fraction of a second from time to time, which was triggering the profile's exit task and removing the display, only to put it right back on again.

Fortunately, the fix was pretty simple.  I modified the exit task for the profile to start with a one-second Wait.  After that, it checks Tasker's built-in %PACTIVE variable to see if the profile is active.  If it is, the exit task is stopped.  This de-bouncing code is enough to stop the problem.  Since I put it in, the display has been rock-solid.

The final change I made was on the phone, rather than the tablet.  Again, if you read some of the earlier posts, you'll know that every couple of minutes the phone is supposed to read the temperature from its sensor and send it to the tablet via an AutoRemote message for display on the main screen.

The problem is that this has never worked quite right.  Messages wouldn't get sent consistently, or they'd get sent but never arrive, or a bunch of them would show up at once.  I ran lots of tests and tried lots of things, but I could never quite figure out the problem.

As it turns out, there were two issues:  One was that AutoRemote normally sends its messages through the web via Google.  That service seems to be a bit buggy and unreliable, causing lost and delayed messages.  The fix was to switch to using AutoRemote's Direct Messaging option.  Now, messages go from the phone to the tablet...uh, directly...using the Bluetooth tether between the two devices.

 That took care of messages the were sent but not received, but the system on the phone still wasn't sending messages consistently.  This time, the problem was of my own making.

When I decided to mount the phone in the car as well as the tablet, I did so because I wanted to have Waze constantly running and visible because I like its road hazard reporting.  However, I don't like its on-screen speedometer; it just too small to be useful.  So, I reused some code that I had originally developed to put a speedometer on Google Maps, without really paying much attention.

I had used a simple task that grabbed Tasker's %LOCSPD variable, converted it from meters-per-second to miles-per-hour and fed that to an onscreen variable.  The task would then wait before looping back and repeating.  The problem was that it was "waiting" exactly one millisecond.  My speed was being reported with great granularity, but that loop was blocking the low-level task I had set up to send the temperature messages.

Rather than rewrite this routine to use AutoLocation, I simply modified it by adding the temperature sending code to the loop.  Now, it has a loop counter that is incremented every time the speed is updated and after so many times, will send the temperature and reset the counter so it can start incrementing again.  I also changed the wait to 250 milliseconds, which is much more reasonable.  The result is that I now get consistent temperature updates about once per minute on the tablet.  It finally works the way I wanted.

None of these changes were very big, but they have made the system more stable, responsive, and user-friendly.

Physical Controls for the Digital Dash

I know, of course, that it's somewhat dangerous (not to mention illegal in many places) to operate a touch screen device while driving.  That's why I've wanted to add physical controls to my system for quite a while.  In fact, the latest version of the system was built with that in mind, with a structure that was prepped for it.

I had initially become pretty excited about the Flic Bluetooth button when I heard about it last year on the Tasker Google Group.  I backed their project on Indiegogo and ended up ordering five of them.  I've become a bit disillusioned, though.  They were supposed to deliver in March, and it's now August and I still don't have them.

I had intended, originally, to mount four in the car: two on the center console for the passenger, and two on the back of the steering wheel (that mirrored the console buttons) for the driver.  I figured that with two buttons, I could control just about everything in my system.  I may still mount one on the console for passenger music control, but I've found something better for complete driver control.

This is a "Compact Bluetooth Gamepad" that I bought from GearBest.  It only costs about $7, has a rechargeable  battery, and incorporates nine buttons (including a four-way joystick) that send standard Android keycodes to your device.  And with Tasker and the AutoInput plugin, I can intercept those codes and make them do anything I want.  And what I want is to control the digital dash system...completely.

Here are the keycodes it sends in it's default mode.  There are at least two other modes that change the mapping, but I haven't messed with those.

I've remapped all the buttons except for the Play/Pause control; that one I use as is.  In addition, each of the joystick buttons uses two linked Tasker profiles to allow it to recognize two different types of activation: a short click, or a longer, held one. (I could do that with the buttons as well, but haven't needed to...yet.)

This picture shows how I've got it mounted in the car.  An inverted "U-shaped" piece of plastic with a couple of self-adhesive rubber feet to hold it in place and a couple of Velcro dots to hold the controller to it.  It gives me a very nice little sidearm controller that's easy to reach and use.  In the descriptions that follow, "up" is toward the front of the car.

Here's a list of functions that each button can perform, broken down by screen:

On the Main Screen

Joystick Up Click - Launch Google Maps
Joystick Up Held - Show the list of pre-programmed destinations
Joystick Down Click - Launch the MyRadar weather app
Joystick Down Held - Launch the Weather Channel app
Joystick Left Click - Replay previous song
Joystick Left Held - Show the list of favorite songs
Joystick Right Click - Skip to the next (random) song
Joystick Right Held - Launch PowerAmp if the music source variable is currently set to "Local".  If it's set to "Net", launch Pandora, instead
Volume Down Click - Launch Pandora and start playing my pre-existing 60's music station
Volume Up Click - Launch Pandora and start playing a mix of my pre-existing stations.
Back Key Click - Launch Pandora and start playing my pre-existing 70's Rock station
Enter Key Click - Launch GasBuddy

On Google Maps

Joystick Up Click - Return to Main Screen
Joystick Up Held - Toggle Voice Navigation on and off (uses AutoInput to press on-screen controls)
Joystick Down Click - Download A-GPS data using the GPSStatus app. (uses AutoInput to press on-screen controls.  Automatically returns to the main screen.)

On Radar or Weather Apps

Joystick Click Down - Return to Main Screen

On GasBuddy

Enter Key Click - Return to Main Screen

When the Destinations List is Showing

Joystick Down Click - Step the cursor down to highlight the next destination in the list.  If you try to step below the last one, it wraps around back to the top of the list.

Joystick Up Click - Step the cursor up to highlight the previous destination in the list.  If you try to step above the first one, it wraps around back to the bottom of the list.

Joystick Left Click - Cancel destination selection and remove the on-screen list

Joystick Right Click - Select a destination and send it to Google Maps.  Navigation starts automatically.

When the Favorite Songs List is Showing

Joystick Down Click - Step the cursor down to highlight the next song in the list.  If you try to step below the last one, it wraps around back to the top of the list.

Joystick Up Click - Step the cursor up to highlight the previous song in the list.  If you try to step above the first one, it wraps around back to the bottom of the list.

Joystick Left Click - Cancel song selection and remove the on-screen list

Joystick Right Click - Select a song and send it as a search to PowerAmp.  The song will start playing and then the system returns automatically to the main screen.

The Play/Pause key executes the Play/Pause function regardless of what screen is showing.

It seems a bit complicated when you're just reading through the list, but the operation is really pretty intuitive (at least to me.)  That's the beauty of designing your own system; you can have something that makes perfect sense to you, even if others don't see it the same way.

If you've read some of my previous entries, you might notice that there are a few functions that aren't accounted for.  They're used so rarely that I didn't feel it was necessary to add those in, but if I get bored, or ambitious I might do it anyway.  The missing functions are: launch ScannerRadio, set the PowerAmp EQ, toggle Auto-Brightness, and launch the fireplace app.

 I just got back from a long weekend mini-vacation where we put about 700 miles on the car and the system worked very well.  So far, I'm very pleased with how this part of the project has turned out.

Digital Dash Documentation, Part 9: Reading Time and Torque Data

This is a bit of a "rogue" task.  Where the other tasks in the system are triggered by some sort of external stimuli (e.g. a button is tapped, a new song comes on, app focus changes) this one is kicked off by the startup sequence, goes off into its own little world, and is killed when the system shuts down.  It spends most of its time sleeping, only to wake up every 25 seconds or so to see what's going on.  Its purpose is to update the time display on the main screen and let me know when it's time to start thinking about getting gas.


V3_TimeAndTorque (336)
A1: Variable Set [ Name:%mytime To:%TIME Do Maths:Off Append:Off ] 
A2: Variable Split [ Name:%mytime Splitter:. Delete Base:Off ] 
A3: Variable Set [ Name:%mytime1 To:%mytime1-12 Do Maths:On Append:Off ] If [ %mytime1 > 12 ]
A4: Variable Set [ Name:%mytime To:%mytime1:%mytime2 Do Maths:Off Append:Off ] 
A5: Variable Set [ Name:%V3_DispTime To:%mytime Do Maths:Off Append:Off ] 

It would have been much easier to just link Tasker's built in %TIME variable to an on-screen display but, unfortunately, it only reports out in 24-hour time; and I wanted a 12-hour display, so I need to manipulate the data a bit.  

It's pretty straight forward: The %TIME variable is copied into a local variable (%mytime) and split into variables holding the hour (%mytime1) and the minutes (%mytime2).  We then subtract 12 from the hour, but only if it's greater than 12.  So, for example, 10 is left alone but 15 has 12 subtracted from it to yield 3.

We then concatenate the hours, a ":", and the minutes back into the %mytime variable and set the global variable %DispTime equal to it.  %DispTime, of course, is the source for a text element on the main display.

The Z3's analog gas gauge has the disturbing habit of going along saying, "Yup, Everything's fine; plenty of gas.  No problem here, Chief.  We can go a long way yet".  Until it gets down to about a third of a tank.  Then it starts sucking it down like a thirsty drunk on Dollar Pitcher Night.  That's one reason there are three displays dealing with gas mileage on the main screen.  The following part of the task is designed to wake me up if I'm not paying attention and let me know that it's time to start looking for some 91-octane go-juice.

A6: Run Shell [ Command:/data/data/burrows.apps.busybox/app_busybox/tail -1 /storage/emulated/0/torqueLogs/trackLog.csv Timeout (Seconds):0 Use Root:Off Store Output In:%obd_log Store Errors In: Store Result In: Continue Task After Error:On ] 

Every five seconds Torque adds a new line to its log file with several pieces of information, including the "Estimated Distance To Empty" (EDE) that it calculates using the current MPG and the vehicle profile I set up.  Since I only want to know the latest information, I use the "tail" command, which simply reads in the last line of the file (tracklog.csv) and stores it in a local variable (%obd_log).

A7: Variable Split [ Name:%obd_log Splitter:, Delete Base:Off ] 

I then split the base variable so that I can access the one piece of data that I really want.

A8: Test Element [ Scene Name:V3_LH Element:LowFuel Test:Element Visibility Store Result In:%lowdistanceindicator Continue Task After Error:On ] 

The line above tests the LowFuel element on the V3_LH scene to see if it is visible or not and stores the result in %lowdistanceindicator.

A9: If [ %obd_log6 < 60 & %lowdistanceindicator ~ false ]

The next thing we do is test to see if the indicator is still invisible and the EDE (stored in the 6th position of the data array) has fallen below my set point; in this case, 60 miles.

A10: Element Visibility [ Scene Name:V3_LH Element Match:LowFuel Set:True Animation Time (MS):0 ] 

If both of those conditions are true, we make the LowFuel element (a translucent red square) be visible over the Distance To Empty element on the screen.

A11: Say [ Text:Warning. Range limit is under sixty miles. Engine:Voice:default:default Stream:3 Pitch:5 Speed:4 Respect Audio Focus:On Network:Off Continue Task Immediately:Off Continue Task After Error:On ] 
A12: End If 

We also give a verbal warning before ending the test started back in line 9.  The reason for doing it this way is that I want a verbal warning when low range point is first reached, but after that I only want the indicator to stay lit.  Once the conditions in the test have been met for the first time, the second part of the test will fail since the indicator is already on; so no repeated verbal warnings.  If I just tested the EDE, the system would be yelling at me about every 30 seconds.

A13: If [ %obd_log6 > 60 & %lowdistanceindicator ~ true ]
A14: Element Visibility [ Scene Name:V3_LH Element Match:LowFuel Set:False Animation Time (MS):0 ] 
A15: End If 

This routine clears the visual indicator when the EDE rises above 60 again.  That is, when I fill up and tell Torque that I have plenty of gas again.

A16: Wait [ MS:0 Seconds:25 Minutes:0 Hours:0 Days:0 ] 
A17: Goto [ Type:Action Number Number:1 Label: ] 

The task finishes by going back to sleep again.  When it wakes up, it starts all over at line one.  Doing it this way means that the clock isn't accurate to the second, but it's close enough for what I want.

Digital Dash Documentation, Part 8: Torque Overlay Handling

This is the last profile (at least on the tablet) that I need to describe.  This one simply handles showing the four main overlay scenes when Torque is in the foreground, and removing them when it loses focus.

Profile: V3_TorqueOverlay (342)
Application: Torque
State: Variable Value [ %V3_DrivingMode Set ]
Enter: V3_ShowMainOverlay (340)

A very simple profile.  Whenever we are in the system (i.e. %V3_DrivingMode is SET) and Torque comes to the foreground, we show the four overlay screens.  When Torque loses focus (i.e. we switch to another app) the scenes are hidden. 

A1: Show Scene [ Name:V3_TopMain Display As:Overlay, Blocking Horizontal Position:100 Vertical Position:0 Animation:System Show Exit Button:Off Continue Task Immediately:On ]
A2: Show Scene [ Name:V3_LH Display As:Overlay, Blocking Horizontal Position:4 Vertical Position:196 Animation:System Show Exit Button:Off Continue Task Immediately:On ]
A3: Show Scene [ Name:V3_Bottom Display As:Overlay, Blocking Horizontal Position:100 Vertical Position:200 Animation:System Show Exit Button:Off Continue Task Immediately:On ]
A4: Show Scene [ Name:V3_RH Display As:Overlay, Blocking Horizontal Position:200 Vertical Position:200 Animation:System Show Exit Button:Off Continue Task Immediately:On ]

The entry task just shows the previously created scenes.  All of them are blocking overlays because they all contain elements that the user can interact with.

Exit: V3_HideMainOverlay (341)
A1: Hide Scene [ Name:V3_TopMain Animation:None Continue Task After Error:On ]
A2: Hide Scene [ Name:V3_TopSources Animation:None Continue Task After Error:On ]
A3: Hide Scene [ Name:V3_TopEQ Animation:None Continue Task After Error:On ]
A4: Hide Scene [ Name:V3_CancelOverlays Animation:None Continue Task After Error:On ]
A5: Hide Scene [ Name:V3_LH Animation:None Continue Task After Error:On ]
A6: Hide Scene [ Name:V3_Bottom Animation:None Continue Task After Error:On ]
A7: Hide Scene [ Name:V3_FavoriteSongs Animation:None Continue Task After Error:On ]
A8: Hide Scene [ Name:V3_Destinations Animation:None Continue Task After Error:On ]
A9: Hide Scene [ Name:V3_RH Animation:None Continue Task After Error:On ] 

For the exit task, I took what my father would call the "brute force and awkwardness" approach.  That is, I don't check to see what scenes might be showing and selectively hide them; instead, I just hide any scene that could possibly be showing.  The "Continue Task After Error" lets that happen.

Digital Dash Documentation, Part 7: Incoming Phone Commands

When the digital dash system starts up, it makes a Bluetooth tethering connection to my phone.  There is a Tasker profile on the phone that listens for this connection to be made, and when it sees it, it runs a startup task of its own.  The details of that will be covered in a later part of the documentation, but the only thing we're interested in now is the fact that part of that sequence launches a low-priority looping task that repeats about every three minutes.

What that task does is to read the current ambient temperature from the phone's sensor (via Tasker's built-in %TEMP variable) convert it to Fahrenheit, append the degree symbol, and send it off to the tablet via an AutoRemote message.


Profile: V3_IncomingCommands (368)
State: AutoRemote [ Configuration:All Messages ]
State: Variable Value [ %V3_DrivingMode Set ]
Enter: V3_HandlePhoneCommands (369)

This profile, running on the tablet, simply listens for any incoming AutoRemote message.  When it sees one, it fires off it's entry task.  Since I'm really only sending one message, I'm not making use of any of AutoRemote's filtering capabilities; I just look for any message and let the entry task figure out what to do with it.

A1: Variable Set [ Name:%V3_CurrentTemp To:%arpar() Do Maths:Off Append:Off ] If [ %arcomm ~ Temp ]

When it comes in, the AutoRemote message looks like this: "the temperature"=:=Temp (Where "the temperature" is the current ambient temperature, including the degree symbol.)  In AutoRemote terms, anything to the left of the =:=  is called the parameter(s) and is contained in the %arpar() local variable.  LIkewise, anything to the right of the symbol string is called the command and is found in the %arcomm local variable.  All this task does is check to make sure that this is a "TEMP" command and, if it is, sets the %V3_CurrentTemp global variable equal to the parameter payload.  %V3_CurrentTemp is used as the source for the temperature text element on the V3_RH scene shown on the main display. 

Although I'm only sending one type of message at this time, the system is easily expandable if I want to add additional types.

Digital Dash Documentation, Part 6: Compass

A very simple profile and task this time.  This is the routine that updates the compass on the main display and the compass and speed on the Google Maps overlay.


Profile: V3_Compass (326)
State: AutoLocation Location [ Configuration:Location Report Name: V3_Compass ]
State: Variable Value [ %V3_DrivingMode Set ]
Enter: V3_Compass (327)

Back in the system startup task, we initialized an AutoLocation routine that began tracking GPS data and gave it the instance name of "V3_Compass".  This profile watches for any updates in the data from that instance and fires off its entry task when something changes.

A1: Variable Set [ Name:%index To:((floor((%albearing+11.25)/22.5))%16+16)%16+1 Do Maths:On Append:Off ] 

The above line converts the bearing information into an index variable in the range of 1 to 16 with 1 representing North and 16 being all the way around the compass ring at NNW.

A2: Variable Set [ Name:%V3_Heading To:%V3_Compass(%index) Do Maths:Off Append:Off ] 

This line just applies the index of the %V3_Compass array that holds the list of possible directions and sets the %V3_Heading value with it.  That variable is used as the source for a text element on both the V3_RH and V3_MapSpeedometer scenes.

A3: Variable Set [ Name:%V3_Sprnd To:round((%alspeed*2.236936290544)*10)/10 Do Maths:On Append:Off ] 

This line converts the speed returned by AutoLocation into miles per hour (rounded to the nearest tenth) and sets %V3_Sprnd equal to it.  That variable is used as a source on the V3_MapSpeedomter screen.  The primary speed display on the main screen does not use this value since Torque is able to read GPS data on its own and put it into a gauge display.

Digital Dash - Some Visual Changes

Among the many things that I'm not, one is a graphic designer.  But even I can tell when something needs a bit of improvement.  When I first started this project I was more concerned about functionality than appearance, and even when I tried to take a stab at that, the results were...adequate (at best).

So, I've made a few changes that, I think, improve the look of the system.  You can see the results, below.  But even if these aren't dramatic improvements, they have the happy coincidence of reducing the number of external graphics used.  Now, there are only four:  the display background used for the readouts on the right side of the screen, the low mileage indicator (which is really just a red-tinted version of the display background), and the two vehicle logos.  Everything else has been replaced with native Tasker elements.  If I get ambitious (or bored) I may try to cut that down even further.

The screenshots, below, show the system connected to the Jag, with the snarling cat logo, which I haven't shown before.

This is the main screen.  The connection indicators, which had formerly been non-descript yellow dots, have been replaced with standard icons that better represent what each connection does.  I also made the track and artist information white.  It had been yellow before, which I had hoped would add a little color to the screen, but just ended up hampering readability and looking a little out of place.

The audio sources sub-panel is now cleaner, with text buttons and simple bars dividing them.

Likewise, the EQ sub-panel has been been given a simplifying makeover.  The "PowerAmp EQ" on the left is just a label.  At this point I don't see a real need to be able access the full EQ settings from here, but if I change my mind it'll be easy to make it a live button and add another dividing bar to the left.

Not huge changes, but I think they're an improvement,  And certainly easier to manage.

Digital Dash Documentation, Part 5: Music Info

One of the functions the digital dash project is to provide an continual display of the currently playing music track and artist.  Since there are two possible sources for music (Pandora and PowerAmp) we need routines to extract that information from either app.

Profile: V3_GetPandoraInfo (281)
Event: AutoNotification Intercept [ Configuration:Event Behaviour: true
Notification Type: Only Created Notifications
Notification Apps: Pandora
Get All Fields : true ]
State: Variable Value [ %V3_DrivingMode Set ]
Enter: V3_PandoraInfo (347)

Whenever Pandora starts playing a new track, it adds a entry to the tablet's notification panel (after first destroying the previous one) that contains the name of the track and the artist.  I use AutoNotification to monitor for the creation of that entry.

A1: Variable Set [ Name:%V3_Track To:%antitle Do Maths:Off Append:Off ]
A2: Variable Set [ Name:%V3_Artist To:%antext Do Maths:Off Append:Off ]

The Pandora information comes into Tasker as the local variables %antitle, and %antext.  I simply copy those values to global variables that are used as the sources for text elements on the V3_TopMain scene.

Getting information from PowerAmp is a little more involved and uses an intent that PowerAmp fires off any time it starts playing a new track.

Profile: V3_GetPowerAmpInfo (345)
Event: Intent Received [ Action:com.maxmpz.audioplayer.TRACK_CHANGED Cat:None Cat:None Scheme:* Mime Type:* ]
State: Variable Value [ %V3_DrivingMode Set ]
Enter: V3_PowerAmpInfo (346)

The profile is configured to listen for this specific intent.

A1: Variable Split [ Name:%track Splitter:, Delete Base:Off ] 

The intent payload from PowerAmp contains 18 pieces of information concatenated into a comma-separated bundle that comes into Tasker as the local variable "%track".  For my application, most of that information isn't needed, but I still need to split the variable in order to get at the information I do want. 

A2: Variable Set [ Name:%artist To:%track1 Do Maths:Off Append:Off ] 

A3: Variable Split [ Name:%artist Splitter:= Delete Base:Off ] 

A4: Variable Set [ Name:%V3_Artist To:%artist2 Do Maths:Off Append:Off ] 

After the initial split, the array variable %track1 contains the bundle start designation as well as the first piece of information I want. For example, it might look like this: Bundle[{artist=Queen.  So, I copy that to a temporary local variable (%artist) and split that, this time using an = as the Splitter. What remains in %artist2 after the split is the artist name, in this case, Queen.  That then gets copied into the global variable %V3_Artist, which is referenced as a source for one of the elements in the V3_TopMain scene (to be described later).

A5: Variable Set [ Name:%song To:%track14 Do Maths:Off Append:Off ]
A6: Variable Split [ Name:%song Splitter:= Delete Base:Off ]
A7: Variable Set [ Name:%V3_Track To:%song2 Do Maths:Off Append:Off ] 

I perform a similar set of splits with the 14th entry in the %track variable array. This contains something like this: title=Bohemian Rhapsody.  I copy that to the local %song variable, split it with an = and copy the resulting %song2 value to %V3_Track, which is, again, linked to a text element on the main screen.

Digital Dash Documentation, Part 4: Tablet Power Status

This is a pair of very simple profiles that handle updating the main screen element that shows the tablet's current power status.  In addition to displaying the remaining battery percentage, it also shows whether or not the tablet is plugged in by underlining the battery value when it detects a external power connection

Profile: V3_TabletPluggedIn (337)
State: Power [ Source:Any ]
State: Variable Value [ %V3_DrivingMode Set ]
Enter: V3_ShowTabletCharging (338)

Pretty simple profile.  Just watches for any power source when the digital dash is active and runs its entry task.  When power is removed, it runs the exit task.

A1: Variable Set [ Name:%V3_BatteryDisplay To:%BATT% Do Maths:Off Append:Off ]

This single-line task uses Tasker's ability to display HTML in a text element to wrap the battery value in underline tags. I don't use Tasker's built-in %BATT value directly because I want to add the % at the end.

Exit: V3_ShowTabletNotCharging (339)

A1: Variable Set [ Name:%V3_BatteryDisplay To:%BATT% Do Maths:Off Append:Off ]

The exit task just removes the HTML tags.

There is a separate profile to track changes to the battery level.

Profile: V3_TrackBatteryLevel (356)
Event: Battery Changed

State: Variable Value [ %V3_DrivingMode Set ]

Enter: V3_UpateBatteryLevel (357)

Again, very simple.  When the battery level changes while the dash is running, this profile runs its entry task.  There is no exit task.

A1: Variable Set [ Name:%V3_BatteryDisplay To:%BATT% Do Maths:Off Append:Off ]
A2: Variable Set [ Name:%V3_BatteryDisplay To:%BATT% Do Maths:Off Append:Off ] If [ %PACTIVE ~R V3_TabletPluggedIn ]

The first line just updates the %V3_BatteryDisplay variable when the tablet is not externally powered.  The second line does the same thing, but it checks to see if the V3_TabletPluggedIn profile is currently active.  If it is, the the HTML underline tags are added to the display variable.