同じデータでも──意味や価値が違えば、別物になる |ストレージ再考 第2話

見た目が同じでも、意味は同じではない

スマートフォンの中にある一枚の画像。
それはただの「写真」かもしれないし、二度と取り戻せない記録かもしれない。

画素数も、ファイル形式も、見た目も同じ。
それでも、その扱いはまったく変わる。

例えば──
・たまたま撮れた風景
・仕事の記録
・家族の思い出
・証拠として残す必要のある写真

どれも「画像データ」であることに違いはない。
しかし、同じ扱いでよいとは、誰も思わないはずだ。

ここで起きているのは、技術の違いではない。
意味と価値の違いだ。


use
use

画像は「データ」ではなく「位置づけ」で価値が変わる

画像という形式だけを見れば、それは単なるデータだ。
だが、人がそこに意味を与えた瞬間、別の存在になる。

同じ構図の写真でも、

  • 落書きの記録
  • 美術作品の記録
  • 事故の記録
  • 成長の記録

それぞれの立場によって、役割はまるで違う。

画像の本質は「ピクセルの集合」ではない。
どの位置づけで存在しているかが、その正体を決めている。


use2
useB

媒体が変われば、意味も変わる

同じ「画像」でも、残され方はさまざまだ。

洞窟の壁に描かれたもの。
紙に描かれた絵。
油絵。
版画。
写真。

それぞれの時代、それぞれの方法で、
「残す」という行為は繰り返されてきた。

そして、残されたものの中には、
意味がはっきりしているものもあれば、
何のために描かれたのか分からないものもある。

それでも共通しているのは、
“残った”という事実そのものに価値が生まれることがあるという点だ。


極端な例で考えてみる

同じ「絵」でも、価値は極端に変わる。

子どもの落書き。
名画。

どちらも画像であり、どちらも記録だ。
しかし、扱いはまったく違う。

捨てられることもあれば、守られることもある。
複製されることもあれば、唯一のものとして扱われることもある。

ここで起きているのは、
媒体の違いでも、画質の違いでもない。

“何として存在しているか”の違いだ。


画像は、使われ方で別物になる

同じ画像でも、状況によって意味が変わる。

・個人的な記録
・共有される情報
・作品
・資料

そして、その扱いは自然に分かれていく。

気軽に消されるもの。
いつの間にか残り続けるもの。
意図して守られるもの。

人は無意識のうちに、
画像を「同じもの」として扱っていない。


しかし、私たちは深く考えていない

日常の中で、画像は大量に生まれる。
保存され、共有され、忘れられていく。

その一つひとつが、
どのような意味を持ち、
どのような価値を持ち、
どのように扱われるべきなのか。

そこまで意識していることは、ほとんどない。

同じように保存され、
同じように並び、
同じように消えていく。

けれど本当は、
同じであるはずがない。


同じ扱いのままでいいのか

同じ形式。
同じ見た目。
同じ保存先。

それでも、意味は違う。
価値も違う。
置かれている位置も違う。

本当は、全部同じ扱いでいいはずがない。

でも、どう違うのかは、
まだ整理されていない。

だから一度、
考えないといけない。


関連記事

https://mic.or.jp/info/2026/02/05/3-reasons-systems-feel-slower/

「星芋がほひいの」 訳アリのあまっているサツマイモの活用レシピ

人気がなく?余っている紫芋を活用して何かできないかレシピを考えてみました。

murasakiimo
紫芋

星芋の作り方

余り気味の甘さ控えめ芋でも、軽いおやつに仕上げる星芋レシピ。
先に薄く切り、元の形に戻して加熱し、夜の冷却と翌日の干しで完成させる。

星芋(イメージ)
星芋(イメージ)

材料

  • さつまいも(紫芋想定)…1本(約300g)
  • グラニュー糖 … 少量
  • バター … ごく少量

下準備

  1. 芋は軽く洗い、土だけ落とす
  2. 皮付きのまま縦に3〜4mmへスライス
  3. 切った順に元の形へ重ねて戻す

※ 完全一致でなくてOK
※ 少し空気層がある方が蒸気が回る


加熱(半生防止・確認最小設計)

  1. 重ねた芋を
     湿らせたクッキングシートで包む
  2. さらにラップで軽く固定
  3. 電子レンジ600W

加熱時間(300g)

  • 600W 5分
  • そのまま余熱 5分
  • 600W 3分

合計:約8〜10分相当

※ 芯チェックは竹串が通ればOK


バラし・夜工程

  1. 加熱直後にスライスをばらす
  2. 網・ザルに並べる
  3. 窓辺など空気が動く場所で自然冷却

時間:夜〜翌朝

murasakiimo
★芋

目的:

  • 水分の再分配
  • 放射冷却
  • 星に当てる工程

ここで初めて「星芋」になる


翌日:干し

  • 日中、風通しの良い場所で干す
  • 片面が乾いたら裏返す

目安:半日〜1日

仕上がり:

  • 表面乾燥
  • 中は柔らかい
  • 薄く軽い食感

仕上げ

完全乾燥前〜直後に:

  • バターをほんの少量絡める
  • グラニューを軽くひとつまみ

→ 甘さ不足の芋でも「おやつ」になる
→ 星屑のような見た目になる

ほしいも 完成品(実物)
ほしいも 完成品(実物)

まだまだ、改善の余地はありそうですね。 もう少しなんとかしてみましょう

データとは何か──「意味」と「価値」から始める記憶の話|ストレージ再考 第1話

ロゼッタ・ストーン ── 読めた記録

記録は、残るだけではデータにならない。
そこに刻まれたものが、誰かに解釈され、意味を持った瞬間、初めて「使えるもの」になる。

ロゼッタ・ストーンは、まさにその象徴だった。
同じ内容が異なる文字で刻まれていたことで、人は古代の文字を読み解く手がかりを得た。
石そのものはただの記録だったが、「読めた」ことでデータになった。

それは、理解された記録だった。

rosetta
Rosetta Stone

チバニアン ── 残った記録

人が残そうとしなくても、痕跡は残る。
地層に刻まれた磁気の向きは、遥かな時間を超えてそのまま保存されていた。
意図も目的もなく、ただ存在し続けることで記録となったもの。

人の手によらない記憶も、この世界には確かにある。

それは、意図せず残った記録だった。


洞窟壁画 ── 残された記録

洞窟の壁に描かれた絵の多くは、その目的が明確には分かっていない。
祈りだったのか、記録だったのか、ただの表現だったのか。

それでも、数万年の時間を越えて残っている。
意味が分からなくても、残存そのものが価値を帯びる。

それは、理由が分からなくても残った記録だった。


粘土板 ── 使われた記録

やがて人は、残すために記録を作るようになる。
交易、約束、数量、出来事。
日々の営みの中で、記録は「使うもの」になった。

そこには、残るだけではない役割があった。
読み、参照し、必要に応じて書き直される。

それは、役割を持って使われた記録だった。


石碑・金属刻印 ── 変わらない記録

一方で、書き換えないこと自体に価値が置かれる記録も生まれる。
石に刻まれた文字、金属に残された印。
そこには「変えてはならない」という意思が込められていた。

変わらないことで、信頼が生まれる。
時間が経っても同じであることが、意味を支える。

それは、変えないことに価値がある記録だった。


paper
paper

巻物・書物 ── 蓄えられた記録

知識は、単発の記録から連なりへと変わっていく。
巻物や書物は、断片ではなく「蓄積」を前提とした形だった。

一つひとつの記録が、積み重なり、つながり、参照される。
知識は保存されるだけでなく、増えていく。

それは、積み重ねられていく記録だった。


図書館 ── 集められた記録

記録は、単体ではなく集合として扱われるようになる。
書物が集められ、分類され、共有される場所が生まれる。

そこでは一つの記録ではなく、全体としての知識が意味を持つ。
記録は「個」から「群」へと変わった。

それは、体系として集められた記録だった。


口承 ── 人が担った記録

記録媒体が整う以前、人そのものが記憶の担い手だった。
語り継ぐことで知識は残り、世代を越えて伝えられた。

しかし、人がいなくなれば、それも消える。
記録は人の存在と切り離せなかった。

それは、人が背負っていた記録だった。


焼失した図書館 ── 失われた記録

集められた記録であっても、永遠に残るとは限らない。
火災や戦乱によって、多くの書物が失われてきた。

残したはずのものが、ある日突然消える。
保存されていることと、安全であることは同じではない。

それは、残したはずの記録だった。


未解読文字 ── 読めない記録

記録は存在していても、読めなければ使えない。
文字が残っていても、解釈の手がかりが失われれば、意味は閉ざされる。

そこに情報はある。
しかし、それを取り出す方法がない。

それは、存在していても使えない記録だった。

nazo
不解読文字

関連記事

https://mic.or.jp/info/2026/02/05/3-reasons-systems-feel-slower/

SSDは本当に速くなったのか?- 3年後に感じる“あの重さ”の正体 –

速くなった、という確信

私たちはいつから、
「ストレージは速くなった」と疑わなくなったのだろう。

HDDからSSDへ。
OSの起動は明らかに短くなり、
アプリケーションは即座に立ち上がる。
ファイル検索やコピーも、
体感できるほど速くなった。

ベンチマークの数値を見れば、
その差はさらに明白だ。
SSD化は成功した。
少なくとも、多くの人がそう感じている。

いまや「遅いならSSDにすればいい」という言葉は、
何の違和感もなく使われている。
速くなった、という認識は、
すでに前提条件になっている。

HDD_SSD
HDD_SSD

使い続けたあとに現れる、あの感覚

ところが、しばらく使い続けていると、
多くの人が似たような違和感を口にする。

「最近、少し重い気がする」
「前はもっとキビキビしていた」

再起動すると、一時的に戻る。
初期化すれば、確かに速くなる。
だが、しばらくすると、
また同じ感覚が戻ってくる。

この現象は、もはや珍しいものではない。
それでも私たちは、
深く考えないまま受け入れてきた。


重くなる理由として語られてきたもの

遅くなった理由はいくつも語られてきた。

データが増えたから。
設定が複雑になったから。
そして、もっとも納得しやすい説明がこうだ。

「アップデートで機能が増えたから」

確かに、アップデートのたびに
新しい機能が追加され、
画面は華やかになり、
内部処理も増えていく。

それなら、多少重くなるのは仕方がない。
多くの人が、そう考えている。


本当に増えたのは「機能」なのか

だが、ここで一度立ち止まってみたい。

アップデートとは、
実際には何をしている行為なのだろう。

大量のファイルが書き換えられ、
差分や履歴が保存され、
ロールバックのための情報が積み重なっていく。
ログやキャッシュも増え続ける。

アップデートとは、
極めて書き込みの多い作業だ。

機能が増えたことによる負荷は、確かに存在する。
しかし、その裏で起きている
「書き換えられた量」は、
どれほど意識されてきただろうか。


「速さ」は、何を測っているのか

ストレージの速さは、
多くの場合、数値で語られる。

シーケンシャルリード。
ランダムアクセス。
IOPS。

それらは確かに重要だ。
だが、そこで測られているのは
ある瞬間の性能でしかない。

時間の経過は考慮されているだろうか。
使い方の違いは反映されているだろうか。
書き込みが積み重なったあとの状態は、
どこまで想定されているのだろう。

速さとは、
初速のことなのか。
それとも、
使い続けた先まで含めた性質なのか。


過去の常識が、いまも残っている

かつて、性能低下の代名詞だったものがある。
断片化だ。

HDDの時代、
データが物理的に散らばることは、
確かに速度低下の大きな原因だった。

だが、少なくともSSDにおいて、
それが支配的な要因であった時代は
すでに終わっている。

それでもなお、
私たちは説明しやすい物語を
手放せずにいる。


本当に、そうなのか

データが増えたから、遅くなった。
本当にそうなのか。

アップデートで機能が増えたから、重くなった。
本当にそうなのか。

古くなったから、仕方がない。
環境が汚れたから、仕方がない。
本当に、そうなのか。

私たちは、
何が起きているのかを理解した上で
「遅くなった」と言っているのだろうか。

それとも、
もっと見えにくい原因から
目をそらしているだけなのだろうか。


再スタート

さあ、はじまりました。久しぶりのストレージネタです。張り切っていきましょう。ストレージといえば、以前のMIC-NETの主要コンテンツで、読者の多いネタでした。そのネタを新らたな角度から見直してみましょう。過去コンテンツに興味のある方はヒストリ検索とかしてみてください。再度取り上げてほしいものがあればコメントください。

第1話 データとは何か──「意味」と「価値」から始める記憶の話


関連記事

なぜ壁は膨らんだのか?IT駆使で迫るコンクリート劣化の原因調査 ~2から6週間分 中間まとめ ~

昨年12月に本格着手して、さまざまな角度でITを駆使しながら進めてきています。以下は、ここまでに確認できた結果の要点の書き出してまとめます。 当初計画した調査環境の整備が整ってから2週間ほどしか経っていませんが、当初の仮説とは少し異なる新たな仮説を立てています。

ATOMCAM2撮影、画像キャプチャ(コンクリート劣化)


カメラでの定点観測は2025/12/23より運用開始: 上のとおり、キャプチャ開始時点から、後述のAEセンサー、温度センサー(熱電対)を追加しています。また、上右よりの2本のテープ状のものは水濡れ検知シールです。水に濡れると下の写真のように赤色に変わり乾いても赤のままなので、水が垂れてきたことがあったかどうか分かります。今のところ、水は出てきていません。同様に熱電対を入れた塩ビ管内にも。このシールを入れたので、壁の内側で結露が発生したかどうかを判別できるでしょう。

mizu
水検知シール

MCR-4TCでの温度測定

温度測定
温度測定

今のところ気温が一瞬0℃になりましたが、コンクリート裏はそこまでは下がっていません。気温が下がってコンクリート内の温度が連動するところもあれば、連動しないところもあります。単純に外気温だけがコンクリート裏側の温度に効いているわけではないようです。

 また、場所によって外気温の影響が異なるように見えます。

AE測定

[ EEPROM Data Analysis Report ]
Type | Date Time (UTC/Local) | Millis (raw) | Details
--------------------------------------------------------------------------------
SYNC | 2026-01-14 13:25:51 | 325120 | Time Synchronized (Unix:1768364751)
DATA | 2026-01-14 14:25:45 | 3919360 | CH0:0, CH1:19, CH2:0, CH3:0
DATA | 2026-01-15 06:45:30 | 62704128 | CH0:0, CH1:8, CH2:0, CH3:0
DATA | 2026-01-16 00:26:07 | 126341632 | CH0:0, CH1:8, CH2:0, CH3:1
DATA | 2026-01-16 06:11:56 | 147090432 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-01-16 07:11:10 | 150644736 | CH0:0, CH1:0, CH2:3, CH3:7
DATA | 2026-01-16 10:10:08 | 161382912 | CH0:0, CH1:16, CH2:0, CH3:0
DATA | 2026-01-16 10:16:08 | 161742848 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-01-16 10:57:17 | 164211968 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-01-16 12:33:41 | 169995520 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-01-16 12:47:02 | 170796544 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-01-17 16:21:30 | 270064640 | CH0:0, CH1:11, CH2:1, CH3:1
DATA | 2026-01-18 01:01:31 | 301265664 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-01-18 05:01:11 | 315645696 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-01-18 12:22:00 | 342094336 | CH0:0, CH1:1, CH2:6, CH3:6
DATA | 2026-01-19 00:38:54 | 386308608 | CH0:0, CH1:45, CH2:0, CH3:0
DATA | 2026-01-19 06:01:51 | 405686016 | CH0:0, CH1:8, CH2:0, CH3:0
DATA | 2026-01-20 12:54:55 | 516869376 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-01-20 18:41:19 | 537653504 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-01-22 01:14:26 | 647640576 | CH0:0, CH1:7, CH2:0, CH3:3
DATA | 2026-01-25 12:50:54 | 948628992 | CH0:0, CH1:9, CH2:0, CH3:2
DATA | 2026-01-29 15:48:20 | 1304874752 | CH0:0, CH1:23, CH2:3, CH3:4
RSET | 2026-01-30 12:55:41 | 0 | System Boot / Reset Detected
SYNC | 2026-01-30 12:58:24 | 162304 | Time Synchronized (Unix:1769745504)
--------------------------------------------------------------------------------
Analysis Finished.

顕著なAE信号検出はなさそうで、たまに何かを検出してはいますが、ほとんど発生していないようです。1/16がちょっと多い感じがしますが、今のところ顕著な問題は起きていなさそうです。

コンクリート壁穿孔工事関連

熱電対を設置した状況からそれぞれの場所ごとにコンクリート壁と、壁内の土の間に隙間があり、場所によってその隙間が、約5mmから約48mmと大きなばらつきがあるように見えます。

中間まとめ 

 今のところ、新たに見えた事象は、コンクリート裏に隙間があるようにみえるということです。その隙間と、コンクリート奥の温度に関連性があるように見えます。つまり、隙間が大きいほど、外気温が下がっても温度が下がりにくそうということです。

 それとは別に隙間に関係なく、タイミングによってどの面の温度が低くなるのかが変わりそうです。

温度測定が終わる4月頃に、熱電対をとおした塩ビパイプを取り出して、内視鏡カメラで壁の裏側の隙間の状態を調査しようと考えています。

今年はほとんど雨降っておらず、乾ききっている感じなので問題事象は発生しにくそうです。

新たな仮説

これまでの仮説はすべての面が均等にアイスレンズが成長するように考えていましたが、片面だけ発生するケースもありそうな感触です。つまり、東面と南面で交互に発生し隙間が広がったり、逆に押されてほとんどなくなったりすることが繰り返されたのかもしれません。

さらにここまでの仮説で将来発生することが予想されていた西面北寄りでの事象発生ですが、下の写真のように新たに発生していることを確認しました。

crack
ひび割れ

ここまでの仮説を補強する材料と言ってよいでしょう。 

関連記事

ATOM CAM2のカメラ画像キャプチャをルーター越えの別セグメントからhsBox1.3でトライ

ルーターの向こう側にあるATOM CAM2の画像をキャプチャしたかったのですが、これまでツールではできていませんでした。今回トライした結果を考慮して、以前に公開したツールの今後の強化項目にしていきます。

cam
cam

どうやるか、これまでの課題も踏まえて、検討してみましょう。
スマホで、rtspでのアクセスURLを確認できるので、これにアクセスできるように環境を整えてみます。

方法1 ルーティングでATOMCAM2にアクセスできるようにする

hsBoxや PC側の設定(ルーティング設定)で、ATOM CAM2に向けてつなげ、ルーターで対象のパケットを通すように許可する。
※hsBox1.3にはシステム設定に「ルーティング設定」機能があり、ルーティングの制御支援機能があるので、これを利用できます。

確認したルーターには。指定したパケットを許可する機能がなく、この方法での動作確認はできていません。
このパターンの場合、ツールの強化ポイントはIP指定できるようにすることです。
また、ルーターのDHCPでの割り当てIP固定化機能もあったほうがよいですね。

方法2 ルーターのDMZ機能を利用してアクセスできるようにする

確認したルーターには。DMZ指定する機能はありますが、1つのIPしか指定できませんでした。すでにスマートスピーカにこのIPを割り当て済みだったので、この方法での動作確認はできていません。
このパターンの場合、ツールの強化ポイントはIP指定できるようにすることも挙げられますが、MACアドレスにルータのMACを指定すれば既存実装でも操作するはずです。

方法3 ルーターのポートオープン機能を使ってアクセスできるようにする

確認したルーターにはこの機能があったので、試してみました。
暫定的に既存のツールを、指定したIPの画像キャプチャーをするように改造して動作確認してみました。IPにルーターのIPを指定することで、難なく画像キャプチャーに成功しました。

複数のATOM CAM2がこのルーターの向こう側にある場合は、ポート番号が被らないように調整する必要が出てくるので、IP指定に加えてポート番号指定機能もあったほうが良いですね。ただ、IP指定を IP:PORTの形式で指定できるように拡張しするだけで対応できるでしょう。
また、ルーターのDHCPでの割り当てIP固定化機能もあったほうがよいですね。

関連記事

温度測定点設置壁裏の温度測定準備完了。見えてきた「隙間」を内視鏡カメラ「YPC99」でどう捉えるか?

これまでにコンクリート劣化の原因調査に関して様々な調査の準備をしてきましたが、2026/1/14、1/21にコンクリート壁への穿孔と温度測定定点設置を行い最終的な調査準備が完了しました。

コンクリート壁の3面に穴をあけ壁の裏側の土の温度を測定できるように熱電対を設置しました。設置後の外観は次の通り。

東面

南面

西面

塩ビ管を奥まで通して、先端にわずかに出した熱電対の先が、その先の土にあたるように設置しています。ぱっと見で、塩ビ管の出方に違いがあることが分かるでしょう。それぞれの準備した塩ビ管の長さと出っ張り具合から、それぞれの場所でコンクリート壁の内側での塩ビ管の出っ張り具合を検討してみました。壁の厚みは設計値では未確認ですが270mmとされています。

場所塩ビ管長さ
切断時測定
それぞれの管の出っ張り長壁裏突出長(推定値)
東側約350mm
32mm
約48mm
南側約350mm
60mm
約20mm
西側約300mm
25mm
約5mm

推定ですが、少なくとも東面については、コンクリート壁内面と、土の間にはある程度の隙間がありそうです。 熱電対設置前に事前確認しておけばよかったのですが、温度測定観測が終了した後に調査してみましょう。 以前に別の調査のために用意した内視鏡カメラYPC99があるので、これで確認することにします。

YPC99
YPC99 内視鏡カメラ

カメラの先は100mmくらい棒状で自由度は低いのですが、線の長さを合わせると450mmほどはあるので、コンクリート壁の穴を通して、隙間の具合がどんな感じなのかは見ることができると思います。

関連記事

hsBoxで、ATOM Cam 2の映像をキャプチャで発生した問題と課題と対処策について

約1か月連続キャプチャできていましたが、キャプチャできなくなる事象が発生したのでその原因調査と対策をしていきます。そして恒久対策に向けた対策案も検討して、以前に公開したツールの今後の強化項目にしていきます。

cam
cam

調査 その1

まず、状況整理ですが、キャプチャは、1回のcron起動で、3つのATOM CAM2を順にキャプチャしてファイル保存するように実装していました。一番最初にキャプチャするカメラ画像は10:00にキャプチャしたものが最後で、そのほかの2つは、14:40が最後でした。つまり、1つ目のキャプチャに失敗しても2つめ以降のキャプチャはできていましたが、その後3つともキャプチャできなくなっています。運用点検のため、hsBoxを再起動したタイミングあたりでキャプチャできなくなっていたようです。
 まずは、切り分けしていくためウォークスルー方式で問題となりそうなところを順にチェックしていきます。まずは、NASのマウント状況を確認しました。マウントはできており問題ありませんでした。
次に、ATOM CAM2のIP探索の確認です。 スマホでATOM CAM2のIPを確認して、そのIPが取れているかを、arpコマンドで確認します。 すると、3台のカメラともにMACが取れていないことが判明した。

暫定対処 その1

それぞれの、IPにpingを打ってみます。 それぞれ、反応がありMACがとれました。これにより、14:40が最後だった2台のカメラのキャプチャが復旧しました。
 残りの1台は、NAS上へのフォルダ作成には成功したものの、画像ファイルがまだ置かれていない状況になっています。

根本対策 その1

 今後の強化策です。 既存実装でもブロードキャストでpingを打つ実装を入れていますが、ブロードキャストではarpに反映されないのが問題のようです。そこで、MACが取れなかったとき、DHCPで割り振られる範囲に対して明示的に個別にpingを打つ実装を追加することにします。

調査 その2

まだ復旧できていない1台分のカメラについて調査を行います。

実装を、最後にキャプチャできたタイミングで何かあったかを確認してみましたが、特に問題はないようです。手動で、FFMPEGコマンドを実行すると、次の結果が返ってきました。

> python3 .\cap_once.py
FFmpeg failed: Command '['ffmpeg', '-rtsp_transport', 'tcp', '-i', 'rtsp://**:***@192.168.*.*/live', '-ss', '00:00:01', '-vframes', '1', '-q:v', '2', '-y', '\\\\192.168.*.*\\***\\2026-01-25\\20260125_124510.jpg']' timed out after 20 seconds

タイムアウトしていますが、pingは通っている。 前のセッションが残っていて接続待ちの状態になっている?のかという説はあるが、 スマホからの確認では動作している。 スマホでの画像表示と、rtspは別動作なので、rtsp側だけの問題(セッション残留?)の可能性がある。

暫定対処 その2

セッション残留の問題だと仮定して、rtspの再起動での復旧を試みる。スマホでの操作で一度「PCで再生」をオフにして再起動してみる。
 この操作を行うとrtsp用のユーザとパスワードが更新された。新たなユーザとパスワードを反映すると、キャプチャに成功し、 自動キャプチャは復旧した。

問題の原因は、残留セッションとみてよいようだ。 これは、ATOM CAM2側で何とかしてほしいが、 録画の都合(解像度の高い録画をしたい)から古いバージョンのファームウェアを使用している。このため最新パッチを適用することができず、ATOM CAM2側での”残留セッション”の改善は望めない。そこで、hsBox側での別の改善策を取ることにする。

その2の問題の 改善策案

”残留セッション”問題の対処方針は、上の”暫定対処”の問題を早期検知し、できるだけ手間をかけずに復旧できるようにするというものである。

 復旧手順を明記した内容での問題検知通知を出し、スマホ操作で「PCで再生」を再起動し、あらたなユーザ名・パスワードをGUI設定画面で更新するというものである。
とりあえず今時点での簡便な復旧策はこの辺でしょう。

他に良い案があれば、コメント投稿をお願いします。


関連記事

https://mic.or.jp/info/2026/01/30/cam-4/

hsBox1.3で、太陽光発電機器故障を検知して通知してみよう

2025年12月22日で太陽光発電 通知メールがなくなる件。 代替として自前で収集した情報をLINEに通知してみた」をさらに高度化を検討してみた。
 過去の実装(太陽光発電システムの故障判断アルゴリズム(その1))で、故障検知を高精度(6年間で5回検知・誤検知なし。1件はパワコンブレーカーダウン、4件はデータアップロードネットワークのダウン)で実装できていましたが、さきのソーラーフロンティアのサービス終了でこの検知システムが使えなくなりました。そこで、新たな検知システムの実装を、先に公開してシステムを強化して、検討してみます。

 ちなみに、公開済みの発電量収集代替実装では、従来のソーラーフロンティアの発電量との誤差は±2%程度なので、3か所ともに発電量収集代替実装を導入して、既存の検知システムにデータを流し込めば高精度での判定を継続できるようになります。しかし、通常、太陽光発電システムを複数保有しているほぼないので、この方式はほぼ使えません。そこで、ここでは1システムだけであっても判定することができる仕組みを検討してみます。

SolarAlert_
太陽光発電システム 故障通知

故障検知実現の設計方針

最終的には、人が判断するが、できるだけ判定精度を上げたい。過去の高精度判定システム構築での知見を反映して設計する。ポイントは次の通り。
・快晴時の発電量は安定しており、きれいなカーブを描く。
   →判定はこの部分のデータを使う。
・雲がある晴れの日のデータは変化が激しい。
・発電量の小さい日の発電量のばらつきが大きい。
   →判定には使用せず、参考値として通知する。
・四季の変化での発電量の補正が必要
→過去実装では、実績のピークデータをもとに関数化して組み込み
想定発電量と比較し、判定するかどうかを切り分けした。
・外部情報として最も近い気象庁観測点のデータを使用する。
・太陽光パネルの様々な設置場所ごとの違いによる想定発電量を単純な計算式ではなく学習方式を採用する。

使用するデータは、以前に公開したParquet形式で保存したものとする。

実装例 


import pandas as pd
import numpy as np
from datetime import datetime, timedelta
import os
import sys
import argparse
import requests
from bs4 import BeautifulSoup

# ==================== 設定エリア ====================
NAS_PATH = r"/mnt/nas/PowerData" #★
MODEL_PATH = os.path.join(NAS_PATH, "learning_model.parquet") # 学習データ保存先
IFTTT_WEBHOOK_URL0 = "https://maker.ifttt.com/trigger/{event}/with/key/{your_key}"
IFTTT_EVENT_NAME = "message_to_myline" #★
your_key = "************" #★
IFTTT_WEBHOOK_URL = IFTTT_WEBHOOK_URL0.replace("{your_key}", your_key)

# 判定しきい値 (期待値の50%以下が2時間続いたら故障疑いなど)
THRESHOLD_RATIO = 0.5 #★
# ====================================================

def send_line_message(title: str, body: str, timestamp: str = "-"):
payload = {"value1": title, "value2": body, "value3": timestamp}
url = IFTTT_WEBHOOK_URL.replace("{event}", IFTTT_EVENT_NAME)
try:
response = requests.post(url, json=payload, timeout=10)
return response.status_code == 200
except Exception as e:
print(f"LINE通知失敗: {e}")
return False

def get_jma_sunshine_hourly(target_date: datetime):
"""気象庁HPから10分ごとの日照時間を取得し1時間単位(0.0-1.0)で返す"""
url = (f"https://www.data.jma.go.jp/stats/etrn/view/10min_s1.php?"
f"prec_no=**&block_no=****&year={target_date.year}&month={target_date.month}&day={target_date.day}&view=p2") #★
try:
res = requests.get(url, timeout=10)
res.encoding = res.apparent_encoding
soup = BeautifulSoup(res.text, 'html.parser')
rows = soup.find_all('tr', class_='mtx')
sunshine_10min = []
for row in rows:
cols = row.find_all('td')
if len(cols) > 10:
val = cols[9].text.strip() # 日照時間の列
sunshine_10min.append(float(val) if val else 0.0)
# 1時間(6個)ごとに合計(最大1.0)
return [sum(sunshine_10min[i:i+6]) for i in range(0, len(sunshine_10min), 6)]
except Exception as e:
print(f"気象庁データ取得失敗: {e}")
return [None] * 24

def update_learning_model(target_date: datetime, hourly_actual: list, hourly_sun: list):
"""日照が良い時のデータを『快晴時の正解』として学習モデルを更新"""
month = target_date.month
try:
if os.path.exists(MODEL_PATH):
model_df = pd.read_parquet(MODEL_PATH)
else:
# 初期モデル: 全月0で作成
model_df = pd.DataFrame(0.0, index=range(1, 13), columns=[f"h_{i}" for i in range(24)])

updated = False
for h in range(7, 18): # 発電時間帯のみ
# 日照率が0.9以上かつ、これまでの学習値より高い(または初データ)場合に更新
if hourly_sun[h] and hourly_sun[h] >= 0.9:
current_val = model_df.loc[month, f"h_{h}"]
if hourly_actual[h] > current_val:
model_df.loc[month, f"h_{h}"] = hourly_actual[h]
updated = True

if updated:
model_df.to_parquet(MODEL_PATH)
print("学習モデルを更新しました。")
except Exception as e:
print(f"学習モデル更新失敗: {e}")

def load_day_data(target_date: datetime) -> pd.DataFrame:
date_str = target_date.strftime("%Y%m%d")
file_path = fr"{NAS_PATH}/power_{date_str}.parquet"
if not os.path.exists(file_path):
raise FileNotFoundError(f"データが見つかりません: {file_path}")
return pd.read_parquet(file_path)

def main():
parser = argparse.ArgumentParser()
parser.add_argument("--da", type=int, default=0)
args = parser.parse_args()

base_date = datetime.now() + timedelta(days=args.da)
date_label = base_date.strftime("%Y/%m/%d")

try:
df = load_day_data(base_date)
# 1時間ごとの発電量(value1)リスト作成
df['hour'] = pd.to_datetime(df['timestamp']).dt.hour # timestamp列があると想定
hourly_actual = df.groupby('hour')['value1'].mean().reindex(range(24), fill_value=0.0).tolist()
except Exception as e:
print(f"データ読み込みエラー: {e}")
return

# 気象庁データ取得
hourly_sun = get_jma_sunshine_hourly(base_date)

# 学習モデルの更新
update_learning_model(base_date, hourly_actual, hourly_sun)

# 故障検知
is_anomaly = False
anomaly_details = []
if os.path.exists(MODEL_PATH):
model_df = pd.read_parquet(MODEL_PATH)
month = base_date.month

for h in range(8, 17): # 影の影響が少ない時間帯を重点チェック
sun = hourly_sun[h]
if sun and sun > 0.3: # ある程度の日照がある場合
expected = model_df.loc[month, f"h_{h}"] * sun
actual = hourly_actual[h]
if actual < expected * THRESHOLD_RATIO:
is_anomaly = True
anomaly_details.append(f"{h}時(実測{actual:.1f}kW/期待{expected:.1f}kW)")

# メッセージ作成
total_gen = sum(hourly_actual) * (10/60) # 10分データの場合の概算
status_msg = "✅ 正常" if not is_anomaly else "⚠️ 故障の疑い"

message = f"⚡️ {date_label} 発電実績 ({status_msg})\n" \
f"総発電量:{total_gen:.2f} kWh\n"

if is_anomaly:
message += "\n【異常検知】\n" + "\n".join(anomaly_details)
send_line_message("太陽光発電アラート", message, "ALERT")
else:
send_line_message("太陽光発電データ", message, "OK")

print(message)

if __name__ == "__main__":
main()

上の実装は、あくまでもサンプルです。 特に”★”印のある行は環境に合わせて修正してください。

このコードで検証していますが、かなり過敏で誤検知が多いです。
閾値調整で、精度を上げることになると思いますが、過去実装での故障判定ロジックを超える精度にはならなさそうです。 誤検知をゼロにするには、十分に学習させたうえで、1日中快晴だった日のデータでのみで判定する必要がありそうです。

他に改善案などあればコメントをお願いします。

関連記事

 

映像監視への、漏水状況の追加監視について2026/1/12

映像による監視は実施済みですが、すこし補強することにします。

Add20250112
Add20250112

内側に結露・凍結蓄積・解凍、そしてその水が割れ目を通って吐水という事象が起きていると推測される。しかし、これまでの観測で湿っているかどうか、吐水が起きているか観測しにくい。そこで、吐水の発生を確認しやすいように、上写真の赤で囲んだところに水性ペンでラインを引いて観測しやすいようにしてみました。水が垂れるとラインがにじむので、使用カメラATOM Can2の解像度であれば確認できそうです。

漏水検知用につかえる「水分検知テープやシート」があるらしい、後日漏れも利用できるか検討してみましょう。

関連記事