楽天モバイルの新料金プランUn-Limit VIを使って0円かけ放題回線を実現

楽天モバイルの2021年4月1日より自動適用の新料金プランUn-Limit VI

楽天モバイルの新料金プランRakuten UN-LIMIT VI（Internet Archive; Web魚拓; Archive.vn）。なかなかいいところを突いてきたという印象。

~1GB/月までで無料としたのは（以下簡単に「無料枠」）無料期間終了後の顧客離れを避ける策だろう。そうでなければ自分も解約していた。どうやらそれでもかけ放題は利用できるようで（Rakuten Linkアプリを使用した場合，という制限はつくが），これなら維持する価値が大いにある。ただし一人につき最初の1回線契約のみに適用される。2回線目以降は無料枠がなく，最安で~3GB/月で980円。

Vまではデータ高速モードを切っていればデータ使用量はカウントしない，という仕様だったが，VIでは事実上これを撤廃するようだ。低速モードでも1Mbpsという太っ腹仕様だった。もしこの点でVと同じであったなら~1GBまでの無料枠でも，低速モード無制限，高速モード1GB/月まで，ならそれだけで十分使い物になると思ったが，さすがにそこまで甘くなかった。速度モードに関わらずしっかりカウントされるとのこと。

海外ローミングも同様の扱いのようで，無料枠でも合計1GBまでは使えるというのは，非常にオイシイ話ではないだろうか。特に，国内で20GBを超えるデータ消費をする人でも海外ローミングは2GBまでしか無料でないことを考えると。

ともかくかけ放題つきで1GB/月まで無料というのは信じがたい嘘のような話。携帯電話は主に通話に使用，たまにネット，というような方にもピッタリのプランになるのではないか（Rakuten Link使用に起因する困難さ，回線品質の問題は残るが）。大げさな言い方は好きじゃないが，これはゲームチェンジャーと言っていい。 “安価に携帯番号を維持する” でソフトバンクのキッズフォン向け契約を利用することを考えて，中古端末まで入手していたのにとりあえず無駄になりそう。

さて，楽天モバイルを今まで使ってる人の多くは，回線品質に不安があるため副回線として使ってる人が多いのではないだろうか。品質が十分高まったと判断して（…実際十分高まったかどうかは知らない），今まで他事業者で持っている大事な回線（私が「公式番号」と呼ぶような，番号を連絡先としてあちこちに登録してあるようなもの）を楽天モバイルにポートさせようと考える人も出てくると思われる。かくいう私がそうだ。

ただ，無料枠は1回線目にしか適用されないということだから，その場合一旦は既存回線を解約し，その上で公式番号を楽天モバイルにポートインさせることが必要になりそうだ。公式の “新料金プラン「Rakuten UN-LIMIT VI」について教えてください | よくあるご質問 | 楽天モバイル“にも以下のように明記されておりこれができそうだ。

一度ご契約されていた回線を解約された後に再度別回線を契約された場合でも、ご利用中の回線が1回線のみであれば、プラン料金は1GBまで0円

この情報は “[誰でも0円維持可能]楽天モバイル新料金(2021年4月開始) 1GBまで無料適用条件公式ヘルプで詳細案内 – モバイルびより” で知った。

実は，私自身がチャットで問い合わせた際は，楽天モバイルに既に回線契約が1本ある場合，それを解約した後新規契約しても，それは2回線目と見なされ，新料金プランUn-Limit VIの「無料枠」（月~1GBまで）は利用できない，という回答だったのだが，これが誤りだったことに不満はない。今に思うと，回答者はVの無料枠と1年間無料キャンペーンをごっちゃにしていたのかもしれない。

さて，実際楽天モバイル回線1本のみで安心できるかというと実際はそうではない。主回線（公式番号の回線）を楽天モバイルにしたとしても，バックアップ用の副回線が欲しい。2台持ちを避けたければDSDV機が必要（物理SIMスロットを持ちeSIM対応の一部端末でも可）。

その副回線としてはロケットモバイルの神プランも考えられる。上限200kbpsの低速だが300円+/月でデータ使いたい放題は安い。経験上，上限250kbpsのUQモバイルの低速モードでもインターネット電話が支障なく使えかなりの目的は達成できた（逆に速度不足を感じたのはマップアプリでリアルタイムで自分の位置を表示させるような場合ぐらい）。 “ロケットモバイルの神プランを評価。200kbps回線で色々試してみた – ガルマックス” にも同様の趣旨の内容が。

しかし私は音声回線契約の方をお勧めする。2つ理由があるが，その1つは，音声回線契約の方が大きなキャンペーンをやっていることが多く，結局データ回線契約より安くなることがままあるから。例えば，y.u mobile(ワイユーモバイル)3GB/月プランを1年間使用した段階でのキャッシュバックでほぼ無料になる。「ほぼ」というのは初期手数料を計算に入れていないから。ただ，Y.u mobileは3月1日から現行プランを値下げしシンプルプランは3GB→5GBへ増量ということが決定済みなので，逆に今申し込んでCB額を確定するのがお得。料金引き下げに伴ってCB額も引き下げられる可能性があるので → 実際そのとおりになった。

もう1つの理由が，いろいろ問題があるとされるRakuten Linkの不安定さを補わせることができるから。よくある問題が，通話が着信できない，だが，楽天モバイルの設定で，着信できない際には副回線に転送するようにしておけば，着信できる。ただし，「転送中は転送者に通話料が発生します（20円／30秒）」ということなので，かけ直す手間をいとわないのであれば無料の留守番電話サービスで用が足りるかもしれない。ただし，この方法ではSMS受信の問題（もしあれば）は解消できない。

具体的に自分が今後どうするかだが，既存楽天モバイル回線は4月上旬までに無料期間が終了した後も，無料枠内で維持。肝心の公式番号回線は， “現在Au上にあるメインの携帯回線どうするか？” にあるような事情でAuで今持っているので，BL入りを避けるため6月末頃まで維持した上で，楽天に乗り換え（MNP）。

この後に書いていたことは， “お世話している親子お二人の今後の携帯契約作戦” に分けた。

Xiaomi Mi Band 5は割り切った用途にはよいかも

追記（2021年7月）:  XiaomiのMi Fitアプリを使うとGoogle Fitにしかデータ同期できまないが，Mi BandやMiスマート体組成計のデータをGoogle Fit以外のStrava, Reliveにも無料で同期させることが可能。

---

Xiaomi Mi Band 5（以下簡単のため “MB5” ）は，AliExpressで購入すれば3,000円程度と安価で，割り切った用途にはいいかもしれない。この記事では基本機能の紹介などはしない。

追記1: ついに正規日本語版が発売された模様（ “やっと日本版も出た!　スマ－トバンドの真打ち・コストパフォーマンスの王者「Mi smartband 5」！ – ケータイ Watch” ）。

追記2: 一般向けに “Xiaomi Mi (Smart) Band 5はおすすめ” を書いた。

自分用ではなく，知人に頼まれて調べた。XiaomiのMi Band 5は海外ではMi Smart Band 5としてマーケットされているようだ。Xiaomiの公式サイトにある情報はグローバル版のことだと思われる。

わかっているだけで以下の3つのバージョンがある:

• 中国標準版
• 中国NFC版（マイク内蔵）
• 国際版

AliExpressで，液晶保護フィルム3枚，白のストラップつきの国際版を3,400円ほどで購入。注文後に，中国版でも日本語フォントの問題がないらしいことがわかり（“Mi Band 5 | Original Firmwares/Resources/Fonts | GeekDoing” からのあくまで伝聞。個人的に検証したわけではない），一般的には国際版より中国標準版の方が安いので，そちらを注文し直すことも一時は検討した。ただ，どうやらたまたま国際版にしては安いものが選択できていたようで最終的な価格差がほぼないことを確認したので，もともとの注文はキャンセルしないことにした。

Mi Band 5は中国標準版で安いのを探せば，例えば付属品なしの単独品で2,800円弱でありスマートウォッチの類にしては安価と言える。ただし，機能は思い切って割り切っており，それで目的が達成される場合に限る。世界的に大量に流通している製品だけあり，付け替え用ベルトなどが多くの種類供給されてて，AliExpressで比較的安価で手に入るのも良い。

特に，後継機種Mi Band 6がそろそろ発売されるので，MB6ならではの機能が必要なければ，これからMB5は型落ち機種としてさらに価格が落ちることが期待できる。MB6についての情報については “Mi Band 6は画面が大型化し、対応アクティビティも増加か – Dream Seed.” などを参照（ただし現時点ではあくまで噂）。経皮的動脈血酸素飽和度 (SPO2)の測定機能とAlexa連携が新機能の目玉。MB5と同様NFC機能付き版がある模様。

さて，話をMB5に戻す。MB5のNFC版は標準版に比べ，NFC機能がありマイクを内蔵する点で異なる（”Xiaomi Mi Band 5 – Wikipedia” には “The NFC-enabled version also has an in-built microphone for Xiaomi’s in-built assistant Xiao.” という記述がある）。ただし，そのNFC機能も少なくとも公式には中国国内での使用にしか対応しないようで，それが正しいのであれば他国では意味がない。

また，マイクは音声アシスタントに連動させるためにあるが，これがXiaomiのもの以外とも対応させられるのかはわからない。関連機種Amazfit Band 5ではAlexa連携が可能（後述）。国際版にはマイクが内蔵されていない，という情報が多く見られるが，国際版と思われるものの公式スペック表にはマイクが内蔵されているという記述があり，真偽の程は定かではない ⇒ AliExpressのセラーに複数問い合わせたところ，どうもマイク内蔵はない模様。

本体のUI言語はコンパニオンアプリから変えられ，中国版であっても英語表示にはできるということなので，英語表示が苦でなければ中国版でよいということになる。国際版が最近のファームウェアのアップデートで日本語表示に対応したということは間違いないようだが，NFC内蔵版を含め中国版が日本語表示に対応しているかどうかまでは確証がない。

これら3バージョンの違いは，このAliExpress上のリスティング情報等を参照した。GeekDoingのフォーラムでの質問に対する回答が最も信用できそう。

“Xiaomi Mi Band 5 Review: Fixing all the quirks from the Mi Band 4, and then some”

“今なら2,980円！完成度高いシャオミの新型スマートバンド「Miスマートバンド5」レビュー” …Gshopperでグローバル版が売られてるとしているが，Gshopper自身はグローバル版ではないとしている（下記）。

“Gshopper – 【日本語版】 Xiaomi Mi スマートバンド 5 [日本語設定ガイド同梱] NFCなし標準モデル シャオミ リストバンド本体セット miband5” …本体は日本語表示でありながら，「グローバル版とは異なります」 ，ということは基本中国版でUI言語を日本語に設定したということか。マイク付きということになっているがそれは誤りでは。

“GeekDoing” にカスタマイゼーションのためのツールやリソースがある。「カスタム・ファームウェア」という表現をしてはいても，ファームウェアそのもというより，フォントであったりアイコンであったりフェイスであったり，そういったリソースの差し替えのことを指していると思われる。

“Mi Band 5 | Original Firmwares/Resources/Fonts | GeekDoing”

“[V94][V5][12/04/20][FINAL] MI Watch UX | GeekDoing”

“Mi Band 5 | How To Flash Firmware And Resources | Ft. Mi Watch Theme – YouTube”

“Amazfit Band 5: Mi Band 5 with Alexa & blood oxygen saturation” によればAmazfit Band 5はいわばMi Band 5の上位機種で，Amazon Alexaとの連携（つまりマイク内蔵），SpO2測定機能が追加。米アマゾンなら$35。安い。噂されるMB6のことが想起される。

現時点でSpO2測定機能が欲しければ同様な価格帯だとHONOR Band 5が候補。 “Xiaomi Mi Band 5 vs. Honor Band 5: Which should you buy? | Android Central”

余談: Mi Band激似のLILYGO® TTGO T-Wristband DIY Programmable Smart Bracelet ESP32-PICO-D4 Main Chip 0.96 Inch IPS Screen Silicone Bracelet Strapが存在する（Xinyuan-LilyGO/LilyGo-T-Wristband: 💐）。 “TTGO T-Wristband DIY – Shigezone Online” によれば「シャオミのMi Band4にクリソツでサイズも同じ、バンドも流用できますが…」。AliExpressなら必要付属品を含めて2,500円強。Mi Band 5が重量12gなのに対してT-Wristbandは30g。

“LILYGO TTGOのT-WristbandでグラフィックライブラリLovyanGFXを使ってみた – Qiita”

Direct Access to P2P File System from Browser

Brave browser is adding native support for the IPFS network. This might well be that brings this global P2P file system into the spotlight for the general public.

According to “IPFS Support in Brave,” Brave is going to be able to recognize and handle URIs with ipfs: and ipns: prefixes (which denote their respective schemes), both of which refer to resources on the InterPlanetary File System (IPFS) network. Unlike the URL resources with the http/https schemes, which employ the location-based addressing, the IPFS resources employs the content-based addressing. The IPFS URIs therefore do not contain any information at all about where the content is stored.

Generally speaking, to allow accessing the resources on the IPFS network, IPFS gateways exist, some private, some public. Ipfs.io is one of the latter, and CloudFlare also provides cloudflare-ipfs.com. There are three “resolution types,” or the ways IPFS resources are mapped to HTTP URLs on IPFS gateways, i.e., path, subdomain, and DNSLink.

Brave, when its IPFS feature is enabled, uses an IPFS gateway to resolve IPFS URIs by default, although Brave currently does not seem to support DNSLink. The other supported way is to install and run a Go-implemented IPFS node, and access IPFS resources through it.

IPFS-specific features are not limited to the latest incarnation of Brave. If your browser is Firefox or a Chromium-based one (including Brave), then you can use IPFS Companion add-on. This add-on seems to have more features than what Brave’s native counterpart offers. It requires a local IPFS node by default, but probably this can be changed by appropriate configurations.

Beaker Browser is to Hypercore (or more specifically, Hyperdrive) what Brave is to IPFS. As an added bonus, Beaker allows you to create and manipulate Hyperdrives from within Beaker, including editing sources. Gateway Browser is somewhat like a mobile counterpart to Beaker Browser, but it is supposedly in alpha. See also “ウェブサイトの「閲覧」だけでなく「公開」もできる異色のブラウザ「Beaker Browser」レビュー – GIGAZINE.”

So far I cannot find a browser plug-in/add-on that enables access to direct Hypercore/Hyperspace resources from browsers.

Agregore Browser supports supports multiple P2P network protocols, such as IPFS (ipfs: and ipns:), Hypercore (hyper:) and Dat (dat:).

Microsoft’s Fluid Framework for Collaborative Realtime Editing

I wrote “Collaborative Text Editing” a few weeks ago. Microsoft’s take on this matter is Fluid Framework (demos; Github). Actually, it is “a collection of client libraries for distributing and synchronizing shared state,” but it seems MS uses it primarily for implementing collaborative realtime editing. In fact, I found out about it in “Collaborative real-time editor – Wikipedia.”

According to its FAQs, Fluid relies on a Total Order Broadcast (“TOB” hereafter), not on either Operational Transforms (OT) or on Conflict-Free Replicated Data Types (CRDT). Supposedly TOB is closer to the latter than to the former; the difference with CRDTs is the existence of its assumption that update-based operations are ordered. Fluid clients always require a Fluid server for syncing amongst them, not just at the initial setup time, so it is not a P2P solution. However, it is not that you have to use one preexisting server; you can host a Fluid server by yourself.

A quick idea (without fully understanding all the intricacies): isn’t it possible to combine TOB and OT or CRDT? In this modern computing world, total ordering can probably be achieved most of the time if all parties are online. It is when there are parties that are not online that’s problematic.

It appears Microsoft 365 allows only real-time “co-authoring,” which seems in line with what Fluid is capable of:

• “Collaborate on Word documents with real-time co-authoring – Office Support“
• “Edit in real time with friends and family – Office Support“

Postscript: I received a comment on Twitter from Mr. Sam Broner, who is actually working on Fluid. This came as a complete surprise to me!

A very nice comment from Mr. Sam Broner

Creating an Isolated P2P Network with Hypercore

This article is another sequel to “Creating an Isolated P2P Network with IPFS,” and I will again explore the ways to create an isolated P2P network, only with Hypercore this time. “A WebRTC-Based Generic Way to Create An Isolated P2P Network” was originally part of this article, but I carved that part out into a separate article once I realized that it is a generic method that does not rely on any of the Hypercore family.

There are are some architectural differences between IPFS and Hypercore — or, to be precise, Hypercore and its Hyper* sibling products, collectively. Hypercore itself is an append-only log system, which is design to be used as a building block for p2p decentralized systems. However, p2p connection and swarming are not part of the Hypercore proper.

I believe Hypercores can be P2P-connected by the method in “A WebRTC-Based Generic Way to Create An Isolated P2P Network.” “Peer objects (as provided by Simple-Peer) are instances of stream.Duplex. They behave very similarly to a net.Socket from the node core net module. The duplex stream reads/writes to the data channel.” Peers should be able to be piped to/from the replication streams of Hypecore objects.

That said, Hypercore comes with a library for establishing P2P connection between Hypercores, Hyperswarm. More specifically, Hyperswarm is a DHT (Distributed Hash Table). Hyperswarm is actually general enough to be used outside the conetxt of Hypercore; it is not exclusively tied to Hypercore.

hyperswarm/dht: The DHT powering the HyperSwarm stack has this comment:

Note: The default bootstrap servers are publicly served on behalf of the commons. To run a fully private DHT, start two or more dht nodes with an empty bootstrap array (dht({bootstrap:[]})) and then use the addresses of those nodes as the bootstrap option in all other dht nodes.

… so this is the way to create a completely isolated P2P network with Hyperswarm. I do not know why one server is not enough and you need at least two. The default value for bootstrap can be found in file dht/index.js in the hyperswarm/dht package.

The signalhub+webrtc-swarm method in “A WebRTC-Based Generic Way to Create An Isolated P2P Network” does make P2P connections between peers possible, but does not take care of swarming. Hyperswarm does, so it is probably a better solution.

However, I am not sure if the inevitable inefficient communication problem when there are more than two peers in the signalhub+webrtc-swarm method applies to Hyperswarm as well. The figure in “How the Hypercore Protocol Works: Hyperswarm” seems to indicate it does not, but I am not sure.

By the way, initially I was puzzled why Hyper* library uses “buffer” to represent keys. It turned out that it’s “buffer” as offered in Node.js and is “a fixed-length sequence of bytes.” In this context, “buffer”‘s are simply used as representations of fixed-length binary data, not as buffers in the usual sense. In browsers, you are expected to use feross/buffer: The buffer module from node.js, for the browser instead.

Uses Node.js’s Stream capabilities. The pipe() method is often replaced with pump(), an upper-compatible facility.

A WebRTC-Based Generic Way to Create An Isolated P2P Network

This article is a sequel to “Creating an Isolated P2P Network with IPFS.” I am still researching ways to create an isolated P2P network. The following is one such way which uses WebRTC. My focus is on the creation of an isolated P2P network, but this is more a template for building a browser/Node.js-based P2P app.

Essentially, use mafintosh/signalhub: Simple signalling server that can be used to coordinate handshaking with webrtc or other fun stuff with mafintosh/webrtc-swarm: Create a swarm of p2p connections using webrtc and a signalhub, which is based on feross/simple-peer: 📡 Simple WebRTC video, voice, and data channels.

This is pretty much the recipe presented in “Building P2P Video Chat Application using webRTC and Node.js.” See also “I MADE A WEBRTC MISTAKE – YouTube.” The concern I have is webrtc-swarm was last updated 3 years ago, and may be a little outdated (see “simple-peer entry is a bit outdated · Issue #39 · mafintosh/webrtc-swarm” ).

It’d be best to host your own signalhub, but you might have to use a public one for whatever reasons. You can have added security with secure-webrtc-swarm (repository already archived). The shared secret key is expected to be shared “out of band,” so it may not be as sophisticated a method as that uses Diffie–Hellman key exchange.

Another potential issue is that the signalhub+webrtc-swarm method does not provide any utility to make communication among peers efficient (would that be called routing?) when there are more than two of them. Simple-Peer recommends creating a full-mesh network, but at the same admits its apparent inefficiency.

“Beginner’s Tutorial to WebRTC using PeerJS | Toptal” is not about Simple-Peer, but rather PeerJS, which seems to have pretty similar functionality. It gives a concise introduction to WebRTC.

IndexedDB and LevelDB

image courtesy of Clipart-Library.com

For the client-side storage of Web apps, there is Web Storage, which offers two types of storage: local storage and session storage, which in turn can be thought of slightly generalized forms of persistent cookies and session cookies, respectively.

There was also Web SQL Database, but it has been depreciated in favor of IndexedDB (see below). Web SQL seems to have been modeled too closely after the underlying SQLite, which Mozilla did not like.

Mozilla instead pushed Indexed Database API, which is a JavaScript API provided by web browsers for managing a NoSQL database of JSON objects. Some wrapping libraries exist that abstract away the intricacies of IndexedDB (see “IndexedDB API – Web APIs | MDN” ).

In Chrome, LevelDB is used to implement IndexedDB. LevelDB is an open-source on-disk key-value store written by Google, inspired by Bigtable, itself being part of Google’s commercial offerings. LevelDB is also one of the supported backends for Riak.

For access to LevelDB store using Javascript from Node.js or browsers, Level/levelup: A wrapper for abstract-leveldown compliant stores, for Node.js and browsers recommends the package Level/level: Fast & simple storage. A Node.js-style LevelDB wrapper for Node.js, Electron and browsers. It includes Levelup: A wrapper for abstract-leveldown compliant stores, for Node.js and browsers JavaScript library, which they recommend you use for usability and safety; it also includes an alternative library Leveldown: Pure C++ Node.js LevelDB binding. An abstract-leveldown compliant store, which is meant for performance.

LevelDB has many related projects. “Level/awesome: An open list of awesome Level modules and resources” is a fairly comprehensive list. Hyperbee can also work as a Leveldown backend.

TuyAPIを使ったNode-REDでのTuya機器の制御に再挑戦…が断念

電力計機能付きスマートプラグを入手し，そのTuyaがOEM提供した電力計機能つきのスマートプラグをNode-REDでコントロールしようとして失敗した。これはTuyaのOEMサービスと思われるSmartLife Air（対応アプリも同名）を利用した，node-red-contrib-smartlifeairというカスタムノードを利用していた。

TuyAPIというよく利用されるJavaScriptライブラリがあり，上記カスタムノードを除くと，他のTuya機器をコントロールするためのNode-REDカスタムノードはTuyAPIを利用している ⇒ node-red-contrib-tuya-smart-deviceとnode-red-contrib-tuya-smartはTuyAPIを利用している。

こちらを利用しなかったのは，そのために必要なTuya社が発行するキーが，そのときは有料アカウントを作成しないと得られなかったから。ところが， “Stuck at the First Step of Getting Keys at IoT.Tuya.com · Issue #369 · codetheweb/tuyapi” によると今は無料アカウントでも取得できるという。自分も試してみると実際取得できた。～-smartlifeairカスタムノードでは，電量計機能つきスマートプラグは一切制御できなかったが， “Energy monitoring through API · Issue #121 · codetheweb/tuyapi” なんてページがあるところを見ると，TuyAPIではできる可能性が大だ。期待が募る。

ところが， “Controlling Tuya devices with cloud API instead of controlling them locally · Issue #20 · codetheweb/tuyapi · GitHub” を見て，やっと気づいた: TuyAPIはローカルにTuya機器を制御するためのもの。なので，VPS上のNode-REDからホームLAN内のTuya機器は制御できない。TuyAPIに “An easy-to-use API for devices that use Tuya’s cloud services.” なんて説明がつけられているので，なんとなくクラウド経由で制御できるものと思い込んでしまっていた。わかってしまえば，確かにTuyAPI自身が「クラウド経由で制御できる」とは書いてないものの，TuyAPIのGitHubページには明瞭にローカルでの制御を対象にしている，とも書いていない。私のような誤解をしてしまう人は他にもいるのじゃないか。少なくとも今までVPS上のNode-RED上で利用する，ということが前提であったので，前回TuyAPIに依存しないnode-red-contrib-smartlifeairカスタムノードを利用したのは，単なる偶然の結果に過ぎないが，期せずして意味のある解の一つだったと言える。

さて，TuyAPIを利用してTuya機器を操作するには，機器それぞれのIDとキーを入手する必要がある。それにはTuyaAPI/cli: 🔧 A CLI for Tuya devicesを利用し，tuyapi/SETUP.md at master · codetheweb/tuyapi · GitHubの指示に従う。これはうまくいって，IDとキーの組は入手できた。その上で tuya-cli get コマンドで機器の情報を得ようとすると， --id，--keyのオプションを与えるだけではだめで， --ip オプションで機器に振られたIPアドレスを指定する必要があった。

デバッグプリントを見ると，正確には --ip オプションなしでも，UDPブロードキャストパケットを受け取って，その機器のIPアドレスは正しく取得しているようだ。それにも関わらず，その後の挙動が最初から --ip オプションでIPアドレスを指定した場合と異なる。どちらの場合も最初に機器に接続して2回以下のようなメッセージを受け取る。IPアドレスを指定した場合は，その後も継続的に機器に対して定期的にpingし，また，機器の状態変化があった場合その通知も受け取っている。IPアドレスを指定しなかった場合はこれらが一切なく，最初の2通のメッセージを受け取った後終了する。

2021-01-05T15:15:32.326Z TuyAPI {
     gwId: devIDと同じ値,
     devId: 'XXX....',
     t: '1609859732',
     dps: {},
     uid: 'YYY....'
}

TheAgentK/tuya-mqtt: Nodejs-Script to combine tuyaapi and openhab via mqtt でローカルのNode.jsからMQTTブローカと交信させることで，MQTTブローカ経由の制御ができよう。

さて，unparagoned/cloudtuya: Tuya control over the cloudはTuyAPIとは別物だが，自分が勝手にTuyAPIの機能と思っていたことをこれは実現している。node-red-contrib-tuyapi-cloudがこれを利用したNode-REDのカスタムノード。ところがここでまた問題が。

Cloudtuya自身は “old API” と “new API” の双方をサポートしている。 “Old API” であれば既に入手している情報で操作できるはずだが，node-red-contrib-tuyapi-cloudは “new API” しかサポートしていない。”New API” で操作するには追加の情報が必要になるが，その手続は大変そうだ。“Old API” をサポートできないか問い合わせてみてるが，返答はあまり期待できなさそうだ。

Cloud APIについては，”Controlling Tuya devices with cloud API instead of controlling them locally · Issue #20 · codetheweb/tuyapi · GitHub” ，特にこの投稿が詳しい。