スマートスピーカ
スマートプラグ + ESP32 で超シンプルに Wake On Wan
スマートスピーカーの普及に伴いスマートホーム系製品の低価格化が少しずつ進んでいます。 最近プライベートで次の製品を買いました。今のところ安定動作しており自宅で使っている Google Home Mini との相性もよく気に入っています。
1) 公式アプリ 2) Google Home Mini 3) マイコンボード により照明を操作
（注：この動画には "OK Google" の発声が含まれます。
近くに Goole Home デバイスのある場合にはご注意下さい）
※スマートプラグを使えば家庭用電源から所定の機器への給電を手軽に操作できるため便利ですが、個人的には何らかの原因で自分の意図しない動作が起こった場合に深刻な事態につながりかねない機器との併用は避けています。たとえば少なくとも現時点で電気ストーブなどをつなぐ勇気はありません ^^;
スマートプラグを PC の起動に利用する
スマートスピーカーへの音声指示で PC を起動するアイディアには実用性があり、ネットを検索すると参考になる多くの興味深い例に触れることができます。一方で、Meross Smart Plug Mini を触っているうちにこれを使えばとてもシンプルな道具立てで同様のことを実現できるのではないかと考えました。以下の発想によるものです。
電源投入からのスタートなのでボード側の初期処理に多少の時間がかかることは予想されるものの全体として筋は通っています。特に難しい要素もないため国内外のどこかにすでに同一の事例があるのではないかと想像しましたが、手元でざっと見渡した範囲では見当たらないようです。そんなわけで、まあもし先例があってもいいか、と思いながらざっくり形にしてみることにしました。
実装と動作の様子
スマートプラグからの給電先は何かと融通のきく ESP32 ボードとしました。AC アダプタと USB ケーブルごしにボード単体をプラグへ接続して使います。 プログラムは以下の内容としました。対象 PC が起動すれば当該ボードはお役御免につきプログラムから給電元のプラグをオフにすることで自らをシャットダウンします。
あわせてネットワーク接続時と電源切断前にメールでその旨を通知します。この通知はリモートで操作を行う場合には状況把握のために有用ですが、スマートスピーカーへ声をかけている在宅時にはいささか冗長なのでいずれ手を加えるかもしれません。
ソースコード
Arduino IDE + Arduino core for the ESP32 環境向けに用意したプログラムです。
前項に挙げたメール通知処理には SendGrid を、プラグのシャットダウンには IFTTT アプレットを利用しています。
これらは ESP32_WakeOnLan.h 冒頭の「#define USE_MAIL_NOTIFICATION」「#define USE_AUTO_SHUTDOWN」の定義を無効化すれば省略されます。
デモ
一式の動作の様子を収めた動画です。 （1分10秒）
（注：この動画には "OK Google" の発声が含まれます。
近くに Goole Home デバイスのある場合にはご注意下さい）
余談ながら、手元では過去に何度か Wake On Wan の試みを行いそれぞれ当ブログの記事として公開しています。見返してみると道具立てに微妙に当時の状況が反映されておりちょっと面白く感じました。
時代が加速を続けています。数年後の未来が楽しみです。
(tanabe)
Google Assistant Service プログラミング事始め
前回の記事では Google Assistant Library ベースのプログラミングを通じて Google アシスタントの各機能を取り回す試みを行いました。今回はもうひとつの Google Assistant SDK である Google Assistant Service に目を向けてみます。
Google LLC は Google Assistant SDK for devices として「Google Assistant Library」「Google Assistant Service」の二種類のセットを提供しています。前者は高水準で稼働環境は狭め、後者は低水準で広範な稼働環境に対応しており、この周到な構成に Google の本気度が窺えます。現時点では一日あたりのリクエスト数に制限はあるものの個人でも無償で利用できることが大きな魅力です。
Google Assistant Service と稼働環境
前回も引用した Google Assistant Library と Google Assistant Service の比較表を再掲します。（2018年12月時点の公式記事より）
Google Assistant Service の最大の特長は、このように gRPC 対応のプラットフォーム＋対応言語環境全般で利用可能であることです。現時点では Google Assistant Library ほどには多機能ではないものの、稼働環境が広く Windows PC や Mac はもとより小振りで消費電力が小さく IoT フロントエンドとして有用な Raspberry Pi Zero / Zero W 系ボードも Google アシスタントクライアントとして利用できることに関心を誘われます。
Google Assistant Service と Google Assistant Library の機能面での違いは SDK 全体のリリースノートを追うことで手早く俯瞰できます。
両者の機能差は今後変化する可能性がありますが、個人的には 2018年12月時点で Google Assistant Service 側にはない要素のうち実用面とのかねあいにおいて以下の三点に留意しています。
- Google Assistant Library とは異なりウェイクワードの待機・検知に対応していない
- ニュースの読み上げや Google Podcasts に未対応
- アラームに未対応 （リマインダは設定可能）
なお、上記 1. は外部の Hotword Detector との連携（後述）によりある程度補うことが可能です。
※余談ながら、Google Home デバイス実機とは異なり今のところ Google Assistant SDK ベースのプログラムの所作に google-home-notifier を絡ませることはできません。たしかに 8009 番ポートを使ったキャスト機構にはハードウェア側要件としての印象が強いものの、google-home-notifier を あち こち で利用しているファンとしてはちょっと残念です。
pushtotalk.py プログラムのこと
Google Assistant Service をセットアップ後の googlesamples/assistant/grpc/ フォルダには「pushtotalk.py」プログラムが配置されます。
このプログラムは名前の示すように Google Assistant Library に含まれる「hotword.py」とは異なり、ウェイクワード（ホットワード）の音声ではなく 'Press Enter to send a new request...' の CUI メッセージを添えた click.pause() API で物理的なトリガーを待って Google アシスタントとの対話を開始する内容で実装されています。
セットアップずみの SDK ディレクトリ下での pushtotalk.py の実行方法は以下の要領です。引数で指定したプロジェクト ID とモデル ID はホスト側へ記憶され、変更の必要がなければ次回以降は省略可能です。
$ pwd
/home/t/wk/GoogleAssistant
$ ls
env
$ source env/bin/activate
(env) $ googlesamples-assistant-pushtotalk --project-id [設定ずみのプロジェクトID] --device-model-id [設定すみのモデルID]
pushtotalk.py を手元の複数の環境で実行した様子の動画を以下に示します。
|
Windows |
Mac |
|
Linux （32bit） |
Raspberry Pi 3 Model B+ |
|
Raspberry Pi Zero W |
|
|
上の動画のRaspberry Pi 3 Model B+ / Zero W には手持ちの以下の以下のマイクとスピーカーを写真の要領で接続しています。
|
今回は、前回の hotword.py と対照的なこの pushtotalk.py を試作の下敷きとします。
Hotword Detector について
前掲の Google Assistant Service 側未対応の機能のうち、実用上の影響がもっとも大きいのはウェイクワードの待機・検知ができないことでしょう。Google Assistant Library プログラムにおいては Google Home デバイスと同様にハンズフリーでアシスタントとの応酬が可能であることを考えあわせると淋しく感じられますが、この点は外部の Hotword Detection ソフトウェアを併用することで補うことができます。
ただし、外部の Hotword Detector との連携は Google アシスタントネイティブでのウェイクワードサポートではなく、あくまでも Assistant API を呼び出すためのトリガーを外側に用意する手立てに他ならないため以下の注意が必要です。
- ウェイクワード設定の柔軟性や認識精度はすべて Detector 側の要件である
- Google アシスタントの発話中にウェイクワードで介入することはできない
こういった事情を理解した上で Hotword Detector を併用すれば、間口の広い Google Assistant Service を様々な環境でより便利に利用することができるでしょう。
Porcupine と Snowboy
現時点でのスマートスピーカー向きの代表的な Hotword Detector として、Picovoice （カナダ系）による Porcupine と、 KITT.AI （中国系） による Snowboy が挙げられます。後者はすでに随所で取り上げられていますね。どちらも機械学習に基づく精度の高さ・低負荷・マルチプラットフォーム対応・カスタマイズの柔軟性をアピールポイントとしており、後発の Picovoice は両者の比較記事を公開しています。
手元ではどちらも使い始めてまだ日が浅いのですが、今のところウェイクワードを認識する能力そのものに際立った性能差は感じておらず負荷の度合いについては未検証です。今の時点で把握している両者の一長一短を挙げてみます。
対応プラットフォームの広さ： Porcupine ◎
カスタムウェイクワードへの対応： Snowboy ◎
（クリックで大きく表示）
$ pwd
/home/t/wk/Porcupine
$ tools/optimizer/linux/i386/pv_porcupine_optimizer -r resources/ -p linux -o . -w "OK google"
手元では今のところ PC では Porcupine、Raspberry Pi では Snowboy の要領で使い分けています。下の動画はそれぞれの動作の様子です。
※ ふたつの動画でのウェイクワード検知時・対話終了時の応答音はいずれも Snowboy の resource/ ディレクトリ下の wave ファイルによるものです。これらが耳に馴染んだため Porcupine との連携においても同じ要領で使用しています
試作
前回記事での hotword.py （Google Assistant Library） ベースの試作に続き、今回は Google Assistant Service の pushtotalk.py を下敷きにプログラムを作成します。作業上の便宜から開発は PC で行いましたが、Google Assistant Service ベースなので指先に乗るサイズの Raspberry Pi Zero W ボードをはじめ広範な環境で実行可能であることに夢が広がります。オールインワンのダンボールキットも製品化されていますね。
今回はシンプルな切り口として前回の Google Assistant Library 版の各プログラムと同じ動きをするものを作ってみることにしました。Google Assistant Serivice プログラミングは奥が深くまだまだ習作の段階ではありますが、事始めとして取り組んだ内容を以下に掲載します。
1. 指定テキストに基づく音声合成と読み上げ
テーマ： Google アシスタントの音声合成機能を単体で利用する。いわゆる Text to Speech。
［前回 Google Assistant Libray 版試作へのリンク］
内容
デモ： 動画 27秒
（前回分）
考えたことなど
(env)t@PC-533:~/wk/GoogleAssistant$ ./textinput.sh
INFO:root:Connecting to embeddedassistant.googleapis.com
: こんにちは
<you> こんにちは
<@assistant> こんにちは、TAnabeさん
どうしましたか？
: 今何時？
<you> 今何時？
<@assistant> 時刻は、17:25です。
: 今晩、雨降る？
<you> 今晩、雨降る？
<@assistant> 夜は、雨の心配はないでしょう
今夜の山口は雨ではないでしょう。 気温10度、晴れるでしょう。
---
（weather.com でもっと見る）
:
083| def iter_assist_requests():
084| config = embedded_assistant_pb2.AssistConfig(
085| audio_out_config=embedded_assistant_pb2.AudioOutConfig(
086| encoding='LINEAR16',
087| sample_rate_hertz=16000,
088| volume_percentage=0,
089| ),
090| dialog_state_in=embedded_assistant_pb2.DialogStateIn(
091| language_code=self.language_code,
092| conversation_state=self.conversation_state,
093| is_new_conversation=self.is_new_conversation,
094| ),
095| device_config=embedded_assistant_pb2.DeviceConfig(
096| device_id=self.device_id,
097| device_model_id=self.device_model_id,
098| ),
099| text_query=text_query,
100| )
109| text_response = None
110| html_response = None
111| for resp in self.assistant.Assist(iter_assist_requests(),
112| self.deadline):
113| assistant_helpers.log_assist_response_without_audio(resp)
114| if resp.screen_out.data:
115| html_response = resp.screen_out.data
116| if resp.dialog_state_out.conversation_state:
117| conversation_state = resp.dialog_state_out.conversation_state
118| self.conversation_state = conversation_state
119| if resp.dialog_state_out.supplemental_display_text:
120| text_response = resp.dialog_state_out.supplemental_display_text
121| return text_response, html_response
149| if len(resp.audio_out.audio_data) > 0:
150| if not self.conversation_stream.playing:
151| self.conversation_stream.stop_recording()
152| self.conversation_stream.start_playback()
153| logging.info('Playing assistant response.')
: 今何時？
<you> 今何時？
0
1600
1600
（引用中略）
1600
1600
244
<@assistant> 時刻は、18:43です。
（mp3 形式へ変換したもの）
import sounddevice as sd
:
text_response = None
html_response = None
s = sd.RawStream(
samplerate=audio_helpers.DEFAULT_AUDIO_SAMPLE_RATE,
dtype='int16',
channels=1,
blocksize=audio_helpers.DEFAULT_AUDIO_DEVICE_BLOCK_SIZE)
for resp in self.assistant.Assist(iter_assist_requests(),
self.deadline):
assistant_helpers.log_assist_response_without_audio(resp)
s.write(resp.audio_out.audio_data)
s.start()
if resp.screen_out.data:
html_response = resp.screen_out.data
if resp.dialog_state_out.conversation_state:
conversation_state = resp.dialog_state_out.conversation_state
self.conversation_state = conversation_state
if resp.dialog_state_out.supplemental_display_text:
text_response = resp.dialog_state_out.supplemental_display_text
return text_response, html_response
:
ソースコード
- pushtotalk_tts.py - github.com/mkttanabe
2. 利用者の発話内容をテキストへ変換
テーマ： Google アシスタントの音声認識機能を単体で利用する。いわゆる Speech to Text。
［前回 Google Assistant Libray 版試作へのリンク］
内容
デモ： 動画 41秒
（前回分）
考えたことなど
138| for resp in self.assistant.Assist(iter_log_assist_requests(),
139| self.deadline):
140| assistant_helpers.log_assist_response_without_audio(resp)
141| if resp.event_type == END_OF_UTTERANCE:
142| logging.info('End of audio request detected.')
143| logging.info('Stopping recording.')
144| self.conversation_stream.stop_recording()
145| if resp.speech_results:
146| logging.info('Transcript of user request: "%s".',
147| ' '.join(r.transcript
148| for r in resp.speech_results))
ソースコード
- PicovoiceWithGoogleAssitantService_input.py - github.com/mkttanabe
- Porcupine をインストールしたディレクトリ下へ配置して実行のこと
- Porcupine/resource ディレクトリ下に前掲の ding.wav, dong.wav が必要
- デモ動画ではパラメータに "--keyword_file_paths resources/keyword_files/picovoice_linux.ppn" を指定
3. 利用者の発話内容を他言語へ連続翻訳
テーマ： Google アシスタントの 音声認識 / 文意解釈 / 言語翻訳 / 応答文生成 / 音声合成 の各機能を利用する
［前回 Google Assistant Libray 版試作へのリンク］
内容
デモ： 動画 2分30秒
（前回分）
ソースコード
- PicovoiceWithGoogleAssitantService_translate.py - github.com/mkttanabe
- Porcupine をインストールしたディレクトリ下へ配置して実行のこと
- Porcupine/resource ディレクトリ下に前掲の ding.wav, dong.wav が必要
- デモ動画ではパラメータに "--keyword_file_paths resources/keyword_files/picovoice_linux.ppn" を指定
4. 利用者の発話内容を復唱
テーマ： Google アシスタントの音声認識 / 音声合成機能を利用する
［前回 Google Assistant Libray 版試作へのリンク］
内容
デモ： 動画 39秒
（前回分）
ソースコード
- PicovoiceWithGoogleAssitantService_echo.py - github.com/mkttanabe
- Porcupine をインストールしたディレクトリ下へ配置して実行のこと
- Porcupine/resource ディレクトリ下に前掲の ding.wav, dong.wav が必要
- デモ動画ではパラメータに "--keyword_file_paths resources/keyword_files/picovoice_linux.ppn" を指定
しりとり
テーマ： Google アシスタントの音声認識 / 音声合成機能を利用する
［前回 Google Assistant Libray 版試作へのリンク］
内容
デモ： 動画 60秒
（前回分）
現時点ではプログラミングを行うための実践的な情報をあまり目にすることのない Google Assistant Library と Google Assistant Service を題材に手元で行った試みを二度に分けて紹介しました。幼児の年齢を迎えたばかりの Google アシスタントはこれからこれらの SDK とともに成長を重ねて行くことでしょう。未来へ向かう道すがらの愉しみがまたひとつ増えた思いです。
(tanabe)
Google Assistant Library プログラミングを楽しむ
Google LLC は Google Assistant SDK for devices として 「Google Assistant Library」「Google Assistant Service」 の二種類のセットを提供しています。前者は高水準で稼働環境は狭め、後者は低水準で広範な稼働環境に対応しており、この周到な構成に Google の本気度が窺えます。現時点では一日あたりのリクエスト数に制限はあるものの個人でも無償で利用できることが大きな魅力です。
Compatibility and feature support
The following table summarizes the platform compatibility requirements and the
supported features for the Google Assistant Library and the Google
Assistant Service:
Library Service
Supported architectures linux-armv7l and linux-x86_64 All gRPC platforms
Supported languages Python All gRPC languages
Hands-free activation
(Ok Google)Yes No
Audio capture and playback Built in Reference code is provided
Conversation state management Built in Reference code is provided
Timers and alarms Yes No
Playback of podcasts and news Yes No
Broadcast voice messages Yes No
Visual output (HTML5) of Assistant responses No Yes
Google Home デバイスやスマートフォンアプリを通じて Google アシスタントの存在感はどんどん大きくなっています。その一方で現時点では Google Assistant SDK プログラミングのための実践的な情報を国内外を通じてあまり見かけないことが残念に思われました。ネットの奥深くに息づいている Google アシスタント陣営の一連の機能を本 SDK ごしに柔軟に呼び出すことができればこの強力で魅力的なサービスをさらに活用できるのではないでしょうか。
- 音声認識
- 文意の解釈
- 応答文の生成
- 音声合成
- 言語翻訳
そんなわけで手元ではここしばらく Google Assistant SDK に向き合っています。今回はまず Google Assistant Library ベースでこれまでに行った調査と実験の内容を紹介します。
Google Assistant Library と稼働環境
前掲の表にも記載のあるように、今のところ Google Assistant Library の稼働環境は Python を利用可能な linux-armv7l または linux-x86_64 なプラットフォームに絞られます。周辺機器としてマイクとスピーカが必須。セットアップは下記ページからの説明にそって行えば問題ないでしょう。導入手順の詳細は随所で紹介されているためここでは省略します。
（※ スペックの上では Raspberry Pi 2 Model B/B+ も適合するかもしれません）
手元では作業用に 64bit lubuntu 環境の PC と Raspberry Pi 3 Model B+ を使っています。
hotword.py プログラムのこと
Google Assistant Library をセットアップ後の googlesamples/assistant/library/ フォルダには「hotword.py」プログラムが配置されます。実質 100行ほどの短い内容ですが、`sample` と言いながらこのプログラムを利用すればウェイクワードの検知を含め Google アシスタントとのいつものやりとりをそのまま実現することができます。抽象度が高くフロントエンドをこのようにシンプルに実装できることが Google Assistant Library の大きな特長です。
セットアップずみの SDK ディレクトリ下での hotword.py の実行方法は以下の要領です。引数で指定したプロジェクト ID とモデル ID はホスト側に記憶され、変更の必要がなければ次回以降は省略できます。
$ pwd
/home/t/wk/GoogleAssistant
$ ls
env
$ source env/bin/activate
(env) $ googlesamples-assistant-hotword --project-id [設定ずみのプロジェクトID] --device-model-id [設定すみのモデルID]
hotword.py を PC / Raspberry Pi 3 で実行した様子の動画です。ここでは個人的な好みからウェイクワードへの反応音「ポコッ」の再生をコードに加えています。
|
|
上の動画のラズパイには手持ちの以下のマイク （USB 接続） とスピーカー （3.5mm オーディオジャック接続） を写真の要領でつないでいます。
|
一連の試作においてはこの hotword.py を下敷きにすることにしました。コンパクトで見通しのよい内容でありながらアシスタントとの応酬に必要な要素の一式が収められているためカスタマイズを試みるための土台としてはまさに好適でしょう。この記事の最後の項目に Google Assistant Library プログラミングを行う上での基本的な作法をまとめています。あわせて参照して下さい。
試作
今回手がけた試作をデモ動画と素のままのソースコードを添えて以下に掲載します。
1. 指定テキストに基づく音声合成と読み上げ
テーマ： Google アシスタントの音声合成機能を単体で利用する。いわゆる Text to Speech。
内容
デモ： 動画 48秒
考えたことなど
send_text_query(query)
Sends |query| to the Assistant as if it were spoken by the user.
This will behave the same as a user speaking the hotword and making a query OR speaking the answer to a follow-on query.
Parameters: query (str) - The text query to send to the Assistant.
ソースコード
- hotword_tts.py - github.com/mkttanabe
2. 利用者の発話内容をテキストへ変換
テーマ： Google アシスタントの音声認識機能を単体で利用する。いわゆる Speech to Text。
内容
デモ： 動画 41秒
考えたことなど
ON_CONVERSATION_TURN_STARTED
ON_END_OF_UTTERANCE
ON_RECOGNIZING_SPEECH_FINISHED:
{'text': '今何時'}
ON_RESPONDING_STARTED:
{'is_error_response': False}
ON_RESPONDING_FINISHED
ON_CONVERSATION_TURN_FINISHED:
{'with_follow_on_turn': False}
61 | if (event.type == EventType.ON_CONVERSATION_TURN_FINISHED and
62 | event.args and not event.args['with_follow_on_turn']):
63 | print()
ソースコード
- hotword_input.py - github.com/mkttanabe
3. 利用者の発話内容を他言語へ連続翻訳
テーマ： Google アシスタントの 音声認識 / 文意解釈 / 言語翻訳 / 応答文生成 / 音声合成 の各機能を利用する
内容
デモ： 動画 52秒
考えたことなど
ソースコード
- hotword_translate.py - github.com/mkttanabe
4. 利用者の発話内容を復唱
テーマ： Google アシスタントの音声認識 / 音声合成機能を利用する
内容
デモ： 動画 42秒
考えたことなど
ソースコード
- hotword_echo.py - github.com/mkttanabe
しりとり
テーマ： Google アシスタントの音声認識 / 音声合成機能を利用する
内容
デモ： 動画 58秒
考えたことなど
ソースコード
- 別途
メモ： Google Assistant Library プログラミングの基本
hotword.py を通じて
前述のように Google Assistant Library のインターフェイスは抽象度が高くシンプルに扱うことができる。実ロジック 100 行程度の hotoword.py が Google Home デバイスとほぼ同等に Google Assistant と連携可能であることは興味深い。hotoword.py の内容にあらためて目を向けると、デバイス ID 等の管理情報の取り回し以外の実質的な処理は以下のごく短い内容のみであることが見てとれる。
- hotword.py#L122-L145 より
122 | with Assistant(credentials, device_model_id) as assistant: 123 | events = assistant.start() : 144 | for event in events: 145 | process_event(event)
（リファレンスより）- class google.assistant.library.Assistant(credentials, device_model_id) - developers.google.com
Client for the Google Assistant Library.
Provides basic control functionality and lifecycle handling for the Google Assistant. It is best practice to use the Assistant as a ContextManager:
with Assistant(credentials, device_model_id) as assistant:
This allows the underlying native implementation to properly handle memory management.
Once start() is called, the Assistant generates a stream of Events relaying the various states the Assistant is currently in, for example:
ON_CONVERSATION_TURN_STARTED ON_END_OF_UTTERANCE ON_RECOGNIZING_SPEECH_FINISHED: {'text': 'what time is it'} ON_RESPONDING_STARTED: {'is_error_response': False} ON_RESPONDING_FINISHED ON_CONVERSATION_TURN_FINISHED: {'with_follow_on_turn': False}See EventType for details on all events and their arguments.
- class google.assistant.library.Assistant(credentials, device_model_id) - developers.google.com
- hotword.py#L47-L66 より
47 | def process_event(event): : 56 | if event.type == EventType.ON_CONVERSATION_TURN_STARTED: 57 | print() 58 | 59 | print(event) 60 | 61 | if (event.type == EventType.ON_CONVERSATION_TURN_FINISHED and 62 | event.args and not event.args['with_follow_on_turn']): 63 | print() 64 | if event.type == EventType.ON_DEVICE_ACTION: 65 | for command, params in event.actions: 66 | print('Do command', command, 'with params', str(params))（リファレンスより）- ON_CONVERSATION_TURN_STARTED - developers.google.com
Indicates a new turn has started.
The Assistant is currently listening, waiting for a user query. This could be the result of hearing the hotword or start_conversation() being called on the Assistant.- start_conversation() - developers.google.com
Manually starts a new conversation with the Assistant.
Starts both recording the user’s speech and sending it to Google, similar to what happens when the Assistant hears the hotword.
This method is a no-op if the Assistant is not started or has been muted.- send_text_query(query)
Sends query to the Assistant as if it were spoken by the user.
- send_text_query(query)
- stop_conversation() - developers.google.com
Stops any active conversation with the Assistant.
The Assistant could be listening to the user’s query OR responding. If there is no active conversation, this is a no-op.
- start_conversation() - developers.google.com
- ON_CONVERSATION_TURN_FINISHED - developers.google.com
The Assistant finished the current turn.
This includes both processing a user’s query and speaking the full response, if any.
- ON_CONVERSATION_TURN_STARTED - developers.google.com
ポイント
- Google Assistant との一連の応酬を開始するには google.assistant.library.Assistant クラスのインスタンスを生成し start() をコールする
- 応酬中の状況はイベントベースで捕捉可能
- 対話開始： ON_CONVERSATION_TURN_STARTED
- 対話終了： ON_CONVERSATION_TURN_FINISHED
- 後は EventType ごとに必要な処理を記述
- start_conversation() によりウェイクワードなしで Assistant との対話を開始
- send_text_query() により発話に代え任意のテキストを Assistant へ送出可能
- stop_conversation() により Assistant との対話を任意に終了
(tanabe)
Google Home でローカルの MP3 ファイルをプレイリスト再生する方法
前回の記事では ほりひろ 様による esp8266-google-home-notifier ライブラリと ESP32 ボードを使って構成した Google Home 用キャストエージェントとその利用例を紹介しました。記事ではあわせて同ライブラリをプライベートにカスタマイズした内容として以下を挙げました。
- 元の google-home-notifier に存在する ip 関数を追加
- 元の google-home-notifier に存在する play 関数 （public）を追加
- play 関数による Google Home での MP3 データ再生終了を検知するためのコールバック機構を追加
今回はみっつめの話題について紹介します。
話のきっかけ
Google Home Mini で Spotify など試しているうちに、昔買った音楽 CD をこういう手軽さで聴くことができればと思うようになりました。そのためには楽曲データを MP3 形式等に変換して Google Play Music へアップロードすれば無料で実現できると随所で紹介されています。なかなか魅力的なサービスではありますが、その一方で Google LLC 側の利用規約とのかねあいが気になりました。
手元では日常的に Google LLC の多くの優れたサービスの便宜を享受しており、ひとりのユーザとして同社には敬意と信頼感を持っています。しかし、自分にすべての権利のあるデータであればともかく、自分には所有権しかない楽曲のデータを丸ごとこの規約のもとへ預けることには個人的にためらいがありました。そこで注目したのが google-home-notifier の MP3 データ再生機能です。
google-home-notifier には URL で指定された MP3 データを Google Home へキャストすることのできる play 関数が用意されています。そのため、LAN 上にローカル Web サーバをを立ててそこへ所定の MP3 データを配置し、そのアドレスをこの関数へ渡せば手元の環境からデータを持ち出すことなく Google Home で再生することが可能です。このやり方なら市販の楽曲に対する自分の権利の範囲を踏み越える心配はないでしょう。
ただ、play 関数は一件のデータをワンショットでキャストすることを前提とするもので複数データの連続再生には対応していません。そのため何曲かを順番に流すといったことはできないのが残念です。そこで、この部分に手を加え、所定のプレイリストを参照して複数の MP3 データの順次再生・シャッフル再生ができるようにしてみました。
まずその動作の様子を動画で紹介します。自宅では向かって左側の Raspberry Pi Zero W をローカル Web サーバとして運用しています。このデモでは soundorbis 様によるフリーのジングル曲を使用させて頂いています。
動画：1分15秒
ちなみにここでは以下の IFTTT アプレット （クリックで可読大表示） 経由でローカル Web サーバから再生リスト「demo.txt」（内容）を読み込んで処理を行っています。
トリガー
|
アクション
|
再生リストとその周辺の話題は末尾の「エージェントプログラム」の項に記述しています。
以下、実現に至るまでの経緯を控えます。
対応方法の調査
google-home-notifier の処理内容
まず google-home-notifier の処理を追うことから始めました。以下はそのまとめです。esp8266-google-home-notifier はオリジナルの google-home-notifier が堅実に移植されたライブラリであるためここでは後者をターゲットとしています。
初期設定
- 呼び出し側から ip() 関数により対象とする Google Home デバイスの IP アドレスと言語が指定されればそれを設定
- 呼び出し側から device() 関数により対象 Google Home デバイスのデバイス名と言語が指定されればそれを保持
主処理
- notify() 関数は渡されたテキストを所定の言語で TTS 処理した結果の MP3 ファイルの URL を対象 Google Home デバイスへキャストする
- ここでの音声合成には getSpeechUrl() 関数経由で 「Google 翻訳」の TTS 機能が利用される => GitHub: google-tts
- play() 関数は指定された MP3 ファイルの URL をを対象 Google Home デバイスへキャストする
- notify(), play() はいずれも呼び出された時点で対象 Google Home デバイスの IP アドレスが未設定状態であれば前出 device() 関数経由で保持しているデバイス名で mDNS 照会により対象 Google Home デバイスの IP アドレスを得る => GitHub: mdns
キャストの手順
- notify(), play() はキャスト処理を onDeviceUp() 関数へ投げる。この短い関数が内部で以下の Google Cast v2 処理を呼び出している
- キャスト対象デバイスの 8009 番ポートへ TLS 接続
- Cast v2 プロトコルにそって次のみっつの名前空間の仮想チャネルをコネクション上に作成
- urn:x-cast:com.google.cast.tp.connection - 接続管理用
- urn:x-cast:com.google.cast.tp.heartbeat - 接続維持用
- urn:x-cast:com.google.cast.receiver - デバイスのプレイヤー起動/ 終了/ 音量設定/ 状態確認等
- キャスト対象デバイス標準のプレイヤーである DefaultMediaReceiver （AppID "CC1AD845"） を launch() 、ここで仮想チャネル urn:x-cast:com.google.cast.media （コンテンツのロード/ 再生/ 停止/ 状態確認等） が作成される。このチャネル経由で対象 MP3 の URL を、バッファリング・自動再生指定つきで load() することにより Google Home デバイスでキャスト再生が実行される
- load() が終わったら各仮想チャネルを close してコネクションを切断
注目すべき点と考え方
ポイントは、上記「キャストの手順」の最後の「load() が終わったら各仮想チャネルを close してコネクションを切断」という部分にあります。該当箇所のソースコードを引用します。
- google-home-notifier.js （#L88-L96）
:
var onDeviceUp = function(host, url, callback) {
var client = new Client();
client.connect(host, function() {
client.launch(DefaultMediaReceiver, function(err, player) {
var media = {
contentId: url,
contentType: 'audio/MP3',
streamType: 'BUFFERED' // or LIVE
};
player.load(media, { autoplay: true }, function(err, status) {
client.close();
callback('Device notified');
});
:
このように、Google Home 側の DefaultMediaReceiver へ再生対象データの引き渡し（player.load()）を終えるとプログラムは直ちにデバイスとの接続を閉じそのまま終了しています。あとは Google Home まかせということになりますが、Google Home はデータ再生中に別のデータのキャストが指示されると現在の再生の終了を待つことなくあっさり新しいデータの再生を開始します。そのため、単に google-home-notifier を繰り返し実行しても、その都度データ再生が中断され別データの再生に移るだけで、プレイリスト再生のように「一件の再生が終了〜次のデータを再生」という動きにはなりません。
一方、手元で上記の player.load() 後も接続を維持した状態で観察したところ、Google Home 側でデータ再生が終了すると前掲の仮想チャネル「urn:x-cast:com.google.cast.media」経由でデバイス側からプログラムへ下記要領のメッセージが送出されることを確認しました。
{"type":"MEDIA_STATUS","status":[{"mediaSessionId":1,"playbackRate":1,"playerState":"IDLE","currentTime":0,"supportedMediaCommands":15,"volume":{"level":1,"muted":false},"currentItemId":1,"idleReason":"FINISHED"}],"requestId":0}
このように、接続を維持していればプログラムはデバイス側の再生終了の捕捉が可能であることがわかりました。
この件を含めここまでの一連の事情を踏まえると、google-home-notifier でデータの連続再生を実現するために必要な措置は大きく次のふたつであることがわかります。
なお、Google Cast の仕様にはデータの連続再生を行うためのネイティブの機構が存在するのではないかとも思うのですが、手元では今のところその方面の具体的な情報に行き着いておらず、いずれにせよここではあくまでも現行の google-home-notifier の機能を拡張することにしました。
実装まわりの話題
方針
実装にあたっては次の方針を基本としました。
処理のイメージ
左側のフローは手元での p8266-google-home-notifier とエージェントプログラムによる処理内容を要約したものです。右側はそこに調査から得られた情報を加味して MP3 データのリスト再生機能を追加したイメージで、ざっくり、赤文字の「キャスト処理」「再生監視タスク」の部分をライブラリ側の処理要素と想定しています。なお灰色のブロックは右フローとの共通部分です。 （クリックで可読大表示）
Google Home からのメッセージについて
上記右フローの「再生監視タスク」パート内の条件分岐部分でも触れていますが、データ再生の監視中には Google Home デバイスから仮想チャネル経由でさまざまなメッセージが送られてきます。手元での観察結果から、今回の実装では以下のメッセージを利用しています。
{"type":"MEDIA_STATUS","status":[{"mediaSessionId":1,"playbackRate":1,"playerState":"IDLE","currentTime":0,"supportedMediaCommands":15,"volume":{"level":1,"muted":false},"currentItemId":1,"idleReason":"FINISHED"}],"requestId":0}
{"type":"CLOSE"}
{"type":"PING"}
{"type":"PONG"}
{"type":"MEDIA_STATUS","status":[{"mediaSessionId":1,"playbackRate":1,"playerState":"PAUSED","currentTime":1.880214,"supportedMediaCommands":15,"volume":{"level":1,"muted":false},"activeTrackIds":[],"currentItemId":1,"repeatMode":"REPEAT_OFF"}],"requestId":388729138}
{"type":"MEDIA_STATUS","status":[{"mediaSessionId":1,"playbackRate":1,"playerState":"PLAYING","currentTime":15.665338,"supportedMediaCommands":15,"volume":{"level":1,"muted":false},"activeTrackIds":[],"currentItemId":1,"repeatMode":"REPEAT_OFF"}],"requestId":388729139}
なお「"requestId":0」のメッセージがデータの再生開始時点で一度発行されるため上記と混同しないよう注意
{"type":"MEDIA_STATUS","status":[{"mediaSessionId":1,"playbackRate":1,"playerState":"PLAYING","currentTime":1.384362,"supportedMediaCommands":15,"volume":{"level":1,"muted":false},"activeTrackIds":[],"currentItemId":1,"repeatMode":"REPEAT_OFF"}],"requestId":0}
ソースコード
カスタマイズした esp8266-google-home-notifier
オリジナルの esp8266-google-home-notifier ライブラリのコードへプライベートに手を加えています。変更箇所は「#ifdef TANABE」部分で、fork した GitHub リポジトリへ反映しています。変更内容はこの記事の冒頭、および前回の記事で触れたとおりです。
$ git clone -b private https://github.com/mkttanabe/esp8266-google-home-notifier.git
また、同リポジトリの examples/esp32/SimpleUsage/ 下に play 関数用のサンプルスケッチを加えました。どちらもオリジナルの SimpleUsage.ino のコピーを小さく書き替えたものです。
play 関数を再生終了通知用コールバック関数指定なしで呼び出すもの
play 関数を再生終了通知用コールバック関数指定つきで呼び出すもの
このふたつの追加サンプルを実行した様子の動画です。
エージェントプログラム
Arduino core for the ESP32 環境で作成したエージェントの Adruino スケッチです。前回分と互換性のある機能拡張版です。
- GoogleHomeNotifierESP32AgentEx - github.com/mkttanabe
GoogleHomeNotifierESP32Agent.ino の 以下の箇所を環境にあわせて書き替える
//------- ユーザ定義 ------------------
// Google Home デバイスの IP アドレス, デバイス名
// 有効にすれば指定 IP アドレスを直接使用
// 無効にすれば指定デバイス名で mDNS 照会
//#define USE_GH_IPADRESS
IPAddress myGoogleHomeIPAddress(192,168,0,110);
#define myGoogleHomeDeviceName "room02"
// WiFi アクセスポイント
#define ssid "ssid"
#define password "pass"
// Beebotte 情報
#define mqtt_host "mqtt.beebotte.com"
#define mqtt_port 8883
#define mqtt_topic "test01/msg"
#define mqtt_pass "token:" "token_************"
// MP3 データを配置する Web サーバ
#define dataServer "192.168.0.127"
#define dataServerPort 80
// MP3 データの URL
#define MP3DataFmt "http://" dataServer "/sound/%s.mp3"
// MP3 再生リストのパス
#define MP3ListFmt "/sound/list/%s.txt"
//-------------------------------------
上の記述の場合、自分の Beebotte アカウントの Channel "test01", Resource "msg" のメッセージの data キーの値に応じて以下が行われる- data 値の先頭文字がアスタリスクであれば音声合成用のテキストとみなして google-home-notifier の TTS 処理にかける
- 例） {"data":"*こんにちは"} => 「こんにちは」と発話
- data 値の先頭文字がアスタリスクまたは "@" でなければ MP3 ファイル名とみなし所定の Web サーバの URL に編集して再生
- 例） {"data":"file01"} => "http://192.168.0.127/sound/file01.mp3" をキャスト
- data 値の先頭文字が "@" であれば MP3 データ再生リスト名とみなし所定の Web サーバの URL に編集して読み込み、記述されている各 MP3 データエントリを再生
- 例） {"data":"@demo"} => "http://192.168.0.127/sound/list/demo.txt" を再生リストとして読み込んで処理
- 下記の指定があればシャッフル再生を行う
{"data":"@demo,1"} , {"data":"@list01,ランダム"}
- 上記以外ならリスト上の記述順に再生
- 下記の指定があればシャッフル再生を行う
- 再生リストの記述例
demo.txt# 各行の '#' 以降はコメントとして扱われる
# 空行は無視、有効行先頭末尾のスペース・タブは除去される
# soundorbis 様によるフリー BGM 作品より
#
# 【フリーBGM】リコーダージングル【01〜05】
# https://www.youtube.com/watch?v=ztm1CSZEpY8
#
# 利用規約
# https://www.soundorbis.net/license
#
demo/[1]nc150689
demo/[2]nc150690
demo/[3]nc150691
demo/[4]nc150692
demo/[5]nc150693
- 例） {"data":"@demo"} => "http://192.168.0.127/sound/list/demo.txt" を再生リストとして読み込んで処理
なお、上の「ユーザ定義」箇所において「#define USE_GH_IPADRESS」が無効な場合は前回版と同様に mDNS 照会によりデバイス名から IP アドレスを取得するが、このやや時間のかかる照会のコストを軽減するために、今回の拡張版においては一旦取得した IP アドレスを ESP32 のフラッシュメモリ領域 （SPIFFS） へ記録し次回はまずそれを参照する処理を加えている。当該アドレスへアクセスできない場合や当該アドレスのデバイスを Google Home と識別できない場合はあらためて照会と記録を行う。詳細は DeviceAddress.cpp を参照のこと - data 値の先頭文字がアスタリスクであれば音声合成用のテキストとみなして google-home-notifier の TTS 処理にかける
こういった経緯を経て形になったのが冒頭のデモ動画で稼働しているエージェントです。Raspberry Pi Zero W のローカル Web サーバとペアでとても快適に利用しています。
(tanabe)
Google Home を拠点間の双方向コミュニケーションに利用する
ESP32 版 google-home-notifier のこと
google-home-notifier の ESP8266 移植版「esp8266-google-home-notifier」の作者である ほりひろ 様が、今年（2018年）6月に ESP32 への対応を実施されました。node.js プログラムであるオリジナルの google-home-notifier を実行可能なもっとも小振りなプラットフォームはラズベリーパイですが、さらにコンパクトで消費電力の少ない ESP32 ボードで自由に Google Home へのキャストを実現できることには大きな魅力があります。自宅ではこの素晴らしいライブラリを使って MQTT メッセージをトリガーにキャスティングを行う内容のエージェントを構成し様々な要件で利用させて頂いています。
「声のアバター」によるやりとり？
そんな中で先日ふと、google-home-notifier の「Google Home で任意の音を出せる機能」と、Google Home 側の「音声で所定の処理を実行できる機能」の組み合わせを、離れた拠点間での定型的なコミュニケーションに利用できるのではないか？ と思い立ちました。図のようなイメージです。
双方のエージェントがそれぞれ MQTT ブローカー上の別のトピックを Subscribe しておき、必要に応じて相手のトピックへメッセージを Publish することで現地の Goole Home が所定のアナウンスを行います。その内容に対する所定のフレーズでの応答で相手へ向けての処理を発動する形にしておけば、いわば「声のアバター」を通じて両者間のやりとりが成立すると考えました。同じく音声による連絡方法であっても電話とは異なりこのやり方には直接的な拘束感やある種の重さがないため双方ともより手軽により淡々と利用できるでしょう。
試作のシナリオ
いろいろ使途がありそうですが、手元ではまず個人的に現在もっとも身近なテーマである「高齢者世帯の安否確認」を想定したシナリオを形にしてみました。以下の内容です。
A：見守り側
B：高齢者世帯側
- A => Google Home A：「ねえ Google、安否を確認」
- Google Home A => A：『はい、これから声をかけてみます』
- Google Home B => B：『身のまわりは大丈夫ですか？問題がない場合は "ねえ Google、順調です" と話しかけて下さい。もし何かご相談があれば、"ねえ Google、コールして" と話しかけて下さい』
- パターン 1： B => Google Home B：「ねえ Google、順調です」
- Google Home B => B：『それはよかったです。さっそく大丈夫と伝えておきますね』
- Google Home A => A：『先方から "元気です"と音声連絡がありました。メールを確認して下さい』
- A あてにメールが届く
- パターン 2： B => Google Home B：「ねえ Google、コールして」
- Google Home B => B：『はい、すぐに電話をするようにと伝えます』
- Google Home A => A：『先方から "電話してほしい"と音声連絡がありました。メールを確認して下さい』
- A あてにメールが届き携帯電話が数回コールされる
相手が高齢者でもあるため Google Home からのアナウンスにはとりわけ「聞き取りやすさ」が求められます。定型の文言なので毎回音声合成を行う必然性もなく、ここでは、google-home-notifier の notify 関数から呼び出される Google 翻訳 TTS を使うのではなく、複数のオンライン TTS サービスを試した中で個人的にもっとも自然に感じられた音声を収録した MP3 データを play 関数で再生することにしました。
動作の様子
後出のプログラムリソース一式を使って二組の「Google Home Mini + エージェント」間でやりとりを行った様子の動画です。
（パターン 1： 「安否を確認」 〜 「順調です」 1分17秒
（パターン 2： 「安否を確認」 〜 「コールして」） 1分16秒
リソース
esp8266-google-home-notifier のカスタマイズ
前述のように手元では作成したエージェントをさまざまな要件で利用しており、この間にオリジナルの esp8266-google-home-notifier ライブラリのコードへ何点かプライベートに手を加えています。変更箇所は「#ifdef TANABE」部分で、fork した GitHub リポジトリへ反映しています。
$ git clone -b private https://github.com/mkttanabe/esp8266-google-home-notifier.git
変更内容
エージェントプログラム
Arduino core for the ESP32 環境で作成したエージェントの Adruino スケッチです。MQTT ブローカーに Beebotte を使用しています。
- GoogleHomeNotifierESP32Agent - github.com/mkttanabe
GoogleHomeNotifierESP32Agent.ino の 以下の箇所を環境にあわせて書き替える
//------- ユーザ定義 ------------------
// Google Home デバイスの IP アドレス, デバイス名
// 有効にすれば指定 IP アドレスを直接使用
// 無効にすれば指定デバイス名で mDNS 照会
#define USE_GH_IPADRESS
IPAddress myGoogleHomeIPAddress(192,168,0,121);
#define myGoogleHomeDeviceName "room01"
// WiFi アクセスポイント
#define ssid "ssid"
#define password "pass"
// Beebotte 情報
#define mqtt_host "mqtt.beebotte.com"
#define mqtt_port 8883
#define mqtt_topic "test01/msg"
#define mqtt_pass "token:" "token_************"
// MP3 データを配置する Web サーバとデータパス
#define dataServer "192.168.0.126"
#define dataServerPort 80
#define MP3DataFmt "http://" dataServer "/sound/%s.mp3"
//-------------------------------------
上の記述の場合、自分の Beebotte アカウントの Channel "test01", Resource "msg" のメッセージの data キーの値に応じて以下が行われる.- data 値の先頭文字がアスタリスクであれば音声合成用のテキストとみなして google-home-notifier の TTS 処理にかける
- 例） {"data":"*こんにちは"} => 「こんにちは」と発話
- data 値の先頭文字がアスタリスクでなければ MP3 ファイル名とみなし所定の Web サーバスペースの URL を編集して再生
- 例） {"data":"file01"} => "http://192.168.0.126/sound/file01.mp3" をキャスト
- data 値の先頭文字がアスタリスクであれば音声合成用のテキストとみなして google-home-notifier の TTS 処理にかける
用意した IFTTT アプレット
今回の試作では、トリガーに Google Assistant サービス、アクションに WebHooks サービスをアサインしたみっつの IFTTT アプレットを使っています。 ※ いずれもクリックで可読大表示
-
問い合わせフレーズ「安否を確認」対向のアプレット
アクションで Beebotte 上の相手側 "test02/msg" トピックへ "AnpiQuery.mp3" のキャスト再生を指示するメッセージを Publish
トリガー
アクション
-
応答フレーズ「順調です」および「コールして」に対向のアプレット
アクションで次項の Google Apps Script による Web アプリコードを所定のパラメータを添えて実行
トリガー
アクション
トリガー
アクション
Google Apps Script による Web アプリコード
上のふたつの応答用アプレットから呼び出している GAS コードです。
アプレットから渡される res パラメータの値は「safe」。
Beebotte 上の相手側 "test01/msg" トピックへ "AnpiSafe.mp3" のキャスト再生を指示するメッセージを Publish して「元気です」と Gmail を送信
アプレットから渡される res パラメータの値は「doCall」。まず Twillio 経由で相手の携帯電話を数回コールしてから Beebotte 上の相手側 "test01/msg" トピックへ "AnpiDoCall.mp3" のキャスト再生を指示するメッセージを Publish して「電話がほしい」と Gmail を送信
/*
AnpiResponse
2018-07
*/
var ADMIN = "***********@gmail.com";
function doGet(e) {
return ContentService.createTextOutput("??");
}
function doPost(e) {
return doIt(e);
}
function doIt(e) {
var msg, mp3Name;
var res = e.parameter.res;
var where = e.parameter.where;
if (res == "safe") {
msg = "元気です";
mp3Name = "AnpiSafe";
} else if (res == "doCall") {
msg = "電話がほしい";
mp3Name = "AnpiDoCall";
doPhoneCall(); // twilio
} else {
return ContentService.createTextOutput("res not found");
}
doPublish(mp3Name); // MQTT
// gmail
doSendMail(ADMIN, "Anpi", ADMIN, ADMIN,
"安否連絡 [" + res + "]",
curDate() + " " + curTime() + "\n" +
where + " より 「" + msg + "」と連絡がありました");
return ContentService.createTextOutput("OK");
}
function curDate() {
var d = new Date();
return d.getFullYear() + '-' +
('00' + (d.getMonth()+1)).slice(-2) + '-' + ('00' + d.getDate()).slice(-2);
}
function curTime() {
var d = new Date();
return ('00' + d.getHours()).slice(-2) + ':' +
('00' + d.getMinutes()).slice(-2) + ':' + ('00' + d.getSeconds()).slice(-2);
}
function doPhoneCall() {
var url = "https://api.twilio.com/2010-04-01/Accounts/****************/Calls";
var data = "To=%2B************&From=%2B***********0&Url=http://demo.twilio.com/docs/voice.xml&Timeout=10";
var options = {
method: "POST",
headers: {
"Authorization":"Basic QUMxZjdhYTIzZWM2YTdkNWM*************************",
"Content-Type":"application/x-www-form-urlencoded"
},
payload: data,
muteHttpExceptions: true
};
var response = UrlFetchApp.fetch(url, options);
}
function doPublish(mp3Name) {
var url = "https://api.beebotte.com/v1/data/publish/test01/msg";
var data = '{"data":"' + mp3Name + '"}';
var options = {
method: "POST",
headers: {
"X-Auth-Token":"token_****************",
"Content-Type":"application/json"
},
payload: data,
muteHttpExceptions: true
};
var response = UrlFetchApp.fetch(url, options);
}
function doSendMail(from, fromName, to, cc, subject, body) {
GmailApp.sendEmail(
to,
subject,
body,
{
from: from,
name: fromName,
cc: cc
}
);
}
現行の Google Home ではサポートされていない「能動的な発話」を擬似的に実現する google-home-notifier を利用しなければできないことであり、こういった使い方も同プログラムの実用的な応用例のひとつではないかと思います。さらに発展させることもできるでしょう。面白い時代になりました。
余談：「うるさいアラーム」機能を DIY した話
手元での google-home-notifier の利用例をもうひとつ紹介します。 Google Home のアラーム機能は手軽で何かと便利なので目覚まし用に使ったりしていました。ところがプリセットのアラーム音がいささか上品すぎるため手元では音量を最大にしても目覚めにつながらないケースが何度かありました。同じ経験をした方はおそらく少なくないのではないかと思います。
ちなみに、Google は 2018-02-01 のアップデートで Google アシスタントのアラーム音を変更可能としたようですが、この機能を利用できるのは現時点では言語設定が英語の場合のみで日本語環境では利用できません。
後日の対応に期待しつつ、前掲のエージェントを利用して耳障りでうるさいアラームを鳴らす機能を自作してみました。
まず、アラーム設定用・解除用の下のふたつの IFTTT アプレットを用意しました。所定のシートの A1 セルを使って音を鳴らす時刻の設定・解除を行う内容です。設定用のアプレットでは Google Assistant トリガーのオプション "Say a phrase with both a number and a text ingredient" での "a number" と "a text" を使って時・分のふたつの音声指示要素を受け入れています。
トリガー
|
アクション
|
トリガー
|
アクション
|
あわせて当該シートに以下の GAS コードを付与、スクリプト実行のトリガー「時間主導型」の「分タイマー」で「1分ごと」に doNotify() 関数の呼び出しを設定しました。シートに記録された時刻と現在の時刻が一致すると、Beebotte 上の "test01/msg" トピックへ "noise01.mp3" のキャスト再生を指示するメッセージが Publish されます。
// Beebotte へ MQTT メッセージを Publish
function doPublish(mp3Name) {
var url = "https://api.beebotte.com/v1/data/publish/test01/msg";
var data = '{"data": "' + mp3Name + '"}';
var options = {
method: "POST",
headers: {
"X-Auth-Token":"token_*************",
"Content-Type":"application/json"
},
payload: data,
muteHttpExceptions: true
};
var response = UrlFetchApp.fetch(url, options);
}
function doNotify() {
// シートをチェック。A1 に時刻が設定されていれば騒音を鳴らす
var spreadSheet = SpreadsheetApp.getActiveSpreadsheet();
var sheet = spreadSheet.getSheets()[0];
var val = sheet.getRange("A1").getValue();
Logger.log(val);
if (val == 0) {
return;
}
var hm = val.split("_");
Logger.log("set => " + hm[0] + ":" + hm[1]);
if (hm[0] >= 24 || hm[1] >= 60){
//Logger.log("invalid");
return;
}
var dt = new Date();
var min = dt.getMinutes();
var h = dt.getHours();
if (String(h) == hm[0] && String(min) == hm[1]) {
sheet.getRange("A1").setValue("0");
doPublish("noise01");
}
}
動作の様子： 動画 32秒
このように単機能でごくシンプルなものですが、手元では結構役に立っています。
(tanabe)
