Accessory reachability #48
Comments
|
We could if it’s cool :) |
|
It's about triggering "No Response" message manually and not only just when bridge is unavailable. Let's say, I have some sensor or switch. Node-RED is subscribed to MQTT topics to get updates (current temperature or switch status). I have trigger node which sends device availability status (true) and if it is not getting new data within 1 minute, it will send false as availability status which leads to "No response" message in Home.app on iOS. Here's a screenshot from Home.app from that thread: screenshot And here is the example flow screenshot: example I was using homebridge with mqtt plugin for that configuration, but it's too complicated compared to this nodered plugin, so it would be great to see this feature here :) |
|
Maybe this will help? https://github.com/KhaosT/HAP-NodeJS/pull/556 |
|
Ps that was my pull request
I’m out on a vacation right now, but when I back am thinking of looking at this further.
I did look at how this node manages set characteristic events, and it is tied in at the accessory level and doesn’t follow the typical homebridge pattern. But you could call the updateValue function at the characteristic level to set ‘not responding’. But it will need some thought, as this codebase is very elegant in its integration with hap-nodejs.
… On Mar 5, 2019, at 4:25 AM, Daniil Molchanov ***@***.***> wrote:
Maybe this will help? KhaosT/HAP-NodeJS#556
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Figured out how to trigger this event from code and submitted PR |
|
This sounds like a cool idea - how do I use it?! For example I have an MQTT switch that is "not responding" - what do I send into homekit? Reading the PR it seems like {"On":"NO_RESPONSE"} would work? |
|
Exactly. You send "NO_RESPONSE" as a value for any valid characteristic and when you reopen Home.app or push the accessory icon and hold it for a while (it will open in fullscreen) its status will change to "not responding". As soon as any other valid value will be sent to Homekit, "not responding" status will go away. For example, I use Trigger node which emits a message when there were no updates through MQTT within 1 minute. |
|
#51 got merged to dev branch. @crxporter could you test it yourself and provide me some info here? |
|
I’m not actually running a dev version anywhere right now - I’ll load it up at work tomorrow and try it! |
|
I went ahead and installed the dev branch on one of my pi's at home and tested this - with mixed results. Using switches - it works when sending Using dimmers (light bulb service) - it works when sending
Using occupancy detector - it works when sending Additionally I can only get the "NO_RESPONSE" to appear when reopening the home app, not when long-pressing the item in homekit as stated above. When keeping the Home app open and sending The "recovery" from "no response" status back to a functioning item is pretty good, I can get it back by long-pressing, swiping to another room then back, or closing and reopening the app. Conclusion - this looks like it works with SOME characteristics (I tested with "on" for both switch and dimmer services also tested with "OccupancyDetected" for occupancy sensor) and it will show an error when opening the Home app (tested on iphone and computer). It doesn't update while inside of the app (have to quit and reopen) and it doesn't "automatically" update back to good status - (have to long press or change screens). I like it! I'll use this to sort through my startup statuses, they always return "NULL" between boot of my pi and the first poll event (up to 10 minutes). During boot I will be able to see whether any item has been polled yet. This looks like it will work really well for long-lasting errors like boot-up or offline devices as @radionoise described as MQTT offline for over 1 minute. |
|
It seems that NO_RESPONSE value will take effect only with required characteristics but not optional ones. |
|
@crxporter You're right about controlling device after NO_RESPONSE was set and Home.app was not restarted. Perhaps we should keep some state in the service that NO_RESPONSE was triggered. I did some research and right now here is the problem after triggering NO_RESPONSE and not reopening Home.app:
I'll try to investigate further. |
|
If you have some time, review the Characteristic.js file in hap-nodejs. It caches state as well, so maintaining a local copy of state could be redundant.
…Sent from my iPad
On Mar 6, 2019, at 1:57 AM, Daniil Molchanov ***@***.***> wrote:
You're right about controlling device after NO_RESPONSE was set and Home.app was not restarted. Perhaps we should keep some state in the service that NO_RESPONSE was triggered. I did some research.
Right now here is the problem after triggering NO_RESPONSE and not reopening Home.app:
Turning switch OF does not fire "characteristic-change" event.
Turning switch ON fires two events simultaneously (one for previous OFF and one for ON).
We can preserve NO_RESPONSE state and send it to Homekit again if it was not recovered properly, but we see the result after we open Home.app when Light was ON.
I'll try to investigate further.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Like I said - I like this idea. Once it's "figured out" it'll be pretty cool. It seems like you're headed in the right direction. |
|
I'm glad to say that NO_RESPONSE feature was improved in this PR: #58. |
|
I am closing this Issue. Improvement merged into dev. Made by @radionoise and confirmed by @crxporter - thanks guys! If you have a problem then first head to this section in README. |
Can we have reachability feature implemented like in this homebridge mqtt plugin?
cflurin/homebridge-mqtt#9
The text was updated successfully, but these errors were encountered: