Falconの思うままに

きままにマニアックなネタを

洗濯検知(その6)

さて、洗濯検知も完成に近づいてきました。

 

OpenPLCへMODBUS経由で流し込んで、OpenPLCから結果をもらいます。

NodeRed側ではMODBUSの読み出しノードを使って、グローバル変数で受けます。

 

これによりNodeRed側は普通の変数としての扱いができます。

ちなみにMODBUSのBIT情報を1BIT取ってきても8BITの配列で

返ってきます。切り出し作業が必要です。はまるので注意!

 

ちなみにMODBUSサーバーはOpenPLCが組み込みで内蔵しており、

デーモンとして起動するので、何の苦労もありません。

NodeRedでもMODBUSサーバーを立てることができますが

どちらでも変わりません。

むしろNodeRed内の場合デプロイすると一旦値がリセットされるので

デプロイ頻度を考えると、

OpenPLC側のMODBUSサーバーのほうがメリットがありました。

 

下記が現在のフローです。

朝、定時にInjectionノードで起動して、洗濯があったら、WAVファイルを

スピーカーから流すという、プログラムとなっています。

 

洗濯検知回路

この実現にはシリアル通信、MODBUS通信,OpenPLC,INFLUXDB,WAVファイル再生

という組み合わせで実現されています。ハードはTWILITE CUEが情報源となって

います。

後は、これをクラウド上のNodeRedへ送信するとスマホから状態確認ができるように

なります。自作のPWA製自宅モニタアプリに項目追加しておきます。

 

以下、脱線しますが、スマホで家電管理が流行りですが、

それぞれのサーバー経由で外へ出てかれるのが、いやな私はすべて手製でと考えてやってます。

Alexaだけは例外ですが(笑) 

AlexaのSkilでNodeRedと連携もあるみたいですが、自分が管理できないサーバーに

アカウント作って情報を送るのが嫌ですね。 家電操作など一般リリースされている製品はクオリティーがそれは高いですが、自宅ネットワークからAPI発行しまくりなので、サーバー側から自宅LANをセンシングされても(極秘VPN貼られていたり)

通常わからないというのが怖いです。技術的には可能ですよね。

悪意あるファーム搭載の製品が突如悪意ある製品になることはあり得ます。

前にコンセントの電源を遠隔で入り切りする製品もどこかのサーバーへの登録

しないと駄目で、コンセント増やすほどアカウント管理が増えるので

便利だけど止めました。

 

うちのLAN見られても困らないからいいやという人もいるでしょう。

でも踏み台サーバーになる可能性もあります。

もう、なんでもできてしまう世の中、守るのは自分ですね。

 

ではでは。

 

 

 

 

 

 

 

洗濯検知(その5) OpenPLC側のプログラム実装

さて、洗濯検知のOpenPLC側の実装ですが、数行のラダーの為に一日がかり

でした。

ええ、数行のラダーは5分で終わるんですが、

コンパイルエラーの原因がわからず、はまってました。

 

OpenPLCはラダーを一度ST言語に変換するんですね。

それをまたCソースに落として、コンパイルをgccでやるよう。

プリプロセスがあるようです。

それでSTに変換した後の文法チェックでエラーがでるのですが、

これがまた、ラダー側からみるとどこでエラーかがわかりずらい。

結局文法ミスなんですが、定数の書き方が悪かったのですが、

)がないとか、いろいろエラーがでました。

 

そういうものということで、学習しました。

エラーメッセージにこだわると本当の原因が不明になる事例でした。

商用のPLCに比べると苦労が多いのは覚悟でしたが、

エディタの入力も慣れないなあ。

 

OpenPLC側実装ラダー

で、ラダーは上記ですが、本当にはずかしいくらいの制御です。

蓋を閉めたのを記憶して、開いたら解除です。

TWILITEが1分間隔の送信なんで、それ以上激しい動きは取れません。

まあ、お試しです。

接点とデータをMODBUSにマッピングしてあり、

NodeRedとデータ交換をする形になります。

上記M0コイルが洗濯有のBITになります。

これをNodeRed側で、朝チェックして、ONであればスピーカーで

アナウンスということになります。

MODBUSへマップするとWeb画面のMONITORで信号状態がでてきます。

 

後は時間をNoedRed側から送り込もうと思っています。

OpenPLC側で時間取得は思いつかないので、間接で流してやって

カレンダータイマ接点のように使おうと思っています。

 

スキャンタイムは最速20msecらしい。(デフォルト)

まあ妥当でしょう。

OpenPLCはPython用モジュールやC言語のインライン書きができるようで、

それも追々試そうかと思います。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

遠隔監視でPovo SIMの活用

今日は朝から妄想中...

さて、懸案事項でしたPovoのSIMをそろそろ買おうかと。

遠隔監視構想

 

 

4G LTEの回線を最低限の維持費で使って、遠隔監視回線として

使おうかなと思っています。 128kpbs前提で常時接続させてもらえます。

 

これで、遠隔の建屋にラズパイを置いて、Povoのモバイルルーター

を置きます。これで、超低速ですが、常時接続した回線ができますよね。

 

VPN接続させておけば、何らかの情報交換をして、遠隔側の情報を

ゲットできればと。

もちろん監視カメラの画像とか無理なんで、ドアの状態とか、室温

モーションセンサの状態など、センシングメインですな。

 

あわよくばドアの自動施錠のコントロールもしたいのですが.....

 

今ラズパイは自宅に2台あるのでRaspi 3のほうを回してあげようかと。

どちらもUbuntuVPN環境なんで、そこはすぐに設置できます。

問題はリモートメンテできるレベルかどうかです。

 

SSHくらいじゃいけるんじゃない? となめてますが(笑)

そこは実験ですね。

 

Povoはトッピングという方式で一時的に増速できるので

緊急メンテしたいときは、ブロードバンド化できるので

それでもいいかなと。

 

これまでの実験はこの為にあるといっても過言ではないんですが、

TWILITE持ってきたのも配線レスでセンシングできるからです。

家中配線だらけにしたら怒られる(汗)

Arduinoにしようかと思ったがOSがあるほうがいいよね。

 

4G LTEの世話になるしかないですが、LoRa Privateも試してみたいなあ。

11byte程度でもbit情報なら使えます。

補助回線でほしい気もする。

 

難点は機材にお金がそれなりにかかります。

そんなこと言ったらLTEもですが、投資するリスクがLoRaのほうが高いですな。

使えなくてはもったない!!

 

TWILITEは最大1kmですが、ちょっと試したところ見通し200mくらいで

ちょっと無理。

遠隔地まで直線500mなんですが、山が間にあります。(汗)

 

そんなわけで、Povo買っちゃおうかな。

ルーターがソフトボタンだと困るので、車載用ルーターを狙ってます。

 

ではでは。

 

洗濯検知のNodeRedフロー解説

さて、洗濯検知はTWILITE CUEで行っていますが、
これを受信して活用するのはラズパイ側のNodeRedです。
 
非常に簡単なフローで紹介するまでもないですが、
受信したシリアルデータをMODBUSとINFLUXDBへ
上げるまでを行っています。
 
このあたり非常にNodeRedの柔軟性を発揮するところで
フローは何通りも書けます。
それを最適化して簡潔なフローとなりました。
 
基本的にfunctionノードを多用したくないという
思いはあります。 

TWILITEからのメッセージ処理
functionノードの中身は以下のようにします。
ちなみにJavaScript書けない人なので手探りです(笑)
ご存じPASCAL LOVEな人ですから...
   
var t,lid,lqi,snumm,ev,evkind,v;

t=msg.payload;

lqi   =parseInt(t.substr(9,2),16);
lid   =parseInt(t.substr(23,2),16);
snum  =parseInt(t.substr(29,2),16);
evkind=parseInt(t.substr(49,2),16);
ev    =parseInt(t.substr(53,2),16);
v     =parseInt(t.substr(69,4),16);

var nmsg = {
    "payload" : {
     "array" : [ lid,lqi,evkind,ev,v],
     "json"  : {
                  "LID": lid,
                  "LQI":lqi,
                  "KIND":evkind,
                  "EVENT":ev, 
                  "VOLTAGE":v
               }
    }
};

return nmsg; 
このようにMODBUS用の配列

payload.array

とINFLUXDBへ流す用のJSON形式

payload.json

を生成して、changeノードで payloadへ変換して流し込んでいます。
もっといい方法あったら、どなたか教授ください。
 
MODBUSに書いておくと、OpenPLCからデータを拾えますので、ラダーもしくはST言語で処理を書きます。
INFLUXDBへは可視化の為に流しておきます。
下準備ができましたので、この後はOpenPLC側を考えます。
処理結果はまたNodeRedへ戻すのですが、OpenPLCを活用する実験としてやっています。
今回の処理ははっきり言って、NodeRedで全部処理できますが
そこは研究ということで。
 
ではでは

 

 

 

TWILITEで洗濯検知 受信感度調査

さて、TWILITEでの洗濯検知ですが、

とりあえず一定周期送信されるデータに受信品質(LQI)を入れて

おきました。

数日たてば、りっぱな時系列データになります。

InfluxDBにデータを入れていますので、Grafanaで可視化してみました。

こういう時Grafana便利ですね。

本当はInfluxDB社の可視化ツールがあるんですが、インストール方法が

わからなく断念。Grafanaはさくっと入りました。

 

LQI

 

すると面白いことがわかります。日中人がいない時間は安定した送信になります。

人がいる時間は受信感度が下がります。人が室内にいるせいで受信品質が

悪くなるようです。

不思議なのは夜に感度が変動することですね。

 

まあ、品質が悪くともデータは届いているので、問題はないですが、

電波の性質がよくわかるデータとなりました。

TWILITEタグの位置検知もできるように紹介されていますが、

見通しが悪いとリニアに変化しないので、距離検知は難しいですね。

 

 

 

 

 

 

CodeTyphonを新規インストール中(最近の私のツール類)

Windows10のマシンが手元に来ました。

2万の中古ですが....

でもサクサク動くので趣味の開発用端末にします。

 

それでいろいろやっているのですが、

WSL

Windows Terminal 

MovaXTerm

RLogin

VSCode

SoftEther Client

Remote Desktop Client

くらいでだいたい作業ができます。

それでCodeTyphonをインストールします。

最新版です。結構Updateが入ってますね。

しかしCodeTyphonのサイトはダウンロードが遅いです。

根気強く待ってファイルを落としてきます。

レジューム付きでリトライできないとつらいですよ。

 

今回のインストールでPASCAL SCADAをちゃんと

使えるようにしたいと思います。

これはSCADAパッケージです。

Pascal言語でSCADAができるんです。

三菱PLCと通信ができるみたいなんで、それ狙いです。

MCプロトコルいければキーエンスもいけますし。

オムロンも三菱PLCとのリンクでサポートしてたりしますね。

FBとかPMとかで。

まあデファクトスタンダードというところでしょうか。

日本国内はこれでカバーされますね。

 

何がいいかというとTAG通信レベルでラズパイで

プログラム作れるところです。フリー環境なんで

ソース公開しても問題なく環境構築してもらえるので

そこが魅力です。

まあPythonでやってもいいんですがタグシステム

出来上がっているので使わない手はないですね。

それでP4D(Python for Delphi) を入れておけば

Pythonとも橋渡しできるし。

まあMODBUSに突っ込んで Python,NodeRedと連携でも

いいですしね。

 

あわよくば、これからこれを標準にしたいなと思います。

Windows,Linux両対応で作れます。

32bit,64bitアプリ両方いけますのでラズパイも

32bit,64bitあるんで使い分けします。

 

これだけのことをさらっとやれるのって相当すごいことですよ。

ぜひCodeTyphon (Lazarus)の完成度の高さを体験してください。

 

日本ではマイナー、世界でもマイナーですが、世の中には

まだまだPASCAL好きはいるんですね。

 

TMS Softwareもそうですが、なかなか熱いものを感じます。

 

日本でも昔のように盛り上がるといいのですが.....

まあ、ひっそり実用的でも私は十分ですが。

 

 

 

 

 

 

 

 

LXDで失敗(復旧済)

さて、OpenPLCを起動して喜んでいたら、やらかしました。

既存NextCloudのコンテナが異常を吐いてサービスが止まって

しまっていました。 

起動指令を出しても、エラーで起動しないことだけがわかります。

 

あら、壊してしまったかなと思って、再構築を覚悟しました。

どうもメッセージを見ているとDiskスペースがどうのという

感じでした。 DFコマンドでみても容量あるしなと思っていたのですが、

単純に私がLXDの仕組みを知らないだけでした。

 

LXD自体がコンテナを入れるストレージを確保するんですね。

これがストレージプールと言われるもので、コンテナを増やした

んで、一杯になって、コンテナが起動異常になったというのが

結論です。

コンテナの容量を気にせず増やしていったのがまずかった。

知識がないと恐ろしいですな。

ZFSでストレージプールがあるので、それを拡張する命令を

発行して、領域を広げればいいということらしい。

 

これは海外の情報なんです。英語を斜め読みしてなんとか。

日本でやっている人はいないのだろうか。

そもそもLXDを使おうとする人はプロなんで、はまらないということかなあ。

ここではまったおかげで、知識が身に付きました。

 

領域を広げたら、既存のコンテナはすべて正常に起動しました。

 

あ~あ、よかったと胸をなでおろした次第でした。

 

理解としてはVMWAREの仮想DISKみたいなものですね。

(本当か?)

なのでバックアップも楽だし。

Dockerの思想はちょっとちがうのかなあ。

中にデータ入れちゃ駄目みたいだし。