Some More On-Screen Information

I've added a couple more pieces of information to the on-screen display.  Nothing major, just some more things I like to be able to see at a glance without having to interact with the system.

When I first made the Digital Dash, I was using the WeatherAce plugin to query a server and return the nearest local environment temperature.  It worked fine, but when I decided to mount the phone as a secondary screen dedicated to running Waze, I realized that it would be exposed to approximately the same temperature environment as the people in the car would.  So, I set up a task on the phone that would send an AutoRemote message containing data from the phone's built-in temperature sensor over to the tablet about every 30 seconds.  This gave me hyper-localized data, and I figured that if I wanted the surrounding area temp, I could just pull up the Weather Channel app.

But the more I thought about it, the more I realized that I wanted to see both values at any time; essentially an interior and exterior temperature display.  This time, however, instead of using WeatherAce, I decided to just use AutoNotification to scrape the temperature from the Weather Channel's notification.

Because I didn't want to make another display element (that I didn't really have room for) I just stacked the two temperatures into a single variable and linked it to the existing display.  In the screenshot, below, the interior (phone temp) is on top and the environmental temp (from the Weather Channel notification) is on the bottom.  There was enough extra room in the element that I didn't even need to change the font size.

The other piece of data I'm now sending to the tablet is the phone's battery level, along with its charging status.

Since the phone is mounted on the driver's "wing" window, and I don't like stringing cables across the car from the utility port, I normally just plug it into my Anker battery pack, which rides in a door pocket right below the phone.  The only problem is that on more than one occasion I've forgotten to push the button on the pack that starts the charging process.  I thought the phone was plugged in and didn't realize I was draining the battery until the phone put up its low battery warning.

Now, however, I can see the battery level and charging status for both the phone and the tablet right on the main screen.  In the screenshot, above, the tablet is the top entry, and the phone is the bottom one.  This also shows that the phone is plugged in and charging because the data is underlined.  (The tablet entry has the same capability.)

To make this work, I set up two new profiles on the phone.  One is a Power ANY profile with both an entry and exit task, and the other is a Battery Changed profile, which only has an entry task.

Here's the Powered profile:

Profile: V3_PoweredCheck (240)

State: Power [ Source:Any ]
State: Variable Value [ %TabletConnected Set ]

Pretty simple.  The profile just watches for a change in charging status.  The secondary context keeps it from firing unless the Digital Dash system is actually running.  The %TabletConnected variable is set when the phone project runs its startup sequence after it receives a command to start Bluetooth tethering from the tablet.  It's the equivalent of the tablet's %V3_DrivingMode.

Enter: V3_Plugged (241)
A1: Variable Set [ Name:%V3_PowerState To:-1 Do Maths:On Append:Off ] 
A2: Perform Task [ Name:V3_SendBatt Priority:%priority Parameter 1 (%par1): Parameter 2 (%par2): Return Value Variable: Stop:Off ] 

Exit: V3_Unplugged (242)
A1: Variable Set [ Name:%V3_PowerState To:1 Do Maths:On Append:Off ] 
A2: Perform Task [ Name:V3_SendBatt Priority:%priority Parameter 1 (%par1): Parameter 2 (%par2): Return Value Variable: Stop:Off ] 

The entry and and exit tasks are nearly identical.  They both adjust the value of the %V3_PowerState variable and then call the task that actually sends the AutoRemote message to the tablet.

Because I actually need to send two pieces of information in each message, I use a little simple math to concatenate the data.  As you can see, the entry tasks sets the %V3_PoweredState to "-1", while the exit task sets it to just "1".  Before the data gets sent, I multiply this variable by Taskers built-in %BATT (which contains the actual battery charge level).  So, when the phone is plugged in, the data sent is a negative number, and when the phone isn't charging, it sends a positive number.

Over on the tablet, I make a check for these conditions and use the result to decide whether or not to wrap the battery value in html underline tags.

(This seems a bit convoluted, and in theory AutoRemote can send multiple pieces of data in a single message, but I was never able to get that to work.  The messages just stopped going out, with no error indications.  So I went with this scheme instead.)

Profile: V3_BattTracker (244)
Event: Battery Changed
State: Variable Value [ %TabletConnected Set ]

The battery tracking profile is just as simple.  Any time the battery level changes and the tablet is connected, it executes the task that sends the AutoRemote message.  That's the same task called by the charging/not charging profile.

Enter: V3_SendBatt (243)
A1: Variable Set [ Name:%mybatt To:%V3_PowerState*%BATT Do Maths:On Append:Off ] 
A2: Variable Set [ Name:%tempmessage To:https://autoremotejoaomgcd.appspot.com/sendmessage?key=(My AutoRemote Key)&message=%mybatt=:=Batt Do Maths:Off Append:Off ] 
A3: HTTP Post [ Server:Port:%tempmessage Path: Data / File: Cookies: User Agent: Timeout:10 Content Type: Output File: Trust Any Certificate:Off Continue Task After Error:On ] If [ %TabletConnected Set ]

The messaging task does the multiplication I mentioned above and prepares an AutoRemote message.  The preparation must be done in a separate Variable Set action because if you try to add variables directly to the HTTP Post step, they won't be interpreted and only the variable names themselves will be sent.

This task, like the one that sends the phone's temperature, uses AutoRemotes direct messaging option.  I prefer this, because it doesn't need an internet connection to function.

That's it.  Pretty minor modifications, but nice to have.

Navigation ETA Information Revisited - Revisited

I had hoped that my solution to the missing information in the Google Maps navigation notification would be a temporary one.  While it does work, it's definitely a kludge and I'm happy to be able to go back to gathering that content via AutoNotification.

Thanks to a user in one of the AutoApps forums, I learned that the ETA information is available in the variable %antextsbig4 under Lollipop. (Formerly it had just been in %antexts.)  With that knowledge I was able to re-do my profile and task and get them working again, so I thought I would post the solution here.


Profile: V3_ETAScrape (109)
Cooldown: 30
Event: AutoNotification Intercept [ Configuration:Event Behaviour: true
Persistency Type: Both
Notification Apps: Maps
Get All Fields : true ]
State: Variable Value [ %V3_DrivingMode Set ]

This is the profile itself.  It triggers when Google Maps puts up a notification AND the %V3_DrivingMode variable is set.  AutoNotification is set as the event handler and configured to look at both created and persistent notifications.  I've also set the flag so that AN will get all the fields in a notification.

The other thing to note is that there is a 30-second Cooldown set on the profile.  This keeps it from constantly firing as Maps updates the notification.  While it does reduce the granularity of the information somewhat, it keeps this profile from blocking other tasks and may make it a bit more stable.

When the profile fires, it gathers the information from the notification and populates a number of AN variables.  However, for this job we only need one of them: %antextsbig4.  It will contain data that looks something like this:

3.2 mi - Continue onto US 20

2 hr 52 min (165 mi) to destination
Estimated arrival at 2:39 PM

If I had enough room on my main screen, I could just display that info in a text box, but I really don't have that kind of real estate available to me, so I need to take it apart and shorten it up.

Enter: V3_NotificationQuery (102)
A1: Variable Set [ Name:%ret To:
Do Maths:Off Append:Off ] 

The first thing the entry task does is define the %ret variable.  Blogger doesn't show it, but the variable is filled simply by hitting the "Enter" key when you create the variable.  This is necessary because we need to split %antextsbig4 based on line returns and Tasker doesn't allow you to enter a return directly in the Variable Split action.

A2: Variable Split [ Name:%antextsbig4 Splitter:%ret Delete Base:Off ] 

As promised, we first use the %ret variable to split %antextsbig4 into its individual lines.  After the split, %antextsbig41 will contain the turn-by-turn info and %antextsbig42 will be a blank line.  I don't care about either of those, so they remain unused.

A3: Variable Split [ Name:%antextsbig43 Splitter:) Delete Base:Off ] 

%antextsbig43 contains the first line of the ETA information.  By splitting it with a parenthesis I can extract just the first part of the line and ignore the "to destination".

A4: Variable Split [ Name:%antextsbig44 Splitter:at Delete Base:Off ] 

Now I split %antextsbig44, which contains the second line of the ETA info. I use the word "at" as the splitter, which isolates the first part of the line,"Estimated arrival", and leaves me with just the arrival time. (Splitters never become part of a variable, so the "at" is gone as well.)

A5: Variable Set [ Name:%V3_ETA To:%antextsbig431)
ETA: %antextsbig443 Do Maths:Off Append:Off ] 

The last step is to populate the %V3_ETA variable, which serves as the source for my onscreen text display.  It's simply a matter of taking the parts of the lines I've split and concatenating them.  Note that I had to add the ) back in because it was used as the splitter in an earlier step and was, therefore, discarded out of the variable.


This is a pretty simple, but very useful addition to the Digital Dash project and I'm glad to have it working properly again.

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.