Galapagos Tech Blog

株式会社ガラパゴスのメンバーによる技術ブログです。

ProtoPieでAppStore動かしてみた! 第2回

こんにちは。UIデザイナーのまあのんです。本格的な冬到来でちょっぴり風邪気味です。ずび


ProtoPie動かしてみたレポート第二回目になります。
一回目の記事はこちら↓

gtech.hatenablog.com

前回はsketchで作成したデザインをProtopieにinportしましたね。


-動かす流れおさらい-

  • スクロールする

  • イメージをタップすると詳細ページに遷移する

  • 詳細ページに遷移する時にイメージが拡がる

  • 一覧に戻る時イメージが縮む



今回はスクロールとページ遷移する途中までつくっていきます!

Step2.画面全体をスクロールさせる



① まずはスクロール可能な範囲をまるっとグループ化(⌘G)してレイヤー最下層に。画面に固定表示したいレイヤーは上にしておきましょう。

固定で見せたいステータスバーとタブバーを残して他はグループ化。 f:id:glpgsinc:20171215164940p:plain:w400

②そしてグループレイヤーを選択しつつ、メニューからScroll Containerを選択するとグループの上に表示されます。
f:id:glpgsinc:20171215173146p:plain:w400
Scroll Containerは、レイヤーパネルからコンテナ内にレイヤーを配置するとコンテナのスクロールやページングが可能になります。
プロパティパネルでスクロール方向やオーバースクロールした時のリアクションが設定できます。

!注意!
Scroll Containerを選択してもあくまでレイヤーパネルに追加されただけです。グループをScroll Containerにひゅっと移動させることを忘れずに!
(これよくわからず地味に苦戦してました、、)


f:id:glpgsinc:20171215173507p:plain:w400
レイヤー名の階層が変わり、グループが左上の正方形にマスクされたら成功です。

③Scroll Containerを選択した状態で、マスクされてる範囲をバイスサイズに合わせましょう。レイヤーサイズではないので気をつけて。


それでは、
Previewを見てみましょう


f:id:glpgsinc:20171215175315g:plain:w160

第一段階成功です!!!
作ってる側はこれだけで謎の感動があったりします



Step3.イメージをタップして遷移する


f:id:glpgsinc:20171215192530g:plain:w160
次にこの動きをProtopieのできる範囲で再現していきます。
最大の難関の予感、、





複雑なインタラクションなので、まずは対象のトリガーとそれに対するレスポンスを整理してみましょう。


【トリガー】
f:id:glpgsinc:20171215193916p:plain:w200
『今日のAPP』エリアをタップ


【レスポンス】(ざっくり)

  • 画像やタイトル:上部に移動しながら画面の横幅全体に広がる

  • アプリ詳細画面のテキストエリア:画像から下ににゅっと伸びながら出現

  • closeボタン:上部に移動しながら出現


f:id:glpgsinc:20171215194115p:plain:w200
遷移完了。


このレスポンスをさらに分解して一つずつ動作を追加していきます。


それではProtopieで実際に動きをつけてみましょう。

f:id:glpgsinc:20171215182908p:plain:w700

① レイヤーパネルからタップする対象のレイヤーを選択します。
②次に、Add Triggerを選択して、Tapを選択してください。

f:id:glpgsinc:20171215191235p:plain:w700
Tapの下に➕が現れましたね。
➕はトリガーに対するレスポンスを選択できます。

f:id:glpgsinc:20171218013940p:plain:w300
③虹の画像エリアを画面上部に動かすため、レイヤーで虹画像を選択しながら➕ではmoveを選択します。

f:id:glpgsinc:20171218014055p:plain:w500
右のインスペクターパネルではその時の大きさの変化量などを定義することができます。
今回はパーツを画面最上部に配置したいので、move項目のXYの値を調節していきます。 アニメーションのタイミングやイージングなどもここで細かく設定できます。

f:id:glpgsinc:20171218015632g:plain:w160
プレビューで確認。位置はこんな感じかな。


レスポンスの選択は直感的で簡単にできますね。これをうまく組み合わせていけば複雑なインタラクションも難なくできます!
この要領で他のレスポンスも追加していきます。

、、、といったところで今日はここまで!

次回で完成までもってきます!宣言!
12月21日更新予定です。


参考記事
https://www.protopie.io/learn/
さよなら Pixate, よろしくProtoPie – heru – Medium
【Protopieのススメ】UIデザイナーのためのインタラクションモックアップツール - Qiita

Gitブランチモデルのおはなし

ご機嫌よう、ガラパゴスのおとめです。

突然ですが皆さまGitをお使いですね? どんなブランチモデルを採用されているのかしらん? 特に意識されていない? Git Flow? GitHub Flow? GitLab Flow? MyGreat Flow? どれにも一長一短あって、何かしら工夫されているかと思います。

そこで今日は、ガラパゴスのサーバーサイド開発の一例を紹介をしてみましょう(全社的にそうしているわけではありません)。

この記事はガラパゴスアドベントカレンダーの15日目の記事です

ブランチモデルって必要?

まず、どうしてブランチモデルが必要なのか例え話をしましょう。何も考えずにブランチを分けていったとします。そしてあるブランチの変更が別のブランチで必要になったとして……

f:id:glpgsinc:20171213164411p:plain

そうやってできたブランチ同士でcherry-pickとかしていたらどうなるでしょう? いかにも衝突しそうですね?

f:id:glpgsinc:20171213172121p:plain

あるいは、それぞれで別個に同じマイグレーションをしていたら? デプロイするときに発覚しそうですね?

f:id:glpgsinc:20171213172925p:plain

こうしてオフィスに呪いが撒き散らされました。

〜完〜

……。

GitLab Flowのおはなし

もちろん実際にオフィスに呪いが撒き散らされるようなことは避けたいです。というわけで、ここしばらく、GitLab Flowをもとにしたブランチモデルを使っていて、ガラパゴスのおとめは「やりやすい」と思っていました。GitLab Flowそのものは次のような紹介記事を読めば良いかしらん?

読んでいただいた前提でお話を進めますね。

GitLab Flowのつらいところ

中には、変更はmasterや本番ブランチにcherry-pickするような説明があったかと思います。でも、変更をいちいちcherry-pickするのは面倒じゃなくてですか? 複数のコミットに別れていたりして、一部だけ反映するのを忘れたりするような事故がいかにも起こりそうに思えます。

それに、ガラパゴスではアプリ開発をしていますが、アプリは開発時にサーバーサイドのどのブランチを参照すれば良いのでしょう。

ガラパゴスでは、以下のようなブランチ構成になっています。

  • feature:開発・ホットフィックス(実際のブランチ名は内容を表すものにします)。
  • master:幹。開発中の最新版。unstable。
  • integration:開発中のアプリ向け。masterよりはstableに近い。
  • staging:QA用(pre-productionと同義)。integrationよりはstableに近い。
  • production:本番。stable。

Galapagos Flow

基本的な運用はこうなりました。

まず、新しい機能ブランチは、masterから分岐して作ります。また、それぞれのトピックブランチに何かをマージする時には、親ブランチからしかマージしないことにします。

f:id:glpgsinc:20171213213844p:plain

そして、親ブランチにマージするときも、cherry-pickではなくマージします。このとき(特に理由がなければ)トピックブランチは削除します(図は単純化しています)。

f:id:glpgsinc:20171213175242p:plain

最終的に変更はmasterまでマージされましたね?

ガラパゴスのGitブランチモデルでは、基本的にmasterブランチはunstableです。ところでmasterブランチがunstableなら、どうやって品質を確認するのかしらん? ガラパゴスではGitLabを使っていますので、ちょっとした設定でGitLab CIも使うことができます。はい、ご想像の通り、CIが通らなければマージできないし、テストがなければマージしません。

そして、integrationではアプリの王子様からのフィードバックがあり、stagingでは検証の姫君からのフィードバックがあります。これらのフィードバックは、masterから分岐したブランチで修正します。

そこで、masterブランチがstableに近い瞬間が生まれると想像してください。チケットを消化した状態。そう、この瞬間です。これがGitLab FlowでいうPre releaseブランチにcherry-pickする瞬間です。でも、先にもお話したように、ここで行われるのは、merge masterです。

f:id:glpgsinc:20171213185909p:plain

一方で本番環境でHotFixを当てることもあります。こちらはproductionブランチから分岐します。

f:id:glpgsinc:20171213190938p:plain

さいごに

プロジェクトの大きさなどによっても適したブランチモデルは変わると思います。今回お話したモデルは、あんまり大規模な開発には向いていないかもしれません。でも、安全で適切なやり方ができるといいですね。

さて、次回はガラパゴスの女神様によるProtoPie第2回の予定です。ぜひご覧ください。

ところで

MacBook Pro Late 2016のTouchBarモデルを使っていて、TouchBarが消えてしまうことがありませんか? 復活方法を調べても、掲載されている方法で復活したことがありません。特に困るのはvimで何かしらのモードに入っている時で、escキーが押せないのでモードから抜けられません……。

そんな時、実はescにはショートカットがあります。^[ でescキーと同じ効果が得られますのでお試しあれ。


ガラパゴスでは、安全な運用を考えたり、Macを再起動せずにTouchBarを復活できるエンジニアを募集しています。皆様のご応募お待ちしています。

では、ご機嫌よう。

この記事は業務の一環として業務時間中に書きました

我が家事情

ガラパゴスのコードヒーヨアン(twitter: @luinily)です。

今回は会社の業務と関係のある話ではなくて、私が個人活動で作った家の自動化システムの紹介をしようと思います。

始まり

始まりは日本の家とエアコンの設定にあります。 日本の家は冬で寒くて、朝に暖房入れないと部屋が寒くて布団から出にくくなっています。 そのためにエアコンが朝に自動的に着くように設定していますが、毎日設定する必要もあって、1時間単位で設定しかできないので設定する時間も考えないといけません。朝起きて、寝ぼけたまま家を出た場合、エアコンを消すの忘れて、つけっぱなしにしてしまうこともあります。

hOme(2016年)

この状況を改善したい思っていて、自動化できないか調べ始めました。

そこで見つけたのはIRKitというデバイス

IRKitWi-Fiでつなげられる赤外線お受信、送信できるデバイスです。iOSSDKがありますが、curlリクエストでも操作できます。

curlで使うと、IRKitが赤外線を受信して、その信号を取得したい時はこういうリクエストを送ります。

% curl -i "http://10.0.1.2/messages" -H "X-Requested-With: curl"

こういうレスポンスが来ます:

HTTP/1.0 200 OK
Access-Control-Allow-Origin: *
Server: IRKit/1.1.1.11.aaa11a11
Content-Type: text/plain

{"format":"raw","freq":38,"data":[18031,8755,1190,1190,1190,3341,1190,3341,1190,3341,1190,1190,1190,3341,1190,3341,1190,3341,1190,3341,1190,3341,1190,3341,1190,1190,1190,1190,1190,1190,1190,1190,1190,3341,1190,3341,1190,1190,1190,3341,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,3341,1190,3341,1190,3341,1190,3341,1190,3341,1190,65535,0,9379,18031,4400,1190]}

赤外線の信号はformat, freq, dataのフィルドにあるデータ、同じ情報をIRKitに送信すれば、IRKitがその赤外線信号を発信します。

リクエスト:

% curl -i "http://10.0.1.2/messages" -H "X-Requested-With: curl" -d '{"format":"raw","freq":38,"data":[18031,8755,1190,1190,1190,3341,1190,3341,1190,3341,1190,1190,1190,3341,1190,3341,1190,3341,1190,3341,1190,3341,1190,3341,1190,1190,1190,1190,1190,1190,1190,1190,1190,3341,1190,3341,1190,1190,1190,3341,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,3341,1190,3341,1190,3341,1190,3341,1190,3341,1190,65535,0,9379,18031,4400,1190]}'

レスポンス:

HTTP/1.0 200 OK
Access-Control-Allow-Origin: *
Server: IRKit/1.1.1.11.aaa11a11
Content-Type: text/plain

IRKitと連携して、マックにサーバーソフトを作って、決めた時間などでエアコンの制御信号を送れるようにすれば、自動化できるのではないかと思いました。

ちょうどその時期Swiftの勉強をしたかったので、Swiftでマックのアプリを書き始めました。実装した機能は:

  • IRKitからの赤外線信号を取得
  • 登録したデバイスにコマンドの追加
  • コマンド送信
  • スケジューリング機能、曜日と時間を指定して自動的に送信される
  • iCloudで設定の保存

アプリがそろそろ使えそうな状態になっていたので、サーバーのためのMac miniを買おうとしましたが、そこでiPad Air 2の方が1万円ほど安いと気づいて、UIをiOSように作り直し、iPadのアプリにしました。

iOSではバックグラウンドに制限がかかっていて、アプリのをバックグラウンドで起動させながら自動化させるのは難しいと思いって、専用のiPadでアプリが常に起動してるような形にしました。

そのアプリは1年ぐらい使いました。冬のエアコンやベッドの電気布団の電源現入切の自動化などに使っていましたが、UIがなかなか完成せず、設定を変えたいときはiCloudでデーターを直接編集する必要があったため、使いにくかった。 それに、PhilipsのHue電球などのサービスと連係したいときは追加開発が必要になりますので、将来的に運用が重くなると思いました。

もっといい方法がないかと悩んでいた時に、homebridgeに出会いました。

homebridge + HomeKit (2017)

HomeKitについて

f:id:glpgsinc:20171205192705j:plain
ホームアプリ

HomeKitはAppleiOS 8から提供してるスマートホームのためのAPIiOS 10からHomeKit用のアプリHomeが追加されました。

HomeKitに対応するデバイスはHomeKitを対応するアプリとSiriから操作できるようになる。HomeKitは家の中でのスマートデバイスをまとめて管理・操作するためのフレームワークです。

ホームアプリはHomeKitのGUIになります。デバイスの追加、シーンの作成などが標準アプリでできるようになりました。アプリを提供始めたと同時に、Apple TVやiPadをHomeKitサーバーとして使えるようになり、オートーメーションルールやiCloudアカウント経由での遠隔操作ができるようになりました。

PhilippsのHue電球はHomeKit対応していて、このまま追加してホームアプリから明度、色相などの設定ができます。ただし、エアコンなどは赤外線でしか操作できなくHomeKitの対応していません。そこでhomebridgeの出番です。

homebridgeについて

homebridgeはHomeKitのAPIエミューレートするをNodeJSのサーバーです。homebridgeの中で設定されているデバイスがHomeKitに追加できるようになり、iPhoneのホームアプリ、Siri、HomeKitのオートーメーションなどで操作できるようになる。homebridgeはRaspberry Piで設定することができます。

homebridge単体でほとんど何もできませんが、プラグインをサポートしていて、npmにある無数のプラグインでいろんなデバイスの対応ができます。homebridge-irkitというプラグインがあって、そのプラグインを使えば、IRKitをHomeKitから操作できるようになります。操作感としてはOn/Offボタンになります。

設定してみると

設定はhomebridgeの設定ファイルの中に書きます:

{
   //homebridgeの情報
   "bridge": {
       "name": "Homebridge",
       "username": "DD:23:2F:E2:DF:20",
       "port": 51826,
       "pin": "000-00-00",
       "manufacturer": "@nfarina",
       "model": "Homebridge",
       "serialNumber": "0.4.20"
   },
  
   "description": "Hombridge",

   "accessories": [
       // homebridge-irkit のデバイスの設定
       {
           // homebridge-irkitのデバイスであること
           "accessory": "IRKit",
           //追加時ホームアプリに表示される名称
           "name": "irkit control device",
           //そのデバイスの操作に使うIRKitデバイス 
           "irkit_host": "irkitxxxxx.local", 
           //オンにするための赤外線信号情報
           "on_form": {"format":"raw","freq":38,"data":[]},
           //オフにするための赤外線信号情報 
           "off_form": {"format":"raw","freq":38,"data":[]} 
       }
   ],



   "platforms": []
}

僕が使っている設定にするとこうなります:

  • 暖房30度 On/Off
  • 冷房27度 On/Off

ホームアプリから暖房と冷房がつけられるようになりました。

うちにApple TVがありまして、HomeKitのサーバーとして設定してありますので、オートーメーションの設定ができます。冬だけ有効にする平日の朝、設定した時間に暖房をつけて、消すオートーメーション(週末は寝る時間、起きる時間が不規則なので、手動で設定しています)夏は平日の夜に冷房入れて、朝に消すオートーメーションも設定しました。

homebridgeでエアコンとHomeKitの連携ができ、簡単にオートーメーションができるようになりました。 自分で作っていたアプリに比べると保守コストがほとんどなく、homebridgeやHomekitの対応デバイスが増えれば簡単に家の自動化が進められるようになりました。スマホやSiriからの操作と遠隔操作、自作のアプリになかった機能も使えるようになりました。

さらに改善していく

今までの流れをまとめると:

2016年、自作アプリで自動化。

  • エアコンの自動化ができる
  • アプリ未完成のため、設定しにくい
  • 自作のため、保守や拡張コストが高い

ハード:

  • IRKit(一つの部屋に1台)
  • 専用iPad

2017でHomeKitとhomebridgeを導入

  • エアコンの自動化ができる
  • 設定しやすい
  • スマホで操作可能
  • Siriで操作可能
  • 遠隔操作可能

ハード: * IRKit(一つの部屋に1台) * Raspberry Pi

ただしその時点からまた改善できる点があります。

まずはオートーメーションについて、ルールは手動で有効か無効にする必要があります。家に誰いなくてもオートーメーションが有効であれば設定通りに実行されます。できれば人がいない時は実行されないようにしたいのと、寒い時は暖房のオートーメーション、暑い時は冷房のオートーメーションが実行れれば何も触らなくても一年中に使えるようになります。

もう一つはhomebridge-IRKitの方です。エアコンは一つなのに、複数の設定(暖房、冷房など)をすると連携されていないボタンとして認識されます。

例えば下記の流れの操作でボタンの状態がどうなるかみてみよう:

  • 最初はエアコンがオフ状態、暖房と冷房のボタンも両方オフになっています
  • 暖房のボタンで暖房オンにします。暖房の赤外線信号が送信され、エアコンが暖房になります。ボタンの方は暖房がオン、冷房がオフ
  • 冷房のボタンで冷房をオンにします。冷房の赤外線信号が送信され、エアコンが冷房になります。ボタンは冷房がオンになりますが、暖房は冷房の操作で影響受けずにオンのままになります。

この時点でホームアプリからみると冷房と暖房両方オンになっている。ただしエアコン一つだけなので、最後に送られた信号の状態になっています(この例では冷房)

さらに操作を続く * 暖房のボタンで暖房をオフにします。エアコンオフの赤外線信号が送信され、エアコンがオフになります。ボタンは暖房がオフ、冷房がオンのままです。

問題は赤外線でエアコンなどのデバイスを操作する時は、デバイスの実際の状態がわからないので、最後に送った信号の状態になっているという想定をするしかありません。On/Offという状態しかない時は問題ありませんが、エアコンみたいに複数の状態があるときに(ここは暖房、冷房、オフ)連携されてないボタンでしか表現できないため、ボタンの状態とデバイスの状態がズレやすい、ボタン間の状態もずれてしまいます。

まとめると気になるところが3点あります:

  • 人がいなくてもオートーメーションが実行される
  • 空調のオートーメーションは気温を見て手動で無効・有効にする必要がある
  • 赤外線デバイスが複数のボタンを使うとき、ボタンがお互い連携していない

オートーメーションは人がいなければ実行されないようにする

今年9月にリリースされたiOS 11ではホームアプリに新しい機能として、家に人がいるかいないかのをオートーメーションの条件として使えるようになりました。最初の人が帰る、最後の人が家を出るというイベントもトリガーとしてつけるようになりました。

これによって、人がいないときに実行したくないオートーメーションは実行されないように設定できました。

気温をオートーメーションの条件にする

元ともNetatmoというウェザーステーションを使っていたのですが、残念ながらHomeKitとの連携はありませんでした。 homebridgeを設定した時は、連携してくれるプラグインはないか念のために調べて見ましたが、ありましたので、設定してホームアプリで気温などが取れるようになりました。ただしホームアプリでは、気温をオートーメーションの条件にする機能はなく、諦めていた。

数ヶ月後、HomeKit対応アプリを調べていたら、アップルのホームアプリは HomeKitの全ての機能を実装しているわけではないことがわかりました。 Home - Smart Home Automationというアプリは、値段がちょっと高めものの、HomeKitの変化に沿って全ての機能に対応しているようでしたので、買って見ました。 UIはアップルのホームアプリより使いにくかったが、できることがホームアプリより遥かに多いです。このアプリでは気温をオートーメーションの条件にすることが可能ですので、暖房は部屋の気温が15度以下の時に制限し、冷房は27度以上の時のみ実行されるように設定できました。

赤外線デバイスのボタン間の連携をつける

homebridge-irkitでボタンの連携ができない問題については、解決するプラグインがあるかどうかのを調べて見ました。IRKitを対応するプラグインは他に見つかりませんでしたが、複数のボタンの連携をするプラグインはありました:homebridge-switcheroo。

その二つのプラグインの機能を合わせられれば、問題の解決ができると思いましたので、homebridge-irkitをフォークして、homebridge-irkitextendedというhomebridge-switcherooの機能を追加するように実装しました。Javascriptのブラッシュアップをしながら、必要な場所を変更して実装しました。

実装した結果、連携されている複数のボタンが設定できるようになりました。設定はhomebridgeの設定ファイルの「accessories」のところに追加します。

{
              //irkit-extendedのアクセサリであること
              "accessory": "IRKitExt",
              "name": "irkit control device multistate",
              "irkit_host": "irkitxxxxx.local",
              //複数の状態をもつデバイスである
              "type": "multiple",
              "multiple": [
                {
                    //オフ状態ある時はこういうふうに書きます
                    "name" : "OFF",
                    "form":  {"format":"raw","freq":38,"data":[]}
                },
                {
                    //暖房の設定
                    "name" : "暖房",
                    "form":  {"format":"raw","freq":38,"data":[]}
                },
                {
                    //冷房の設定
                    "name" : "冷房",
                    "form": {"format":"raw","freq":38,"data":[]}
                }
              ]
          }

動作としてはラジオボタンみたいになっています。一つのボタンを有効にすると連携されているボタンが他のボタンがオフ状態になります。追加で、「name」が「OFF」とされている項目があれば、オンになっているボタンをタップしてオフにする場合、オフのボタンが有効になるようにしました。レポジトリーへのリンクは記事の下にまとめますので、気になるかたはぜひ見てください。

最後に

プラグインを作成して、iOS 11とHome - Smart Home Automationというアプリを使うことで、現時点で気になるところを全て対応できました。

今回は例として最初の動機であったエアコンを使いましたが、現在自動化しているのはエアコンだけだはないので、現在僕の家で何が自動化されている、どういうふうに設定されているか簡単に紹介したいと思います。

図にまとめてみました。 f:id:glpgsinc:20171206162640p:plain

設定の中心になっているのはこの記事で説明したHomeKitとhomebridgeになっています。ハードとしては自分のiPhone、AppleTV(HomeKitサーバー)、Raspberry Pi(homebridgeサーバー)、IRKit(台所1台、寝室1台)になっています。

照明

照明は基本的に2種類使っています:Philipps Hue(リビング)と、自動化始める前に買ったシーリングライト(台所と寝室)。下記のように設定しています。シーリングライトはリモコンで操作できるものでしたので、IRKitで赤外線操作げできて、HomeKitで使えるようにできました。

  • 朝起きやすくするため、平日の起きる時間よりちょっと前に家に人がいれば全力にするようにしています。
  • 家に人がいなくなれば、照明が消えるように設定しています。家を出る時に気にせずに付けっ放しできるようになった。
  • 日の入り1時間前、人がいればオンになります。
  • 日の入り1時間前〜朝の間に誰もいない状態から誰か帰ると照明がつく。ドアを開ける時にすでに照明がついている。
  • 平日例時から照明がついていたら暗めの照明になる。(Nightshift的な発想で)
  • おやすみシーンをオンにすると寝室以外全ての照明がオフになります。

空調

主にエアコンですが、冬はベッドシーツの下に電気毛布をつけています。電気毛布の電源に赤外線でオン・オフができるプラグをつけて、HomeKitで操作できるようにしました。

  • 平日23時に、家に人がいて、気温が15度以下だと電気毛布が付きます
  • 平日朝起きる前に家に人がいて、気温が14度以下だと暖房がつく
  • 同時についてたら電気毛布が消える
  • 平日23時に、家に人がいて、気温が27度以上だと冷房がつく
  • 朝に冷房がついていたら消える
  • 家に誰もいなくなるとエアコン、電気毛布が消える

加湿器も対応させたかったが、赤外線の対応をしていないのと、電源の方で切ってもう一回入れるとオフ状態になっていてボタンを押す必要があるため、現在自動化していません。

ボタン

照明と空調かなり自動化しましたが、手動で操作したい時も結構あります。赤外線のデバイスは本来のリモコンとかで操作するとデバイスの状態とHomeKitの中の状態がずれてしまい、必ずHomeKitを使って操作する必要があります。

ホームアプリで操作できますが、いちいちスマホ出して操作するのもリモコンや壁のスイッチ比べて面倒に感じます。その代わりになるものはないかと調べていたが、ほとんどのボタンは電池か電源が必要で、家を借りているともちろん壁につけられません。電池を使うボタンを使ってみましたが、意外と電池を変更する頻度が高くて、使いにくいと思いました。

そうなやっていたところで、Philippsのhue tapボタンにHomeKit対応を追加しました。hue tapは電池要らず、ボタンを押す力で発電して動くボタンです。電源をつける必要もなく、電池交換も不要なボタンで、HomeKitに対応しているということは、家の照明などをそのボタンから操作できるようになります。hue tap一つにして、4つのボタンがあります。

一個購入して設定して見たところ、アップルのホームアプリで設定するとボタンを押す時に一つのアクションしか設定できない。例えばボタンに照明をオンにするアクションを設定すると、照明をオフにするために別のボタンを使う必要があります。 そのボタンの仕様の想定は一つのボタンで照明をオフにする、残りの三つで照明の違う設定三つが使えます。 一つの部屋の照明全体に使いたいときはいいのですが、寝室では部屋の照明オンオフ、エアコン、電気毛布、部屋以外家の照明を消すというアクションを設定したかったので、それだけではhue tapが二つか三つ必要になります・・

Home - Smart Home Automationの方で設定してみるとボタンを押した時に行うアクションについて条件がつけられますので、一つのボタンでできることが増えます。

たとえば、寝室のボタンはこういうふうに設定されています: * ボタン1:部屋の照明がオフであれば、オンにする、オンであればオフにする * ボタン2:エアコンがオンであれば、オフにする、オフであれば、気温が25度以上の時は冷房入れる、16度以下の場合は暖房入れる * ボタン3:電気毛布がオフであればオンにする、オンであればオフにする * ボタン4:部屋以外の照明を消す

ボタン2の方はエアコンをオンオフという操作ができますが、気温によって勝手に暖房か冷房をつけてくれますので、結構使いやすいです。

まとめ

この記事では趣味でやっている家の自動化の経緯と現状を紹介しました。最初は勉強を重ねてアプリの自作を行なっていたが、途中で方針変換して、アップルのHomeKitと連携をすることで、できることを増やしました。HomeKitを対応していない従来のデバイス(エアコン、シーリングライト、電気毛布)も使っているため、Raspberry Piとhomebridgeサーバーの設定、Javascriptでhomebridgeのプラグインの作成までしました。 家が便利になって、いろんな触ったことのなかったことの勉強ができてよかったと思います。興味ある人はぜひ挑戦して見てください。赤外線とHomeKitを連携したい方は、ぜひIRKitとhomebridge-irkitextendedを使って見てください。プラグインについての意見などがあればこの記事やgithubのページでコメントしていただければかと思います。

リンク