BASICコマンドをLTE送信!PCやスマホからIchiogoSodaを遠隔制御

LTEモバイル通信機能を搭載したIchigoSodaへBASICコマンドを送る実験をしてみました。

PCやスマホから「LED 1」「BEEP」「?”こんにちわ”」といったIchigoJam BASICのコマンドを送信する(上図)と、IchigoSoda上で実行することが出来ます。※ただし8文字まで

β版IchigoJam BASICで8文字受信

ベータ版のIchigoJam BASIC 1.3.2 bata 11で、8文字までの文字列の受信に対応していただけたので、対応プログラムを作ってみました。

IchigoSoda用プログラム

以下にIchigoSoda側のプログラムを示します。sakura.ioモジュールがBASICコマンドを受信すると、キーバッファへBASICコマンドを取込み、IchigoSoda上で実行します。

new
1 cls:?"SAKURA IoT RX
2 ?"CC BY Wataru Kunino
3 T=1:?" シュウキ=";T;" ビョウ
8 'M=#820 :'Ver. 1.2.4 IoT
9 M=#114E :'Ver. 1.3.2

100 ?"== RX マチウケ ==
110 ?".";:wait T*60

200 '== RX ==
210 poke M,0
220 I=IoT.in()
230 if peek(M)!=1 goto 110
260 cls:?"Ch=";peek(M+2)
270 if peek(M+3)=98 goto 300
280 ? I
290 goto 200

300 '== String ==
310 I=0
320 C=peek(M+4+I)
330 poke #1004+I,C
340 I=I+1
350 if C AND I<8 goto 320
360 P="/goto 200/"
370 poke P,10:poke P+9,10
380 copy #1004+I,P,I+10
390 poke #1003,I+10
400 end
999 ?"MJ GET bokunimowakaru.github.io/MJ/803.txt

行番号100番台は、1秒ごとに「.」を表示するだけです。何か他の処理をさせたいときのために確保しました。

行番号200番台は、sakura.ioからの受信の待ち受け部です。行番号220のIoT.inコマンドが、sakura.ioから受信データを取得します。文字列(バイナリ)の受信に成功したら、行番号300番台へgotoします。数値を受信した時は、行番号280で数値を表示します。

行番号300番台は、受信したバイナリデータをキーバッファへ取り込む部分です。行番号330で、キーバッファへ書き込みます。また、行番号360で「goto 200」の命令をキーバッファへ入れておきます。これで、プログラムを終了後、受信した命令を実行し、goto 200で再び、プログラムに戻ります。

キーバッファへの操作コマンドは、あまり自信がありません。誤っていたら、コメント欄などから教えてくださいますよう、お願いします。

WebSocket 確認ツール Message IoT からBASICコマンドを送信する

BASICコマンドの送信には「WebSocket 確認ツール Message IoT 」を使用しました。
冒頭の画面のように、Tokenを入力し、sakura.ioへの接続に成功したら、Module IDを入力し、Message欄へBASICコマンドを入力し、実行してください。

https://bokunimowakaru.github.io/IchigoJam/message_iot/index.html

以上で、8文字までのBASICコマンドをIchigoSodaへ送ることが出来ます。

ただし、コマンドに誤りがあるとSyntax Errorが発生し、プログラムが停止してしまいます。

試しに

on error goto 200

と、入れてみましたが、動きませんでした。

by ボクにもわかるIchigoJam用マイコンボード
https://bokunimo.net/ichigojam/

IchigoSodaから複数の測定値を同時送信!β版ファームウェアを試してみた

β版ファームウェアを使って、IchigoSodaから複数の測定値を同時送信する実験を行ってみました。

IchigoSodaから複数値の同時送信

IchigoJamの開発者のブログに、β版のファームウェアで最大128バイトのデータをsakura.ioモジュールで送信する記事が掲載されていました。

(参考文献)福野泰介の一日一創
sakura.ioの4G格安IoTで拡充オープンデータ! 128byteまとめて送信、新IOT.OUTコマンド対応 IchigoJam 1.3β10
https://fukuno.jig.jp/2490

そのファームウェアを使って、送信データをRaspberry Piで受信する実験を行ってみました。

ダウンロードするもの

まずは、上記の記事で使用しているichigojam-1.3b10.zipをダウンロードし、IchigoSodaへ書き込みます。
https://ichigojam.github.io/ichigojam-1.3b10.zip

また、筆者が作成したRaspberry Pi側で動作する受信用ソフトウェアもダウンロードします(ダウンロード方法は後述)。
https://raw.githubusercontent.com/bokunimowakaru/iot/master/server/ws_logger_sakura.py

sakura.ioモジュールの設定などは下記をご覧ください。
https://bokunimo.net/ichigojam/sakura.html

なんと、ありがたいことに、IchigoJamの開発者のブログ「福野泰介の一日一創 」の当該ページに当方ウェブサイトのリンクを掲載していただきました。

動かしてみよう①複数の変数を送信する

それでは、早速、動かしてみましょう。まずは、Raspberry Pi側からです。起動するには、sakura.ioで取得したToken(トークン)が必要です。

《Raspberry Pi》
$ cd
$ git clone http://github.com/bokunimowakaru/iot
$ cd ~/iot/server
$ ./ws_logger_sakura.py sakura.ioのトークン

起動後に「CONNECTED」が表示されたら準備完了です。


こんどは、IchigoSoda(ファームウェアはIchigoJam 1.3β10 )から以下のコマンドを送ってみます。

《IchigoSoda》
[0]=1:[1]=-1:[2]=32767:[3]=-32768
IoT.out #800,8

これで、4つの変数の数値(8バイト)が、sakura.ioから LTE送信されます。


Raspberry Pi側を見てみると、以下のように表示されていると思います。下から2行目のvalueの部分に受信した数値が表示されました。

2019/05/19 22:47, {"module":"uXXXXXXXXXXX","type":"channels","datetime":"2019-05-19T13:47:02.71463767Z","payload":{"channels":[{"channel":1,"type":"b","value":"0100ffffff7f0080","datetime":"2019-05-19T13:47:02.713638539Z"}]}}
from = uXXXXXXXXXXX
datetime = 2019-05-19T13:47:02.713638539Z
channel = 1
type = Binary
value = [1, -1, 32767, -32768]
Message = yyy€

動かしてみよう②少し長め、文字列「Message from IchigoSoda!」の送信

今度は文字列です。福野さんのブログと同じ文字列を送信するために、IchigoSodaで「IoT.out “Message from IchigoSoda!”,24」と入力すると、Raspberry Pi側(下図)の最下行に同じメッセージが表示されました。

2019/05/19 22:44, {"module":"uXXXXXXXXXXX","type":"channels","datetime":"2019-05-19T13:44:13.121625999Z","payload":{"channels":[{"channel":1,"type":"b","value":"4d65737361676520","datetime":"2019-05-19T13:44:13.120626868Z"},{"channel":1,"type":"b","value":"66726f6d20496368","datetime":"2019-05-19T13:44:13.120626868Z"},{"channel":1,"type":"b","value":"69676f536f646121","datetime":"2019-05-19T13:44:13.121626868Z"}]}}
from = uXXXXXXXXXXX
datetime = 2019-05-19T13:44:13.120626868Z
channel = 1
type = Binary
value = [25933, 29555, 26465, 8293]
datetime = 2019-05-19T13:44:13.120626868Z
channel = 1
type = Binary
value = [29286, 28015, 18720, 26723]
datetime = 2019-05-19T13:44:13.121626868Z
channel = 1
type = Binary
value = [26473, 21359, 25711, 8545]
Message = Message from IchigoSoda!

動かしてみよう③いよいよ本命。変数64値、128バイトを送信

最大128バイト、変数[0]~[63]を送信するには、「IoT.out #800,128」と入力します。
datetime、channel、type、valueが16回、表示され、全64値を受信することが出来ました。
(同じような結果画面につき、valueのみを抽出)

《IchigoSoda》
for I=0 to 63:[I]=i:next
IoT.out #800,128

《Raspberry Pi》
value = [0, 1, 2, 3]
value = [4, 5, 6, 7]
value = [8, 9, 10, 11]
value = [12, 13, 14, 15]
value = [16, 17, 18, 19]
value = [20, 21, 22, 23]
value = [24, 25, 26, 27]
value = [28, 29, 30, 31]
value = [32, 33, 34, 35]
value = [36, 37, 38, 39]
value = [40, 41, 42, 43]
value = [44, 45, 46, 47]
value = [48, 49, 50, 51]
value = [52, 53, 54, 55]
value = [56, 57, 58, 59]
value = [60, 61, 62, 63]
Message = 123456789:;<=>?

受信側プログラム(抜粋)

以下は、今回、作成したRaspberry Pi用の受信側のPythonブログラムの抜粋です。データタイプ(data_type)が’i’なら整数、’b’ならバイナリとして処理します。
複数の変数は’b’のバイナリとして送られてくるので、2バイトごとに数値変数valへ代入し、配列変数data_valueへ蓄積します。

data_text=''
for data in res_payload_dict:
data_type = data['type']
data_ch = data['channel']
data_time = data['datetime']
data_type_s= 'Unknown'
if data_type.lower() == 'i':
data_type_s= 'Integer'
data_value = data['value']
if data_type == 'b':
data_type_s= 'Binary'
data_str = data['value']
i=0
data_value=[]
while i < len(data_str):
if i % 4 == 0:
val = int(data_str[i+2:i+4] + data_str[i:i+2],16)
if val >= 32768:
val -= 65536
data_value.append(val)
c = chr(int(data_str[i:i+2],16))
if ord(c) >= 16 and ord(c) < 256:
data_text += c
i += 2
print('datetime =', data_time)
print('channel =', data_ch)
print('type =', data_type_s)
print('value =', data_value)
print('Message =', data_text)

100回目の投稿

今回、IchigoJamに関連したブログの投稿記事数が、100記事に達しました。
このところ、Yahoo!ジオシティーズのサービス終了とYahoo!ブログのサービス終了予定にともない、引っ越し作業に時間がとられていました(実は、まだ古いリンクが残っている)。
本来の記事を書く作業も、ぼちぼちと進めてゆこうと思います。
本日、下記のIchigoJamに関連したページの更新を行いましたので、お時間がありましたら、お立ち寄りください。

IchigoSoda / sakura.io の接続方法
https://bokunimo.net/ichigojam/sakura.html

by ボクにもわかるIchigoJam用マイコンボード
https://bokunimo.net/ichigojam/

IoT Express × TTGO Camera 玄関カメラで0.8fpsパラパラ漫画表示

M5Stackで0.4fpsの動画表示が出来たので、IoT Expressで試したところ2倍の0.8fps動画表示が出来ました。
紙芝居からパラパラ漫画へと進歩しました 。
表示部には、フルカラー有機ELディスプレイSSD1331を使用しました。

(参考)下図は前回の記事です。

概要

TTGO T-Cameraの映像をフォトフレーム端末へ転送する玄関カメラシステムです。
カメラ側は中国で2000円程度で売られています。
フォトフレーム端末側は、前回、M5Stackを使用しましたが、今回、ESP32マイコンボードとしてCQ出版社およびaitendoが販売しているIoT Expressに変更してみました。
詳細は、前回やそれ以前の記事をご覧ください。

前回からの変更点

フォトフレーム側のマイコンボードをCQ出版社のIoT Expressに変更し、ディスプレイに有機ELディスプレイSSD1331を接続しました。

プログラムは同じM5Stackとレポジトリのフォルダ「iot-photo_oled」へ収録しました。

フォトフレーム(GitHub):
https://github.com/bokunimowakaru/iot-photo/tree/master/iot-photo_oled

動作確認結果

QQVGAで再生してみたところ、2倍の0.8fpsで動作することが分かりました。

 HTTP://192.168.0.2/cam.jpg
Recieving…HTTP/1.1 200 OK
Content-Type: image/jpeg
Content-Length: 4000
Connection: close
loading….http END
4000 Bytes, 257ms, Done
Loading image '', 4000 bytes
HTTP time :290 ms
JPEG time :939 ms
Total time:1229 ms (0.814 f/s)

HTTP://192.168.0.2/cam.jpg
Recieving…HTTP/1.1 200 OK
Content-Type: image/jpeg
Content-Length: 3546
Connection: close
loading….http END
3546 Bytes, 256ms, Done
Loading image '', 3546 bytes
HTTP time :288 ms
JPEG time :939 ms
Total time:1227 ms (0.815 f/s)

HTTP://192.168.0.2/cam.jpg
Recieving…HTTP/1.1 200 OK
Content-Type: image/jpeg
Content-Length: 3200
Connection: close
loading….http END
3200 Bytes, 255ms, Done
Loading image '', 3200 bytes
HTTP time :288 ms
JPEG time :935 ms
Total time:1223 ms (0.818 f/s)

考察

QQVGAで0.8fpsを達成しましたが、QVGAでも0.7fpsでした。
HTTP処理部については、TCP接続部や応答遅延などが影響しており、JPEG処理部についてはデコード部ではなく、描画部が影響しているようです。

by ボクにもわかる電子工作
bokunimo.net

M5Stack×TTGO Camera 玄関カメラ用デモの高速化

M5Stackと、 中国で 約2000円で売られているTTGO T-Cameraを使って製作した、玄関カメラシステム用の画像転送速度を(少しだけ)高速化しました。

(参考)下図は前回の記事です。

前回の課題と今回の対策の概要

前回、Wi-Fi玄関カメラの製作方法について、紹介しましたが、撮影後、画像が転送されるまでの時間が長い(約5秒)という課題がありました。そこで、HTTP処理部を見直し、画像転送速度の高速化を図り、約0.4fpsの動画再生(といっても、ほとんど紙芝居)に対応しました。

動かし方

GitHubのソフトを更新しましたので、前回と同じようにダウンロードして下さい。人感センサ反応中(ずっと反応し続けている状態)に動画再生モードになります。

今回の対策内容

主にHTTP処理部の対策を行いました。以下に4月30日のコミットからの変更点を記します。

  • HTTP処理部の高速化
    • 受信バッファにRAMを使用(#define CAMERA_BUF_ENで切替可能)
    • 画像データの受信完了にHTTPヘッダ内のContent-Lengthを使用
  • 人感センサ反応中に繰り返し画像取得を実行(検知信号の受信で動画を開始、検知完了信号で動画を停止)
  • ピンポン音の追加(人感センサ検知時に「ピンポン」音)

動作確認結果

QVGA(320 x 240)の画像で、約0.4fpsの動画再生が行えるようになりました。再生中のログのようすを以下に示します。「Loading image ”」は取得データをRAMから取得したときに表示されます。

 HTTP://192.168.0.2/cam.jpg
Recieving…HTTP/1.1 200 OK
Content-Type: image/jpeg
Content-Length: 12000
Connection: close
loading…………http END
12000 Bytes, 271ms, Done
Loading image '', 12000 bytes
HTTP time :483 ms
JPEG time :1976 ms
Total time:2459 ms (0.407 f/s)

HTTP://192.168.0.2/cam.jpg
Recieving…HTTP/1.1 200 OK
Content-Type: image/jpeg
Content-Length: 12766
Connection: close
loading………….http END
12766 Bytes, 271ms, Done
Loading image '', 12766 bytes

HTTP time :482 ms
JPEG time :1979 ms
Total time:2461 ms (0.406 f/s)
HTTP://192.168.0.2/cam.jpg
Recieving…HTTP/1.1 200 OK
Content-Type: image/jpeg
Content-Length: 11010
Connection: close
loading………..http END
11010 Bytes, 270ms, Done
Loading image '', 11010 bytes

HTTP time :476 ms
JPEG time :1970 ms
Total time:2446 ms (0.409 f/s)

より滑らかな動画に(プログラム変更なし)

HTTP処理に要する時間が0.5秒程度、JPEG処理(表示を含む)が2秒程度かかっています。

撮影解像度をQQVGA(var = framesize, val = 0)に落とすことで 、HTTP処理時間とJPEG処理時間の両方を短縮くすることができます。確認したところ、現状のプログラムのままで、0.8fpsの滑らかな表示にすることが出来ました。しかし、広角レンズを使用した場合、人物の顔などが分かりにくくなってしまうので、かえって実用的ではなくなります。

さらなる高速化を目指したい方へ

HTTP処理部については、都度、TCP接続を切断しています。接続したままにする、またはUDPを使用することで、より高速化が図れるでしょう。

JPEG処理部では、デコード処理と描画処理を行っています。それぞれの時間を計測したことはありませんが、Adafruitのライブラリを使って1ドットずつ描画コマンドをコールしている点が課題だと思います。直接、LCDへコマンドを送るようにすれば、高速化することが出来るでしょう。

by ボクにもわかる電子工作
bokunimo.net

IFTTTとの連携が出来なくなるWio Node

今日、IFTTTよりWio Nodeとの連携サービスが廃止になるとの連絡がありました。

Wio Nodeとの連携サービス(5/8まで)
https://ifttt.com/seeed_wio

下記のような連携も出来なくなります。

2019年5月8日にIFTTTとの連携サービスを終了する。
Wio Link Serverは、これまでどおり存続する。
IFTTT側の新しいCEOによるビジネスモデルの変革が原因で、互換性が保てない方向に進みつつある。

他のサービスへ変更するために、サービス期間を1週間、延長したとのことですが、簡単な連携サービスが無くなることは、とても残念です。

TTGO T-Camera+M5StackでWi-Fiカメラ

中国で販売されている2000円のWi-Fiカメラで撮影した写真をM5Stackへ送信するWi-Fi玄関カメラの実験を行ってみました。

(参考)Wi-FiカメラTTGO T-Cameraの製品紹介記事はこちら:


このカメラには人感センサがついています。そこで、人感センサが人体などの動きを検知したときに、写真を撮影し、M5Stackへ送信して表示するソフトを作成しました。
また、普段はM5Stack内のMicro SDカード内の写真をフォトフレームのように表示するようにしました。

カメラ側について

カメラ側は、 TTGO T-Camera の出荷時に書き込まれていたサンプルを改造して作成しました。人感センサが反応したときに、UDPブロードキャストを送信し、M5Stackへ通知します。

Wi-Fiカメラ TTGO T-Camera側:
https://github.com/bokunimowakaru/iot-camera

  • 人感センサが反応したときにUDPでM5Stackへ通知します。
  • リセットボタン(RST)でM5StackへT-Cameraのアドレスを通知します。
  • インストール方法は、上記のGitHubのREADME.mdをご覧ください。

フォトフレーム側について

M5Stack側は、Adafruitの液晶ドライバなどを使用して作成したフォトフレームです。
Wi-Fiアクセスポイント・モードとして動かしており、デフォルトでWi-Fiカメラも同じSSIDに設定してあります。

Wi-Fiフォトフレーム M5Stack側:
https://github.com/bokunimowakaru/iot-photo

  • TTGO T-Cameraのリセット操作でアドレス登録後、T-Cameraが写真を撮影するたびに写真を表示します。
  • Micro SDカードまたはSPIFFS内の写真を表示します。 SPIFFSは遅いので、Micro SDカードの使用をお奨めします。
  • インストール方法は、上記のGitHubのREADME.mdをご覧ください。

動かし方

両方の機器の電源を入れ、M5Stackが起動してから、Wi-Fiカメラのリセットボタン(RST)を押すと、ペアリングが完了し、動作させることが出来ます。

スマホからM5Stack(http://192.168.0.1/)へアクセスすると、SPIFFSの初期化や、SPIFFSやSDカード内の写真の表示が行えます。

今日から令和になりました。
この休み中に、もう少し、機能を追加してゆこうと思います。

by ボクにもわかる電子工作
bokunimo.net

Wikipediaで検索する

今日は、Wikipediaで検索するプログラムを作ってみました。

Wikipediaでは、JSON形式で応答するAPIが公開されていることを知りました。

参考文献:https://ja.wikipedia.org/w/api.php

そこで、以下のようなプログラムで検索してみました。

#!/usr/bin/env python3
# coding: utf-8
# Example 08 IoT連携の基本 HTTP GET Wikipedia情報の取得

# 参考文献:https://ja.wikipedia.org/w/api.php

from sys import argv
import urllib.request
import urllib.parse
import json

keyword = 'ウィキペディア'

print('Usage:', argv[0], '検索キーワード') 

if len(argv) >= 2:
    keyword = argv[1]

url_s = 'http://ja.wikipedia.org/w/api.php?'
url_s += 'format=json' + '&'
url_s += 'action=query' + '&'
url_s += 'prop=extracts' + '&'
url_s += 'exintro' + '&'
url_s += 'explaintext' + '&'
url_s += 'titles='
url_s += urllib.parse.quote(keyword)
print(url_s)

try:
    res = urllib.request.urlopen(url_s)
    res_s = res.read().decode()
    res.close()
    res_dict = json.loads(res_s)
except Exception as e:
    print(e)
    exit()

# pages_dict = res_dict['query']['pages']
query_dict = res_dict.get('query')
pages_dict = query_dict.get('pages')
for pageid in pages_dict:
    # extract = pages_dict[pageid]['extract']
    pageid_dict = pages_dict.get(pageid)
    extract = pageid_dict.get('extract')
    if extract == None or extract == '':
        print('見つかりませんでした。',pageid)
    else:
        print(extract.split('\n')[0])

https://github.com/bokunimowakaru/iot/blob/master/learning/example08_htget_wiki.py

以下は、実行結果です。

pi@metal:~/iot/learning $ ./example08_htget_wiki.py 百科事典
Usage: ./example08_htget_wiki.py 検索キーワード
http://ja.wikipedia.org/w/api.php?format=json&action=query&prop=extracts&exintro&explaintext&titles=%E7%99%BE%E7%A7%91%E4%BA%8B%E5%85%B8
百科事典(ひゃっかじてん、拉: encyclopaedia)とは、あらゆる科目にわたる知識を集め、これを部門別やアルフ ァベット順・五十音順などに配列し、解説を記した書物のこと。「百科」と略記されることもある。
pi@metal:~/iot/learning $

応用として、音声認識で入力した内容をWikipediaで検索し、その結果を音声合成で再生するといった使い方が考えられます。

by ボクにもわかるRaspberry Pi
https://bokunimo.net/raspi/

Yahoo! ジオシティーズの思い出

写真は、Yahoo!ジオシティーズで公開していたウェブサイト「ボクにもわかる地上デジタル」を、 Mac版のインターネット・エクスプローラで表示したときの様子です。Safariが開発される前のMac用の標準ブラウザは、Microsoft IEだったのです(ほんの一時期です)。

今日は、Yahoo!ジオシティーズの思い出+ちょっと自慢をしてみたいと思います。

2003年に地上デジタル放送の試験放送を受信する方法について解説したウェブサイト「ボクにもわかる地上デジタル」を公開しました。当時、放送電波の出力が弱かった上に、地上デジタル放送に対応したアンテナ部品が少なかったこともあり、地上デジタル放送を受信するためのウェブサイトとして、多くの方に訪問していただきました。

地上デジタル放送の試験放送の様子。当時はブラウン管テレビが主流で、写真の36インチのブラウン管テレビは、たため1畳分に近い設置面積を要した。

しかし、この当時に使用していた ホームページ公開サービスは 、電話による男女の出会いサービスを提供する会社だったため、自動的に表示される広告の品位が良くない課題がありました。そこで、2004年09月にYahoo! ジオシティーズへ移転しました。

その後、地上デジタル放送に関する豊富な情報を提供するサイトとして、2006年にYahoo!検索サイトにカテゴリ登録されました。カテゴリ登録とは、検索サイトのトップページからジャンルを選んで表示されるウェブサイトのことで、当時は、名誉なことでした。

Yahoo!ジオシティーズを利用していたことは、カテゴリ登録されやすい点で有利でした。さらにYahoo!のカテゴリ登録されたことで、Google検索順位も上がり、「地上デジタル」の検索で5位以内に表示され、月に5万件ものアクセスをいただけるようになりました。この時期がボクのサイトのヒット期となりました。

地上デジタルテレビが普及してからは、徐々にアクセス件数が減ってゆき、月4千件程度になりましたが、かつての栄光が検索エンジンに有利だったようで、ほとんど対策をすることなく、高い順位をいただくことが出来、約14年にわたって利用させていただきました。

ところが、Yahoo!ジオシティーズの2018年10月、Yahoo!ジオシティーズの終了が通知されました。

このため、新しいサイトbokunimo.netへ移転することになりました。

ちなみに、新サイトのアクセスカウンタは、現在「320」。かつての5時間分のアクセス件数に、5か月を要しました。

1995年     ウェブサイト開設
2003年10月   地上デジタル放送の技術情報ページを開設
2004年10月14日 Yahoo!にディレクトリ登録される
2004年11月01日 Yahoo!ジオシティーズへ移転
2005年12月29日 累積アクセス件数10万件
2006年02月16日 Yahoo! 検索のカテゴリ登録★
2008年01月19日 累積アクセス件数100万件
2018年10月01日 Yahoo!ジオシティーズの終了案内
2018年10月13日 bokunimo.netへ移転
2019年03月31日 Yahoo!ジオシティーズ終了

Yahoo!ジオシティーズのおかげで、ボクにもわかる地上デジタルが生まれ育ちました。これからは、親から独立して大人になった気分で、一からやり直そうと思います。

by bokunimo.net

iCloudから取得するときにテキストが消失してしまった

iCloudからメモ(中央の行の一番左側)を取得しようとした

とても悔しいことをしてしまいました。

この1か月ほどにわたってiPhoneのメモに書いていた原稿が一瞬にして消えてしまったのです。

本来、iPhoneのメモに書いた内容をiCloudと連携しておくことで、万一、iPhoneを紛失したり誤ってデータを消失してしまってもiCloudにデータが残ります。
なので、バックアップを行わずに、日々、原稿を書き貯めていました。

失敗は、そのデータをPCに取得するために、iCloudへアクセスし、メモのテキストを全選択し、テキストエディタへ貼り付ける作業を行おうとしたときに発生しました。

[Ctrl]+[A]、+[C]でコピーしたつもりが、キーを誤ったのかテキスト文字が全て消え、しかもメモ一覧が「新規メモ」となってしまいました。この段階で[Ctrl]+[Z]を実行すれば良かったのかもしれませんが、あわてて他のメモを触ってしまった瞬間、「新規メモ」も消えてしまいました。
「大丈夫、iPhoneに残っている」と、iPhone側のメモを開いてみると、、、残念なことにiCloudとの同期によって、こちらも消失してしまっていました。

教訓
・ テキストの全選択は慎重に行う
・端末とクラウドの両方にデータがある≠バックアップがある
・どちらかのデータを消失したときは、すぐに、通信を切断する

iTunesでインターネットラジオを聴くには[Radio]ではなく[ライブラリ]タブを選択する

インターネットラジオを聴くには[Radio]ではなく[ライブラリ]タブを選択する

「インターネットラジオ」を聴くためのソフトiTunesで、「インターネットラジオ」を聴く方法がアップル社のサポートサイトに書かれていました。

アップル社のサポートサイト:

https://support.apple.com/ja-jp/guide/itunes/itns2946/windows

[Radio]ではなく[ライブラリ]タブを選択し、ライブラリの[編集]メニューから「インターネットラジオ」を有効に設定します。
もはや、 iTunesがインターネットラジオを聴くためのソフトであったことすら、忘れていないでしょうか?

インターネットラジオを聴くためのソフトウェアiTunes。[入力源]から「ラジオチューナ」を選択するだけでラジオが聴けた。

ところで、iTunesが広まった要因は、インターネットラジオのプレーヤとしてではありません。写真の[入力源]に現在のiTunesにも残る[ライブラリ]というメニューがあることを見逃さないでください。

実は、iTunesは、「音楽CDをCD-Rへコピーするツール」として大ヒットしました。

どちらかと言えば、「 音楽CDをCD-Rへコピー 」するツールのヒットが、後のApple社を支える事業へ導いたような気もします。

by bokunimo.net