*アーカイブ済み*
= IoT管理Webサーバーの構築方法 =

こんにちは、みんな、
私は趣味のプログラマーなので、少しアドバイスが必要です

簡単に言うと、Philips Hue ランプやその他の IoT 機器を自宅で制御するための小さな Web アプリを作成したいと考えています。

私はすでに Python で Hue API を試しており、うまく機能するスクリプトをいくつか持っています。別のデバイス上で SSH ごとにコマンドを実行するスクリプトもいくつかあります

次のステップとして、見栄えの良い UI を持つ Web アプリを作成したいと思います。

私も過去に、最初は Kotlin で、次に Flutter と Firebase で小さな Android アプリを作成しましたが、Flutter で動作するある程度見栄えの良い UI をいかに簡単に取得できるかに驚きました。 Flutter が Web アプリとしても使用できることは知っていますが、これが Web アプリとして適切なツールであるとは思いません

私は React と Angular を見て、初心者向けのガイドを読みました。 Flutterと比較すると、見栄えを良くするのに手間がかかるように見えますが、おそらくより良いテンプレートが必要なだけかもしれません

私の想像では、現在のステータスを収集するために 1 つのスクリプトをトリガーしたいと考えています。スクリプトはそれを JSON ファイルに書き込み、UI に素敵なグラフまたは図を表示します。次にボタンを押すと、別のファイルが書き込まれ、スクリプトが起動され、ファイルが読み取られ、それに応じてライトの色が変更されます。

さて、正直に言うと、何から始めればいいのか少し迷っています

私が収集した情報によると、Angular を使用してフロントエンドを構築し、ライトや設定スクリプトの状態を保存およびロードできる「ファイルシステム」として MongoDB を使用できます。その場合、DB を UI に接続するための API が必要になると思います。私が少なくとも部分的に正しいことを願っています:D
JS/TS から始めて、Angular または React で UI を作成するのが正しい方向だと思いますか?それとも、これは私の意図とは完全に間違っていますか？
アドバイスありがとうございます！

ここであなたは間違いなく正しい軌道に乗っています。あなたに欠けているのは、すべてをサーバーの仕様に結び付けることです。

あなたの場合、私がやることは、Web ページを提供するサーバーを構築することです。 Web ページは、サーバーによって公開されている REST API に HTTP リクエストを返します。サーバーは、フロントエンド Web ページ、スクリプト、DB の間の中心的な接続ポイントです。サーバーを経由せずにWebページからDBに接続したり、ライトステータスを変更したりしないでください。

API エンドポイントを定義します。ライトを制御したいとします。おそらく必要なものは次のとおりです:
認証トークンを取得する [
HTTP GET/api/token with creds in header], returns token or 401
Get status of devices [
HTTP GET /api/devices with token in header], returns JSON status of all devices
Get status of lights [

HTTP GET /api/devices/lights with token in header] returns JSON status of all lights
Control a single light [
HTTP POST /api/light/ with token in header, payload specifying RGB], returns empty 200 on valid request, 422 otherwise
And so forth. Once you have an API spec you can develop whatever you want to first; the server code for the API (Django is good if you're comfortable with Python), the front-end code, the server code for integrating your scripts or the DB. As long as the API is sufficiently specified then the parts will all talk to each other nicely. Separation of concerns makes it simple to build some bits, mock others up, modify and replace as needed

A tip: don't write anything to files if you're just sending JSON data around. The server itself can
*probably* just call all the script code directly with no need to pass files, and can definitely serve the JSON via HTTP to the web page for display purposes

This sounds like a fun project. Can you tell me a little about your end goal with it? Maybe I’ll do something like it at my house. I guess what I’m wondering is aside from being a fun project, what (if any) controls does it give you over your devices that don’t come sort of “baked in” via remote controls or apps for example that may come with the device. Just would like to hear about your real world advantages of doing this
== About Community ==
Members
Online