POCセンサーモジュール 開発ガイド

はじめに — 開発の全体像

POCセンサーモジュールを使う開発は、大きく3ステップで完結します。ライブラリを導入し、APIを初期化し、目的の機能を取得して読み書きする。これだけです。デバイスドライバのインストールや、レジスタ仕様書との格闘は必要ありません。

モジュールと「機能」の関係

設計上、重要な考え方が一つあります。1台のモジュールは、複数の「機能」を持ちうるという点です。たとえば温湿度・気圧の複合センサーは、温度・湿度・気圧という3つの機能を1台で提供します。ブザー付きの操作パネルモジュールなら、ボタン入力・ブザー・LEDがそれぞれ独立した機能です。

プログラムから操作する対象は、モジュールそのものではなくこの「機能」の単位になります。温度を読みたければ温度機能を、リレーを動かしたければリレー機能を取得します。どのモジュールに載っているかを意識せずに書けるため、後から機種を変更してもコードが影響を受けにくい構造です。

接続モードの選択

APIの初期化時に接続先を1つ指定するだけで、動作モードが決まります。ここが本シリーズ製品の設計上もっとも効いている部分です。

この1行以外、コードを変更する必要はありません。USB直結で開発したプログラムを、そのままネットワーク構成の本番環境へ移せます。試作から量産への移行コストが小さいのは、この設計によるものです。

最初のプログラム

温度センサーの値を読み、しきい値を超えたらリレーを動かす——産業用途でよくある構成を例に、最小限のコードを示します。Pythonで書いていますが、他言語でも構造はまったく同じです。

# ライブラリの読み込み
from yoctopuce.yocto_api import *
from yoctopuce.yocto_temperature import *
from yoctopuce.yocto_relay import *

# API初期化（USB直結モード）
errmsg = YRefParam()
if YAPI.RegisterHub("usb", errmsg) != YAPI.SUCCESS:
    sys.exit("初期化に失敗しました: " + errmsg.value)

# 使用する機能を取得
t = YTemperature.FirstTemperature()
r = YRelay.FirstRelay()
if t is None or r is None:
    sys.exit("モジュールが見つかりません")

# 制御ループ
while True:
    value = t.get_currentValue()
    if value > 25: r.set_state(YRelay.STATE_B)
    if value < 24: r.set_state(YRelay.STATE_A)
    YAPI.Sleep(100, errmsg)

設計上のポイント2つ

しきい値にヒステリシスを設ける。上の例では25℃で動作させ、24℃で戻しています。同じ値で判定すると、測定値がしきい値付近で揺れたときにリレーが激しくばたつきます。機械式リレーでは寿命に直結するため、1℃程度の不感帯を設けるのが定石です。

待機にはAPIのSleepを使う。言語標準のsleepはプロセス全体を止めてしまいますが、APIのSleepは待機中もモジュールとの内部通信を継続します。デバイスの着脱検出やイベント処理が正しく動くため、こちらを使ってください。

対応言語と導入方法

主要な開発環境をひととおり網羅しています。既存の社内システムに合わせて選定いただけます。

導入方式は2通り

• パッケージマネージャ経由 — Python（pip）、Node.js（npm）、Java（Maven）、Android（Gradle）などは1コマンドで導入できます。バージョン固定ができるため、チーム開発や CI 環境ではこちらを推奨します。
• ソース・バイナリの直接配置 — 配布アーカイブを展開し、パスを通す方式です。パッケージマネージャに依存したくない環境や、オフライン環境ではこちらを使います。

ネイティブライブラリの同梱漏れに注意

C#／Java／LabVIEW など、実行ファイルを配布する形態ではUSBアクセス用のネイティブライブラリ（.dll / .so / .dylib）が必要です。IDEの自動パッケージング機能はこれを含めてくれないことがあり、開発機では動くのに配布先で「ライブラリが見つからない」となる典型的な原因になります。64bit版は所定のサブディレクトリに配置する必要がある点にもご注意ください。

論理名による設計

機能を取得する方法は3通りあります。用途に応じて使い分けます。

なぜ論理名を推奨するのか

各モジュールには任意の論理名を書き込めます。設定は不揮発で保持されるため、一度設定すれば以後その名前で参照できます。これには実務上2つの利点があります。

• 可読性 — 多数のモジュールで構成されたシステムでも、炉内温度／排気ファンのような名前でコードが読めます。シリアル番号の羅列と比べて保守性が大きく変わります。
• 横展開のしやすさ — 同じ装置を複数台製作する際、각個体のシリアル番号に合わせてコードを書き換える必要がありません。同一のプログラムをそのまま配布できます。

ネットワーク構成への移行

USB直結で作ったシステムを、そのままネットワーク越しの構成へ拡張できます。変更するのは初期化の引数1つだけです。

# 開発時：PCに直結
YAPI.RegisterHub("usb", errmsg)

# 本番：ネットワーク上のハブ配下を操作
YAPI.RegisterHub("192.168.1.2", errmsg)

# 認証が設定されている場合
YAPI.RegisterHub("admin:password@192.168.1.2", errmsg)

センサーを設置現場に置き、収集側を別の場所に置く構成が、これだけで実現します。複数拠点を扱う場合は、拠点ごとに初期化を呼べば1つのプログラムから同時に扱えます。

ネットワーク接続に使うハブ製品

用途に応じて有線LAN（PoE給電対応）、無線LAN、LTE／セルラー回線から選定します。センサー側のプログラムは共通のまま、通信手段だけを差し替えられる点が実務上大きな利点です。

コールバック方式（NAT越え）

モバイル回線や一般的な社内LANでは、外部からハブへ直接接続できません。グローバルIPを持たず、NATの内側にあるためです。この制約を回避するのがコールバック方式です。

通常とは通信の向きが逆になります。ハブ側から定期的にサーバーへ接続してくるため、外向き通信さえ通れば動作します。ルータやファイアウォールの設定変更が不要になり、導入のハードルが大きく下がります。

2つの方式

• HTTPコールバック — 一定間隔でサーバー上のスクリプトへ接続します。PHPなど、常駐プロセスを持てない環境で使えるのが利点です。ただし通信は一度きりで完結するため、連続的なやりとりはできません。
• WebSocketコールバック — 双方向の通信を維持できます。サーバー側からモジュールへ問い合わせができるため、データ収集だけでなく遠隔制御まで踏み込めます。Node.jsやJavaなど常駐サーバーを立てられる環境向けです。

複数モジュールの扱い

種類を問わず値を読む

温度・照度・電圧など、すべてのセンサー機能クラスは共通の基底クラスを継承しています。この基底クラスを使えば、センサーの種類を問わない汎用コードが書けます。現在値と単位の取得は共通のメソッドで行えるため、機種追加のたびにコードを増やす必要がありません。

# 温度センサー限定の書き方
sensor = YTemperature.FirstTemperature()

# センサー種別を問わない書き方
sensor = YSensor.FirstSensor()
# → 温度・照度・電圧・気圧など、接続されている任意のセンサーに対応

GUIアプリケーションでの注意

コンソールアプリと異なり、GUIでは無限ループで値を読み続けることができません。タイマーで定期的に処理を呼ぶ構成にします。その際、以下を組み込んでください。

• イベント処理の呼び出し — 定期的にAPIへ制御を渡します。
• デバイス一覧の再取得 — 新規接続を検出するために必要ですが、処理が重いため2秒程度の間隔に抑えます。毎回呼ぶとUIが重くなります。
• オンライン確認 — 利用者は予期しないタイミングでケーブルを抜きます。アクセス前に必ず状態を確認し、切断時の表示を用意しておきます。

また、本格的なアプリケーションではAPI呼び出しを別スレッドへ分離することを推奨します。特にネットワーク経由の構成では通信待ちが発生するため、UIスレッドで処理するとレスポンスが悪化します。

よくあるつまずき

「別のプロセスが既に使用中」というエラー

最も多い相談です。同一PC上で、USB直結モードを使えるプロセスは1つだけという制約によるものです。設定ツールを起動したまま自作プログラムを実行すると発生します。

解決策は、仮想ハブを常駐させ、プログラム側は127.0.0.1を指定して接続することです。こうすると複数のプログラムから同時にアクセスできます。開発中は設定ツールとプログラムを併用する場面が多いため、最初からこの構成にしておくと快適です。

配布した実行ファイルが動かない

前述のネイティブライブラリの同梱漏れが大半です。開発機には環境が整っているため気づきにくく、配布先で初めて発覚します。パッケージング設定でライブラリの出力先を明示的に指定し、クリーンな環境で一度動作確認することをお勧めします。

終了処理を忘れる

アプリケーション終了時にはAPIの解放処理を呼んでください。忘れると、次回起動時にリソースが掴まれたままになることがあります。開発環境を再起動するまで復旧しない場合もあるため、終了処理は最初に書いておくのが安全です。

センサー値が不安定に見える

制御対象がしきい値付近で振動している場合、前述のヒステリシスを設けてください。また熱系のように応答が遅い対象では、単純なオン／オフ制御では行き過ぎ（オーバーシュート）が生じます。目標値へ急激に変化させず、段階的に近づける制御を入れることで安定します。

サポート・受託開発

ポジティブワンは、これらのモジュールの正規取扱代理店として、国内での供給と技術サポートを提供しています。

• 選定のご相談 — 測定対象・確度・設置環境から適切な機種をご提案します。
• 構成検討 — USB直結／ネットワーク／コールバックのいずれが適切か、拠点数や回線条件を踏まえて設計をお手伝いします。
• 動作検証 — 実機での事前検証に対応します。屋外や高温環境など、仕様範囲外での使用可否の確認もご相談ください。
• 受託開発 — 収集システムやGUIアプリケーションの開発、既存システムへの組み込みまで対応可能です。
• 組み合わせ提案 — 当社主力ブランド Chinchilla のSOMと組み合わせた、組込みシステム全体の構成もご提案できます。