Merry FishMoose!
(See, because it's a fish bottle, with a moose candle... Never mind. Whatever you celebrate, enjoy the holidays.)
Tuesday, December 22, 2015
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:
When on the Google Maps screen:
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
- 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.
Wednesday, December 09, 2015
Schrödinger's Profile
How do you define when a Tasker profile is active?
One way, is to say it's active when all of its contexts are true. In practice, though, that can sometimes be difficult to monitor directly, so we tend to use another method. Commonly, we assume a profile is active when it runs its Entry task.
Normally, these two metrics align exactly and can be considered equivalent. However, there are some profiles where that's not true; where the contexts are active, but the Entry task hasn't been run.
Since, depending on which definition we use, the profile can be considered both active and inactive, we call these Schrödinger's profiles. (Yeah, okay. Fine. I'm the only one that calls them that, but I like it, and it's my blog.)
So what makes a profile behave like that, and what is it good for?
Creating a Schrödinger's profile is very easy; all you need to do is go into the profile properties and configure the Cooldown time. Cooldown is a little-used parameter in Tasker that keeps a profile from running it's entry task until the the Cooldown time has elapsed. If you set a Cooldown of 20 seconds, the profile can't activate any more often than that, even if all the explicit contexts for it are true.
One thing this type of profile is good for is ignoring some triggers, while allowing others of the same type to be acted on.
For example, in the Digital Dash project, I have a profile that watches for changes in the Google Maps navigation notification so that I can display ETA information on the main screen.
(As described here: http://mikesgeneralblog.blogspot.com/2015/10/navigation-eta-information-revisited.html.)
That notification can update many times a minute, particularly when there are a lot of navigation events happening close together, and when it starts counting down distance in tenths of a mile. I'm not displaying the navigation instructions at all, and I don't really need second-by-second updates, so I've added a 30-second Cooldown to the profile that monitors the notification. That way I still get data with the granularity I need, but don't waste a lot a system resources processing useless information; I get updates every 30 seconds even though the notification itself updates much more often than that.
The other thing you can do with a Schrödinger's profile is use it to replace a looping task.
I've never been conceptually happy with the Time and Torque task in the system. I've previously described it as a "rogue task" because it's the only one that isn't triggered directly by some action. (http://mikesgeneralblog.blogspot.com/2015/06/digital-dash-documentation-part-9.html) Instead, it gets kicked off by the Digital Dash startup task and simply loops about every 30 seconds until the system kills it via the shutdown task. And that's always bothered me. I'd prefer that it not run constantly in the background, and a profile with a Cooldown allows me trigger it to run regularly and on-demand without a loop.
Let's take a look at how to get that set up. Let's say that, for some ungodly reason, you want Tasker to beep at you every five seconds. We can make that happen.
The first thing to do is base a profile on a context that is always true. For example, set up a global variable and Set it to something; doesn't matter what it is. Then, you use a context of "Variable IS Set" in your profile.
Here's what that might look like (Assuming you've Set the %MyLoop variable elsewhere.)
Profile: Looper (468)
Cooldown: 5
State: Variable Value [ %MyLoop Set ]
Enter: Action (466)
A1: Beep [ Frequency:8000 Duration:1000 Amplitude:12 Stream:3 ]
Enter this into Tasker and back all the way out. After five seconds, you'll get a beep. And after another five seconds you'll get...nothing. And every five seconds after that, you'll get nothing. You get one beep, and that's it. Clearly, this isn't working.
That's because the Cooldown is really just a timer. It gets triggered when the profile becomes active and starts counting down. Once it reaches the end, the profile is allowed to run its Entry task. The problem is, Cooldown doesn't automatically reset itself. It only starts when the profile becomes active, and since, in the example above, the profile never becomes inactive, the Cooldown timer won't fire again.
So, we need to make the profile go inactive and then activate it again so the timer can restart itself.
We can easily add a line to the Entry task to accomplish the first part:
Profile: Looper (468)
Cooldown: 5
State: Variable Value [ %MyLoop Set ]
Enter: Action (466)
A1: Variable Clear [ Name:%MyLoop Pattern Matching:Off ]
A2: Beep [ Frequency:8000 Duration:1000 Amplitude:12 Stream:3 ]
By clearing the %MyLoop variable, we've made the profile go inactive because its context is no longer true. Of course, we're still not going to get repeating beeps, because all we've done at this point is turn off the profile. Now we need to activate it again. We can do that by adding an Exit task.
Profile: Looper (468)
Cooldown: 5
State: Variable Value [ %MyLoop Set ]
Enter: Action (466)
A1: Variable Clear [ Name:%MyLoop Pattern Matching:Off ]
A2: Beep [ Frequency:8000 Duration:1000 Amplitude:12 Stream:3 ]
Exit: Reaction (467)
A1: Variable Set [ Name:%MyLoop To:True Do Maths:Off Append:Off ]
So, what happens is, when the profile runs its Entry task (after the Cooldown period has expired) it gets turned off by line A1 in the Entry Task. This causes it to immediately run its Exit task, which resets the %MyLoop variable, making the context True again, and restarting the Cooldown period. Note that deactivating the profile does not stop the entry task from running to completion, so we get our beep. And every five seconds after that, we'll get another beep until we go into Tasker and either disable the profile with its On/Off switch or explicitly clear the %MyLoop variable on the Var panel.
This is the technique I used to convert the Time and Torque loop to a triggered task rather than a loop, and it's working quite well. I still get regular updates, but nothing is sitting in a Wait state. And I'm happier with that.
One way, is to say it's active when all of its contexts are true. In practice, though, that can sometimes be difficult to monitor directly, so we tend to use another method. Commonly, we assume a profile is active when it runs its Entry task.
Normally, these two metrics align exactly and can be considered equivalent. However, there are some profiles where that's not true; where the contexts are active, but the Entry task hasn't been run.
Since, depending on which definition we use, the profile can be considered both active and inactive, we call these Schrödinger's profiles. (Yeah, okay. Fine. I'm the only one that calls them that, but I like it, and it's my blog.)
So what makes a profile behave like that, and what is it good for?
Creating a Schrödinger's profile is very easy; all you need to do is go into the profile properties and configure the Cooldown time. Cooldown is a little-used parameter in Tasker that keeps a profile from running it's entry task until the the Cooldown time has elapsed. If you set a Cooldown of 20 seconds, the profile can't activate any more often than that, even if all the explicit contexts for it are true.
One thing this type of profile is good for is ignoring some triggers, while allowing others of the same type to be acted on.
For example, in the Digital Dash project, I have a profile that watches for changes in the Google Maps navigation notification so that I can display ETA information on the main screen.
(As described here: http://mikesgeneralblog.blogspot.com/2015/10/navigation-eta-information-revisited.html.)
That notification can update many times a minute, particularly when there are a lot of navigation events happening close together, and when it starts counting down distance in tenths of a mile. I'm not displaying the navigation instructions at all, and I don't really need second-by-second updates, so I've added a 30-second Cooldown to the profile that monitors the notification. That way I still get data with the granularity I need, but don't waste a lot a system resources processing useless information; I get updates every 30 seconds even though the notification itself updates much more often than that.
The other thing you can do with a Schrödinger's profile is use it to replace a looping task.
I've never been conceptually happy with the Time and Torque task in the system. I've previously described it as a "rogue task" because it's the only one that isn't triggered directly by some action. (http://mikesgeneralblog.blogspot.com/2015/06/digital-dash-documentation-part-9.html) Instead, it gets kicked off by the Digital Dash startup task and simply loops about every 30 seconds until the system kills it via the shutdown task. And that's always bothered me. I'd prefer that it not run constantly in the background, and a profile with a Cooldown allows me trigger it to run regularly and on-demand without a loop.
Let's take a look at how to get that set up. Let's say that, for some ungodly reason, you want Tasker to beep at you every five seconds. We can make that happen.
The first thing to do is base a profile on a context that is always true. For example, set up a global variable and Set it to something; doesn't matter what it is. Then, you use a context of "Variable IS Set" in your profile.
Here's what that might look like (Assuming you've Set the %MyLoop variable elsewhere.)
Profile: Looper (468)
Cooldown: 5
State: Variable Value [ %MyLoop Set ]
Enter: Action (466)
A1: Beep [ Frequency:8000 Duration:1000 Amplitude:12 Stream:3 ]
Enter this into Tasker and back all the way out. After five seconds, you'll get a beep. And after another five seconds you'll get...nothing. And every five seconds after that, you'll get nothing. You get one beep, and that's it. Clearly, this isn't working.
That's because the Cooldown is really just a timer. It gets triggered when the profile becomes active and starts counting down. Once it reaches the end, the profile is allowed to run its Entry task. The problem is, Cooldown doesn't automatically reset itself. It only starts when the profile becomes active, and since, in the example above, the profile never becomes inactive, the Cooldown timer won't fire again.
So, we need to make the profile go inactive and then activate it again so the timer can restart itself.
We can easily add a line to the Entry task to accomplish the first part:
Profile: Looper (468)
Cooldown: 5
State: Variable Value [ %MyLoop Set ]
Enter: Action (466)
A1: Variable Clear [ Name:%MyLoop Pattern Matching:Off ]
A2: Beep [ Frequency:8000 Duration:1000 Amplitude:12 Stream:3 ]
By clearing the %MyLoop variable, we've made the profile go inactive because its context is no longer true. Of course, we're still not going to get repeating beeps, because all we've done at this point is turn off the profile. Now we need to activate it again. We can do that by adding an Exit task.
Profile: Looper (468)
Cooldown: 5
State: Variable Value [ %MyLoop Set ]
Enter: Action (466)
A1: Variable Clear [ Name:%MyLoop Pattern Matching:Off ]
A2: Beep [ Frequency:8000 Duration:1000 Amplitude:12 Stream:3 ]
Exit: Reaction (467)
A1: Variable Set [ Name:%MyLoop To:True Do Maths:Off Append:Off ]
So, what happens is, when the profile runs its Entry task (after the Cooldown period has expired) it gets turned off by line A1 in the Entry Task. This causes it to immediately run its Exit task, which resets the %MyLoop variable, making the context True again, and restarting the Cooldown period. Note that deactivating the profile does not stop the entry task from running to completion, so we get our beep. And every five seconds after that, we'll get another beep until we go into Tasker and either disable the profile with its On/Off switch or explicitly clear the %MyLoop variable on the Var panel.
This is the technique I used to convert the Time and Torque loop to a triggered task rather than a loop, and it's working quite well. I still get regular updates, but nothing is sitting in a Wait state. And I'm happier with that.
Friday, November 20, 2015
Another Bluetooth Button Control Scheme
My post on adding button control to my Digital Dash project (http://mikesgeneralblog.blogspot.com/2015/08/physical-controls-for-digital-dash.html) has turned out to be one of the most popular ones that I've written. (Around here that only means about 550 views, but it's something.) It's been linked to in a couple of places and over on the AutoApps forum someone asked me if there was a way to make a button continually perform a task as long as it was held down. It turned out to be pretty easy, so here's an example that controls the Media Volume of a device.
I chose to use the "Media Rewind" keycode to lower the system's media volume because it made sense in the physical layout of the Bluetooth Gamepad I was using, but you can, of course, use any key you want. To make a companion way to increase the volume, just copy the profiles and tasks and rename them with "Up" instead of "Down" in the names and change the "-1" in line A1 of the first task to a "+1". You'll also need to modify the IF clause in line A3 so that it checks for a maximum value rather than a minimum.
Profile: Vo!umeDownStart (437)
Event: AutoInput Key [ Configuration:Keys: Media Rewind
Key Action: Key Down ]
Enter: VolDown (436)
A1: Media Volume [ Level:%VOLM-1 Display:Off Sound:Off ]
A2: Wait [ MS:250 Seconds:0 Minutes:0 Hours:0 Days:0 ]
A3: Goto [ Type:Action Number Number:1 Label: ] If [ %VOLM > 0 ]
Profile: VolumeDownStop (438)
Priority: 11
Event: AutoInput Key [ Configuration:Keys: Media Rewind
Key Action: Key Up ]
Enter: VolDownStop (439)
A1: Stop [ With Error:Off Task:VolDown ]
A couple of things to note: The first profile triggers on the Key Down event and the second one triggers on Key Up. Be sure you bump up the priority for launched tasks in the second profile; it needs to be greater than the the task it's trying to stop. You'll also need to run AutoInput's KeySupress function before you use these profiles and then disable key suppression when you're done. The 250 ms delay in line A2 seems to give a nice response ramp, but if you want something a little faster, just decrease that value. Finally, you'll probably need to disable "Restore Settings" in the first profile to make the volume changes stick.
Hope this helps someone.
I chose to use the "Media Rewind" keycode to lower the system's media volume because it made sense in the physical layout of the Bluetooth Gamepad I was using, but you can, of course, use any key you want. To make a companion way to increase the volume, just copy the profiles and tasks and rename them with "Up" instead of "Down" in the names and change the "-1" in line A1 of the first task to a "+1". You'll also need to modify the IF clause in line A3 so that it checks for a maximum value rather than a minimum.
Profile: Vo!umeDownStart (437)
Event: AutoInput Key [ Configuration:Keys: Media Rewind
Key Action: Key Down ]
Enter: VolDown (436)
A1: Media Volume [ Level:%VOLM-1 Display:Off Sound:Off ]
A2: Wait [ MS:250 Seconds:0 Minutes:0 Hours:0 Days:0 ]
A3: Goto [ Type:Action Number Number:1 Label: ] If [ %VOLM > 0 ]
Profile: VolumeDownStop (438)
Priority: 11
Event: AutoInput Key [ Configuration:Keys: Media Rewind
Key Action: Key Up ]
Enter: VolDownStop (439)
A1: Stop [ With Error:Off Task:VolDown ]
A couple of things to note: The first profile triggers on the Key Down event and the second one triggers on Key Up. Be sure you bump up the priority for launched tasks in the second profile; it needs to be greater than the the task it's trying to stop. You'll also need to run AutoInput's KeySupress function before you use these profiles and then disable key suppression when you're done. The 250 ms delay in line A2 seems to give a nice response ramp, but if you want something a little faster, just decrease that value. Finally, you'll probably need to disable "Restore Settings" in the first profile to make the volume changes stick.
Hope this helps someone.
Wednesday, November 18, 2015
Another (Very) Minor Tweak
I have a control on the main screen that allows me to toggle the tablet's AutoBrightness on and off, but it doesn't get used very much. 99% of the time we're driving in the sun with the top down and I want the tablet at full brightness. About the only time I use it is on those rare occasions when we are traveling at night.
It occurred to me today, though, that if I do dim the screen on the tablet, the phone will remain at full brightness. That would be annoying and since I don't really have a control interface on that unit, changing the brightness would be distracting and annoying, requiring me to go into settings and fumble around.
I don't really want to put controls on the phone, so instead I used AutoRemote. Now when I toggle the screen brightness on the tablet, it sends a direct message to the phone, which causes it to toggle as well.
As I said, a very minor thing, but when I need to use it, it will be handy.
It occurred to me today, though, that if I do dim the screen on the tablet, the phone will remain at full brightness. That would be annoying and since I don't really have a control interface on that unit, changing the brightness would be distracting and annoying, requiring me to go into settings and fumble around.
I don't really want to put controls on the phone, so instead I used AutoRemote. Now when I toggle the screen brightness on the tablet, it sends a direct message to the phone, which causes it to toggle as well.
As I said, a very minor thing, but when I need to use it, it will be handy.
Wednesday, November 11, 2015
Torque and Tasker
If you're interested in getting data from the Torque app into Tasker, take a look at the video I posted on YouTube:
https://www.youtube.com/watch?v=bjFLbbYakBo
It begins by showing you how to set up Torque, then steps through gathering the information and tools that you need, and finishes up with some actual Tasker code.
https://www.youtube.com/watch?v=bjFLbbYakBo
It begins by showing you how to set up Torque, then steps through gathering the information and tools that you need, and finishes up with some actual Tasker code.
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.
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 ]
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.
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.
Tuesday, October 27, 2015
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.
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.
Saturday, October 03, 2015
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.
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.
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.
Monday, September 28, 2015
Flic Bluetooth Button Review
I had mentioned the flic Bluetooth buttons earlier when I was talking about adding physical controls to my Digital Dash Project (http://mikesgeneralblog.blogspot.com/2015/08/physical-controls-for-digital-dash.html). I had been an early backer of the project on Indiegogo with the idea of using them specifically for that system. I ended up ordering five of them, and four were delivered over the weekend. (Not sure what happened to the fifth one, but it was a late addition and may not come for a while.)
Although I won't be using them entirely as I planned, I've installed one in the car and will be experimenting with the others. Since these are new, I thought I'd do a review.
What is a flic?
A flic is a self-contained Bluetooth button that can be connected to both Android and IOS devices to perform tasks when pressed. The free flic software has direct integration with a number of apps and can be used with both IFTT and Tasker (Android only) to control nearly any action that you care to automate. Each flic can recognize three different activation types (Click, Double-Click, and Hold). You can program these separately, so each button can essentially do three things.
Flics are the brainchild of a Swedish company, Shortcut Labs, who used Indiegogo to crowd fund the startup. They reached their initial funding goal in only 30 hours and ended up with over $900,000 in pledges; 801% of their original goal.
Packaging
The flics arrived in an attractive box that has a thank you message to Indiegogo backers on the bottom. The Flics themselves are nestled in custom foam cutouts inside the box. There are two layers of these, and each one can hold three flics, so each box can contain six buttons. The foam rests on a cardboard stand which has some space underneath where the optional clips are stored.
There was also an insert directing you to the website (https://flic.io/), and a large round sticker that you can use to show your support.
All in all, the packaging provides a nice presentation and holds the contents securely and safely.
Hardware
Each flic is slightly larger than a U.S. quarter and just over a quarter-inch thick. The body is covered with a textured, velvety rubber embossed with the cursive version of the name from the logo.
The back is hard plastic that comes covered with thin transparent shield. Removing that exposes the reusable adhesive that you use to stick the flic to a non-porous surface. If the adhesive loses its stickiness, you can just clean it with water and it will regain its holding power. I had originally intended to mount a couple of these to the back of the steering wheel in my car, but I don't think the adhesive would be up to that task; it holds the button just fine on the console, however.
The unit is entirely self-contained and powered by a button cell battery that the company claims will last up to five years. They also claim that the battery is common item and can be easily replaced, although there are no instructions that tell you what to get or how to change it.
Flics come in black, white, green, yellow, turquoise, but I choose all black ones for my application.
The button is light, but it has very nice tactile experience and a satisfying physical "click" when pressed.
There's also a small clip that you can attach to your flic so that you can clip the button to clothing. The company suggests you might want to do this for personal safety or to provide a way of faking a phone call to get out of a bad Tinder date.
Software
The free flic app is available in both the Apple and Google app stores and is required for operation. It is used for pairing the button to your device, assigning actions, and changing settings. You do need a free flic account to use the software.
The flic app is also where you start and stop the flic service. This service must be running in order to use a flic on your device. By default, it runs as a foreground service that starts when your device does and puts up a persistent notification. You can use it as a background service as well, but then it is subject to be killed by memory management. There doesn't seem to be any appreciable battery drain from this service when it isn't being used, so there's really no need to ever turn it off, but you can if you'd really like to.
Once you've set up a flic (See Operation, below) you can access the individual functions. There are 46 built-in app integrations and most of them give you several options to choose from. You have free rein to set things up as you wish. That is, one button can control up to three different apps: a single-click might turn on your Phillips Hue lights, while a double-click might send a text message, and a hold command could start a Skype call.
More sophisticated options such as IFTT and "Send Intent" allow for even greater control. (And, of course, there's Tasker, integration, which means you can do anything you want. Tasker is covered separately, below.)
I won't cover all the settings, but there is one that I particularly like. By default, a flic will play pleasant sounding chimes through your device to indicate that it has been pressed. Each action type has a different chime associated with it, so you know right away if your press has been registered. For my Digital Dash project, this is ideal and I've left it enabled, but you can turn it off if you wish.
Finally, the app also has a help section that explains most functions, but it also has context sensitive help that walks you through most operations.
This is a nice, simple piece of software that gets the job done. It has a clean and open look that make it easy to navigate and use.
Operation
Here are the basic steps to using a flic.
Pairing
Pairing is a simple operation. Just open the flic app and press the button once. The app generates a key and links the button to your device. Once that is done, the process is automatic from then on. Flic appears to use Bluetooth Near to detect the button and activate it. You don't need to turn it on, wake it up, or do anything else; it's just there when you need it. Once it's in range, it's active. Once the button is paired, you can go ahead and rename it and configure it.
Configuring
Open the app and touch the button entry on the screen. It will then take you to another screen where you can add actions for each type of button press. Just tap the plus sign to get a list of programs. Click one of those and the system will guide you through the steps to get everything set up. If you already have an action, there is a standard "three dot" menu that allows you to Remove, Edit, or Execute the action.
Use with Tasker
When I first opened the flic app and began scrolling through the list of possible integrations, I was a bit concerned because I didn't see Tasker anywhere on the list. I was afraid it didn't make the initial release cut and that I'd need to wait before I could use it.
However, on a hunch, I went into Tasker itself, created an Event profile, and chose the Plugin category. Sure enough, there was flic. Installing the app also installed the Tasker plugin.
Using it is very simple. Once you chosen flic as the Event handler, you just click the standard Tasker plugin configuration icon and you are taken to a screen where you choose the flic you are programming and which of the three activation types you are trying to capture. Once you've done that, you link the profile to the task you want to execute. In other words, it's just like every other Tasker plugin you've ever used. Note that the plugin gives you a few more options, such as triggering on either the up or down portion of a press and executing a task based on the button connecting or disconnecting.
It only took me a few minutes to program the flic to act as a Next Track button for both Pandora and PowerAmp. In the next day or two I'll be programming its other functions to provide additional music control and I'm confident that it will work as expected.
Notes and Observations
Here are a few random things about using the flic.
You can have up to eight (8) flics connected to a single device.
A flic can only be paired to one device at a time. If you want to use it with a new mobile, you need to disconnect it from the old one first and move it to the new one by opening the flic app on the new device and pressing and holding the button for at least seven seconds. The app will connect to the flic servers and download the button's key. Since all this is stored in your flic account, it will also download the configuration for the button, so your programmed actions come over as well.
Response time is excellent. When my Digital Dash project is in full swing, it really works the tablet; running turn-by-turn navigation, regularly querying web servers via Bluetooth tethering, running Torque (which is also writing it's own log file), sending and receiving AutoRemote messages, handling interactive screen overlays, playing music, and more. Despite all that, there was never any lag between pressing the the flic and hearing the confirmation chime. This is a very fast implementation.
There is a "Providers" screen under settings where you can disable apps or services that you don't use or configure the ones you do.
Conclusions
I like these little buttons a lot. There were some delays in getting them out, but I'm glad the company chose to delay and release a product that they were happy with rather than putting out something that wasn't quite finished. I feel that they delivered exactly what they promised and I have no regrets about backing them.
As of the time of this review, flics are not yet shipping to the general public. However you can pre-order them on their website (https://flic.io/) with an estimated time delivery of about eight weeks.
If you need or want a simple physical control for a project, flics are a good choice.
Although I won't be using them entirely as I planned, I've installed one in the car and will be experimenting with the others. Since these are new, I thought I'd do a review.
What is a flic?
A flic is a self-contained Bluetooth button that can be connected to both Android and IOS devices to perform tasks when pressed. The free flic software has direct integration with a number of apps and can be used with both IFTT and Tasker (Android only) to control nearly any action that you care to automate. Each flic can recognize three different activation types (Click, Double-Click, and Hold). You can program these separately, so each button can essentially do three things.
Flics are the brainchild of a Swedish company, Shortcut Labs, who used Indiegogo to crowd fund the startup. They reached their initial funding goal in only 30 hours and ended up with over $900,000 in pledges; 801% of their original goal.
Packaging
The flics arrived in an attractive box that has a thank you message to Indiegogo backers on the bottom. The Flics themselves are nestled in custom foam cutouts inside the box. There are two layers of these, and each one can hold three flics, so each box can contain six buttons. The foam rests on a cardboard stand which has some space underneath where the optional clips are stored.
There was also an insert directing you to the website (https://flic.io/), and a large round sticker that you can use to show your support.
All in all, the packaging provides a nice presentation and holds the contents securely and safely.
Hardware
Each flic is slightly larger than a U.S. quarter and just over a quarter-inch thick. The body is covered with a textured, velvety rubber embossed with the cursive version of the name from the logo.
The back is hard plastic that comes covered with thin transparent shield. Removing that exposes the reusable adhesive that you use to stick the flic to a non-porous surface. If the adhesive loses its stickiness, you can just clean it with water and it will regain its holding power. I had originally intended to mount a couple of these to the back of the steering wheel in my car, but I don't think the adhesive would be up to that task; it holds the button just fine on the console, however.
The unit is entirely self-contained and powered by a button cell battery that the company claims will last up to five years. They also claim that the battery is common item and can be easily replaced, although there are no instructions that tell you what to get or how to change it.
Flics come in black, white, green, yellow, turquoise, but I choose all black ones for my application.
The button is light, but it has very nice tactile experience and a satisfying physical "click" when pressed.
There's also a small clip that you can attach to your flic so that you can clip the button to clothing. The company suggests you might want to do this for personal safety or to provide a way of faking a phone call to get out of a bad Tinder date.
Software
The free flic app is available in both the Apple and Google app stores and is required for operation. It is used for pairing the button to your device, assigning actions, and changing settings. You do need a free flic account to use the software.
The flic app is also where you start and stop the flic service. This service must be running in order to use a flic on your device. By default, it runs as a foreground service that starts when your device does and puts up a persistent notification. You can use it as a background service as well, but then it is subject to be killed by memory management. There doesn't seem to be any appreciable battery drain from this service when it isn't being used, so there's really no need to ever turn it off, but you can if you'd really like to.
Once you've set up a flic (See Operation, below) you can access the individual functions. There are 46 built-in app integrations and most of them give you several options to choose from. You have free rein to set things up as you wish. That is, one button can control up to three different apps: a single-click might turn on your Phillips Hue lights, while a double-click might send a text message, and a hold command could start a Skype call.
More sophisticated options such as IFTT and "Send Intent" allow for even greater control. (And, of course, there's Tasker, integration, which means you can do anything you want. Tasker is covered separately, below.)
I won't cover all the settings, but there is one that I particularly like. By default, a flic will play pleasant sounding chimes through your device to indicate that it has been pressed. Each action type has a different chime associated with it, so you know right away if your press has been registered. For my Digital Dash project, this is ideal and I've left it enabled, but you can turn it off if you wish.
Finally, the app also has a help section that explains most functions, but it also has context sensitive help that walks you through most operations.
This is a nice, simple piece of software that gets the job done. It has a clean and open look that make it easy to navigate and use.
Operation
Here are the basic steps to using a flic.
Pairing
Pairing is a simple operation. Just open the flic app and press the button once. The app generates a key and links the button to your device. Once that is done, the process is automatic from then on. Flic appears to use Bluetooth Near to detect the button and activate it. You don't need to turn it on, wake it up, or do anything else; it's just there when you need it. Once it's in range, it's active. Once the button is paired, you can go ahead and rename it and configure it.
Configuring
Open the app and touch the button entry on the screen. It will then take you to another screen where you can add actions for each type of button press. Just tap the plus sign to get a list of programs. Click one of those and the system will guide you through the steps to get everything set up. If you already have an action, there is a standard "three dot" menu that allows you to Remove, Edit, or Execute the action.
Use with Tasker
When I first opened the flic app and began scrolling through the list of possible integrations, I was a bit concerned because I didn't see Tasker anywhere on the list. I was afraid it didn't make the initial release cut and that I'd need to wait before I could use it.
However, on a hunch, I went into Tasker itself, created an Event profile, and chose the Plugin category. Sure enough, there was flic. Installing the app also installed the Tasker plugin.
Using it is very simple. Once you chosen flic as the Event handler, you just click the standard Tasker plugin configuration icon and you are taken to a screen where you choose the flic you are programming and which of the three activation types you are trying to capture. Once you've done that, you link the profile to the task you want to execute. In other words, it's just like every other Tasker plugin you've ever used. Note that the plugin gives you a few more options, such as triggering on either the up or down portion of a press and executing a task based on the button connecting or disconnecting.
It only took me a few minutes to program the flic to act as a Next Track button for both Pandora and PowerAmp. In the next day or two I'll be programming its other functions to provide additional music control and I'm confident that it will work as expected.
Notes and Observations
Here are a few random things about using the flic.
You can have up to eight (8) flics connected to a single device.
A flic can only be paired to one device at a time. If you want to use it with a new mobile, you need to disconnect it from the old one first and move it to the new one by opening the flic app on the new device and pressing and holding the button for at least seven seconds. The app will connect to the flic servers and download the button's key. Since all this is stored in your flic account, it will also download the configuration for the button, so your programmed actions come over as well.
Response time is excellent. When my Digital Dash project is in full swing, it really works the tablet; running turn-by-turn navigation, regularly querying web servers via Bluetooth tethering, running Torque (which is also writing it's own log file), sending and receiving AutoRemote messages, handling interactive screen overlays, playing music, and more. Despite all that, there was never any lag between pressing the the flic and hearing the confirmation chime. This is a very fast implementation.
There is a "Providers" screen under settings where you can disable apps or services that you don't use or configure the ones you do.
Conclusions
I like these little buttons a lot. There were some delays in getting them out, but I'm glad the company chose to delay and release a product that they were happy with rather than putting out something that wasn't quite finished. I feel that they delivered exactly what they promised and I have no regrets about backing them.
As of the time of this review, flics are not yet shipping to the general public. However you can pre-order them on their website (https://flic.io/) with an estimated time delivery of about eight weeks.
If you need or want a simple physical control for a project, flics are a good choice.
Wednesday, September 23, 2015
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/
A3: HTTP Get [ Server:Port:https://maps.
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))
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)*
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:
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/
A3: HTTP Get [ Server:Port:https://maps.
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))
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)*
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.
Thursday, September 10, 2015
Ok, this is just weird.
I'm not sure if it's Moe's pageboy bob, Curly's barefoot tummy tickling, the bondage, or the general assault on fashion, but something about this image just gives me the creeps.
On second thought, it's the tummy tickling. Ugh.
Tuesday, September 08, 2015
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.
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.
Tuesday, August 18, 2015
Controlling Bluetooth Buttons
Since I mentioned in the last post that I was intercepting and modifying some of the buttons on the Bluetooth gamepad to respond to two different types of input, I thought I'd share the Tasker code that I'm using to do that.
Actually, most of the work is done by the AutoInput plugin, which is one of the AutoApps series that extends and simplifies Tasker itself.
Just as I did for the Digital Dash, I'll be using the gamepad as the input source. Just to recap, here are the functions it sends by default:
I'll just be capturing the "Media Fast Forward" button and giving it two functions: a normal click, and a long press. Just for completeness though, I'm suppressing all the gamepad buttons.
The first thing to do is to run the AutoInput Key Suppress command:
KeySuppress (473)
A1: AutoInput Modes [ Configuration:Key Suppress: Enable
Keys: Enter
Back
Media Fast Forward
Volume Up
Volume Down
Media Next
Media Previous
Media Rewind Package:com.joaomgcd.autoinput Name:AutoInput Modes Timeout (Seconds):2 ]
This function traps the specified key inputs and prevents them from being delivered to the OS. If you don't do that, you can still make the keys do whatever you want, but they'll also be passed along and perform their original function as well. That might be useful for some situations, like having Tasker's "Say" function confirm what key was pressed while still letting it through, but I want to completely change the key functions, so I'm going to suppress them.
In my Digital Dash project, the Key Suppress command is part of the Startup task, but you can just run it manually if you want to experiment, since it's persistent and will stay in force until explicitly cancelled.
Now we need a couple of profiles and tasks.
Profile: FFLong (107)
Priority: 40
Event: AutoInput Key [ Configuration:Keys: Media Fast Forward
Key Action: Key Down ]
Enter: LongClick (106)
A1: Profile Status [ Name:FFShort Set:On ]
A2: Wait [ MS:0 Seconds:1 Minutes:0 Hours:0 Days:0 ]
A3: Profile Status [ Name:FFShort Set:Off ]
A4: Flash [ Text:Long Click Long:On ]
This is the profile that determines what happens when the key is pressed and held.
The first thing it does is enable the second profile (which we'll get to in a minute). It then waits for one second and then deactivates the second profile. After that, it simply performs the function you want. Here's it's a simple Flash Alert, but it can be any set of Tasker actions.
The second profile determines what happens when you click and release the key before the one second Wait expires:
Profile: FFShort (108)
Priority: 45
Event: AutoInput Key [ Configuration:Keys: Media Fast Forward
Key Action: Key Up ]
Enter: ShortClick (103)
A1: Stop [ With Error:Off Task:LongClick ]
A2: Flash [ Text:Short Click Long:On ]
Note that this profile is activated when the key is RELEASED and the task it launches is at a higher priority than the one for "FFLong".
Because this task is at a higher priority, it can interrupt the FFLong task and stop it during the Wait period. Beyond that time, the FFShort profile will become inactive and won't fire at all.
If it does activate it simply shuts down the FFLong task and executes its own action, again, in this case, a simple Flash Alert.
That's all there is to it.
A couple of things to note, however. Firstly, you have to name a profile before you can set its status. So, "FFShort" needed a name. "FFLong" doesn't (technically) but it's always a good idea to name your profiles.
Secondly, the actual status of "FFShort" doesn't matter after the key press has been handled. If the "FFLong" task is the one that gets executed, the profile will be turned off. However, if the "FFShort" task is called, the profile remains enabled. But since it responds to a key up state and you can't have that without a corresponding key down event first, the profile can never trigger until "FFLong" is called first.
Of course, once you are done using the buttons, you need to stop capturing them. This is done with the Key Suppress command again, but this time the configuration is set to disable:
KeyAllow (474)
A1: AutoInput Modes [ Configuration:Key Suppress: Disable Package:com.joaomgcd.autoinput Name:AutoInput Modes Timeout (Seconds):2 ]
Again, in this case, this is just a standalone task that you can run manually. In my dash project that command is part of the Shutdown task.
Actually, most of the work is done by the AutoInput plugin, which is one of the AutoApps series that extends and simplifies Tasker itself.
Just as I did for the Digital Dash, I'll be using the gamepad as the input source. Just to recap, here are the functions it sends by default:
The first thing to do is to run the AutoInput Key Suppress command:
KeySuppress (473)
A1: AutoInput Modes [ Configuration:Key Suppress: Enable
Keys: Enter
Back
Media Fast Forward
Volume Up
Volume Down
Media Next
Media Previous
Media Rewind Package:com.joaomgcd.autoinput Name:AutoInput Modes Timeout (Seconds):2 ]
This function traps the specified key inputs and prevents them from being delivered to the OS. If you don't do that, you can still make the keys do whatever you want, but they'll also be passed along and perform their original function as well. That might be useful for some situations, like having Tasker's "Say" function confirm what key was pressed while still letting it through, but I want to completely change the key functions, so I'm going to suppress them.
In my Digital Dash project, the Key Suppress command is part of the Startup task, but you can just run it manually if you want to experiment, since it's persistent and will stay in force until explicitly cancelled.
Now we need a couple of profiles and tasks.
Profile: FFLong (107)
Priority: 40
Event: AutoInput Key [ Configuration:Keys: Media Fast Forward
Key Action: Key Down ]
Enter: LongClick (106)
A1: Profile Status [ Name:FFShort Set:On ]
A2: Wait [ MS:0 Seconds:1 Minutes:0 Hours:0 Days:0 ]
A3: Profile Status [ Name:FFShort Set:Off ]
A4: Flash [ Text:Long Click Long:On ]
This is the profile that determines what happens when the key is pressed and held.
The first thing it does is enable the second profile (which we'll get to in a minute). It then waits for one second and then deactivates the second profile. After that, it simply performs the function you want. Here's it's a simple Flash Alert, but it can be any set of Tasker actions.
The second profile determines what happens when you click and release the key before the one second Wait expires:
Profile: FFShort (108)
Priority: 45
Event: AutoInput Key [ Configuration:Keys: Media Fast Forward
Key Action: Key Up ]
Enter: ShortClick (103)
A1: Stop [ With Error:Off Task:LongClick ]
A2: Flash [ Text:Short Click Long:On ]
Note that this profile is activated when the key is RELEASED and the task it launches is at a higher priority than the one for "FFLong".
Because this task is at a higher priority, it can interrupt the FFLong task and stop it during the Wait period. Beyond that time, the FFShort profile will become inactive and won't fire at all.
If it does activate it simply shuts down the FFLong task and executes its own action, again, in this case, a simple Flash Alert.
That's all there is to it.
A couple of things to note, however. Firstly, you have to name a profile before you can set its status. So, "FFShort" needed a name. "FFLong" doesn't (technically) but it's always a good idea to name your profiles.
Secondly, the actual status of "FFShort" doesn't matter after the key press has been handled. If the "FFLong" task is the one that gets executed, the profile will be turned off. However, if the "FFShort" task is called, the profile remains enabled. But since it responds to a key up state and you can't have that without a corresponding key down event first, the profile can never trigger until "FFLong" is called first.
Of course, once you are done using the buttons, you need to stop capturing them. This is done with the Key Suppress command again, but this time the configuration is set to disable:
KeyAllow (474)
A1: AutoInput Modes [ Configuration:Key Suppress: Disable Package:com.joaomgcd.autoinput Name:AutoInput Modes Timeout (Seconds):2 ]
Again, in this case, this is just a standalone task that you can run manually. In my dash project that command is part of the Shutdown task.
Subscribe to:
Posts (Atom)