Update status continuously

Question

Update status continuously

Closed this issue 5 years ago · 39 comments

Hey,

Thanks for building a fantastic workflow 🤗

I had an idea... I am using this to connect to my Bose QC 35. And those don't want to connect unless they're in pairing mode. But it's not always obvious whether they are. So I usually just type blt [name of my headphones and connect.

And then I wait. I won't know whether I was successful unless I re-open Alfred type in the same command again.

I don't know if Alfred supports this but I guess I have two requests/proposals:

Add a modifier key that connects to the selected device, but doesn't close Alfred
Update the connectivity status of each device regularly (1s?) to see whether a connection was successful

Sorry if this is another annoying request from someone who should've submitted a PR... but my Python days are long gone — sorry!

Cheers 👍

littke commented 6 years ago

👍

littke commented 6 years ago

Sweet!

Answer 1 · 2019-05-14T17:15:33.000Z

Hey @littke,

first of all thanks for the kind words! :)

I like the idea. But I also don't know if it is possible in Alfred to wait for the execution of a command or continously update the result set until a desired state is reached. This was my first workflow so I will need to dig into it. Maybe @trietsch has an idea?

Maybe this feature could be configurable inside the workflow. I am not entirely sure if I would like to have the prompt open until my headphones are connected, which might take a few seconds — they already beep and a voice tells me Bluetooth connected. :)

Sorry if this is another annoying request from someone who should've submitted a PR.

No worries! Asking for a feature is never something to apologize for, as long as no one expects an immediate implementation. ;)

Answer 2 · 2019-05-14T17:37:13.000Z

Hey @littke, thanks!

Regarding your idea, it sounds nice indeed. I caught myself today doing the exact same thing (even though it says Bluetooth connected).

Easiest (and also very easy to configure for end users) is to just send a push notification stating the end result of the action. @tilmanginzel how does that sound?

Answer 3 · 2019-05-14T17:40:36.000Z

That sounds like the perfect solution! :) This wouldn't interrupt anyones workflow, so a configuration is probably not even necessary. The notification could also be used for disconnecting devices, turning bluetooth on or off. That's a great visual feedback, if you might not be sure what just happened.

@littke What do you think?

Answer 4 · 2019-05-14T17:43:25.000Z

If it can be used for all commands, here are some proposals for the texts:

Connected to [device]
Disconnected [device]
Bluetooth turned on
Bluetooth turned off

The last two are especially useful if someone uses the blt toggle command.

@trietsch Do you want to give it a go some time or should I try? :)

Answer 5 · 2019-05-14T17:56:22.000Z

Great! Keen on what @littke thinks.

You can implement it if you want, I'll review :) Quite busy at the moment.

Answer 6 · 2019-05-14T17:58:14.000Z

Alright. I should be able to find some time later this week, without any guarantees. ;)

Answer 7 · 2019-05-16T20:25:19.000Z

Haha wow. You're both not only kind, but appreciative of my input and you're thinking of starting on it almost right away. Jackpot! 🙌

In terms of the proposed solution, let me think...

I think the important piece is what happens if it doesn't connect. The "connection successful" is all fine and good... but sometimes my headphones are paired to something else (my phone? my ipad? my watch? my windows machine? I never know) and I just need more visibility as to whether it paired successfully to the Mac. And if it did not pair successfully, I think I'd like a retry feature. So something like:

Failed to connect to [device]. {Retry|Close}

And if you are implementing actions on the notification, you could even do that for the others (albeit less important):

Connected to [device] {Close|Disconnect}*
Disconnected [device] {Close|Reconnect}*
Bluetooth turned on {Close|Turn Off}*
Bluetooth turned off {Close|Turn On}*

= Autoclose after 3s (if Mac notifications allow for this feature)

Maybe that's a bit overkill...

Finally, I suppose that the timeout period is interesting to maybe configure... or at least know about. Like: how long does the workflow wait before it gives up? Just to inform the user, we could do something like:

Failed to connect to [device] after trying for 5sec. {Retry|Close}

Then we're really onto something 🙌

Thanks again!!

Answer 8 · 2019-05-17T11:02:59.000Z

Hey @littke, good idea to include buttons into the notifications! I quickly checked, and the default Alfred notifications do not allow to use custom buttons. Luckily, this exists: https://github.com/julienXX/terminal-notifier

Using the terminal-notifier would have another advantage: We can use custom icons for each notification, so for example if the connection failed, we can add a small red x to it, or a green check mark if it was successful. :)

Answer 9 · 2019-05-17T20:31:54.000Z

Sweet. Let's do it.

Errr... I mean. You do it.

If you need any design stuff done though, I'm happy to help. Been designering for many years now.

I also don't check GitHub too often so if you need input on anything just ping @littke on Twitter

Cheers

Answer 10 · 2019-05-19T18:53:00.000Z

So, unfortunately some bad news. terminal-notifier does not support action buttons anymore, which previously have been provided by alerter. Alerter features have been removed from terminal-notifier due to some issues, and apparently it's not actively maintained anymore. For example, there are open issues regarding memory leaks. Therefore I would not be comfortable in including it in this workflow.

I tried to find other possibilities to add actions buttons to notifications, and most articles refer to private macOS APIs, which might be unstable. In addition, I have zero experience with macOS development and its APIs.

@littke @trietsch Do you have other proposals for a retry feature? If not I would just go with the simple notification approach, which at least makes it quickly transparent what just happened. IMO it is still a useful tradeoff.

Answer 11 · 2019-05-19T19:48:29.000Z

Some further reasearch led me to this: node-notifier, a Node.js module supporting cross-platform notifications with action buttons. :)

It could be complicated to include this into the workflow (but I assume it's possible). I am a JavaScript noob, so it might take a lot more time to get this working. Thus I will probably implement the "simple" notifications first, as an intermediate step. I will try to find some time in the coming week! :)

Answer 12 · 2019-05-25T22:49:29.000Z

Hi @littke, @trietsch. I have added a pull request for the notifications. Here are some examples on how they look like:

The icon stuff turned out to be really difficult. I would have preferred to have just a single icon on the left, with an added checkmark or x, but this not easily possible without compiling multiple different versions of terminal-notifier. So I went for the solution to have a small content image on the right, which is supported out of the box. Most notifications now have an image to the right. My gut feeling was that this is counterintuitive for two results, so these have no image:

Bluetooth turned off
Disconnected device <title>

In total, these notifications can occur:

Connected to <title> ✔
Bluetooth turned on ✔
Failed to connect to <title> x
Failed to disconnect <title> x
Failed to turn Bluetooth on x
Failed to turn Bluetooth off x
Disconnected <title>
Bluetooth turned off

In the meantime I have learned that terminal-notifier supports to execute a command when you click on the notification. Clicking on it could maybe just retry the previously failed command. Unfortunately it is not possible to route this back to the workflow, so some further implementation would be required to get notified again. Should we add a hint for this like Click to retry.?

What do you guys think of this? :)

Answer 13 · 2019-05-28T17:52:54.000Z

Super. How can I try it?

So I went for the solution to have a small content image on the right, which is supported out of the box.

SGTM 👍

Disconnected <title>

How about: Disconnected from <title>

Clicking on it could maybe just retry the previously failed command.

I've never seen this elsewhere and it feels non-standard. I would recommend to wait until you know how to implement a button in the notification instead.

Answer 14 · 2019-05-28T19:55:29.000Z

How about: Disconnected from <title>

Done, thanks.

How can I try it?

Feel free to test the following workflow: Bluetooth Connector.alfredworkflow.zip

I would recommend to wait until you know how to implement a button in the notification instead.

Fine with me. :) But: I have tried to do that already so there is a high possibility that this won't get implemented until someone can provide a merge request for this.

Answer 15 · 2019-05-29T18:00:27.000Z

But: I have tried to do that already so there is a high possibility that this won't get implemented until someone can provide a merge request for this.

I see. In that case, I guess a "Click to retry" is better than having to reopen the workflow.

Feel free to test the following workflow: Bluetooth Connector.alfredworkflow.zip

This worked just like before. Meaning, I saw no notifications, regardless of which action I chose. The version file says 0.5.0, and I am positive that I installed the file you provided.

Answer 16 · 2019-05-30T13:50:41.000Z

Hmm, that is weird. I have added some debug output, so you need to install this version:
Bluetooth Connector.alfredworkflow.zip

Can you enable the debug output in Alfred and check if the logs show the same as in this example:

Answer 17 · 2019-05-30T13:53:23.000Z

Also, just to be 100% safe: The Do Not Disturb mode is off? Someone else reported that he once had issues with terminal-notifier (and other notifications) and a restart seems to have fixed it.

Answer 18 · 2019-05-30T23:12:19.000Z

Interestingly, that version worked.

Do Not Disturb mode is off now. I think it was off when I tested this last, as well, since I never use that feature.

Answer 19 · 2019-05-31T17:26:24.000Z

That is definitely weird, but nice to hear that it generally works now. :) In the coming days, I will try to implement the "Click to retry" feature.

Answer 20 · 2019-06-06T20:37:33.000Z

Hey @littke, just to keep you in the loop: Unfortunately I was very busy this last week, and now I am again unavailable for roughly one and a half week. So it will take a bit more time until the retry feature is implemented.

Answer 21 · 2019-06-20T21:02:31.000Z

I was finally able to put some time into the "Click to Retry" feature. :) It was confirmed once again that the notification handling is quite difficult in MacOS, especially if you want to do custom stuff. But I think the current solution is working well enough!

If a command fails, you can now click on it to retry. You will be notified of the result, and could retry it again.

There is one caveat which cannot be solved easily. The -execute command from terminal-notifier is only working when the -sender flag is not used. I had to use the -sender flag so that MacOS knows which icon to show. As a workaround if a command fails, I do not use the -sender flag anymore, but the -appIcon flag. The result is the following (notice the two icons):

The only way to solve this could be to compile a custom version of terminal-notifier with the correct icon baked into it. But at the moment I don't think that this is worth the effort, as the two icons are only shown for failed commands.

Please test the following workflow (still version 0.5.0): Bluetooth Connector.alfredworkflow.zip

@littke Happy to hear your feedback and if it is working as expected.
@trietsch Feel free to review #8 if you find the time. :)

Cheers

Answer 22 · 2019-07-08T09:26:43.000Z

Hello,

I tried to use the latest zip of this issue and I obtain the following error:

[10:24:54.411] ERROR: Bluetooth Connector[Run Script] ./scripts/blt.sh: line 4: cd: /Users/tdurieux/Library/Application: No such file or directory
./scripts/blt.sh: line 9: ../blueutil: No such file or directory
./scripts/blt.sh: line 20: ../blueutil: No such file or directory
./scripts/blt.sh: line 22: ../blueutil: No such file or directory
./scripts/blt.sh: line 26: ./notify.sh: No such file or directory

Do you know what could produce it? Alfred 4 (I have no issue with version 0.4)?

Answer 23 · 2019-07-08T11:11:31.000Z

Hey @tdurieux, thanks for the feedback! I feared that something like this will happen, I don't think it has anything to do with the Alfred version (I am still on version 3). I had to rework the script path resolution because they must be executed from two different contexts now:

from inside the workflow itself
globally from the notification center when retrying a command, which is executed in a totally different shell session

To mitigate this, I added the following snippet to each of those scripts, so that the script "knows" where it is and all relative paths are stable:

PARENT_PATH=$(cd "$(dirname "${BASH_SOURCE[0]}")"; pwd -P)
cd ${PARENT_PATH}

It seems like that workaround does not work with the space in the Application Support folder. I didn't notice it as my workflow is symlinked to a folder without a space. I will provide a fix shortly!

Answer 24 · 2019-07-08T11:14:20.000Z

@tdurieux @littke This should work now: Bluetooth Connector.alfredworkflow.zip

Answer 25 · 2019-07-08T13:40:31.000Z

Thanks, this new version does not crash however I do not receive the notification.

[14:39:02.081] STDERR: Bluetooth Connector[Run Script] [debug] ./notify script triggered
[debug] Send notification (message: Connected to MDR-1000X, image: -contentImage ../icons/success.png, command: )
[debug] Notification sent successfully

Answer 26 · 2019-07-08T18:04:11.000Z

Hm, unfortunately I can only guess here as this is out of my hands. Do you have Do Not Disturb mode enabled? @littke above also mentioned that the notification wasn't working at first and then suddenly it was...

Answer 27 · 2019-07-10T07:42:36.000Z

the notification started to work, i have no idea why...

Answer 28 · 2019-07-10T17:30:02.000Z

@tdurieux Cool! On one hand that's great to hear, but also a bit weird that you are now the second one were it started to work just after a while. ;)

Were you able to check if the retry functionality is working? Just connect to an unavailable device, click on the notification and wait until there is new notification.

Answer 29 · 2019-07-10T17:44:39.000Z

It was not working again...
I debug a little bit the script and I found the issue. It is related to -sender "de.tilmanginzel.alfred.bluetooth". If the id is not correct the notification will not be sent.

Were you able to check if the retry functionality is working?
I received only once this notification and it worked!

Using this version of the script, the notification always works

#!/usr/bin/env bash

>&2 echo "[debug] ./notify script triggered"

PARENT_PATH=$(cd "$(dirname "${BASH_SOURCE[0]}")"; pwd -P)
cd "${PARENT_PATH}"

while getopts ":m:i:c:" opt; do
    case ${opt} in
        m) MESSAGE="$OPTARG"
        ;;
        i) ICON="$OPTARG"
        ;;
        c) COMMAND="$OPTARG"
        ;;
    esac
done

CONTENT_IMAGE_OPT=""
if ! [[ -z ${ICON} ]]
then
    CONTENT_IMAGE_OPT="-contentImage ../icons/${ICON}.png"
fi

COMMAND_OPT=""
if ! [[ -z ${COMMAND} ]]
then
    COMMAND_OPT="${PARENT_PATH}/$COMMAND"
fi

>&2 echo "[debug] Send notification (message: ${MESSAGE}, image: ${CONTENT_IMAGE_OPT}, command: ${COMMAND_OPT})"

if ! [[ -z ${COMMAND_OPT} ]]
then
    # do not specify -sender as this breaks the -execute command
    ../terminal-notifier.app/Contents/MacOS/terminal-notifier \
        -title "Bluetooth" \
        -message "${MESSAGE}" \
        -appIcon "${PARENT_PATH}/../icon.png" \
        -execute "${COMMAND_OPT}" \
        ${CONTENT_IMAGE_OPT}
else
    ../terminal-notifier.app/Contents/MacOS/terminal-notifier \
        -title "Bluetooth" \
        -appIcon "${PARENT_PATH}/../icon.png" \
        -message "${MESSAGE}" \
        ${CONTENT_IMAGE_OPT}
fi

>&2 echo "[debug] Notification sent successfully"

Answer 30 · 2019-07-10T18:46:35.000Z

Thanks for investigating this! :) I removed the -sender flag. My guess it that the sender id must be unique and known to MacOS. As the workflow is only integrated inside Alfred, this might be a bit flaky.
Ideally we should compile a custom version of terminal-notifier with the icon baked into it, because the -appIcon integration is not super beautiful.

There is still one issue left which I cannot fix though. The retry command requires an absolute path, e.g. the following:

-execute "/Users/<user>/Library/Application Support/Alfred 3/Alfred.alfredpreferences/workflows/<workflow>/scripts/blt.sh <device_id> <device_name>"

Due to the spaces in the path, it does not work. I assume the retry does also not work for you? I tried to escape the spaces in every possible way, \ or adding quotes around the path etc, but terminal-notifier will always crash. I assume it is related to this. My ruby knowledge is basically non-existent, but I can imagine that simply concatenating the parameters will yield an invalid command.

I will try to create a minimal example to reproduce it and then create an issue at terminal-notifier.

Answer 31 · 2019-07-10T18:57:00.000Z

Hm, interestingly a path with spaces (escaped with \ ) works in my minimal example. So this should be fixable. Will dig deeper. ;)

Answer 32 · 2019-07-10T19:19:49.000Z

Fixed, here is the latest version: Bluetooth Connector.alfredworkflow.zip

Notifications and retries should now work without any issues (hopefully!).

Answer 33 · 2019-07-11T10:22:36.000Z

Thanks a lot.

It seems to work fine for me!

Answer 34 · 2019-07-26T23:47:12.000Z

Very nice! I'd love to try this as I'm now back in California, but the workflow doesn't work with Catalina. I've filed another issue.

Answer 35 · 2019-07-29T18:44:16.000Z

Meh, that's unfortunate. Hopefully we can find a solution in #9.

Answer 36 · 2019-10-03T18:43:29.000Z

I think it was time to merge this feature. :)

Answer 37 · 2019-10-03T20:22:18.000Z

Thanks again!