ラベル RaspberryPi3 の投稿を表示しています。 すべての投稿を表示
ラベル RaspberryPi3 の投稿を表示しています。 すべての投稿を表示

2016年8月16日火曜日

PHILIPS Hueを67個制御してみた


暫く更新をサボってしまいました。

今回機会に恵まれて、会社のFabLabを開設するプロジェクトに参加して照明システムを作ってみました。フロア全体の設計はNOIZ ARCHITECTSさんにお願いしています。

約400平米のフロア全体にPHILIPS Hueを67個(うち2個はHue light ribbon 6m)入れて、Hue Bridge2台をRaspberryPiにいれたnode.jsでWebアプリを立てて制御するシステムを組んでいます。


GUIはこんな感じで、右半分で制御対象のランプを矩形、もしくは領域選択ボタンで指定して左側のColorPickerで色と明るさを指定するというものです。
ColorPickerの下のボタンは色を登録しておくボタン、SCENE SELECTボタンは全体の状態を登録しておくボタンです。




こちらは管理者向け画面で、SCAN LIGHTSでlinkされてないHue lampを探して左側にオレンジの丸で表示し、それをDragすると実物のランプが赤くフラッシュし続けるので右画面のマップ上の位置にDropするとその位置に登録します。67個を如何に手を抜いて設置&設定をするかを考えた末のUIです。
マップ上のランプの色の違いはつながっているBridgeの違いを表しています。



Hueのスターターキット(第2世代 Bridgeが四角のHomeKit対応のもの)を2セット借用して自宅で色々APIを叩いてなんとかなるだろうと高をくくっていたのですが、67個を制御しようとするとそう簡単ではなく色々とうまくいかないところが出てきてスケジュールぎりぎりにようやく動かすことが出来ました。
Googleで検索しても数個を制御している例しか見つからないので、引っかかったポイントを記しておきます。

1.一度Hueのランプを1つのHue Bridgeとペアリングさせると、Delete ligthsで登録を削除しても他のHue Bridgeとペアリング出来ないことがある。(出来ることもあったので条件が何かあるのかもしれません。)

やってみたこと
 ・Hue Bridgeを2台使用して1台目のBridgeとペアリングして制御できる状態のランプをDelete lightsして、2台目のBridgeでSearch new lightsでbodyを空の状態で検索
  -> なにも見つからない
 ・同じく2台目のBridgeでSearch new lightsでbodyにランプのシリアルNoを指定して検索
  -> ランプが点滅して繋がったように見えるが、検索結果には何も見つからない
 ただ、不思議な事に1つのランプだけは他のBridgeに移動することが出来た
 スターターキットはBridgeとランプ3個が既にペアリングされた状態になっているので、結果的に片方のBridgeには4個がペアリングされた状態になり、もう片方には2個がペアリングされた状態になってしまいました。時間切れでこの件はこれ以上追っていません。

2.HueのランプはAPIからはUniqueIDやBridgeに登録されているLightの番号は引けるけど、Search new lightsではランプの側面に書かれているシリアル番号が必要になる可能性があるため取り付け前にシリアル番号を控えておく必要がある。
 今回は、ランプが全て設置された状態からセットアップだったので全て外して確認するのは大変だと思ったのですが、Search new lightsでbodyが空でも全てのランプが検索できたので外さずに済みました。

3.数が多いので制御対象を都度group登録してstateを変更して制御しようとしたけど、連続してAPIを叩くと色々とエラーになって指定してないランプの色まで変わってしまったり、ところどころ色が変わらなかったりする。特にon/offの制御を取りこぼすと1つだけ点いていたりして目立つのでちょっとNGかな。
 -> 結局、groupでの制御はやめて、set light stateで個別制御を制御対象全てのランプに投げてエラーが返ってきたものについてはretryを3回ほど投げる仕様にして、その後2秒間GUIの制御が無い場合は全ランプの最終stateの状態を2度投げることでリカバリーすることにした。これはSuccessが返ってきているにもかかわらず、Stateが正しくないランプがあったので念の為にこうしている。

色々と書きましたが、色の均一性とか表現範囲はHueが一番かと思います。これだけ並べて色が均一に出ているのが素晴らしいです。




2016年4月27日水曜日

RaspberryPi 3 Model B

RaspberryPi 3 Model Bをようやく入手しました。
これまでRaspberryPi 2 Model Bを使用していたうちのシステムに入れ替えたところ早速トラブりました。
まず、XBee制御に使用していた/dev/ttyAMA0はWiFi/BT用に使用されるとのことで、40pinのコネクタに出ているUARTは/dev/ttyS0に変更されています。
BCM2835の仕様書とGPIOのPinMuxの設定値を調べてみると、なかなか微妙な仕様になっていました。

RaspberryPi 2の場合
40pinコネクタの8,910,11,36はTXD0,RXD0,RTS0,CTS0で/dev/ttyAMA0にアサインされていて、UARTのIPはARM PrimeCell PL011です。
RaspberryPi 3の場合
40pinコネクタはTXD1,RXD1,RTS1,CTS1で/dev/ttyS0にアサインされてIPは16550 UART下位互換のMiniUARTになっています。
これは対応ボーレートが476bps~31.25Mbpsになっていますが、一般的な115200とかのボーレートの場合誤差がそれなりにありそうです。(ちゃんと計算してませんが)

それでもまぁ大丈夫だろうと取り敢えず試してみようと繋いでみましたが、最初動作しているのに暫くすると動かなくなる現象が発生しました。
通信路を見ていると途中から周波数が変化している現象が発生しています。
ネットで色々調べてみると、CPUのcore clockがIPのCLKになっているようで、現状のraspbianではCPU周波数が変動するとMiniUARTのクロックも一緒に変動してしまうようで使い物になりません。
これは対策として/boot/config.txtにcore_freq=250を追加することで対応できるようです。
そのうちクロックソースを固定のものから供給する設定になる気がしますがいまのところこの対策しかないようです。

もう1つRaspberryPi3で発生した問題が、PWR-LEDの問題です。
/sys/class/leds/led1が消えていたのでPWR LEDが消せなくなってしまいました。
どうもPWR-LEDの制御がメインCPUのGPIOから他の所のGPIOに移動したようで、直接制御できなくなってしまったようです。
そのうち、対応策が出てくることを期待して取り敢えず置いておきます。