Milesight センサーをデスクと会議室の状況にする

Offision に現れたばかりのセンサーは、正確に報告しているのに何も意味しません—— 「在席」と言っているだけの製造番号で、それがどこの話なのかを知らないからです。デスクや会議室に結び付けて初めて、人が見られる状況になります。

センサーを見つける

報告したセンサーはすべて、マーケットプレイスの Milesight タイルの中で、それぞれのゲートウェイのページに並びます——つないだばかりのセンサーを探すにはここが一番近道です。どれも Milesight センサー として、シリアル番号 （devEUI） とともに並びます。

デバイスモニタリング にも他のあらゆる機器と一緒に出てきます。台数が 1 画面に収まらなくなったら、こちらのほうが向いています。

センサーに場所を与える

センサーを開き、バインドタイプ を使います。

デスクのセンサーや会議室のセンサーなら リソース を選び、向けている先のデスクか会議室を指定します。結び付けはこれだけです——1 台に 1 リソース。

空気センサーはたいてい 所在地 です。部屋の空気を語るものであって、「この部屋は予約されて使われている」とは別の主張だからです。同じ場所を測るものをまとめたいときは、IoT スペース に入れることもできます。

センサーが指すのは機器であって、デスクではない

センサーは製造時に焼き込まれた番号で識別されます。電池交換でも、初期化でも、別の建物へ移しても変わりません。ここから、知っておかないと後で刺さることがひとつ出てきます。

壊れたセンサーを新品に替えると、そのデスクは黙ります。 新しい機器は別の番号を持つので、Offision は別のセンサーとして扱い、どこにも結び付いていない状態で現れます。交換した機器をデスクに結び付ければ元どおりになり、デスクの履歴はどちらの場合も残ります。

届いた値の見え方

センサー自身のページには、報告しているかどうか、最後の報告がいつか、そして送ってくる値ごとのタイルが出ます。このページは このセンサーは元気か を見るためのもので、以下はデスクや会議室の話です。

センサーの各セクションには 履歴を表示 があり、選んだ期間のひとつの値をグラフにします。昼過ぎになるといつも息苦しい会議室が、感想ではなく CO₂ の曲線に変わります。

デバイスモニタリング は別の問い——報告していない機器はないか——に、全台をまとめて答えます。ひとつの部屋の物語ではありません。

在室状況をチェックインとチェックアウトにする

リソース に結び付ける目的はこれで、デスクに在室センサーを置く一番の理由でもあります。リソースのポリシーで設定します。

このうち 2 つは、そのまま受け入れずに考える価値があります。

• 継続検知時間 が短すぎると、デスクのセンサーの前を通っただけの人が他人の予約をチェックインしてしまいます。長すぎると、チェックインが壊れていると思われます。
• 非検知の継続時間 が短すぎると、全員が昼食に出ている間に部屋が解放されます。終日予約についてはセンサーによる自動チェックアウトを丸ごと無視する設定が別にあり、終日のデスク予約ではたいていそちらが要ります。

どちらもセンサーが送る 在席／不在 をそのまま読むだけです。人数はまったく要りません——だから在室センサーで足りますし、この機種が人数を数えられないことも問題になりません。

パネル、看板、フロア図では

デスクや会議室に結び付いてしまえば、その状況は他のどんな状況とも同じように伝わります。フロア図でデスクが使用中になり、扉の外のルームパネルが使用中を示し、自動でチェックインされた予約はどの画面でも同時にチェックイン済みになります。

このために設定するものはありません。センサーの仕事は報告した時点で終わり、そこから先はリソースの状況で、リソースはもともとそれらの画面に載っています。

状況がおかしいとき