search

banban525 / echonetlite2mqtt

ECHONET Lite to MQTT bridge.
MIT License
48 stars 7 forks source link

CF-TC7B以下のデバイスが異なった認識をしたり、重複したりします。 #29

Open grandevice opened 10 months ago

grandevice commented 10 months ago

パナソニック製のメディアコンバーターです。エコキュート1台とエアコン4台が接続されております。

何度か再起動をすると治ったりするのですが、v2.3.0までは起こっていなかったと思いましたので報告させていただきました。

echonetlite2mqtt_logs_internalsStatus (6).zip

banban525 commented 10 months ago

@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

banban525 commented 10 months ago

なお、二重登録される原因は、プロパティ受信の待ち時間が短いだけでなく、 プロパティ受信エラー時の処理が甘いことも問題です。 こちらも対処する予定ですが、完全には対応できないかもしれないので、まずは待ち時間の対処を行います。

詳しい中の話をすると・・・ ECHONET Liteでは、プロパティ"83"がデバイスのIdを表しています。 ECHONETLite2MQTTは、プロパティ"83"があればそれをIdとして扱いますが、 プロパティ"83"を持たないデバイスもあり、その場合は (ノードプロファイルのId)_(eoj) をIdとしています。 今回の問題では、初回のプロパティ"83"はエラーになったので、プロパティ"83"を持たないデバイスとして (ノードプロファイルのId)_(eoj) のIdが割り当てられましたが、 その後プロパティ"83"が受信できたので、プロパティ"83"をIdとする別のデバイスとして扱ったようです。

本来なら、プロパティ"83"の受信がエラーになった場合にリトライするなど対策ができるとは思いますが、 そこまで実装できていませんでした。

grandevice commented 10 months ago

1000→3000msにて減少は少なくなりましたが未だおこることがありますが大分ましになりました。ありがとうございます。

30についてはたまに空欄になるものの気づくと明るさが埋まっていたりします。

一つ気になっていることがあります。CF-TC7Bが180秒ごとにエコキュート1台、エアコン4台をpublishしていて、この間45秒ほどですがMqtt越しのpublishがRecieveされず5台の情報更新が終わった45秒後にReciecveされるといった現象を確認しております。普段はエアコンの室内温度が180秒ごとに更新され便利とさえ感じることなのですが・・・ Mqttthing Homekitの問題かとも思ったのですが、この45秒間の間にEchonetlite2MQTTからpublishしても同様にRecieveされませんでした。

なお、HF-JA2も180秒ごとに更新があるのですが鍵1個の更新なので気になるほどではありません。 また、スマホのアプリからは操作可能でした。

banban525 commented 10 months ago

@grandevice

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

なお、ソースコードを変更されているのなら、変更を取り消してから最新のコードを取得してください。

banban525 commented 10 months ago

@grandevice

一つ気になっていることがあります。CF-TC7Bが180秒ごとにエコキュート1台、エアコン4台をpublishしていて、この間45秒ほどですがMqtt越しのpublishがRecieveされず5台の情報更新が終わった45秒後にReciecveされるといった現象を確認しております。普段はエアコンの室内温度が180秒ごとに更新され便利とさえ感じることなのですが・・・

こちらについて。 前提として、ECHONETLite2MQTTは、デバイスから"インスタンスリスト通知"(プロパティコード:0xD5)を受けると全プロパティを再取得するようにしています。 (これが正解かはわからないのですが、他の機器やアプリがそのように動いているので真似しています)

おそらく、CF-TC7Bは180秒ごとにこの通知を送っているのだと思います。

ここから、この問題は、以下の2つが原因と思われます。

(1)については、エアコンはプロパティを多数持っているので、デバイスの性能が低く応答が遅いと 時間がかかることもありそうです。 また、結果を返さないプロパティがあると、応答待ちである3秒待ってしまうので、そこでも時間がかかります。

この再取得をOFFできればよかったのですが、現状未実装です。 また180秒ごとの更新がなくなってしまうので、やはりいまいちです。

(2)については、ECHONETLite2MQTTの問題です。 この全プロパティの再取得はそれほど時間がかからない想定だったので、他の通信をブロックするように実装されています。 ここは見直したほうが良さそうです。

この問題については次のバージョンに向けて調整してみます。 少し頭をひねらないといけないので、1～2週間ほど必要と思いますが。

banban525 commented 9 months ago

@grandevice

最新のコード( 386a9b9af659a4c00f30cb75a005dfcd2a35cd40 ) で、定期的に操作できなくなる時間がある問題について対処しました。 ただ、私の環境では再現できないので、もう少し様子見してから次のバージョンとします。

可能なら、テストしてみてください。

banban525 commented 9 months ago

@grandevice

再現環境を作ることができ、テストできたので、この修正を取り込んだ新バージョン v3.1.1 をリリースしました。

このIssueは少ししたらCloseします。

ちなみに、再現環境は昔作ったECHONET Liteエミュレーターを改造して再現しました。 https://github.com/banban525/echonet-lite-kaden-emulator

grandevice commented 9 months ago

ありがとうございます。週末にやっとテストできそうです。 後ほど結果を報告させていただきます。