banban

@AnthonyOGorman Thank you for your report. As you report, ECHONET_TARGET_NETWORK is used to pick one network interface when a host has multiple network interfaces. echonetlite2mqtt cannot find the device even...

@AnthonyOGorman But I don't know about the "ECHONET_ALT_MULTI_NIC_MODE" problem. >My second mistake was not setting docker to network host. This can cause issues with the "ECHONET_ALT_MULTI_NIC_MODE" due to Multicast. What...

> No crashes or issues here, just trying to use "ECHONET_ALT_MULTI_NIC_MODE" without the `--net=host` docker option. Which was my mistake. Thank you for the reply. I was relieved that echonetlite2mqtt...

@aftertommy @AnthonyOGorman I will explain about tag:master. tag:master is a release candidate for the next v2.3.0. The major differences from v2.2.0 are as follows. 1. Updated the library for EchonetLite,...

@flutschepfeil Is the feature you want a light bulb that gradually brightens? ECHONETLite2MQTT does not have such functionality. However, it seems that this function can be achieved by sending a...

@grandevice 単機能照明の照度レベル設定(light level)は、Echonet Liteではプロパティ"b0"ですが、確かにプロパティの受信エラーになっています。 エラーとしてはタイムアウトであり、 #29 や #31 で報告されているものと同じで、 プロパティの要求をしてから受信するまでの待ち時間の間に結果が返ってこなかったようです。 こちらも、現在のバージョンでは待ち時間が固定値1秒になっているのでソースコードをいじる以外に対処ができません。 待ち時間を変更できる次バージョンを用意します。 ``` {"category":"[ECHONETLite][raw]","exception":{"commandResponse":{"command":{"deoj":"02910c","edt":"","epc":"b0","esv":"62","ip":"192.168.11.252","seoj":"0ef001","tid":"c034"},"responses":[]},"message":"timeout"},"level":"warn","message":"error getProperty: timeout 192.168.11.252 02910c b0","timestamp":"2023-12-19T10:42:12.776Z"} {"category":"[ECHONETLite][raw]","exception":{"commandResponse":{"command":{"deoj":"02910c","edt":"","epc":"f0","esv":"62","ip":"192.168.11.252","seoj":"0ef001","tid":"c035"},"responses":[]},"message":"timeout"},"level":"warn","message":"error getProperty: timeout 192.168.11.252 02910c f0","timestamp":"2023-12-19T10:42:13.778Z"} {"category":"[ECHONETLite][raw]","exception":{"commandResponse":{"command":{"deoj":"02910c","edt":"","epc":"f3","esv":"62","ip":"192.168.11.252","seoj":"0ef001","tid":"c036"},"responses":[]},"message":"timeout"},"level":"warn","message":"error getProperty: timeout 192.168.11.252 02910c...

@grandevice 確かに、もらっているログの最新の状況では、エコキュートとエアコン1台(eoj:013005)が2重で登録されているようです。 ログからわかることは、メディアコンバーターと思われる、192.168.11.253 で多数のプロパティ受信エラーが記録されています。 また、192.168.11.252でも同様にエラーが多く記録されています。 逆に他にもデバイスがいくつかあるようですが、そちらではエラーが無さそうです。 ここから推測される原因は #31 でも挙げていますが、ECHONETLite2MQTTがデバイスにプロパティを要求してから それを受け取るまでの待ち時間が短すぎるのではないかと思います。 現在のバージョン ver.3.0.2ではこの待ち時間は1秒になっています。 おそらく、この2つのデバイスはプロパティを要求してから返してくるまでの時間が1秒前後ではないかと思います。 ただ、残念ながらこの待ち時間を変更することができません。 次のバージョンで、変更できるようにするオプションを追加するのと、デフォルトの時間を少し伸ばそうと思います。 なお、 @grandevice さんは、Node.jsで実行されているようなので、 テキストエディタで編集すればこの待ち時間を変更できると思います。 場所は以下のソースコードなので、実験できるなら、1000から2000くらいに変更してみてください。 https://github.com/banban525/echonetlite2mqtt/blob/b4c98d20abdaa75bffe92df9231d879d2688c327/server/EchoNetCommunicator.ts#L243

なお、二重登録される原因は、プロパティ受信の待ち時間が短いだけでなく、 プロパティ受信エラー時の処理が甘いことも問題です。 こちらも対処する予定ですが、完全には対応できないかもしれないので、まずは待ち時間の対処を行います。 詳しい中の話をすると・・・ ECHONET Liteでは、プロパティ"83"がデバイスのIdを表しています。 ECHONETLite2MQTTは、プロパティ"83"があればそれをIdとして扱いますが、 プロパティ"83"を持たないデバイスもあり、その場合は `(ノードプロファイルのId)_(eoj)` をIdとしています。 今回の問題では、初回のプロパティ"83"はエラーになったので、プロパティ"83"を持たないデバイスとして `(ノードプロファイルのId)_(eoj)` のIdが割り当てられましたが、 その後プロパティ"83"が受信できたので、プロパティ"83"をIdとする別のデバイスとして扱ったようです。 本来なら、プロパティ"83"の受信がエラーになった場合にリトライするなど対策ができるとは思いますが、 そこまで実装できていませんでした。

@grandevice まず、当初の問題であった、デバイスが正常に取得されない問題について。 次のバージョンである ver.3.1.0を公開しました。 コマンドの待ち時間のデフォルトを3秒にしたのと、 `--echonetCommandTimeout` を追加して待ち時間を変更できるようにしました。 ソースコードをいじって3000秒に変更してもらっていたと思いますが、これは不要になります。 なお、ソースコードを変更されているのなら、変更を取り消してから最新のコードを取得してください。

@grandevice > 一つ気になっていることがあります。CF-TC7Bが180秒ごとにエコキュート1台、エアコン4台をpublishしていて、この間45秒ほどですがMqtt越しのpublishがRecieveされず5台の情報更新が終わった45秒後にReciecveされるといった現象を確認しております。普段はエアコンの室内温度が180秒ごとに更新され便利とさえ感じることなのですが・・・ こちらについて。 前提として、ECHONETLite2MQTTは、デバイスから"インスタンスリスト通知"(プロパティコード:0xD5)を受けると全プロパティを再取得するようにしています。 (これが正解かはわからないのですが、他の機器やアプリがそのように動いているので真似しています) おそらく、CF-TC7Bは180秒ごとにこの通知を送っているのだと思います。 ここから、この問題は、以下の2つが原因と思われます。 * (1)全プロパティの再取得に45秒かかってしまう * (2)この全プロパティの再取得中は別のコマンドが待たされてしまう (1)については、エアコンはプロパティを多数持っているので、デバイスの性能が低く応答が遅いと 時間がかかることもありそうです。 また、結果を返さないプロパティがあると、応答待ちである3秒待ってしまうので、そこでも時間がかかります。 この再取得をOFFできればよかったのですが、現状未実装です。 また180秒ごとの更新がなくなってしまうので、やはりいまいちです。 (2)については、ECHONETLite2MQTTの問題です。 この全プロパティの再取得はそれほど時間がかからない想定だったので、他の通信をブロックするように実装されています。 ここは見直したほうが良さそうです。 この問題については次のバージョンに向けて調整してみます。 少し頭をひねらないといけないので、1～2週間ほど必要と思いますが。