Thursday, October 29, 2015

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.


1 comment:

Cooking Charles said...

Hello mate great bllog