Resource Identification in RDF

This is one of those “Oh, sh*t, that was totally unnecessary and/or pointless in hindsight” articles. This particular one is pointless because I had a complete misunderstanding. The first section describes the misunderstanding I had, and the second section is what I wrote initially before I realized my misunderstanding, so the discussion there is naturally off.

Resource Identification in RDF

The way Tim Berners-Lee described his Linked Data concept gave me the impression that resources need to be accessible via HTTP, but I was wrong.

The section “Resource Identification” in the “Resource Description Framework (RDF)” Wikipedia page says this:

In fact, the URI that names a resource does not have to be dereferenceable at all. For example, a URI that begins with “http:” and is used as the subject of an RDF statement does not necessarily have to represent a resource that is accessible via HTTP, nor does it need to represent a tangible, network-accessible resource — such a URI could represent absolutely anything. However, there is broad agreement that a bare URI (without a # symbol) which returns a 300-level coded response when used in an HTTP GET request should be treated as denoting the internet resource that it succeeds in accessing.

My Problem with Tim Berners-Lee’s Ideas of Linked Data

Note: This section contains falsehood, which resulted from my misunderstanding. Please see the previous section.

According to “Linked data,” Tim Berners-Lee described his Linked Data (LD) concept as follows (2009 version):

  1. All kinds of conceptual things, they have names now that start with HTTP.
  2. If I take one of these HTTP names and I look it up…I will get back some data in a standard format which is kind of useful data that somebody might like to know about that thing, about that event.
  3. When I get back that information it’s not just got somebody’s height and weight and when they were born, it’s got relationships. And when it has relationships, whenever it expresses a relationship then the other thing that it’s related to is given one of those names that starts with HTTP.

Such vague phrases as “names that start with HTTP” and “HTTP names” leave room for interpretation, but since he used the phrase “HTTP URIs” in his 2006 memo on the same topic, it should be safe to assume he meant accessing resources on the Internet by way of the HTTP protocol.

I do not think the use of the HTTP protocol should be an essential part of the LD concept. The transport can be anything. What I do not like about HTTP URIs is that by definition, hostnames need to exist, which then means domain names need to exist as well, having been registered with an domain name registrar under the supervision of ICANN. I do see the convenience of using a hostname as a name space separator because it is guaranteed to be unique, but I do not think it needs to be the only way. Note URIs in general, as opposed to HTTP URIs, do not necessarily have hostnames or domain names as part of them.

Even when you remove the HTTP protocol mandate from TimBL’s LD concept, it is still a valid and useful concept as long as you provide an alternative method or methods of uniquely identifying data and accessing them. In other words, the LD concept can be transport agnostic. When it is, it is no longer directly tied to the World Wide Web as we know it — but it still constitutes a web of information.

A benefit of detaching data’s identity from hostnames is that data can now be hosted on a P2P network.

I wrote “Some Personal Notes on the Semantic Web” as objectively as possible, but this article was originally meant for a place to express my own ideas… and look what happened.

Some Personal Notes on the Semantic Web

Just some personal notes on the Semantic Web, from “Whatever Happened to the Semantic Web?” and what little knowledge I gathered from skimming through related pages on Wikipedia and some search results. Note this is not a summary of the article above.

Semantic Web Has Had Limited Success

The venerable Tim Berners-Lee, “Father of the World-Wide Web,” in 2001 advocated the Semantic Web, which he later called “Web 3.0” as opposed to the then emerging Web 2.0 technologies, and even later “Linked Data.” The Semantic Web has had limited success. Some may disagree with this statement, but everybody would agree that it has not succeeded to the extent TimBL envisioned.

The primary reason is that the metadata provided voluntarily by website authors, if any, are hardly trustworthy. Anyone who has put in a large number of keywords to the <meta> tag in an html file for the sake of SEO (Search Engine Optimization) would understand exactly why.

In One Area It Shines

The flip side of this is that when the source information is a relatively reliable set of facts, it can be useful. In fact, knowledge bases constructed from reliable sources have been proven successful, for example, DBpedia (website), which extracts data from Wikipedia (although I am still not clear on exactly how — is it manual, or is it at least partially automated?); and Google’s Knowledge Graph, which also extracts from Wikipedia, and in addition use the CIA World Factbook and Wikidata, which replaced Freebase.

DBpedia is used in creating the “infobox,” a short listing of basic facts about the subject of the page on Wikipedia, and also used as a knowledge source for IBM Watson. Google uses Knowledge Graph in providing an infobox to their search results, and in creating answers to Google Assistant and Google Home voice queries. So they are definitely used in production environments. Wikipedia’s page on Wikidata is easy to understand, with a few examples. Wikidata itself is easy to browse. In contrast, I have not seen any concrete example of knowledge in DBpedia.

Data Representation and Query Mechanism

From the viewpoint of data representation, DBpedia uses RDF (Resource Description Framework); and Knowledge Base, JSON-LD (JavaScript Object Notation for Linked Data). Also used in Knowledge Graph along with JSON-LD is schema.org, which gives a set of agreed-on vocabulary in describing ontology. As to the query mechanism, both DBpedia and Knowledge Base employs SPARQL.

Wikidata provides a compilation of documents on SPARQL. “Wikidata:SPARQL query service/A gentle introduction to the Wikidata Query Service – Wikidata” is a good starting point. Manu Sporny has published some videos on JSON-LD.

Bits of Semantic Web Are Sneaking into Our Everyday Websites

Google now encourages Web authors/developers to embed semantic info into their websites with what they call “structured data,” which in turn could help their content be displayed in a customized format tailored to the nature of the content. They support JSON-LD, Microdata and RDFa, and they recommend JSON-LD.

Opportunistic Use of Semantic Web Technologies

Facebook’s OpenGraph (Wikipedia) protocol defines a schema that web developers can use (via RDFa (Resource Description Framework in Attributes) ) to determine how a web page is displayed when shared in a social media application.

Some may view this as an application of the idea of the Sematic Web, but I disagree; this is rather just opportunistic repurposing of a technology originating from the idea of the Semantic Web. The beneficiaries of OpenGraph is for the most part Facebook and, perhaps, to a much smaller degree, the content provider and those who view the content embedded and displayed on Facebook. OpenGraph is not meant to benefit everyone.

 

かけ放題が望ましいシニア向けの携帯プラン候補

追記(10月29日): 予定通り,スマホベーシックプランSにプラン変更。11月1日より適用。ソフトバンクは「MNP転出手数料を、来春をめどに完全撤廃を予定」ということなので, これが起こってから場合によっては一時的に他キャリアに転出し,さらに最終的にワイモバイルに戻るようにするのが(セコセコやるなら)一番お得。


携帯のかけ放題回線を安価に” で書いていたシニアの方の契約更新月に入っているので候補を再確認。ちなみに,ワイモバイルのプラン変更でみまもりグッズがもらえると思っていたが,実は特定のプランからの契約変更のときに限る,ということで,結局特典は受けられないことに。みまもり電池についてはさらに調べ, “ノバルスのMaBeeeみまもり電池” にまとめた。

もともと考えていたように,ワイモバイルで維持するとスマホベーシックプランSで3GB/月で2,680円。スーパー誰とでも定額がシニア特典で無料でかけ放題なのはいいが,新規・乗り換えではないため割引の類が一切なく,決して安くない。プラン変更に伴う手数料は発生しないとのこと。

日本通信の合理的かけほプラン2,480円/月と若干安い。ただし初期手数料3,000円。必要なら250円/GBで追加できるのもよい。特にキャンペーンはやってない模様。ドコモ回線なのでワイモバイル端末だと田舎での電波の入りが悪いんじゃないかとそこは心配。お持ちのかんたんスマホ705KC(京セラ)の対応周波数帯を見てみると,バンド1には対応しているがバンド19に対応していないのが不安。バンド3に対応しているのはいいが,ドコモでは東名阪エリア限定で使用されているということで特にうれしくないか(参考: “日本の全キャリアの4G周波数帯まとめ【楽天モバイル追加】 | telektlist” )。

日本通信から提供を受けていて,サービスの条件は同じのHISモバイルの格安かけ放題プランもある。こちらは価格.comのキャンペーンはあるが使用量に応じたキャッシュバックで,想定された使用量なら1,000円だけ。

もしLineで通話もまかなえるのなら,LINEモバイルで3GB/月で1,480円/月。ソフトバンク回線を選べば安心。初期費用は3,400円だが価格.comで8,000 Lineポイント還元のキャンペーンあり。加えて,公式の月額基本利用料3か月980円値引きあり。

やはり電話をある程度するのであれば,日本通信のWスマートプランが70分/月の無料通話,3GB/月で1,580円/月。合理的かけほプランと同様,必要なら250円/GBで追加できるのもよい。ドコモ回線で不安あり,は同じ。

ワイモバイルで続けても旨味が少ないので,仮に最終的には再度ワイモバイルに戻るとしても,一旦転出するのが賢明だと思う。そうすればワイモバイルに戻ってきたときにいろいろ特典にありつけるし。まだ残ってたらみまもりグッズももらえるかも。

ノバルスのMaBeeeみまもり電池

過去に書いた記事内容の訂正と補足。

携帯のかけ放題回線を安価に” で,ワイモバイルのキャンペーンでもらえるみまもり電池について以下のように書いた。

ちなみに,ワイモバイルで契約変更する際,「みまもり電池」と「センサーライト」がもらえるキャンペーンをやっており,かつ条件を満たすはずだから必ず利用しよう。ただ特定ショップでしか対応していないようなので,そこを気をつける必要がある。

ワイモバイルのみまもりサービスは結局ソフトバンクが提供しているそれである。動作機構はソフトバンクセレクションの説明ページがわかりやすい。製造元のMabeeeでもみまもりサービスを提供しているが,それが550円/円なのに対し,ワイモバイル/ソフトバンクでは480円/月の「基本プラン」と無償の「シンプルプラン」を用意している。これら2プランの違いは,一定時間使用がない,ということをトリガーにした自動アクションをサポートしているかどうか。みまもる側のアプリがどのようにクラウドから行動履歴のデータを取得するのかさえ解析できれば,シンプルプランででも同様な自動化は実現できよう。

その「60歳以上のシニア」の方の乗り換え時期が近づいたので,調べ直したらいろいろ誤りがあった⇒契約変更でもこの特典が適用されると思っていたが,実は特定のプランからの契約変更のときに限る,ということで,結局特典は受けられないことに。せっかく調べたのに…。

みまもり電池はノバルスが製造。自分たちでそれを利用した見守りサービス(980円/月)を提供しているが,他社もみまもり電池をそれぞれのサービスに利用している。なのでサービス提供事業者ごとに使うことが想定されているアプリが違う。電池自身はスリーブの色を変えることで区別がつくようにしているようだ。ノバルスが提供しているのはみまもり電池という名前のアプリ。 “「MaBeeeみまもり電池」熱中症計アラームにも対応した新アプリをリリース” によると以下のような通知をしてくれるそうで,ここでいう「使っていない通知」が特に有用だと思われる。

  • 使っていない通知;一定時間内に使用(動作)がなかった際に、通知を発信します。
    (ex.24時間テレビリモコンの使用が無い場合)
  • 使いすぎ通知:一定時間内に設定の回数以上使用(動作)した際に、通知を発信します。
    (ex.2時間以内に、熱中症計のアラームが5回以上動作した場合)
  • 使った通知:設定した時間内に使用(動作)があった際に、通知を発信します。
    (ex.深夜0時〜3時の間に、玄関へ設置したセンサーライトが点灯した場合)

余談だが,ノバルスのサイトでは、その見守りサービスについて以下のように表記してある。

「※今なら30日間無料トライアル 無料期間終了後に最低1ヶ月分の月額利用料が発生します」ということだが,不明瞭なので問い合わせて内容を正すと,要は「2ヶ月以上の使用で初月使用料無料」ということらしい。これでは詐欺まがいと言われてもいたしかたなかろう。苦言を呈したところ速やかに訂正すると言っていたが今だにその様子はない。

なお,ノバルスは同じMaBeeeブランドの元,MaBeeeコントロールモデル (トイコントロールモデル) (電源のオン・オフだけでなく出力もスマホアプリから操作できる模様),MaBeeeスクラッチモデル (プログラミング教育モデル)(Scratchを利用したPC/Mac上でのプログラミングに対応)も提供している。説明を読む限り,これら2種は本質的には同じハードウェアだと思われるが,差別化のため前者の電池で後者の使用法はできないなどの措置を取っているかも知れない。

ノバルスとは異なるIoTBASE株式会社も,MaBeeeみまもり電池を使った見守りサービスを提供している500円/月。アプリはMaBeeeみまもり電池対応アプリ「スマート電池」。説明を読む限り,本家アプリのようなインテリジェントな通知はサポートしてない模様。

同じくMaBeeeみまもり電池を利用するソフトバンク/ワイモバイルのみまもりサービスシンプルプラン無料,基本プラン480円/月。後者は正確には,「“ワイモバイル”のお客さま:月額480円,“ワイモバイル”以外のお客さま:月額980円」ということなんだが(プレスリリースでもそうなっている)ソフトバンクのサブスクライバはどうなんだろう?自分には直接関係ないが…。

アプリは,見守る側が使うみまもりサービス (みまもる)と,見守られる側が使うみまもる(みまもられる)。ソフトバンクのドキュメント中には後者へのリンクは見られず,見守る側がサービス使用開始後に見守られる側にそれを通知する流れ,と説明しているがPlay Storeで普通に見つかった。

このサービスは,MaBeeeみももり電池使えるが,それはあくまで見守りの1手段という位置づけのようで,見守られる側のスマホで検知できるイベント(ロック解除,充電開始,移動,等)による通知もあり,より包括的と言える。以下の説明ビデオ参照。ビデオ後に記事は続く。

開発者寄りの情報を別途MaBeee.mobiというサイトで公開している。SDKも公開している

MaBeee電池は優れた製品だと思う。原理的にはシンプルな機構から複数形態のサービスに展開したのもご立派。ただ見守りの観点からは,Bluetooth Low-Energy (BLE) で通信するためみまもり電池と見守られる側のスマホが10m以内になければならない,というのはサービスの有効性を根底から揺るがしかねない大きな問題だと思う。

自分は家でも常時スマホをポケットに入れて持ち歩いているので,もし自分が見守られる側ならこれは問題にならないが,それは誰にでも当てはまることではないだろう。そうでない場合,見守られる側が木造の家に住んでいるのならまだしも,鉄筋コンクリート造りの家・アパート住まいであればなおのこと電波の通りは悪くなり,スマホでみまもり電池の状態変化が検知できなくなるかも知れない。理想的には,専用のBLE/インターネットブリッジを据え置きで用意すべきだろう。もっとも,そんなことを要求すれば,大きなウリの「お手軽運用」が主張できなくなるが。

みまもり電池がスマホとペアリングしない作りになっていることを祈る。ペアリングをせず,状態を垂れ流していれば(アドバタイズしていれば),それこそESP32でブリッジを実現して自分でクラウドにデータを流せるようになる。

電力計機能付きスマートプラグ

スマホバッテリを容量いっぱいまで充電させないことを一つの目的に,スマートプラグの類をいろいろ入手して試してみたが,給電可能状態で,実際そこで電力が供給されているかを検知するには電力計機能が必要であったことに気づいた。

その機能付きのものは,日本のアマゾンではあまり見つからず,以下の2種ぐらい。この手の製品は要は中国メーカからOEM提供を受けてアプリなんかを日本語化しているだけ,ということが多いと思うのだが,仮にそうだとしても日本人向けにちゃんと手を入れている印象。

【+Style ORIGINAL】スマートプラグ 2個セット 消費電力/タイマー 動作 Amazon Alexa/Google Home 対応 アプリ連携 Wi-Fi 音声コントロール ハブ不要 スマートコンセント ソケット極性付きプラグが問題。大半の場合,結局アメリカの3穴/芯プラグ用アダプタを介さないと日本のコンセントには刺さりもしないと思われる。

どうせアダプタを併用しなければならないのなら,US用のものが安い。例えば16A WiFi Smart Plug Socket With Power Energy Monitor EU Standard Multi Plug Tuya APP Control Works With Alexa Google Assistant|Smart Power Socket Plugが送料込みで$8程度⇐電力計機能なしでした,Tuya Plug Smart WiFi Adaptor power energy consumption metering function for home work with Alexa Google Home 110V 220Vなら送料無料で$10程度⇐実際購入したが(写真),商品説明でははっきり電力計機能があるとされていたのにも関わらず,実際にはなかった。

SwitchBot スイッチボット スマートプラグ Wi-Fi コンセント – タイマー 遠隔操作 音声コントロール Alexa Google Home IFTTT Siriに対応…SwitchBotの素性がよくわからないが,クラウドファンディングサイトMakuakeでいくつかプロジェクトを成功させているところをみると日本の会社なのだろうか。後にあげるアマゾンのレビューではFUGU Innovationsという中国会社の日本支社,としているのがある。日本語サイトのみならず,英語サイトも用意している。ただし,素性を現す情報は見当たらないのが正直怪しい。

IFTTTやAmazon Alexa,Apple Siri,Google Homeなどとのサードパーティーサービスとの連携についてちゃんと説明ページを用意しているのは好感が持てる。製品をコントロールするPythonスクリプトも公開している(OpenWonderLabs/python-host: The python code running on Raspberry Pi or other Linux based boards to control SwitchBot)。ただし,これは機器のBluetooth MACアドレスから操作するようだからLAN内での使用が前提?スマートプラグにはBluetooth機能がそもそもないからこのスクリプトでは操作できない?それをNode-REDから使用した例

ただ,スマートプラグ自身は全般的には高評価だが,否定的なものも無視できないほどある

AliExpressに目を向けると,米の3芯プラグ用製品は多く見られるが,日本の2芯プラグ用製品は珍しい。唯一,Tuya WIFI Smart Socket Smart Plug EU UK Swit AU BR FR JP Israel Ita ZA Plug 10A Remote Control Alexa Google Home Energy Monitorがあったが,プラグに極性あり?⇒問い合わせるとやはり極性あり,つまりprongの一つが他方より幅広だ,と。アプリの画像みると,+Style ORIGINALのものと同じ。

ちなみに,冒頭の図は,Adobeが写真や動画など約7万点の無料素材を公開,しかも商用利用OKということだったので,そこから1点無理矢理選んで入れてみた。

スマホバッテリを容量いっぱいまで充電させないようにする

スマホ等でよく利用されているリチウムイオンバッテリは80%程度までの充電を心がけるのが電池が「ヘタる」のを極力抑える上で有効とされている

なのでオズマ OSMA UC-ECO100W [エコモード搭載スマートフォン用 充電専用USBケーブル 100cm ホワイト]をかつて買っていて,ガラホ(Auの4G対応Gratina)で使ってみると実際そのように充電されるようだ。ただ,(今だに)メインで使ってる端末,Oppo R17 Neoに使ってみると期待されるような動作にならず100%まで充電されてしまう。

もしrootが取れているのなら,Battery Charge Limit [ROOT]なるアプリでこの機能は実現できるようだが,残念ながらrootは取れてない。⇦ R17 Neoの次のメイン機に選んだRedmi Note 10 Proroot化したので無事Battery Charge Limitが使えてる

特に最近のスマホの内蔵電池は,以前のようにバッテリパックとして簡単に交換できなくなっているので,これが以前にもまして重要。Oppo R17 NeoにもOppo Reno Aにもこれが当てはまる。

Rootを取ることを諦めるのなら,Android端末であれば端末上で走らせるTasker等自動化アプリと,遠隔で給電をオン・オフできるスマートプラグを組合わせることが考えられる。

How to Automatically stop charging a phone once it’s charged using Tasker” がその方法の一例を示している。端末内のコントロールはTaskerで行い,スマートプラグのコントロールはIFTTTを使うという方式。

自分はAndroid端末の自動化にはAutomateを使っているのだが,Power source pluggedブロックであったり,Battery levelブロックであったりが用意されているのでこれらで実現できるはず。

スマート・プラグには以下の3種類の可能性がある。そのそれぞれについて自分で調べたり試したりしたことをまとめた記事を併記。

Sinilink Wifi USBリモートコントローラーについては,カスタムファームウェアをフラッシュでもしないと実現できないであろうが,TuyaのスマートプラグとSonoff MicroについてはNode-RED上に自作したフローで,MQTTブローカを介してオン・オフができるようになっている。

Chargie – limit phone’s nighttime charging to extend battery lifespanという製品を発見。見た目はSinilinkに似通ってるが,wifi機能がない代わりにBluetooth機能があり,それでスマホと直接通信できるのは大変良い。SinilinkにTasmotaなりを入れても,スマホ,Sinilink以外の「第3者」が給電の中止を判断しなくてはならない。

さて…普通にやるなら,充電ソースの電源を手作業で入れ,その上で端末内で充電度合いをモニターし,80%付近になったら充電ソースの電源をプログラム的に遠隔で切ることになる。「手作業」と言ったが工夫のしようはあり,先のYouTubeビデオではスマートスピーカを利用し、音声での操作を実現している

実は,充電は複数の場所でできるようにしようと考えていて,その充電ソースから充電しているかは,①端末側で充電が始まったを検知したタイミングと,②充電ソースから充電が始まったことを検知したタイミングを見比べて判断するつもりでいた。

が,①は可能なのだが,②は今まで検討したどのスマート機器でもできないことがわかった。スマートプラグなら当然できるものと思い込んでいたが甘かった。同じスマートプラグでも電力計機能があるものでなければならなかった…

Node-REDでSmartLife Airカスタムノードで給電がコントロールできないTuya製プラグをなんとか

Node-RED(自分が使用しているのは無料VPSサービス上にインストールしもの)でTuya製スマートプラグSmartLife Airカスタムノードを使用してNode-REDからアクセスする試みをした。部分的にはうまく行ったが肝心の給電のオン・オフを操作できない。それでは全く意味がない。

作者に問い合わせてみたところ,それはこのスマートプラグでは本質的に提供されてない機能とのこと。ただ,回避策のヒントをもらい,それがうまくいった。

その方法とは以下。Node-REDからコントロール可能な他の機能のオン・オフと給電のオン・オフを,SmartLife Airアプリで設定させて連動させる。この自動化はSmartLife Airのサーバ側で実行されるのでSmartLife Airアプリが走っていなくても連動は起こる。そうしておいて,Node-REDで「その他の機能」の方をオン・オフすれば,間接的にプラグの給電状態もオン・オフできる,というもの。

その「Node-REDからコントロール可能な他の機能」としては以下の条件を満たして欲しい:

  1. 必須: SmartLife Airカスタムノードで操作可能な機能
  2. 必須: SmartLife Airスマホアプリで給電状態入り切りと連動できる
  3. オプション: スマホアプリやスマートプラグ本体操作の本来関係ないはずの操作で影響を受けないもの

1. の条件を満たすのは,colour_data, flash_scene_{1, 2, 3, 4}, scene_data, switch_led, work_mode。この中で2. の条件を満たすのは,switch_ledとwork_mode。

Switch_ledの意味は自明だと思うが,work_modeはどうやらLEDのモードのようで, white, colour, scene, scene_1… scene_4のいずれかの値を取る。アメリカ英語式の “color” という綴りではないところが地味に気をつけなければならないところ。LEDの点灯状態とは無関係にこの値は設定できる。

実は自分の所有するスマートプラグのLEDはホワイトモードはサポートしてないようだが,設定はできてしまう。このときLEDは点灯状態のはずでも実際には消灯しているように見える。colourモードのときのLED色のデータがcolour_data,sceneモードのときのLED色データがscene_color,scene_NモードのときのLED色データがflash_scene_N,という構成。

いろいろ試してみると,work_modeはLEDが消灯していても変更でき,特に望ましくない副作用はない。また,scene_dataを変更するとwork_modeはsceneに変更される。アプリでLEDの設定を変えるとすると,まずcolourモードでの色だが,これはアプリでは点灯状態でないとできず,やるとwork_modeはcolourに変更され,colour_dataがその色を表現する値に書き換えられる。

極力LEDの点灯状態やその色と,給電状態とは分けたい。また,個人的には「シーン」は「フラッシュシーン」を含めまず利用しない。これらを全て加味すると以下のようにするのがいいように思える。

  1. SmartLife Airアプリでの自動化で,work_modeと給電状態を連動させる。具体的には:
    • Work_modeがwhiteになれば,給電停止
    • Work_modeがsceneになれば,給電開始
  2. 給電状態の変更を,Node-REDでwork_modeの値を変更する操作で間接的に実現する。給電を停止したければwork_modeの値をwhiteに,開始したければsceneに変更。

LEDの点灯・消灯操作は1.に影響を及ぼさない。アプリ側の操作でwork_modeがcolourやscene_Nになることはありえるが,それは1.に影響を及ぼさない。Sceneになると影響を及ぼすがそういう操作はしないことでそれを避ける。Whiteにする操作はそもそもできるようになってない。

後知恵としては,sceneモードではなくscene_4のようにより使わないようなモードにした方がよかったかもしれない。シーン操作は筐体ではできない。アプリで操作する際は,scene_Nは対応するボタンが一つだけなのに対し,sceneはパラメタを変えていると思われる複数ボタンがあり,その分誤って押してしまう可能性が高い。

上記のようにするだけで,とりあえずもともとの目的は達成できる。だが,もうひと工夫。Work_modeのwhiteモードとsceneモード給電入り切りに操作するわけだが,他のモードには影響を与えたくない。例えばcolourモードだったところで,給電を切るためにwhiteモードにすると,LEDは消灯してしまう。なので,そういった場合には一旦whiteモードにして給電を切るという目的を達成した後,元のcolourモードに戻すようにした。Colourモードに戻しても給電操作には影響はない。

この部分は,JavaScriptの仕様に疎いのとNode-REDに慣れてないのとで,かなりスパゲティーになってしまったが実現できた(最下部図)。

考えてみれば,work_mode等を利用した今回の方策は,LED が内蔵している機種ならではのこと。 “TuyaがOEM提供する日本向けスマートプラグ” でLEDなんてあっても何に使っていいかわからない,といった趣旨のことを書いたが,全く予想外なところで役に立つことになった。

TasmotaやESPHome等ESP8266向けのカスタムファームウェアをフラッシュするのが面倒だったのと,専用アプリを使い続けたい,という観点からこの方式を試してみたが,その苦労はペイしただろうか。ここまで手間がかかってしまうと,素直にフラッシュしたほうがよかったのかもしれない。

Tuyaのスマート機器をNode-REDからアクセスする

追記(2021/07/05): ふと気づくとSmartLife Airアプリにログインできなくなっていた。Smartlife.nzでは問題なくログインできたし,Node-REDのノードでも引き続き問題なくログインできたにもかかわらず,だ。Node-red-contrib-smartlifeairのGithubレポジトリで指示されているように,パスワードリセットをリクエストして,同じパスワードを設定することで解消した。


Tuyaが直接,あいはOEM提供するスマート機器を我が家では使うという結論が早い段階でなされ,スマートプラグを実際に購入した

Tuya製品選択の理由の一つは,多くがESP32やESP8266を採用していて,やろうと思えば,ESPHomeやTasmotaのような代替ファームウェアに書き換えができること。しかも,Tuya Convertで,配線をする必要なくOTAでファームウェア書き換えができる可能性がある。だが,この記事ではファームウェアの書き換えを行わない場合を考える。

その場合,TuyaのSmart LifeとIFTTTとの連携は大きなプラスポイントだったが( “IFTTT resumes support for Tuya Smart Life and Wink, gains 22 other new services” ),IFTTTの方が実質有料化したため,メリットが大きく損なわれてしまった。

IFTTTの代替自動化システムの中でもNode-REDに注目し,無料VPSサービス上にインストールして使えるようにしたので,Node-REDで操作できないか試みてみる。

TuyAPIに依存したカスタムノード

カスタムノードでTuyaのスマート機器を扱えるものがないか探してみるといくつか見つかる。この記事を書いた時点で更新が新しい順に以下:

どれもTuyAPIというJavaScriptライブラリを使用しており,そのライブラリ使用のために必要な情報を取得しなければならない。ところがその最初のステップすらできない。Tuyaの開発者アカウントを取得して,それからプロジェクトを開始する,というステップなのだが,開発者アカウントは取得できても,プロジェクトを開始するにはメンバーシップをアップグレードしなくてはならない。 3ヶ月は無料だが,それが終了すると全ての特権を失う,と。

TuyAPIにイッシューとして上げてみたが( “Stuck at the First Step of Getting Keys at IoT.Tuya.com · Issue #369 · codetheweb/tuyapi” ),Tuya側の話なので彼らにはどうしようもできない,無料アカウントを3ヶ月起きに取得し直したら,といった返答。そんなことをしてクラウド経由でデバイスにアクセスするためのキーを再取得するのを3ヶ月ごとに繰り返すのはいくらなんでも非現実的。

SmartLife Airを使う方法

実は,この記事を書こうと考えたもともとのきっかけはnode-red-contrib-smartlifeairというカスタムノードの存在に気づいたこと。そこからさらに調べて上のカスタムノードの存在に気づき,そちらの方がいい選択肢に思えたのでそちらで進めてみようとしたのだが,それが駄目なのならこちらを試してみる。

この方法ではTuyaのOEM機器やサービスを再販していると思われるニュージーランドの会社の提供するSmart Life AirというサービスにTuya機器を再登録する必要があった。

念のためTuya自身によるSmart Lifeアプリからスマートプラグの登録を削除し,SmartLife Airアプリに再登録。おそらくはSmart Lifeアプリをベースに作られているだろうから当然だが,やはりパーミッションの許可を求める画面が出なかった。おそらくはそれが出ればAPのSSIDの入力を省けたのだろうが,手入力でクリア。

node-red-contrib-smartlifeairカスタムノードの説明では,SmartLife Airアプリでアカウント作成・機器登録をしたのち,SmartLife Airのサイトでアカウントを作成し,そこで双方のアカウントをリンクさせる,という手順を指示している。自分は先にSmartLife Airのサイトでアカウントを作成し,次にSmartLife Airアプリで同じメールアドレスでアカウントを作成しようとした。そうすると,このアドレスでは既にアカウントがあるのでログインするか,と問われ了承すると,ログイン画面に遷移。正しいパスワードを何度入力しても,「メールアドレスが正しくないか,パスワードが誤っている」と言われる。「パスワードを忘れた」リンクをたどると,パスワードが「再設定」でき,アプリのアカウントが作成できたようでログインできた。

SmartLife Airのサイトは何をするものかよくわからない。以下にログインした状態の画面を示す。”Set & Refresh Account Details” ボタンを押すと右に登録済みの機器が表示される。ちなみに,node-red-contrib-smartlifeairカスタムノードの指示に従って,米国サーバに登録したはずなのに,このボタンを押すとなぜかカナダのサーバに登録してあるかのような表示がなされる。

Node-red-contrib-smartlifeairカスタムノードを使う

Node-red-contrib-smartlifeairは “Device-Node” というノード一種しか提供しない。そのプロパティーは以下。そのスクリーンショットには含まれていないが,この上部にSmartLife Airにログインするための情報を入力するところがある。

アウトプットとして “All Output Channels as JSON” を選択して得られた出力を末尾に掲載する

ドキュメントに “Please change a status before you select the device, Backend has to receive at least one update in order to pop up in the list.” とあるのでそうする。

Sonoff機器を操作するためのカスタムノードは達成したいことに応じて複数種類のノードが用意されており,見通しが良かった。それに比べるとノードが1種類しか用意しておらず不親切な印象。Sonoff機器を操作するためのカスタムノードでは状態変化の通知を受けるためのノードEvent Listenerが用意されているのだが,それに相当するものはパッと見あたらないため,ポーリングしないと状態検知は検出できないのかと思ったが,その唯一のDevice-Nodeで状態変化通知によるイベント駆動が実現できるとわかってホッとした。いずれにせよ,状態変化の通知を受けるのも,状態を変化させるのも,同じノードで行うというのは親切設計とはいえない。

LEDの状態検知,およびその点灯・消灯はMQTTからできるようになった。しかし肝心の電源の入り・切りについては,そのDevice-Nodeで入力はとして電源入り切りを操作できる選択肢が出てこない…。なんでだよ…。

とりあえず作者に問い合わせて様子見することにする。その他,Node-RED Forumにも’smartlifeair’に関するスレッドがわずかながらある

作者から返事があり,それはこのスマートプラグでは本質的に提供されてない機能とのこと。ただ,回避策のヒントをもらいそれが実際うまく行った

”All Output Channels as JSON” による出力

{"bright_value":180,
 "colour_data":"{\"h\":136.0,\"s\":255.0,\"v\":62.0}",
 "countdown":0,
 "flash_scene_1":"{\"bright\":255,\"frequency\":80,\"hsv\":[{\"h\":120.0,\"s\":255.0,\"v\":255.0}],\"temperature\":255}",
 "flash_scene_2":"{\"bright\":255,\"frequency\":128,\"hsv\":[{\"h\":0.0,\"s\":255.0,\"v\":255.0},{\"h\":120.0,\"s\":255.0,\"v\":255.0},{\"h\":240.0,\"s\":255.0,\"v\":255.0},{\"h\":0.0,\"s\":0.0,\"v\":0.0},{\"h\":0.0,\"s\":0.0,\"v\":0.0},{\"h\":0.0,\"s\":0.0,\"v\":0.0}],\"temperature\":255}",
 "flash_scene_3":"{\"bright\":255,\"frequency\":80,\"hsv\":[{\"h\":0.0,\"s\":255.0,\"v\":255.0}],\"temperature\":255}",
 "flash_scene_4":"{\"bright\":255,\"frequency\":5,\"hsv\":[{\"h\":0.0,\"s\":255.0,\"v\":255.0},{\"h\":120.0,\"s\":255.0,\"v\":255.0},{\"h\":60.0,\"s\":255.0,\"v\":255.0},{\"h\":300.0,\"s\":255.0,\"v\":255.0},{\"h\":240.0,\"s\":255.0,\"v\":255.0},{\"h\":0.0,\"s\":0.0,\"v\":0.0}],\"temperature\":255}",
 "power":false,
 "scene_data":"{\"h\":0.0,\"s\":0.0,\"v\":0.0}",
 "switch_led":false,
 "temp_value":255,
 "work_mode":"colour"}

 

TuyaがOEM提供する日本向けスマートプラグ

「スマート」なコンセントやテーブルタップ” で検討した上で,日本の2芯規格に対応したLonsonho Japan Wifi Smart Plug Smart Socket with Scene Light Tuya Smart Life APP Works With Alexa Google Homeはを7/19に1,191円(送料無料)で購入した。

TuyaのOEM製品を選択した理由

過去の記事の内容ともかぶるが,Tuya製品を選んだ理由は以下の3つだった。

最初の感想

  • なしのものと値段が変わらなかったのでLEDつきのものを選んだ。通電状態であればLEDが点灯するように連動させる,といったことは可能だろうが,それには少し大げさな気がする。今ひとつ有効な使い方が思いつかない(通電状態と独立の使用方法もあり)。
  • テーブルタップのようにコンセントが並んでいるものに挿して使う場合,この丸形の形状は隣接するコンセントの使用を妨げる可能性がある。例えばこの製品のように,長方形になっているものの方がそういう問題を回避できる可能性が高い。

スマホアプリ

Tuya SmartアプリとSmart Lifeアプリ “Smart Life APP VS Tuya Smart APP! What is the differance? – YouTube” によれば後者だけがIFTTT連携をサポートしている。Smart LifeアプリはOEM製品での使用が想定されているのでは?

公式ドキュメント “User Guide for Tuya Smart V3.18.1-Tuya Developer

デバイスを追加するところで,「wifiでスキャンできるよう,位置情報へのアクセスを許可するように」というメッセージが出るのだが,実際それを求めるプロンプトがアプリからなかなか表示されなかった。なんの拍子かそれが表示され,それを許諾し,EZモードで登録をすすめるとできた。

Smart Life App – A Comprehensive Guide” には以下のような記載があった。なぜか最新版からはこの部分が消えている。

…you can try out Brilliant, which is similar to SmartLife and accepts all SmartLife-compatible products as well. However, that does mean you may have to disconnect all of your current smart products and reconnect them to another application.

Same password on Smart Life and Brilliant causing strange occurrence. : smartlife

Sonoff MICRO USBスマートアダプタをMQTT経由で操作できるように

Sonoff Micro USBスマートアダプタを買った。もともとは,IFTTTと連携させるつもりをしていたが,IFTTTの方が実質有料化したため,メリットが大きく損なわれてしまった。せっかくNode-REDをインターネット上で使えるようしたことだし,Node-REDでなんとかならないかと考えた。結果としては,MQTT経由で操作できるようになった。

Node-REDのライブラリで “Sonoff” で検索してみるといくつかヒットする。 が,Tasmotaをフラッシュしていることをベースにしているものは使えない。というか,MicroはESP32/ESP8266を採用していないので,それ用Tasmota等用ファームウェアはフラッシュできない。

さらに,node-red-contrib-sonoff-server (node) はベースになっているsimple-sonoff-server.がもう使えなくなっているということで使えない。

結局使えるのはnode-red-contrib-ewelink (node)のみ。node-red-contrib-ewelink – NodeRED nodes for eWeLink smart devicesがホームページ。skydiver/ewelink-api: eWeLink API for JavaScriptドキュメント)をベースにしているらしい。

ドキュメントは決して親切とは言えないが,いくらかの試行錯誤で以下が実現できた。

  • Microの状態(通電状態,非通電状態)が変わるたび,それをMQTTブローカ(具体的にはBeebotte)上の特定トピックの値としてパブリッシュ。
  • MQTTブローカ上の特定トピックをコマンドとして捉え,それの値(”turn_on” と “turn_off”)がパブリッシュされるたび,それに応じてMicroの通電状態を変更する。

これにより,Microの操作がMQTTを介してできるようになる。以下はそのフローのNode-RED上での様。

ドキュメント中にこれに関する記述は一切なかったと思うが,フロー中にeWeLinkをアクセスするノードを複数同時には使用できない模様ー普通にやると。「そのようなリージョンが存在しない」とか「認証エラー」とかいうエラーメッセージが出るが,それを真に受けていると多分解決策に到達できない。

eWeLinkをアクセスするノードそれぞれには,予めスマホアプリeWeLinkで作成したアカウントの情報を与えなければならない。アカウントの情報とは,具体的にはユーザ名(メールアドレス),パスワード,使用するeWeLinkサーバの地域,の3種のデータの組。これをセットで扱い,名前も自動的に振られる。どうせ中身は同じなのだから,と全てのノードに同じセットを指定すると先のような問題が起こる。

解決策は,そのセットを,使いたいeWeLinkノードの数だけ用意すれば良い。中身は全く同じで構わないのだが,セットとしては別扱いになっていて,別の名前が振られていればいい。このように設定したeWeLinkノードを運用しているとき,おそらくeWeLinkサーバから見ると,同じアカウント情報を使用してアクセスしてくるクライアントが複数あるように見える状態なのだろう。

また, “Sonoff Micro has a secret! – YouTube” でも言ってたことでもあるが,Event Listnerノードの出力(下のリスト)を見るとチャネルが4本用意されていたようだ。そのうち実際の通電状態に対応しているのは最初のもの。 “0” 番だとされているのだが,このチャネルを操作して通電状態を変更するためのPower State出力ノードでは “1” と設定しなくてはならなかった。

{"action":"update","deviceid":"XXX...","apikey":"XXX...","userAgent":"device","d_seq":1957890180,"ts":0,
 "params":{
   "switches":[{"switch":"on", "outlet":0},
               {"switch":"off","outlet":1},
               {"switch":"off","outlet":2},
               {"switch":"off","outlet":3}]},
 "from":"device","seq":"1957890180"}