-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ceiling Light ProのPowerStatusが正しく反映されない #25
Comments
アドオンのv1.0.15以前のマスタ定義に誤りがありました。 デバイス取得時にマスタデータを個別の内部デバイスデータとして永続化するつくりのため、 リリースノートには記載しましたが、
今回のケースでは1.は不要と思いますが、もし 2.~3. を行って改善しない場合、1.~3.の順序で試してみてください。 もし、v1.0.16以降に構成したデバイスの場合、何か想定外の事象が起きているので、 |
数日前に追加されたarmv7:1.0.17でraspbianにdockerで昨日構築が完了した環境になります(環境構築ができるまでの推移は某掲示板で見ていただけたのかと思います) 指示された1.~3.の手順に該当すると思われる操作を下記のように実行しましたが現象は変わりませんでした。 1.MQTT Explorerを使いhomeassistant/(component)/.*Ceiling Light ProのデバイスID.*となっているTopicをすべて削除し、MQTT統合から削除されたのを確認しました。 必要なログの取り方がわからないので教えていただけますでしょうか? |
options.jsonのLogLevelを また、原因が分かりました。 Webhookの場合、 MQTT統合としては、MQTTトピック: 問題の事象のような、StatusAPI、Webhook両方に値が存在し、具体値が(SwitchBotの仕様上)異なるケースについて、値を小文字化して送信するよう変更しました。 修正し、v1.0.18を先ほどリリースしましたので、そちらで確認ください。 |
添付画像1,3のWebhookボディのtimeOfSampleから、 PlugMiniでは、いままで そこまでの遅延した経験はありません。 現状アドオンはデバイスのステータスを保持しない(ステートレス)ですので、 通知が欠けたり、順序性が保証されない 事が常だとすると、アドオンの実装で回避が必要そうです。 実用上は、 Webhookの送信速度や正確性については、 |
追記です。 ColorBulbでも数回 試しましたが、 APIで操作した場合も(Webhookを受信するアプリが異なる可能性があるので、) もしかしたらシーリングライトも同様の振舞いかもしれません。 (PlugMiniも再確認しましたが、SwitchBotAPIで操作してもWebhookは必ず来ます。) |
やはりSwitchbot側の問題っぽいですね。 |
MqttCoreServiceのstart時とwebhookの受信時に正しく反映されないのですが、仕様上仕方がないものでしょうか?
添付画像1はCeiling Light Proで最後のbrightnessが59の状態でOFFにした状態から、下記の1,2を実行したものです。
1.純正リモコンのON/OFFボタンを押してONにした。
2.純正リモコンの「明るい」ボタンを押して明るくした(内部的にはbrightnessが77に変更)
webhookのログからpowerStateの値がONになっているのに画面上ではクリアのまま変わりません。brightnessは59から77に変わりました。
また画面上のPollingの「押す」を押すと正しく反映されます。(添付画像2)
The text was updated successfully, but these errors were encountered: