ヘルプ

無料です。デバイス、メッセージ、購読、サーバーの数に制限はなく、ライセンスキーも不要で、テレメトリーも収集しません。

Debian と Ubuntu（APT リポジトリのパッケージ）、Windows 10・11 x64（そのまま使える .exe）、さらに amd64、arm64、armhf 向けの Linux ビルドがあり、Raspberry Pi を含むどのディストリビューションでも手動で起動できます。

何も要りません。バイナリは静的リンクされており、実行環境も libc も外部データベースも不要です。状態はブローカー自身の中の純 Go の SQLite に保存されます。

ダッシュボードは http://あなたのサーバー:8567 で待っています。初期のログインは admin、パスワードは admin です。最初のログイン後すぐにプロフィール画面で変更してください。

TCP 上の MQTT は 1883、TLS 上の MQTT は 8883、Web ダッシュボードと /mqtt での WebSocket 上の MQTT は 8567 です。ポートは config.json かコマンドラインのオプションで変更できます。

おそらくダッシュボード管理者のログイン情報を使っています。両者は別物で、管理者が扱うのは Web インターフェースだけです。デバイスはユーザー画面で作る別のアカウントで接続します。そこでユーザーを作り、その名前とパスワードで接続してください。

権限を確認してください。ACL は既定ですべて拒否で、明示的な許可がなければアクセスできません。対象のトピックフィルターについて read か readwrite のルールがあり、それが拒否のルールより上にあることを確かめてください。ルールは上から順に最初の一致まで確認されます。

フィルター $u/#、アクセス readwrite のルールを追加してください。$u は接続してきたクライアント名に展開されるので、1 つのルールで全員に対応でき、各デバイスは自分の枝しか見えません。ダッシュボードにはこのための「自分の枝」ボタンがあります。

はい。設定 → ブローカーに専用のスイッチがあります。ただし匿名クライアントには $SYS を含め $ の名前空間全体が拒否されます。

仕様がそう定めているためです。ワイルドカードは $ で始まるトピックに届きません。統計を読むには $SYS/# のような明示的なルールが必要です。ブローカーの設定には $SYS の全体スイッチもあります。

WebSocket 上の MQTT を使います。アドレスは ws://あなたのサーバー:8567/mqtt、サブプロトコルは mqtt です。WebSocket はダッシュボードと同じポートで動くので、別のゲートウェイは要りません。

初回起動時にブローカーが自己署名証明書を生成するためです。試験用には十分ですが、クライアントはこれを信頼しません。本番では設定の tls ブロック（cert と key の項目）に自前の証明書を指定し、ブローカーを再起動してください。

プロフィール画面で変更します。新しいパスワードはハッシュとして config.json に書き込まれ、平文のパスワードはファイルに残りません。

ブローカーを停止し、config.json の auth ブロックから passwordHash の項目を削除して、代わりに "password": "新しいパスワード" を書いてください。次の起動でブローカーがハッシュを計算し、平文の値をファイルから消します。

Linux の標準的な導入では、ダッシュボードは 127.0.0.1 だけで待ち受け、nginx 経由で公開します。そこに HTTPS やアクセス制限を足すのは容易です。ポート 8567 をそのまま外に出すのは得策ではありません。

設定 → API でベアラートークンを作ります。表示は 1 度きりで、保存されるのはハッシュだけです。統計しか要らないシステムなら「読み取り専用」にチェックを入れてください。GET、HEAD、OPTIONS だけが通ります。

設定 → ブローカーで制限を有効にしてください。毎秒のメッセージ数、バースト、毎秒のバイト数で、接続ごとに効きます。超過しても接続は切れず、メッセージも失われません。ブローカーがソケットの読み取りを遅らせ、送信側が自ら速度を落とします。

ルール → トピック制限の出番です。パターンごとのルールで、最新値を保ちながら一定の頻度まで間引くか、そのトピックを丸ごと捨てられます。毎秒 10 回送るセンサーは毎秒 1 件になり、しかも最新の値が届きます。

retain メッセージ、購読とオフラインキューを含む永続セッション、未完了の QoS 手順、遅延メッセージです。クリーンセッションは保存されません。仕様上、接続とともに消えるものだからです。

いいえ。このブローカーは単一プロセスとして設計されています。複数のブローカーをつなぐにはブリッジがあり、サーバー間でトピックを双方向に転送します。

トラフィック画面に、フィルターと一時停止を備えたメッセージとブローカーイベントのリアルタイムな流れが出ます。概要画面には流量のグラフ、マシンの状態、イベントの流れがあります。データは WebSocket で届きます。

システム全体と一緒に行います。sudo apt-get update && sudo apt-get upgrade だけで、ほかに必要な作業はなく、設定もデータもそのまま残ります。

設定 → インポートとエクスポートで、古いサーバーでファイルを取得し、新しいサーバーで読み込みます。設定、ユーザー、ルールが引き継がれます。

データはバイナリの隣の data ディレクトリ（Linux では /opt/elxmqttbroker）にあり、broker.db、users.json、証明書が入っています。Linux ではログは journald へ送られます：journalctl -u elxmqttbroker -f。

バージョン、ビルド番号、ビルド日時はバイナリに埋め込まれています。サイドバーの下部、バージョン情報の画面、elxmqttbroker -version の実行結果で確認できます。

はい。config.json で persistence: false にします。その場合はすべてメモリー上だけに保たれ、再起動で失われます。試験環境では理にかなった選択です。