ラベル 赤外線リモコン の投稿を表示しています。 すべての投稿を表示
ラベル 赤外線リモコン の投稿を表示しています。 すべての投稿を表示

2016年4月1日金曜日

RP-5基板の組み立て

KiCadで設計してElecrowに注文していた基板も上がってきて、部品も揃ったので組み立ててみました。

ちなみに今回はFedExにしてみました。

3/15火曜日の夜 出図
3/16水曜日 製造開始
3/22火曜日 写真付きで基板できたよとの連絡
3/23水曜日
17:32 出荷地のFedEx営業所を出発  YUEN LONG HK
21:50 FedEx経由地に到着         GUANGZHOU CN
3/24木曜日
03:13 FedEx経由地を出発         GUANGZHOU CN
05:06 輸送中/処理中                          GUANGZHOU CN
07:32 仕向国仕分け場所                    NARITA-SHI JP
11:57 輸送中/処理中                          TOKYO-KOTO-KU JP
14:14 国際輸送許可 - 輸入                 TOKYO-KOTO-KU JP
20:16 輸送中/処理中                          TOKYO-KOTO-KU JP
3/25金曜日
10:02 FedEx 営業所                          TOKYO JP
13:24 配達完了

製造開始から土日を挟んで9日間で到着しています。

今回はTAKACHIのケースに合わせて基板を設計しました。
当然ながらピッタリと収まっています。


レーザーカッターで1.5mm乳白色半透明のアクリル板を切り出して赤外線LEDと受光部の窓を作っています。

後ろ側も同じ板で電源とUSB、Etherの口をRaspberryPi 2 Model-Bの穴位置に合わせて加工しています。
本当は段差が無いようにできればいいのですが、素人の加工としてはこのくらいが限度でしょうか。

2016年3月24日木曜日

HomeServerのinstall

GitHubにRaspberryPi 2 Model Bを使ったSiri対応の学習リモコンのコードを公開しました。
RaspberryPi Model A+/B+でも動くと思います。RaspberryPi 3に関しては確認できたら報告します。

■このソフトで現時点で出来ること
 ・赤外線リモコン、HA端子(JEM-A端子)、弱電スイッチなどの制御
 ・赤外線リモコン信号、HA端子、弱電スイッチ、各種センサーなどのステータス情報取得

 - telnet(socket)経由での上記制御と情報取得(human-readble IF, JSON IF)
 - HomeKit対応アプリからの上記制御と情報取得(HAP-nodeJS経由)
   AppleTV(3rd generation以降)を経由して外出先からの上記制御と情報取得
   iPhoneのsiriによる上記制御と情報取得
   ※ ただしAppleがHomeKitの認証を強化すると動かなくなる可能性あり
 - javascript(node.js)での制御
   センサー等の変化や30sec intervalのイベントでjavascriptの関数が呼び出されるので条件を設定して制御することが可能
     日没にあわせてシャッターを閉める、あかりをつける
     玄関のロックが5分間開いていたらメールする
     雨が降ってきたら窓を閉める
     室温に応じて起床前にエアコンをつける
     窓を開けたらエアコン停止
     etc

■今後追加していきたい機能(余裕があれば)
 - リモコンの学習、各種設定のWebUI化
 - javascriptでの制御部分のVisualPrograming化

■下のブレッドボード用回路の機能
 - 赤外線リモコン送信・受信

■RP-5基板の機能
 - 赤外線リモコン送信・受信
 - ZigBee(XBee)経由でのリモート子機(HA-5)制御
 - HA-5子機の故障診断とファームウェアアップデート、ペアリング

■HA-5基板の機能
 - 赤外線リモコン送信・受信
 - HA端子(JEM-A端子)での家電制御、ステータス確認
 - 弱電(24V以下)のスイッチ制御・ステータス確認(電動シャッターなどのスイッチ)
 - 各種センサー情報の取得(温度、湿度、雨、人感、etc)


ブレッドボード用回路は以下のとおりです。





リモコン学習時のブザー音とリモコン発光時の発光音が不要なら真ん中のブザー音出力ブロックは不要です。

LED101/102はリモコン用の940nmあたりの波長の赤外線LEDなら大体動くと思います。
ちゃんと赤外線LEDが発光しているかどうかはデジカメ等で見ながら発光させると確認できます。
ただし、iPhoneはカメラに赤外線フィルターが入っているようで見えませんでした。

赤外線受光モジュールは電源が逆になっているデバイスもあるので他のものを使う場合は気をつけて下さい。

FETもNchで耐圧がOKなら動くかと思います。こちらもピン配置を確認して使って下さい。

installの大まかな手順を書いておきます。
詳細手順はこちらのREADME.mdを御覧ください。(下の方です)
※scriptからダウンロードするので、gitをcloneする必要はありません。

1.最新版のRASPBIAN JESSIE LITEをダウンロードしてSDカードに書き込みます。
2.SDカードをRaspberryPiにセットしてNetworkを接続し起動後loginします。
3.setup scriptを実行する
 > curl -O https://raw.githubusercontent.com/mnakada/ha1control/master/setup.sh
 > sudo bash setup.sh
4.piのアカウントpasswordを変更する
5.reboot
6.HomeKit対応アプリをiPhoneにinstall
7.対応アプリでHA1HomeServerを登録

国内のエアコン等も大抵のものは動くかと思います。
Daikin/Panasonic/三菱重工は確認しました。

AppleTVの第3世代以降があってiCloudの設定をしてあれば外出先からもアクセス出来ます。
ただし、AppleTVの自動updateをonにしているとupdate後自動起動してくれるのですが、iCloudのloginを一度解除してからもう一度loginし直さないとアクセスできなくなってしまいます。

2016年3月19日土曜日

RP-5基板

最近XBeeの新型のS2Cが出たり、ATmega328も昨年からATmega328pbが出ていてRaspberryPi3も出るし、Kicadも最新版をbuildしたので、回路を見なおして基板を起こし直すことにしました。
これまで親機の方はアクリル板をレーザーカッターで切り抜いてケースを作っていましたが、曲げ加工とか手間がかかるのでTAKACHIのPF-15-3-10Wを使ってみることにしました。
赤外線を通す必要があるので、このケースの前後のパネル部分の代わりに乳白色の半透明アクリル板をレーザーカッターで加工して使ってみます。
赤外線LEDや受光部、RaspberryPiの各種コネクタの位置をパネルの範囲に入るように配置しながら高さ方向の適当な位置を考えていきます。
下の図の赤い線で書かれているのがRP-5基板とRaspberryPiの位置になります。


最初は基板固定用のM2.3用ボスで基板を固定することを考えたのですが、この高さで固定するとRaspberryPiのコネクタがパネルの高さ内に収まらないため3mm程度スペーサーで嵩上げする必要があります。
そこで、ケースの固定用の支柱部分に基板をいれて上側に適当なクッションを入れることでちょうどいい高さに収まらないかと考えています。

基板の回路はこれまでとほとんど変わってませんが、RaspberryPiと接続してIRリモコンの学習用の受光部と発光部、子機との通信用のXBeeと将来置き換えていけるようにESP8266用の回路を入れています。


RaspberryPiと接続して使う場合は下の回路だけ部品をのせることで親機としての機能になります。


Bee経由で子機として使う場合はATmega328pbでリモコン機能を中継する形になります。
回路はシンプルで電源とマイコン、XBee、赤外線受発光部だけになります。



この回路を丁度ケースに入るような形で設計したのが下の基板です。



それほど面積は要らないのですが、ケースに固定する部分の関係で10x15cmに入る位の大きさになってしまいました。
もう1つのFriskサイズの子機基板と一緒にElecrowに発注しました。
今月末くらいに届く予定です。

もう1枚の基板については次回書きます。


2016年2月27日土曜日

HomeBridge改めHAP-nodeJSと接続してsiriで家をコントロール その3

コントロールサーバーの動いているRaspberryPi2の上にhomebridgeを動かして、pluginとしてコントロールサーバーと接続しようとしていたのですが、いろいろ実装していく内にhomebridgeの下のレイヤーであるHAP-nodeJSと直接繋ぎこんだ方が良さそうなことがわかってきて繋ぎ方を改めました。
ところが、実装を切り替えて試してみてもEveで初期設定まではうまくいくのですが、接続されたホームの中にAccessoryが何もない状態になってしまいます。
そんなこんなをしている内にHomeBridgeとの接続も同じ状態になってしまい訳がわからなくなってしまいました。
2日ほどわからない状態だったのですが、色々と試している内に最初に試していたdirectoryのイメージを起動するとちゃんと繋がることに気が付きました。
差分を切り分けるために実験していくとHAP-nodeJSのVersionが0.2.4以前ならちゃんと繋がることが分かりました。
どうも0.2.5でHomeKitの最新のプロトコルにupdateされていたようで、自分のiPhoneがiOS9.3beta3だったため繋がらなかったようです。
iOS9.3beta4にupdateして、HAP-nodeJSも0.2.5にしたら無事に繋がるようになりました。
このdebugの過程でdebug情報を色々出していたのですが、何故かAppleTVとの通信をしているlogが残っていました。
AppleのHomeKitのページをよく読むと、うちにある第3世代のAppleTVだとHomeKitの外からのアクセスを中継してくれるようです。
AppleTVのiCloudの設定を再度し直して、LTE回線からiPhoneでEveを起動してみるとちゃんと繋がり、コントロールもできています。
LTE回線経由でもsiriでのコントロールもちゃんとできました。
なかなかいい感じです。

siriとの会話の方は相変わらず実験中で、まだエアコンとシャッター、電動窓、TVはNHKがうまくコントロールできていません。
エアコンは温度設定はできるのですが、暖房、冷房を指定することが出来ません。
エアコンを切ることも出来ていません。
シャッター、電動窓は開くことは出来ても閉じることが出来ません。
「シャッターを開けて」で「100%に設定しました」と言われてシャッターが開きますが、「シャッターを閉めて」でも「100%に設定しました』と言われてしまいます。これはsiriのbugのような気がします。
「NHKをつけて」はNHKをつけてをwebで検索されてしまいます。
もう少し会話の練習が続きそうです。

2016年2月19日金曜日

homebridgeと接続してsiriで家をコントロール その2

homebridgeを使って自宅システムをsiriでコントロール出来るようにするために色々と試しています。
とりあえずざっくりとしたつなぎ込みは出来て、eveというhomekit対応のアプリで接続できるようになりました。

ステータスを取得する方は結構つながってきました。

「リビングの湿度は?」『34%に設定されています』ちょっと日本語が変ですが値は返ってきます。
「寝室の湿度は?」『56%にせっていされています』こちらも日本語がおかしいですが値は返ってきます。
「2階の温度は?」『4.7度から17.6度です』これは全ての温度デバイスの値を読み込んで範囲を回答してます。
「1階の温度は?」->「外の温度は」(文字が勝手に外に置き換わる) -> 自宅周辺の天気予報から温度を答えてくる
「外の気温は?」 -> 同じく自宅周辺の天気予報から回答

制御の方もなんとなく動いてきてます。
「リビングの床暖房をつけて」『デバイスからの応答がありません』eveからは制御できています。
「ダイニングの床暖房をつけて」『デバイスからの応答がありません』こちらもeveからは制御できています。
「風呂のお湯を入れて」-> OK
「冷暖房の自動運転を入れて」-> OK
「テレビを消して」『私には無理です』
「テレビをオフして」->OK
「NHKをつけて」->WebからNHKをつけてに関する情報を表示
「日本テレビをつけて」『よくわかりません』
「Eテレをつけて」->OK
「日テレをつけて」->OK
「TBSをつけて」->OK
「テレビ東京をつけて」->OK
「テレビ朝日をつけて」->OK
「テレ朝をつけて」->OK
「フジテレビをつけて」->OK
「テーブル照明をつけて・消して」->OK
「スポット照明をつけて・消して」->OK
「間接照明をつけて・消して」->OK
「ダウンライトをつけて・消して」->OK
「カウンター照明をつけて・消して」->OK
「南側のエアコンを18度にして」->OK
「南側のエアコンを消して」『デバイスからの応答が有りませんでした』
「西側のエアコンを20度にして」「西川のエアコンを20度にして」(勝手に変換される)『私には出来ません』
「西川のエアコン」も登録するとOK

なかなか難しいです。
『デバイスからの応答が有りません』系は何かプログラムに問題がある気がするのでもう少し検討ですね。
他の勝手に違う単語に置き換えられる系はその単語も登録してしまう作戦で行くことにします。
もう少しSiriとの会話?戦い?は続きそうです。

2016年1月30日土曜日

homebridgeと接続してsiriで家をコントロール

最近homebridgeというopen sourceのHomeKitのブリッジソフトが流行っているようなので、自宅のシステムと仮接続してみました。
とりあえず、まだTVのon/offだけですが動作させることが出来ました。
ただ、siriがどんなコマンドを受け付けてくれてサービスをどう登録するのかがよく判りません。
「テレビをonして」「テレビをoffして」は動きますが「テレビをつけて」はダメでした。
放送局とかを指定したりボリュームをコントロールするには何と言えばいいんですかね?

とりあえず、呼び出される関数の中でhomebridge.hap.Serviceをdumpすることで
     AccessoryInformation: { [Function] super_: [Circular] },
     AirQualitySensor: { [Function] super_: [Circular] },
     BatteryService: { [Function] super_: [Circular] },
     BridgingState: { [Function] super_: [Circular] },
     CarbonDioxideSensor: { [Function] super_: [Circular] },
     CarbonMonoxideSensor: { [Function] super_: [Circular] },
     ContactSensor: { [Function] super_: [Circular] },
     Door: { [Function] super_: [Circular] },
     Fan: { [Function] super_: [Circular] },
     GarageDoorOpener: { [Function] super_: [Circular] },
     HumiditySensor: { [Function] super_: [Circular] },
     LeakSensor: { [Function] super_: [Circular] },
     LightSensor: { [Function] super_: [Circular] },
     Lightbulb: { [Function] super_: [Circular] },
     LockManagement: { [Function] super_: [Circular] },
     LockMechanism: { [Function] super_: [Circular] },
     MotionSensor: { [Function] super_: [Circular] },
     OccupancySensor: { [Function] super_: [Circular] },
     Outlet: { [Function] super_: [Circular] },
     SecuritySystem: { [Function] super_: [Circular] },
     SmokeSensor: { [Function] super_: [Circular] },
     StatefulProgrammableSwitch: { [Function] super_: [Circular] },
     StatelessProgrammableSwitch: { [Function] super_: [Circular] },
     Switch: { [Function] super_: [Circular] },
     TemperatureSensor: [Circular],
     Thermostat: { [Function] super_: [Circular] },
     Window: { [Function] super_: [Circular] },

     WindowCovering: { [Function] super_: [Circular] } } }
といったサービスの種類があることは分かりました。
現状はSwitchにTVのon/offを接続しているだけなのですが、少しずつ他のWindowとかDoorやLightあたりを掘っていってみようかと考えています。

2015年11月7日土曜日

KiCad 4.0RC1でESP-WROOM-02用基板作成 その6

次はESP-WROOM-02版です。

RP-3基板





HA-4基板


こちらの基板はXBeeの裏面に書かれているアドレスを読み取れるようにXBeeの下のところに穴を開けてあるのですが、ESP-WROOM-02を載せると丁度放熱用のPadのところが穴に位置してしまってあまりよろしくないかもしれません。

まだ、ESP-WROOM-02をどう使うか悩み中です。ATコマンドのままでうまく使っていくのか、何らかの独自のバイナリのI/Fを定義してAVRと通信させるのか、とか考えてるところです。


2015年10月31日土曜日

KiCad 4.0RC1でESP-WROOM-02用基板作成 その5

基板が上がってきたので部品をマウントしてみます。
まずは従来通りのXBee版です。

RP-3基板
いい感じです。

HA-4基板
こちらもいい感じです。


RP-3基板をRaspberryPi2と組み合わせます。


あれ?

RP-3基板のHA-4基板書き込み用のコネクタがRaspberryPi2のHDMI、Audioコネクタと干渉しています。
CAD上で基板の板端をギリギリで避けたつもりだったのですが、コネクタの出っ張りを考慮するのを忘れてました。
実物確認しなかったためのミスです。
回路動作チェックをしてソフト書いたらもう一度出し直しです.......


2015年10月23日金曜日

KiCad 4.0RC1でESP-WROOM-02用基板作成 その4

日曜日に届きました。



速かったです。注文してから8日です。
10/10(土)の朝に出して10/14(水)の夕方には基板が上がってきてDHLに渡されています。
business day 4-7日となっていたのに土日も動いてくれてるんですね。
そのあと39時間後の10/16(金)の朝には国内についてますが、そこから配達されるまで49時間もかかってます。
実際の配達は佐川急便でした。
深センから成田のほうが成田から東京より近いようですね。

Wednesday, October 14, 2015
1 Shipment picked up SHENZHEN - CHINA             18:50
2 Processed at SHENZHEN - CHINA                      22:59
3 Departed Facility in SHENZHEN                      23:04
4 Clearance event SHENZHEN - CHINA, PEOPLES REPUBLIC 23:18

Thursday, October 15, 2015
5 Customs status updated HONG KONG            00:16
6 Clearance processing complete at SHENZHEN - CHINA  01:19
7 Arrived at Sort Facility HONG KONG                 03:17
8 Processed at HONG KONG                             06:37
9 Clearance processing complete at HONG KONG         06:37
10 Processed at HONG KONG                            19:15
11 Departed Facility in HONG KONG                    22:34

Friday, October 16, 2015
12 Customs status updated TOKYO - JAPAN        03:07
13 Transferred through TOKYO - JAPAN                 08:42
14 Arrived at Sort Facility TOKYO - JAPAN      10:00
15 Clearance event TOKYO - JAPAN                     10:37
16 Processed for clearance at TOKYO - JAPAN          10:37
17 Customs status updated TOKYO - JAPAN        22:42
18 Clearance processing complete at TOKYO - JAPAN    22:56

Saturday, October 17, 2015
19 Processed at TOKYO - JAPAN                        01:21
20 Departed Facility in TOKYO - JAPAN                01:45
21 Arrived at Delivery Facility in TOKYO - JAPAN     08:13
22 Forwarded for delivery TOKYO - JAPAN        09:33

Sunday, October 18, 2015
23 Delivery attempted; recipient not home            10:58
24 Delivered - Signed for by : DLVD BY AGNT          19:31


2015年10月9日金曜日

KiCad 4.0RC1でESP-WROOM-02用基板作成 その2

2つ目の基板を作成してみました。
HA端子、SW制御、赤外線リモコン送信、受信、GPIO、ADC機能の子基板で以前XBee用に設計したものをESP-WROOM-02対応とダイオード、FETが小さすぎてハンダ付けがしにくいのでひとまわり大きいものに変更したり、機能を変更したりしました。

回路図は以下のとおり


出来上がったパターンは以下のとおりです。



KiCADのバグでしょうか?

DRCの未配線は無いので大丈夫だと思うのですが、KiCADのpcbnewをOpenGLモードで見ていると下側のStatusのところの未配線が2になっています。

これが表示設定を標準にすると0になります。


KiCADのBZR5814とかで作った前回のパターンからいじったのでどこかにゴミデータでも残っているのかもしれませんが、よくわかりません。BZR5814で開くとOpenGLモードでも未配線が0になります。
最初から4.0RC1で作成したRP-3基板はOpenGLモードでも未配線0なので、この基板データ固有の問題かもしれません。

急いでも仕方が無いので週末にガーバーの確認をしてから出図しようかと思います。
Elecrowも国慶節明けで混んでそうなので、週明けくらいに出してもあまり変わらないかと。

今回の基板は10cm x 10cmに3枚面つけでV-Cutの予定です。
RP-3基板と今回の基板それぞれ10枚で、まとめると送料が安くなりそうです。




2015年10月2日金曜日

KiCad 4.0RC1でRaspberryPi2用のESP-WROOM-02用基板作成

KiCad 4.0RC1をせっかくbuildしたのでESP-WROOM-02用の基板を作成してみました。
RaspberryPi2用の基板ですがHAT規格ではありません。合わせられる所はHAT規格に合わせてますが、ACアダプタ用のコネクタを後ろ側から出すため基板外形を変更しています。
ケースは以前作成したRP-2基板用のものを流用する予定です。

回路は色々と余計なものがついていますが、基本的にはRaspberryPi2の電源をUSB-miniからではなくACアダプタ用のコネクタを背面側に出すための回路と、XBeeモジュール・ESP-WROOM-02のいずれか経由で子機と接続するための回路、RaspberryPi2に赤外線リモコンの送受信機能を追加するための回路、子機として使う時のためのAVRマイコン回路で必要に応じてマウント部品を変更して使うようにしています。

回路図は以下のとおり






で出来上がったパターンが以下のとおりです。


SWITCH-SCHIENCEがSeedStudioのPCB作成サービスの取り扱いを始めたのでこちらでお願いするか、以前出したElecrowに出すか、どちらが安いのか比較してみます。
今回は10cm x 10cm x 1.0mm panelizeなし、黒レジスト、10枚です。

SWITCH-SCHIENCEの場合
 Greenレジスト 10cmX10cm基板で3074円
 それ以外のレジスト 10cmX10cm基板で5882円
 +パブリックベータ期間なら送料324円、通常は1080円
で緑レジストの最安なら3398円
黒レジストにすると6206円

Elecrowの場合
 Greenレジスト 10cmX10cm基板$14
 それ以外のレジスト 10cmX10cm基板$15.9
 + 送料(Registerd Airmaailで$10.37,DHLで$16.37)
で緑レジストの最安で$24.37 = 2924円 ($1=120円換算)
黒レジストにすると$26.27 = 3152円
DHLにすると+720円

価格は緑レジストにすればいい勝負ですが他の色の場合はElecrowの方が半額近いですね。
納期はSWITCH-SCHIENCEは14-21日、ElecrowはこれまでDHLでの経験では1回目14日、2回目v-cutありでも14日だったので、こちらもそれほどの違いはなさそう。
ということで今回は黒色にしたいのでElecrowでRegisterd Airmailを試してみます。
.........
ところが、注文しようとしたらElecrowは国慶節で10/7までお休みでした。
別に急いでないので、もう1つの基板も描いてまとめて注文しようかと思います。

2015年9月25日金曜日

angular.jsとonsenUI

node.js、express、mongoDBときているので次はangular.jsです。
UIはどうしようかと思ったのですが、angular.jsと相性が良さそうで日本語で情報が豊富なonsenUIにしてみました。
ちょっとまだソースコードがグチャグチャなのでもう少し整理してから後ほどGitにでもあげようと思います。
まだ、どの処理をサーバーのnode.js側で処理してどの処理をクライアントのangular.js側で処理するのがいいのかを悩み中です。
最初はほとんどの処理をangular.js側に持っていったのですが、mongoDBから読みだしたデータを大量に送った場合にかなり動作が重たくなることがわかったので、ある程度サーバーサイドで処理して扱いやすい形に変換してからクライアントサイドでUIに表示する形にしたほうがいいようです。
サーバーを動かしているさくらVPSのx86仮想サーバーとiPhone5sのARM系64bitCPUではやはりパフォーマンスが違いますね。


2015年9月11日金曜日

UIの設定ファイル


node.jsのサーバーとmongoDBでサーバーサイドまで繋がったので、その先のクライアントサイドの実現方法を考えていきます。
UIをHTMLでベタに書いていくのはありえないのでUI定義ファイルを設計します。
まず最初にどんなUIにするのか仮決めします。一度パスが通るところまで作ってしまってから気に入らなければ修正する方針で行きます。
初めてなので色々と想定できていない事があると思うので、とりあえず一度作ってみるのが手っ取り早いですよね。

ざっと要件を考えます。
・全体のステータスを表示するメインページ
 ・部屋ごとにまとめて表示
 ・制御できるものに関しては選択すると制御用のボタンが出てくる
  ・TVはon/off/volume+/volume-/選局のボタン
  ・エアコンはモード切り替え/温度選択/offのボタン
・温湿度のグラフページ
 ・3日分くらい表示
・ログの確認ページ
 ・状態の変化、コマンドの記録
・デバイスの動作状況の確認ページ
 ・各コントロールモジュールの電源電圧と動作状況
といったところを表示します。

 最終的に作ったUIのメインページはこのような感じです。

  


UI定義ファイルは最終的にjavascriptで扱うのでJSONで記述します。

最初は部屋を定義します。
この後のItemの定義で使用するroomと表示用のlabelを定義しています。
Itemとは上のUIの1行ごとの部分を指しています。
この定義は上のUIのグレーになっている部分のタイトルなどに使用されます。
  "RoomList": [
    { "room": "all", "label": "全体"},
    { "room": "living", "label": "リビング"},
    { "room": "kitchen", "label": "キッチン"},
    { "room": "bathroom", "label": "浴室"},
    { "room": "bedroom", "label": "寝室"},
    { "room": "studyroom", "label": "書斎"}

  ],

次に各制御対象毎にUI定義をします。全部出しても同じような定義だらけなので代表的なものだけに絞っています。

 "ItemList": [
   { 
     "room": "all",
     "label": "玄関",
     "status": [
       {"label": "玄関錠", "sensor": "entrance_key_stat"}
     ],
     "buttons": [
       {"label": "open", "command": "entrance_key_open"},
       {"label": "close", "command": "entrance_key_close"}
     ]
   },

このItemは上のUIの一番上の方の玄関のラインを定義しています。
最初にroom:でallを指定しているのでUI上は全体の項目の中に配置されています。
次のlabelはこのItemの項目名として表示されているものです。
status arrayの中はCloseと表示されている状態表示の定義です。
この中のlabelはsensorのための表示用ラベルですがここのUIでは使用していません。
後にGraph等の中で必要になるかもしれないので定義しています。未定義の場合はroom.label+item.labelとみなされます。
button arrayの中はこのItemを選択した時に出てくるボタンを定義しています。下が玄関Itemを押すと出てくる制御用のボタンです。

  
labelでボタンに表示する名称、commandに送信するコマンドを定義しています。

次のItemは制御部分が無くstatusが2つあるものの定義です。
  
この例のように同じような種類の情報表示のみの場合に使っています。

  { 
    "room": "all",
    "label": "室内1F/2F",
    "status": [
      {"label": "室内1F温度", "type": "temp", "sensor": "internal_1f_temp"},
      {"label": "室内2F温度", "type": "temp", "sensor": "internal_2f_temp"}
    ]
  },

statusにtypeを設定すると単位をつけたりいくつかのところで特別な処理をしたりします。
今のところtemp,humidity,pir,rainと設定なしの5種類があります。

次はエアコン用のitemです。
  {
    "room": "study room",
    "type": "aircon",
    "label": "エアコン",
    "status": [
     {"type": "temp", "sensor": "studyroom_aircon_temp"},
     {"sensor": "studyroom_aircon_stat"}
    ],
    "commandPrefix": "studyroom_aircon_", 
    "buttons": [
     {"label": "off", "command": "off"}
    ]
  },
typeでairconであることを指定しています。これはモード切り替え、温度切り替えのために特殊処理があるためairconであることを指定します。 statusは温度とエアコンの状態を表示しています。commandPrefixは送信コマンドの前に追加する文字列を指定していて、この後出てくるAirconListで指定しているコマンドと合わせることで送信するコマンドを決定します。これはエアコン自体のコマンドは同じものだけどコントロールモジュールが違うのでエアコン毎にprefixを付けたい場合に付加します。
buttonsでモード切り替え、温度切り替え、送信ボタン以外のボタンを定義します。ここではOffボタンだけです。
エアコンを選択すると下の状態になります。

  

ここでcoolerの所を上下にスライドするとモードが切り替わります。


  
さらに温度の所を上下にスライドすることで温度設定を変更できます。
このカルーセルの動作の度にリモコンコードが出てしまうと煩わしいので決めた後にsendボタンで送信するようにしています。

カルーセル自体のUI設定はItemListの中ではなく別途AirconListの中で定義しています。

  "AirconList": [
    { "label": "auto", "color": "#404040",
      "command": [
        { "label": "auto", "commandSuffix": "auto" }
      ]},
    { "label": "cooler", "color": "#2586d9",
      "command": [
        { "label": "18", "commandSuffix": "cooler_18" },
       : 途中省略
        { "label": "29", "commandSuffix": "cooler_29" },
        { "label": "30", "commandSuffix": "cooler_30" }
      ]},
    { "label": "heater", "color": "#d93625",
      "command": [
        { "label": "18", "commandSuffix": "heater_18" },
       : 途中省略
        { "label": "28", "commandSuffix": "heater_28" },
        { "label": "29", "commandSuffix": "heater_29" }
      ]}
  ],

 最後にTVのitemです。

  {
    "room": "living",
    "type": "tv",
    "label": "TV",
    "commandPrefix": "",
    "buttons": [
      {"label": "on", "command": "tv_on"},
      {"label": "off", "command": "tv_off"},
      {"label": "vol+", "command": "tv_vup"},
      {"label": "vol-", "command": "tv_vdn"}
    ]
  },

typeをtvにしてitemがTV用であることを指定します。
commandPrefixはエアコンの時と同じです。
buttonsにon, off, vol+, vol-を指定しています。
TVの場合はこれらのボタンと選局のカルーセルが現れます。

  

TV局名の所を上下にスライドすることで選局できます。

  
選局後に局名ボタンを押すことでコマンドが送信されます。
TVの選局リストは下記のように定義しています。

 "TVChCommandList": [
    { "label": "NHK", "commandSuffix": "tv_1" },
    { "label": "NHK", "commandSuffix": "tv_2" },
    { "label": "日テレ", "commandSuffix": "tv_4" },
    { "label": "テレビ朝日", "commandSuffix": "tv_5" },
    { "label": "TBS", "commandSuffix": "tv_6" },
    { "label": "テレビ東京", "commandSuffix": "tv_7" },
    { "label": "フジテレビ", "commandSuffix": "tv_8" },
    { "label": "TOKYO MX", "commandSuffix": "tv_9" },
    { "label": "放送大学", "commandSuffix": "tv_12" }
  ]

今回はここまで。




2015年9月4日金曜日

mongoDB/mongoose

自宅のNATの内側から、さくらVPSのnode.js上のサーバーまでsecure websocket serverが開通したので気温や湿度、コマンドのやりとりや各種センサーの情報を記録するデータベースを設定していきます。
MEANスタックというのが流行りのようなので、mongoDBを使ってみることにしました。
node.js上のアクセスはmongooseを使用しています。
素人が書くよりも色々ネット上に書いてくれている情報があるのでインストール方法とかは省略します。
mongooseはSchemaを設定してアクセスするようなので、最初にどういうデータで格納していくかを考えていきます。
まず、定期的に測定する気温や湿度などのセンサー情報と何かスイッチ等をon/offした時などのタイミングで上がってくるイベントの最新情報のみを記録するためのStatusSchemaを考えます。これはLogとは別に最新データを素早くアクセスするために記録します。
情報としては接続先のclientID、センサー名称、センサーの値、更新時のTimeStampです。

var StatusSchema = new mongoose.Schema({
  client: {type:String, required: true},
  sensor: {type:String, required: true},
  value: {type:String, required: true},
  update: {type:Date, default:Date.now}
});
var Status = db.model('status', StatusSchema);

次にデバイスの最新情報を取得して保持しておくためのDeviceInfoSchemaです。
記録する情報は接続先のclientID、デバイス名称、デバイスタイプ、ZigBeeアドレス下位32bit、デバイスの機能情報、バージョン、電源電圧、デバイス状態、更新時のTimeStampです。
var DeviceInfoSchema = new mongoose.Schema({
  client: {type:String, required: true},
  device: {type:String, required: true},
  type: {type:String, required: true},
  addrL: {type:String, required: true},
  func: {type:String, required: true},
  version: {type:String, required: true},
  voltage: {type:String, required: true},
  state: {type:String, required: true},
  update: {type:Date, default:Date.now}
});
var DeviceInfo = db.model('deviceInfo', DeviceInfoSchema);

次は全ての変化の記録を記録していくLogSchemaです。
ここには接続先のclientID、情報のタイプ、データベースを検索する時に情報粒度を落とすためにつける分解能フラグ、更新時のTimeStamp、データ本体です。
データ本体はコマンド、レスポンス、ステータスなどのメッセージobjectです。
var LogSchema = new mongoose.Schema({
  client: {type:String, required: true},
  type: {type:String, required: true},
  fine: {type:Boolean, required: false},
  timeStamp: {type:Date, default:Date.now},
  data: mongoose.Schema.Types.Mixed
});
var Log = db.model('log', LogSchema);

最後にclientごとのUIを定義するためのClientUISchemaです。
これは制御する機器のコマンドとUIの表記を記述したテーブルを記録しています。
var ClientUiSchema = new mongoose.Schema({
  client: {type:String, required: true},
  clientUi: mongoose.Schema.Types.Mixed
});
var ClientUi = db.model('client_ui', ClientUiSchema);

長くなってきたのでUIのテーブルについては次回にします。

2015年8月21日金曜日

websocket

これまでは自宅のNAT内のRaspberryPiのホームコントロールシステムを外からアクセス出来るようにするためにNAT内から外のサーバーに対してTLSでsocketを1本通しておいて、外部サーバーの443portにアクセスしてきたものをclient認証をした後にTLSを逆流させてRaspberryPiのapache2に繋ぐという仕組みを作って運用していました。
これはこれで簡単でいいのですが、apache2をRaspberryPiで運用していたのでどうしても重たくなっていました。
少し世間一般的な解決方法を取り入れようと考えて、色々と最近の流行を調べたりしているのですが、webの世界はフレームワークの標準とかの変化が激しすぎてなかなかついていけません。とりあえず始めないと始まらないので、まずは手始めにサーバーサイドをnode.jsにしてRaspberryPi上のホームコントロールサーバーにwebsocketのプロトコルを話せるような機能を追加してみました。
websocketはwikipediaの説明を読めば大体理解できたので対向のwebsocketサーバーにnode.jsのサンプルプログラムを利用してそのままTLS化して繋いで動作確認をしていきます。
まだ他の部分が安定して動作してないので安定してきたら公開しようかと思います。
最終的にはセンサー、HAコントロール、etcの機能をESP8266を使ったWiFiモジュールで実現し、RaspberryPi2上のホームコントロールサーバーで情報集約してsecure websocketでNAT越しにさくらVPSで借りているサーバー上のnode.jsに接続、そこからiPhone上のWebAppに繋ぐということを実現しようかと考えています。
まだjavascriptを勉強し始めたところなので道のりが長そうですが........

2015年7月24日金曜日

ESP-WROOM-02 WiFiモジュール

Cerevoから発売された技適対応のWiFiモジュールが安いので買おうと思っていたら、あっという間に売り切れてしまいました。
暫く入荷待ちするつもりでいたら数日後にスイッチサイエンスからも予約販売されたのですかさず注文してみました。モジュール単体でも普通にハンダ付け出来そうですが、一応変換基板付きも一緒に購入しました。

IEEE802.11b/g/n対応で技適対応で710円+消費税は格安です。XBeeよりも千円くらい安くてWiFi接続できるのは魅力的ですね。WPA2対応のようですし、家電制御に使うにはこんなものかと思います。


入荷予定日に発送しましたとの通知が来て翌日届いたので、秋月のUSB-UARTモジュールと接続しました。


今週は組み立てただけで、ちょっと忙しくてまだ火入れできていません。
動かしたらどんな感じかレポートします。

2015年7月17日金曜日

DAIKINエアコンのコントロール

自宅ではないのですが、ダイキンのエアコンにHA2moduleを接続しました。機種はS22STES-Wです。
HA端子対応と聞いていたので簡単につながるかと思いましたが、色々と大変でした。
現地でカバーを開けて基板を確認してみましたが、どこにもHA端子らしいものが見当たりません。




ネットでカタログとか色々調べてみると、どうも別売りの基板が必要でそれなりの値段です。
エアコンの電源の状態を取るためにはHA端子が必要なのですがそのために基板を購入するのは勿体無いので、statusを取れそうなところを探してみました。
メイン基板上のコネクタなどをテスターであたりながら電源をon/offして変化するかを確認していきますが適当な信号が見当たりません。今回は自分のものではないので基板にハンダ付けとかで線を引き出すわけには行きません。
混み合っているところなので線を引き出すのが大変そうなのですが、結局on/offの表示LEDとSWや赤外線リモコンの受光部の載っている基板から取ることにしました。




基板のパターンを追いながら回路図(下の回路の黒線部分)にしていきます。
動作中の電圧をみながら動作を想定して、HA2moduleのHA端子のフォトカプラに繋ぐ回路を追加。
LED基板側の10pinコネクタを外してコネクタの種類を確認します。
形状からJSTのPHコネクタのようですので、オス・メスのコネクタを用意して中継する途中から信号を横取りすればいけそうです。(下の回路の赤線部分)



運転LEDは13.7Vの電源からLEDをとおして1.8kΩの抵抗の先で多分Trでon/offされるようです。
このLEDと並列にフォトカプラのLEDに2Kの抵抗を介して接続します。
HA2moduleのHA端子の制御側もフォトカプラのTrなのでon/off出来るSWのところに噛ませます。
これで通常のHA制御と同様の機能が実現できます。
ちょっと判りにくいですが、元々のPHコネクタの先に延長ハーネスを追加して途中から信号を取り出しています。
 




これに温度センサーと赤外線発光部をつけてエアコンの内部に収めて出来上がりです。
かなりごちゃごちゃしてますが、なんとか収まりました。


ちゃんとリモコン信号でも制御できて、HA端子側からon/off制御、動作ステータスがとれていることを確認して完成です。


2015年7月10日金曜日

バーチカルブラインドの電動化 その5

仮組みした所はロフトからアクセスが簡単な、目的とは別のブラインドの手動の紐が出ている側ですが、実際に取り付けたい所は簡単にアクセス出来ない吹き抜けの上のブラインドで、手動の紐と両立したいので手動の紐の出ていない側になります。梯子をかけて頑張って取り付けました。




紐の無い側の構造は非常に簡単で、2本の軸をスペーサーと止め輪(丸くて内側に歯がついていて軸に咬むようになっているリング)で止まっているだけなので止め輪を2つ外すことで簡単に取り外せます。写真はカバーと止め輪とスペーサーを外した状態です。

ここにモーター部を取り付けます。上から見るとこんな感じです。



ちょっとごちゃごちゃしていますが吹き抜けのところなので下から4.5mほどあり、それほど気になりません。




実際の動作はこんな感じです。




実験していた側のブラインドが24枚スラットだったのですが、最終的に取り付けた側のブラインドが30枚スラットと増えているのと僅かですが手動用の紐の負荷もあるのでちょっと重そうです。

本当はもう少し強力なモーターの方が良さそうですが、モーターの軸間が20mmなので直径20mm以下のモーターで手頃なものとなるとなかなか選択肢が無いのとGear比をこれ以上高くすると今度は手動で回せなくなりそうなので暫くこれで運用してみようかと思います。





2015年6月5日金曜日

KiCadで作成したパターンをelecrowに出図







パターンを引き終わったらDRCを掛けます。
エラー、未配線とも無いことを確認しファイルメニューのプロットからガーバーデータとドリルデータを出力します。
必要なレイヤーはF.Cu,B.Cuの銅箔レイヤー、F.Silk,B.Silkのシルクレイヤー、F.Mask,B.Maskのレジストレイヤー、Edge.Cutsの外形図です。
オプションはフットプリントの参照記号を出力のみ選択します。
ガーバーオプションはProtelの拡張子を使用する。とシルクをレジストで抜く。を選択し、4.6mmで製造ファイル出力を行います。
ドリルデータの方は単位をmmに変更、リーディングゼロサプレス、ガーバーフォーマット、補助座標系を選択しドリルファイルを生成します。
出来上がったガーバーデータ、ドリルデータをガーバービューアーで開いて確認します。
ドリルの穴位置とガーバーの穴位置があっていること、シルクなどの位置を確認してOKならzipで固めてelecrowで手続きします。
今回は67mmX27mmの基板なので100mmX100mmの基板に3面付けしてv-cutを入れてもらい10枚オーダーします。合計30枚出来上がる計算です。
前回は香港DHLを選んだので比較のため深圳DHLを選んでみます。


3/8(日) 注文
3/9(月) 受付、製造開始
3/19(木)19:19出来上がったと写真付きメール、発送したとのDHLのtracking numberの連絡
3/19(木)
1       Shipment picked up                  SHENZHEN - CHINA 20:01
2       Arrived at Sort Facility            SHENZHEN - CHINA 22:03
3       Processed at SHENZHE                SHENZHEN - CHINA 22:36
4       Departed Facility in SHENZHEN       SHENZHEN - CHINA 22:40
5       Customs status updated                     HONG KONG 23:49
6       Clearance event                     SHENZHEN - CHINA 23:50
3/20(金)
7       Clearance processing complete       SHENZHEN - CHINA 00:20
8       Arrived at Sort Facility                   HONG KONG 03:33
9       Processed at HONG KONG                     HONG KONG 04:00
10      Clearance processing complete at HONG KONG HONG KONG 04:00
3/21(土)
11      Processed at HONG KONG                     HONG KONG 02:19
12      Departed Facility in HONG KONG             HONG KONG 02:19
13      Customs status updated                 TOKYO - JAPAN 09:32
14      Transferred through                    TOKYO - JAPAN 10:37
15      Arrived at Sort Facility               TOKYO - JAPAN 12:35
16      Clearance processing complete at TOKYO TOKYO - JAPAN 13:07
17      Processed at TOKYO                     TOKYO - JAPAN 16:05
3/22(日)
18      Processed at TOKYO                     TOKYO - JAPAN 21:15
3/23(月)
19      Departed Facility in TOKYO             TOKYO - JAPAN 01:51
20      Arrived at Delivery Facility in TOKYO  TOKYO - JAPAN 07:03
21      With delivery courier                  TOKYO - JAPAN 08:27
22      Delivered                              TOKYO - JAPAN 12:13

と10日(土日を除くと8日)で製造、4日(日曜を除くと3日)で届きました。
前回は11日(土日を除くと7日)で製造、3日で到着だったので3面付け、v-cutの分で1日余計にかかっている感じです。
出来上がった基板です。



Panelizeと送料含めて$40.27=¥5045でした。

これに部品を載せます。



古いHA-2基板との比較です。



 左側が新しい基板です。
改修がなくなり作るのが楽になりました。