政府統計を機械判読可能にするために提言した

政府統計を機械判読可能にするための意見を募集していたので提言した。といっても別にたいそうなことは何もなく,知ってる人であれば誰でも考えることに過ぎないので,同様の趣旨の提言をしている人は他にもたくさんいるだろう。たまたま,最近RDFについて調べていたので,ま,ついでに。

以下に応じた。

内容は以下。横線は送信した後気づいた基本的な誤り。


[自己紹介は削除]「日ごろ、e-Statをご利用いただいている利用者」には当たりませんし,決して統計データ処理の専門家でもありませんが,意見を述べさせてください。

統計データでは,例えばあるデータセット内の「東京」と,他のデータセット内の「東京」が同じ東京都を指しているかは文脈によります。場合によっては,「東京」という名前の料理屋を指すのかも知れません。

こういった曖昧さを省き厳密に定義しようとする試みの一つがResource Description Framework (RDF)です。知識表現のために考え出された枠組みです。
https://en.wikipedia.org/wiki/Resource_Description_Framework

一般には知られていませんが,例えばWikipediaに蓄えられている事実を可能な限りRDFで表現したデータベースがあり,Googleで例えば「東京」をキーワードに検索したときに,右枠に表示されるサマリーはこのデータベースを利用して生成されているそうです。

多種類のデータセットがある際,RDFで各項目が厳密に定義されていれば,それらを組み合わせた複合的解析が楽になり促進されます。厳密な定義がなければ,必ず人がデータの意味を解釈し,例えば別データセット内の「東京」が実際同じものを指しているか検証する,などのステップが必要になりますがこれが必要なくなります。

RDFによる記述は厳密である分極めて煩雑で,敷居が高いことは否めません。しかし,政府で生成する統計表は各省庁・部局を跨いで被るところも項目も多いであろうことと,また,同じ部署であれば同種の統計を継続的に作成するであろうことを考えると,最初に包括的にこれの道具立てを済ませてしまうことは有意義な投資になると思われます。特に,同じ統計を毎年作成するような場合は,一旦雛形ができてしまえば,後は数字を入れ替えるだけになりますから,事務職員の大きな負担にもならないと思われます。

以上よろしくご検討ください。

Functional Reactive Programming

Functional Reactive Programming, or FRP is very hard for me to understand, as if functional programming itself was not hard enough. This concept is supposed to have been popularized by Conal Elliott. I tried to read what is supposed to be his seminal paper (“Genuinely Functional User Interfaces“), but it went straight over my head. He also gives an answer to a question on StackOverflow, “terminology – What is (functional) reactive programming? – Stack Overflow,” which is a bit approachable.

Elm, a functional programming language for Web apps (Wikipedia), parted ways with FRP.

Cellx, which bills itself as “the ultra-fast implementation of reactivity for Javascript” is a whole lot easier to understand. “Building a Reactive App using Cellx and React | 60devs” But I can see it is reactive, but I don’t think it is functional.

Speaking of FRP and Javascript, RxJS – Introduction Cycle.js

Gun, “the database for freedom fighters” (often stylized “GUN” in official documents, but I will write “Gun” instead because I have not seen any proof or even indication that the word is an acronym) claims to support FRP because it supports “a code structure that emphasizes vertical readability by avoiding nested loops and callbacks.” Does this meet the requirement of FRP? It seems to mean that it only supports operator (function) chaining and I do not think that alone means it supports FRP.

CouchDB-Related Products

IBM Cloudant, a CouchDB hosting service, possibly one of the very few remaining of the kind.

Barrel, formally known as RCouch, seems to add P2P and local data to CouchDB, but I cannot find any comprehensive documentation. I am not sure if it has been updated recently.

PouchDB, the JavaScript Database that Syncs! reimplements a lot of CouchDB functionality in JavaScript and syncs to CouchDB-compatible servers.

RxDB, a “realtime database for JavaScript applications” can use a PouchDB backend and sync to CouchDB-compatible servers. Actually, my impression is that this was made on top of PouchDB to add schema capabilities based on JSON Schema. The claim that it is “realtime” is a stretch; what it means is that queries are not one-off and can continue to emit events as data changes, which is conducive to reactive programming for the front-end. This reactivity comes from RxJS.

What is particularly of note about RxDB is that it has the leader-election mechanism. When you have multiple tabs on the same browser all of which communicate with a same remote CouchDB instance, their communication can be redundant if they are natively implemented. The leader-election mechanism can have just one RxDB communicate and remove redundancy. I do not think PouchDB has an equivalent facility.

Hoodie is a hosted frontend development service which provides the bakend via combination of CouchDB and PouchDB.

タッチパッドつき携帯用Bluetoothキーボード

最終的には入手しないとは思うのだが調べてしまったので。

タッチパッドだけでなくそれ用のボタンもあるものというと,iCleverの折りたたみキーボードIC-BK08しか見当たらない。定価で5,500円ほど。クーポンを利用しても4,500円ほどで決して安くない。違う製品名で売られてるのもあるが安いどころかむしろ高い。これ相当の製品はAliExpressでもeBayでも見当たらない。ちょっと気になるのは以下:

回答: マニュアルによると、AndroidとWindowsに関しては2本指タップすると右クリック機能が本来の仕様です。iOS/iPad OSに関しては文字入力が快適なので私は気にしていません。
投稿者: 1968@51、投稿日: 2020/04/28

似たような製品でタッチパッド用ボタンを諦めるのなら3,000円ほどこれと同じものは “B033” という型番でAliExpressで多数売られているので,そこから安いのを選べば2,500円ほど。国内販売でも頑張って探せばこれよりさほど高くないお値段で入手できよう。

ボタンもあるタッチパッド付属のものがいいと考えたのは,かつてWindows 10が走るタブレットとBluetoothキーボードを併用した経験から。タッチパッドがないと非常に不便で,あとでマウスを追加することになった。今想定しているのは外出先で,スマホにぱっと少~中量の文字入力をするというシナリオなので,実はボタンはさほど重要ではないかもしれない。

携帯のため折り畳めることを諦めるものの,タッチパッド用ボタンを諦めないから,サンワダイレクトのBluetoothキーボード(タッチパッド・コンパクト・充電式・iPhone・iPad・アイソレーション・パンタグラフ・マルチペアリング・英字配列) 400-SKB066定価通りの4,980円で売られている。折り畳めないと持ち運び時にキー面を保護する工夫が必要になるだろう。というか長さが40cmほどあるのでやはり持ち運びには向いてないか。以下にレビュー:

Logicool Wireless Touch Keyboard K400 Plusも同様の商品かと思われたが,BluetoothではなくUnifying接続だった。

折りたたみできずタッチパッドのみ付属(ボタンはなし),というのがある。タッチパッド部がモード切替でテンキーとして使えるようで,そこはユニーク。が評価は悪い。

English Keyboard Rii mini K12+/i12+ Wireless Keyboard and K12+ Bluetooth Keyboard with Touchpadは単にタッチパッドが付属したもの。

What I Wish They Had Told Me about GraphQL

It took me a long time to understand the benefits of GraphQL. The official website summarizes it on the front page as:

A query language for your API

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.

I had a really hard time trying to understand what this means.

I had to read the following articles to get a better sense of GraphQL:

GraphQL as I See it

The fundamental assumption is that there already exists usable data from the beginning. Let’s call it “the original data.” GraphQL comes into the picture to add another layer with regards to the access to this data, which increases its utility. Potential benefits include: i) precise definition of the accessible data; ii) querying capabilities that yield just the data you ask for and nothing else; and iii) improved performance. The last claim can be true only in specific circumstances, which we will look at later.

One crude analogy could be made here, and that is that GraphQL is like SQL in that it provides data definition and querying, except that GraphQL is only added as an afterthought to a database that is already operational.

There is not any particular restriction or assumption on the means of data fetching between the GraphQL layer and the original data. The original data can reside in local files, local databases, or remote databases — or it can even be simple variables in the GraphQL implementation language (there are many).

Two Parties Involved in Use of GraphQL

The following two parties are involved in the introduction and use of GraphQL to the original data: the GraphQL Manager and the GraphQL User (my own terms, not the GraphQL developers’). Their roles are as follows:

The GraphQL Manager:

  • Defines type-wise structure of the data available for querying, in a schema-like fashion; this will be visible to the GraphQL User by introspection
  • Implements the methods to access the data, in the form of “resolvers”; this will not be visible to the GraphQL User

The GraphQL User:

  • Queries the data within the bounds of the GraphQL query format defined by the GraphQL Manager

Note the GraphQL Manager by himself is not responsible for managing the original data. Even though he “defines” the structure of the data available through the GraphQL interface, this definition does not determine how the original data is actually stored and managed. Rather, he defines what of the original data he wants to be exposed through the GraphQL interface.

Where GraphQL Is Inserted

In the typical scenario where a server holds data and clients request it, GraphQL is usually added on the server’s side, so the server can provide a better interface with querying capabilities to its clients. This seems what is usually assumed in the documents on GraphQL that I have read.

I do not think this has to be the only way, however. You could use GraphQL in a bridge to it. Or you could even use it on the client’s side. As long as the GraphQL Manager can implement the resolvers that fit in the given scenario, you should be able to enjoy the benefits of GraphQL.

Increased Performance?

One of the purported benefits of GraphQL is increased performance. However, you have to note it applies only in the context where GraphQL is used to implement a Web API, and its performance is compared to that of a strict REST API (not a Web API in general), and also only when the GraphQL Manager carefully implemented the relevant resolvers in a performant way.

Generally speaking, increased performance is not inherent in GraphQL by itself, despite the impression that the documents on GraphQL might give you; it does not “come for free” just by using GraphQL alone. On the contrary, a naïve implementation of resolvers by the GraphQL Manager is likely to give you pretty bad performance.

The following resources helped me understand this issue:

Performance becomes an issue when the nested objects are allowed to be requested and are indeed requested. Let’s say you want a list of movies that match a certain criteria (say, older than 20 years), with the list of performers for each such movie. Nested objects will be returned to such a query, which are a list of movie data, with a list of performers for each movie. In the relational database terminology, there is either a one-to-many or many-to-many relation between the Movie entity and the Performer entity.

If this query is to be executed against a database server with a REST API, there will be N+1 sub-queries.

  • One query is sent to the /api/movies endpoint, for example, to get the list of N movies
  • One query is sent to the /api/performer/id endpoint for each performer who appeared in each of the N movies above

If the API is implemented in the strict sense of REST, then this is inevitable by its very definition. This is exactly what the REST architecture prescribes. In contrast, there is no such limitation to implementing a GraphQL-based Web API, so you can just provide one endpoint for handling all the GraphQL queries.

In GraphQL, a resolver is implemented for each field of an object type. In the scenario above, if resolvers for [Movie] and Performer(id) are implemented naively, then the there will also be N+1 resolver function invocations and the performance will be just as bad. However, unlike with the REST API whose architectural design decisions make this inescapable, there is room for performance tuning for GraphQL.

I do not know what kind of performance tuning methods are there, but memoization is definitely one of them. But more importantly, since this is such a common occurrence with GraphQL, there are already libraries to mitigate the situation. These include DataLoader (originally from Facebook, just like GraphQL is) and Apollo Data sources (see “ReactとApolloを使ってGithub GraphQL APIを試してみる – Qiita,” “世のフロントエンドエンジニアにApollo Clientを布教したい – Qiita” ). I have not looked into these so I do not know what exactly they do.

Addendum: Apparently I was not the only one to feel odd about that recommended design pattern not being automated. gajus/graphql-lazyloader: GraphQL directive that adds Object-level data resolvers addresses it. Also, “Moving OkCupid from REST to GraphQL” seems interesting.

For application development with React (also from Facebook), there is Relay — the production-ready GraphQL client for React.. A Japanese document explains using Relay with React and GraphQL. It deals with pagination and a similar discussion can be found in “Pagination | GraphQL.”

My Small Grievance about GraphQL’s Notation

In GraphQL’s schema definition, you can define object types and query types, among other things. An object type can have multiple fields (or “slots” in the Lisp nomenclature), and it means the said type is an aggregate of those fields. A query type definition seems to follow exactly the same format with an object type definition except the “query” and “type” keywords. However, the included fields of a query type do not constitute just one pattern of query as a whole.

Take the following query type for example (taken from “Schema basics – Apollo Server – Apollo GraphQL Docs” ):

type Query {
  books: [Book]
  authors: [Author]
}

This query type definition does not mandate that every query be always one for a list of books and a list of authors at the same time. Rather, it means you can query for a list of books or a list of authors, or both. This goes contrary to the naïve aggregate assumption you might get from object type definitions — I certainly did! I do not think this was explained this way in any of the resources I referenced. It took me a long while to realize this.

Each field of a query type definition is an entry point of query, for which the GraphQL Manager has to provide a resolver, as we saw earlier.

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点無理矢理選んで入れてみた。