有線LANにノイズが乗ってインターネットが切断される話。
Power Platform とは全然関係のない話。
タイトルで答え書いちゃってる話だけど、せっかくなので記録しきます。
ここ最近、自宅のインターネットがぶつぶつ切れまくってて、家族からクレームの嵐だったのです。
YouTube観れない!
Apex切断される!
1. 原因調査開始
ルータがダメになったか?と思いながら取り急ぎルータのログを取得して原因分析。
でもね、自分ネットワーク屋さんじゃないのでルータのログとか見ても全然わからんわけなんです。
と言いつつ、気になる以下のログを見つける。
cannot get public IP address, stopping
パブリックIPアドレスを取得できないから停止しました!?
何故そのようなことを申すか、このルータは。今までうまく仕事してくれてたじゃないの。
直前で変なログ出てないかなーと調べてみるものの、特段変なエラーとかNGっぽいようなキーワードは見つからない。
どうやって調べるか。。。
2. エラーの仮定してみる
取り急ぎ、「cannot get public IP address, stopping」のキーワードでインターネット上に何かヒントがないかを調べ、以下のサイトにたどり着く。
nekozukiojisan.blog.fc2.com
色々想定される原因が記載されているものの、結局今回のどれも当てはまらず。
IPv6も無効化してみるが効果なし。
設定周りじゃない。
無線LANがおかしいわけでもない。(ルータからの有線LANも切れる)
。。。
もう一度ログを見返してみると以下が出力されていたことに気づく。
Link Status Changed - Port0 Link Down
単純に、Port0 のリンクがダウンしたよーってメッセージなんだけど、Port0ってなんじゃ?と疑問に思うわけ。
なんでPort0が切れるの?
Port0ってどのポート?
多分このポート(終端装置とつながっているWAN側のポート)
3. ネットワークの構成を変更していた件
思い返してみると、直近でネットワークの構成を変更していたんだと思いだす。
構成って言ってもそんな大それたことではなくて、ルータの位置を変えただけ。
何故位置を変えたのかというと、話が長くなる・・・が簡単に説明すると
- 初代ルータの調子が悪くなる
- 偶然にもルータのおさがりを頂く
- 新ルータに置き換える
- 2Fや反対側の部屋まで電波が届かなくなる ← ここまではインターネット接続そのものは問題なし
- ルータの場所を変更する ← 今回の事象発生
そもそも、初代ルータはイーサネットコンバーターセットの無線ルータで、当時はフラッグシップぐらいの無線ルータじゃないかなと思われる製品。家中どこでも快適にネット接続できてたわけです。
それを、「3.」の置き換えで無線電波が届かなくなっちゃったわけ。
もともとルータの場所が1Fの端の方で、家中に電波を飛ばしにくい設置個所がいけないなと思い、できるだけ家の中心に近づけれるようにルータを移動しちゃったんです。(5.)
4. 原因は長いスリムLANケーブルと敷設場所によるノイズ(たぶん)
終端装置の場所は変えられないので、長いLANケーブルを使って、家の中心に近づけるようにルータを設置したんだけど、この時のLANケーブルの敷設した場所が悪かったみたい。
敷設の際、テレビの裏側を通さなくちゃいけないのだけど、テレビの裏は電源や各種ケーブルによってノイズが大量発生している箇所を通しちゃったわけです。
最初は、LANケーブルが古いから断線か?と思ったんだけど、取り急ぎテレビの裏から離れるよう敷設(と言ってもテレビの前を通しただけ。超絶邪魔)してみて今日一日様子見。。。
見事インターネット切断事象は発生しませんでした。
調べてみると、長いLANケーブルやスリムタイプのケーブルは断線しやすいうえ、ノイズも乗りやすいとのこと。
いつ買ったかわからないケーブルだし、こいつが超絶長いケーブル(多分20m??)なうえ、スリムタイプであるため、おそらくノイズ対策のシールドなどもないと思われる。
LANケーブルなら無線のように切断されることもないし、しっかり接続してくれているだろうという先入観に捕らわれてしまっていました。
無線ルータもあんまり良い品じゃないし、ケチらずちゃんとしたものを買うべきかなぁ😅
お金があるならメッシュWi-Fiを構成してみたい今日この頃でした。
Power Apps が Azure のサブスクリプションを利用して従量課金が可能になった!
今回プレビューで公開された内容が、本来月額で課金しているユーザでしか利用できないアプリを、Azure サブスクリプションを利用して従量課金で利用できるようになったという内容。
詳細は以下の吉田さんのブログを参照されたし
Power Apps をより手軽に - Azure サブスクリプションから Power Apps の従量課金が可能に - Taiki's Memorandum (tyoshida.me)
これって使い方によってはすごくリーズナブルになるよね?
ちょっとお試しで(有償ライセンスが必要な)アプリ作って展開したいけど、アプリを利用するためにはライセンス契約しなきゃいけなくて~って時に、対象の環境を Azure のサブスクリプションに紐づけちゃえば、使ったアプリ数×人×月単位で課金されるので気軽に展開できちゃう。
一通り Docs 読んできたけど、がっつり毎月アプリを利用するなら従量課金よりも毎月契約していた方が良い感じ(そりゃそうだ)
あと、ログ使用量の課金については、環境を従量課金対象にしてたら速攻で課金されるようなので、そこについては注意が必要。監査ログをオフにするなどの対応が必要そうです。
これなら気軽にお試しできて、軽い気持ちで提案ができそう!使わなくなったら環境削除しちゃえばいいだけだもんね。
以下、Docsを機械翻訳で日本語にしてみた結果です。
注:2021/11/3時点のドキュメントです
転載元ののURLはこちら:Preview: Pay-as-you-go meters - Power Platform | Microsoft Docs
プレビュー: 従量課金制メーター
この資料はプレリリースドキュメントであり、変更される可能性があります。
従量制を利用している場合、アプリの使用量と、含まれる金額を超える Dataverse または Power Platform リクエストの使用量は、Azure メーターを使用して Azure サブスクリプションに対して請求されます。アプリごとの Power Apps メーターは、アプリの使用量を測定します。Dataverse capacity add-onメーターは、データベース、ファイル、およびログ全体のDataverseの使用量を測定します。Power Platform requests capacity add-on meter は、API コールを測定します。環境をAzureサブスクリプションにリンクするとすぐに、3つのメーターが自動的に有効になります。
メーターはどのように機能しますか?
メーター |
何がカウントされますか? |
請求対象の料金は何ですか? |
Power Apps per app |
従量制環境における各アプリやポータルのユニークな月間アクティブユーザー数の合計。 アクティブユーザーとは、指定された月に少なくとも一度はアプリ/ポータルを開いた人のことです。 ユーザーによるアプリ/ポータルの繰り返しのアクセスはカウントされません。Power Apps のユーザーごとのライセンスを持つユーザーはカウントされません。 |
$10/アクティブユーザー/アプリ/月 |
Dataverse |
データベース ストレージの場合、従量課金制環境あたり 1 GB を超える使用。 |
データベースで1GB以上ご利用の場合:48ドル/GB/月 ファイルの使用量が1GBを超える場合 2.40ドル/GB/月 ログの使用量が多い場合 12ドル/GB/月 |
Power Platform requests |
従量課金制の環境では、各ユーザーはライセンスに基づいて Power Platform のリクエストを毎日受けることができます。 1アプリメーターあたりのPower Appsでは、1ユーザー/1アプリ/1日あたり6000回のAPIコールを受けることができます。 これは、ほとんどのお客様にとって十分なものですが、大規模なシナリオをお持ちのお客様にとっては、この権利を超えて必要なPower Platformリクエストがカウントされます。 |
0.00004$/リクエスト/日(1日あたりの制限値を超える場合 |
価格の詳細については、「Power Apps の価格」を参照してください。
注意
パブリックプレビュー(2021年11月1日)の時点では、環境をAzureサブスクリプションにリンクしても、Power Platformのリクエストメーターは報告されず、請求もされません。環境内のユーザーやフローは、スロットルされたり、超過料金を支払ったりすることなく、権利のある使用量を超えて消費することができます。報告と請求は、パブリックプレビューの発表後、数週間でオンになる予定です。
アプリメーターあたりのPower Platform
アプリごとのPower Appsメーターでは、ユーザーはPower Appsのライセンスを持っていなくても、あらゆる種類のアプリを使用することができます。アプリごとのPower Appsメーターでは、キャンバスアプリとモデルドリブンアプリの両方にアクセスでき、認証されたユーザーにはポータルが提供されます。
アプリごとの Power Apps メーターは、1 ヶ月の間に環境内で 1 回以上アプリやポータルを開いたユニークユーザーの数を測定します。何人のユーザーがアプリにアクセスしたかに関わらず、月にアプリを開いたユニークユーザーに対してのみ課金されます。例えば、100人のユーザーがアプリにアクセスしていても、月に10人のユーザーしかアプリを使用しなかった場合、その10人のユーザーに対してのみ課金されます。ユーザーは月内に何度も同じアプリにアクセスしても、そのアプリの月間アクティブユーザーは1人としかカウントされません。ただし、ユーザーが複数のアプリを運営している場合は、その月に運営している各アプリの月間アクティブユーザーとしてカウントされます。
例えば、ある環境にアプリA,B,Cの3つのアプリがあり、この環境が従量制に対応したとします。
注意
この例で示されている価格は、例示的なものです。お客様の組織の価格は、マイクロソフトとの契約に基づいて異なる場合があります。
3つのアプリを使用した環境
Dataverse容量計算
データバース・キャパシティ・メーター
環境が従量制環境(Azureサブスクリプションにリンクされている環境)になると、テナント全体のDataverseストレージプールからストレージを消費しなくなります。代わりに、その消費はAzureに請求されます。従量制の環境では、最初の1GBのDataverseデータベースストレージと最初の1GBのDataverseファイルストレージの容量は、Azureに請求されません。ただし、ログストレージの容量は直ちにAzureに請求されます。ログストレージの容量は、環境の監査をオンにする場合にのみ使用されることに注意してください。
Dataverseのストレージ使用量の各カテゴリの測定は、1日3回(1ヶ月に90回)、08:00 UTC、16:00 UTC、00:00 UTCに行われます。この8時間のスナップショットの使用量に1/90を乗じて、測定期間中のストレージの端数使用量を算出します。この端数の使用量は、GBあたりの月額料金に乗じられ、Azureコスト管理に表示されます。合計金額は、お客様のAzureの請求サイクルに基づいて合計され、請求されます。
注意
この例で示す価格は、例示的なだけです。組織の価格は、Microsoft との契約によって異なる場合があります。
Power Platform要求メーター(近日公開予定)
注意
パブリックプレビュー(2021年11月1日)の時点では、環境をAzureサブスクリプションにリンクしても、このメーターは報告されず、請求もされません。環境内のユーザーやフローは、スロットルされたり、超過料金を支払ったりすることなく、権利のある使用量以上を消費することができます。報告と請求は、パブリックプレビューの発表後、数週間でオンになる予定です。
各Power Platformライセンスには、ほとんどのお客様とシナリオに十分なPower Platformリクエストの大きなエンタイトルメントが含まれています。これらの権利を超える必要のある非常に大規模なシナリオをお持ちのお客様は、Power Platformリクエストメーターを使用することで、スロットルを使用せずに拡張することができ、権利を超えて使用されたPower Platformリクエストの料金のみを支払うことができます。
Power Platform リクエストと各 Power Platform ライセンスに含まれるエンタイトルメントの詳細については、「リクエストの制限と割り当て」を参照してください。
Power Platform リクエストのエンタイトルメントは、日単位のエンタイトルメント (リクエスト/日) として構成されています。従量制の環境 (Azure サブスクリプションにリンクされている環境を意味します) では、1 日のエンタイトルメントを超えたユーザーやフローは、Azure サブスクリプションに請求されます。従量制の環境で、Power Apps をアプリメーターごとに使用した場合、6000 API コール/ユーザー/アプリ/日の権限が与えられます。なお、フローの場合も、ベースとなるライセンス (Power Automate per user、Power Automate per flow、Office のいずれか) が必要です。
以下の例では、ユーザーAにはユーザーごとのPower Appsライセンスが、フローAにはフローごとのPower Automateライセンスが適用されています。ユーザーAとフローBで消費されたPower Platformのリクエスト数は毎日計測され、1日のエンタイトルメントを超えた使用量は、$/リクエストレートが乗じられ、Azure Cost Managementに表示されます。合計金額は、お客様のAzureの請求サイクルに基づいて合計され、請求されます。
注意
この例で示す価格は、例示的なだけです。組織の価格は、Microsoft との契約によって異なる場合があります。
SharePoint Online のドキュメントに保存した JSON ファイルを Power BI からデータ取得する
Fitbit で記録した体重や歩数情報は毎日 Power Automate で取得して Twitter で公開してるが、もうかれこれ2年ぐらいアップデートかけてないような気がするので、そろそろ Power BI でレポート作って公開したいなと思った次第。
Power Automate で Fitbit の API を叩いてデータ取得するのはお手の物。 でもこれをカスタムリストや Dataverse にレコードとして格納するのはなーんか違うような気がする。
データは Fitbit 側にあるんだから、わざわざ自前でデータベースを準備せず、API から取得した最新情報をファイル(JSON)に保存しちゃって、毎回 Power BI 側を更新しちゃえばええやんと思ったわけ。
しかし、これがうまくいかない。。
JSON を格納したファイルを Power Query で読むわけだけど、どうやっても 読み込んだ JSON ファイルを展開できなくて1日ぐらいうだうだやっていたが、ようやく解析する手順がわかったので、ここにまとめておくとする。
まずはお決まりの「データを取得」
今回は SharePoint Online のフォルダにファイルを格納しているので、「SharePoint フォルダー」を選択する
ファイルを格納しているサイト URL を選択する。※フォルダーパスまで入れちゃダメ。
「データの変換」を選択
ファイルの一覧が読み込まれるので、対象ファイルの「Binary」を変換する。
対象のファイルがインポートされるので、「テーブルへの変換」を変換する。
テーブルに変換されるので、「Value」項目の右側にある小さいアイコンを選択する。
メニューが表示されるので「新しい行に展開する」を選択する。(このやり方がわからなかった・・・)
展開する項目を選択できるので、必要な項目にチェックを入れる。
展開完了!
手順化したらめっちゃ簡単な操作なんだけど、なんでこのやり方にすぐ気づかなかったんだろう。これから JSON 展開しまくるので、忘れないうちに記録しておきます☺
Echo で再生した曲を Power BI でレポートしてみる② ~Apple Music API をつかって曲のメタデータも合わせて取得~
だいぶ時間が経ってしまったけど、以前自分が作成した記事、「初めての Power BI ~Echo で再生した曲をレポートしてみる~」 をバージョンアップしたので久しぶりにブログにまとめてみたいと思う。
レポートもある程度見栄えが良くなったし、ドリルダウンや関連フィルターもできて面白い感じになってきた。
けど、何かが足りない・・・。そう、このレポートて、基本的に「再生した日時」「曲名」「アーティスト」しかない。
echo で再生した曲を取得する際に、Alexa アプリを作らずに IFTTT を使って簡単に Webhook する仕組みからスタートしてるもんだから、上記の属性しか取れなかったりするわけ。
本来であれば、ジャンルや発売日、CD のジャケットなど再生した曲のメタデータを取得・記録したいんだけど、IFTTT で取得したデータだけだとその願いは叶いません。
(さっきのスクショはジャケット取得してしまってるけど)
そこで考えたのは、Apple Music API を使った曲のメタデータ取得。
当初のフローの流れは以下の通り。
- IFTTT で再生された曲を取得し、Webhook でPower Automate につなぐ
- Power Automate (Webhook) で曲名、アーティスト名、アルバム情報を受け取る
- SharePoint のカスタムリストに上記の情報を書き込む
これを以下のように変更しました。
- IFTTT で再生された曲を取得し、Webhook でPower Automate につなぐ
- Power Automate (Webhook) で曲名、アーティスト名、アルバム情報を受け取る
- Apple Music API に対して HTTP リクエストを投げる
- SharePoint のカスタムリストに IFTTT から受けっとった情報と Apple Music API から取得した情報を書き込む
① Power Automate のフロー全容は以下の通り。
② 再生した曲リストは以下のような感じになる。
③ 曲のメタデータはこんな感じ。
上記の②③を Power BI に読み込ませれば、CDのジャケット情報なども合わせて表示することができる。
今回は Power Automate で曲のメタデータ取得についてまとめてみた。 次回は Power BI で作った だい³ 初のレポートを紹介してみようかな。
【Power Automate】俺専用チートシート(随時更新)
だい³が今まで Power Automate 使ってきた関数を整理する場所としていったん書き溜めていくところです。 Power Apps しかなかったので作成しました。 随時更新予定。
- 日付
時刻を日本標準時(JST)に変換する(convertTimeZone)
convertTimeZone(変更前の日時,タイムゾーンの名前,日付のフォーマット);
※日付のフォーマットは任意。必須ではない。
以下の例は、SharePont Online のカスタムリストから読み取ったリストをループ(Apply to each)しながら、作成日時である 'Created' を日本時間に変更しつつ、'yyyy/MM/dd HH:mm:ss' の形式に変換する例。 SharePoint のカスタムリストでデフォルトで保持している作成日時は UTC であるため、以下はよく使う関数だったりする。
convertTimeZone(items('Apply_to_each')?['Created'],'UTC','Tokyo Standard Time','yyyy/MM/dd HH:mm:ss')
参考:関数リファレンス(Azure Logic Apps および Power Automate の式で関数を使用するためのリファレンス ガイド)
- 変数
文字列変数を初期化する
null
使った文字列を初期化(空白)してもう一度利用したいけど、「変数の設定」アクションで値を空白(null)設定することはできない。 解決策は簡単で、単純に関数でnullを設定するだけ。
初めての Power BI ~Echo で再生した曲をレポートしてみる~
だいさんから見た Power BI
今まで数回勉強会い参加してきたので概要レベルはとりあえず知ってます。 (ほんとちょっと知ってるぐらい) 今まで何度か挑戦してみようかと思っていたけど、なかなか手を付けることができなかったのが Power BI なんだよね。 今回、Power Platform の資格に挑戦してみようかと思い勉強と遊びを兼ねるネタを探してました。
Echo で再生した曲ってもしかして Power BI でレポートできるんじゃね?と思いつく
Alexa の developer で再生リスト取れるかなーと思ったけど、結局挫折して IFTTT 使っちゃいました。 IFTTT なら再生した曲を取ることができるので、それを活用して Webhook でPower Autoamte のトリガーを起動するようにしました。
手順
Power Automate
全体概要はこんな感じ HTTP 要求受信時をトリガーにします。
トリガーで発行された Webhook エンドポイントの URL を控えておきます。
スキーマは、「サンプルのペイロードを使用してスキーマを生成する」から簡単に生成できます。 以下は生成した内容。 ※うまくコードブロックできない・・・。
{ "type": "object", "properties": { "PlayDateTime": { "type": "string" }, "SongName": { "type": "string" }, "AlbumName": { "type": "string" }, "ArtistName": { "type": "string" } } }
後は作成しておいたカスタムリストに放り込むだけ。
IFTTT
IFTTT 側はこんな感じ。
URL には先ほど控えた エンドポイント URL を貼り付けます。
出来上がった Power BI のレポート
とりあえず SharePoint Online のカスタムリストに接続してレポートを作ってみた感じがコレ。
もっとかっこよいグラフやランキングを作れたらいいんだけどねぇ・・・。 所どころ変なところあるけど、ご愛嬌ということで。
もちょっと勉強が進んだらしっかり記事を仕上げます(;´Д`)
【Power Apps】俺専用チートシート(随時更新)
だい³が今まで使ってきた関数を整理する場所としていったん書き溜めていくところです。
随時更新予定。
変数
グローバル変数
アプリ内のすべてのスクリーンで使用できる変数
Set(変数名,値);
例)Set(gblFilterTrainingMonths,1) ・・・gblFilterTrainingMonths に 1を設定する
コンテキスト変数
そのスクリーンのみで使用できる変数。
別のスクリーンに移動すると変数は使えない
UpdateContext({変数名: 値});
コレクション
ソート
Sort 関数
データソースを任意の並び順にするために必須となる関数。
SharePointをデータソースにする場合は委任問題に注意。
昇順の場合は Ascending 、降順の場合は Descending を指定する。
Sort( データソース, ソート対象の列, 昇順か降順の指定 );
フィルタ
Search 関数
任意の文字列で、列を指定して、前方後方一致で一致するものをフィルタしてくれる。
複数の列の指定ができるため、フリーワード検索のような使い方できる。
Power Apps の関数の中でも好きな部類に入る。
以下の、「検索するテキスト」にテキストボックスのテキストを指定すれば出来上がり。
「検索するテキスト」が空っぽ(Null)の場合はフィルタなしでデータソースを引っ張ってきてくれるのでとても便利。
検索する列を指定する場合、内部名となるため注意。
特に、SharePoint等は日本語で列を作っちゃうとエンコードされた内部名になるので後から調べるのが大変(;´Д`)
Search( データソース, 検索するテキスト, 検索する列1, 検索する列2, 検索する列3, 検索する列N );
並列処理
Concurrent 関数
Concurrent 内に複数処理を記述することで、同時に処理を開始することができる。OnVisible など、できるだけ処理時間を短くしたい場合や、複数処理がシーケンスでない(並列処理可能な)場合に有効な関数となる。
Concurrent( 処理1, 処理2, 処理N );
条件分岐
比較対象が空白かどうかで分岐
If( IsBlank( 検査対象 ), 空白のとき, 空白でないとき );
ギャラリー
選択しているアイテムの色を変える
プロパティ:TemplateFill
If(ThisItem.IsSelected,Color.LightBlue,Color.White);
※選択していたら"LightBlue" 未選択は"White"
日付処理
今日の日付をYYMMで表現
Text( Today(), "[$-ja]yymm" );
今日の日付をYYMMDDで表現
Text( Today(), "[$-ja]yymmdd" );
今日から1ヵ月後を計算
DateAdd (Today(), 1, Months );
今日から-1ヵ月後を計算
DateAdd (Today(), -1, Months );
今日から-1ヵ月後を計算してYYMMで表現
Text( DateAdd (Today(), -1, Months ), "[$-ja]yymm" );
日付のタイムスタンプを作成
Text( Now(), "[$-ja]yymmddhhmmss" );
日付に対しての曜日表示
Text(Now(), "[$-ja-JP] m/dd(dddd)", "ja-JP" );
※ 参考にしました
qiita.com
日付に対しての曜日表示(”曜日”を削除)
Substitute(Text(ThisItem.作成日,"[$-ja]yy/mm/dd hh:mm(dddd)" ),"曜日","");
ロード中画面
*吉田さんの動画を内容を参考にしました
下準備としてロード中画面を準備する。
Google画像検索で 「Loader gif」とやるといい感じの画像が検索できる
※ 著作権には注意してネ。Free GIF画像を準備しましょう。
www.google.com
GIFをアップロードする
Loder用のGIFやテキストを配置する
Visible プロパティに [showLoader] を設定
ボタン等の処理で、[showLoader] の値を true や false に変化させて、Visible プロパティを変数で制御。これで、ロード画面を表示したり、させなかったりできる。
ロード画面を表示させる場合
UpdateContext({showLoader,false});
ロード画面を非表示にする場合
UpdateContext({showLoader,ture});
コンポーネント
動的なタイトル変更
コンポーネントで動的なタイトル表示を行う場合、変数を受け取る準備(カスタムプロパティ)を行わなければいけない。
docs.microsoft.com
変数を受け取りたいコンポーネントを選択する
「+新しいカスタム プロパティ」を選択する
任意の値を入力する
今回はヘッダーに値を入れたいので、プロパティの型は「入力」にする。
また、受け取ったテキストデータを表示したいため、データ型は「テキスト」にする。
コンポーネントに作成したカスタムプロパティ定義されているので、埋め込みたい変数を指定する。
埋め込みたいラベルのテキストプロパティに、設定したカスタムプロパティを記述する。
hedder.HeaderText (コンポーネント名).(定義したカスタムプロパティ名)
あとは画面側で変数にテキストをSetしちゃえば、そのテキストがヘッダーに出てくる。
画面のOnVisibleに以下のようなSetコマンドを入れれば、画面名が自動的にヘッダーに出ることになる。