NorthernMan54 / node-red-contrib-homebridge-automation

Homebridge and Node-RED Integration
Apache License 2.0
107 stars 18 forks source link

hb-event disconnected #26

Closed hepcat72 closed 4 years ago

hepcat72 commented 4 years ago

TL;DR: How do I reliably prevent this "disconnected" status of the hb-event nodes?

I installed node-red-contrib-homebridge-automation a couple weeks ago or so and realized that I could use the hb-event node to replace a more complicated (but reliable) flow to trigger events when my garage door opens (it involves an email, an applescript, IFTTT, and webhook relay). So I was psyched I could circumvent all that, but...

When I went into the workflow to set it up, I noticed that all of my hb-event nodes had "disconnected" under them.

When I installed node-red-contrib-homebridge-automation a couple weeks ago, I'd done it to keep node-red-contrib-homekit-bridged devices synched with my homebridge devices (as a part of trying to debug issues I've had over the past year with homebridge). I wanted the node-red-contrib-homekit-bridged device states to represent the states of the actual devices and stay up to date.

So, to see if this disconnected status prevented the synch from working, I tested the homebridge representations of 2 devices (my TV and my garage door) to see if the node-red-contrib-homekit-bridged copies of those devices would update their status. They did not. I.e. The homebridge device updated in the Home app on my iPhone, but the node-red version did not update, thus I confirmed that the hb-event nodes were not functioning. E.g. I turned on the TV using the homebridge copy of the TV device and the state of the node red version of the TV remained off. It should have updated via the hb-event node. and they had all been functioning a week ago (i.e. a status change to the homebridge event propagated to the node red version via the hb-event node).

So:

  1. Is there a way to get the hb-event nodes to reinitialize without restarting node red?
  2. How can I prevent the hb-event nodes from getting into this state
  3. Is there a way to automatically address this bad state when it occurs so I can rely on it?
hepcat72 commented 4 years ago
hb-event_disconnected
NorthernMan54 commented 4 years ago

For your homebridge environment is it stable?

My node is dependent on your homebridge implementation being stable and not changing a lot. Does your server running homebridge change ip addresses? Are you using docker or ???

hepcat72 commented 4 years ago

I haven’t added any devices in awhile if that’s what you mean. However, I have had some reliability issues. I’ve been posting about those issues here: https://github.com/nfarina/homebridge/issues/1801 and here: https://github.com/nfarina/homebridge/issues/2165

Part of the reason for my endeavor to start using node red was to possibly/eventually switch over to one of the HomeKit nodes to try and circumvent the issues I’ve had with homebridge (or determine if they're both susceptible to the same issues). And at this point, I’m running both Homebridge and a HomeKit-bridged node (synchronized via your node) to see if both strategies are experiencing the same issues (when they occur). So far, since setting up this test, both are functioning as well as I would expect and no recurring issues I've been experiencing have yet recurred. This issue however with hb-event is a new issue, but could be related to my other issues(?).

I’m not using docker. I’m running on a raspberry pi 3. It’s set up using pm2. It doesn’t change IP addresses. I have a reserved dhcp address. However, part of my suspicion is Apple’s mDNS/bonjour because I’ve had other issues unrelated to Homebridge. I blogged about it here: https://alwayswithyouwhatcannotbedone.wordpress.com/2019/03/10/temporary-fix-for-an-iphone-that-cannot-access-local-addresses/

hepcat72 commented 4 years ago

FYI, I just edited my above comment to add details.

NorthernMan54 commented 4 years ago

After reading your blog, it appears you likely have mdns/bonjour issues with your router. I had something similar with my setup, I then picked up an AirPort Extreme ( from Kijiji for cheap ) and used it as the router on my network and switched my existing router into bridged mode.

hepcat72 commented 4 years ago

I’ve thought about getting a new router, but I was thinking of trying something other than AirPort Extreme. I have a relatively young AirPort Extreme that supports 802.11 ac. It’s maybe about 2 or 3 years old. I had noticed issues early on when I got that AirPort Extreme. At that time, it was just airplay issues to an old airport express, so I didn’t think much about it. And it’s only my phone, my wife’s phone, and my iPad that are affected. I have never had issues from my computers. .local addresses have always worked to and from my computers. Ssh with the .local address to my rPi has always worked too. It’s only when I started messing around with Homebridge where bonjour has been a real issue. When it was just using airplay or watching shows on my eyetv, it was just a minor annoyance to heave to toggle airplane mode. But lately, when I’m having Homebridge issues, the airplane mode trick rarely helps. Debugging communication issues like this is not something I have the skills to dig into.

hepcat72 commented 4 years ago

I’ve been thinking my issues may have to do with a mixed iOS version environment and some of my older computers...

NorthernMan54 commented 4 years ago

I’m on vacation for the next 2 weeks, but when I’m back want to look into what causes the disconnected. I’m using mine and HomeKit-bridged together for a while, and for me 100% stable except after a power failure. Need to work on startup order as my node is dependent on everything else starting first.

My last thought, are you changing anything in node-red? I know that HomeKit-bridged has issues when you change things and you need to restart to fix. ( I keep thinking about delving into the restart issue, but it hasn’t been enough of a pain to make it worth my time )

hepcat72 commented 4 years ago

I’ve been restarting node red with pm2 restart node-red whenever I deploy. Otherwise, my device states are out of synch. I’ll do it again this to see what happens.

hepcat72 commented 4 years ago

Well, I looked after the restart and they don’t say disconnected now. I should have checked before the restart, so I don’t know if the restart did anything or not. I was making a bunch of changes to node red last weekend and kept restarting and I’d noted they all remained disconnected through multiple restarts. Sigh. I suspect your hunch about my router may be close to the mark. I wish my Homebridge (/bonjour?) issues were consistently reproducible.

hepcat72 commented 4 years ago

I don’t want to go on a tangent, but I was just googling and this old issue from 2008 sounds very similar to my bonjour issues: https://discussions.apple.com/thread/1470067

hepcat72 commented 4 years ago

Hmmm... Maybe this is my problem and solution: https://forums.macrumors.com/threads/bonjour-services-blocked-by-airport-express.387385/

I have 3 old airport expresses configured to “join” the network. I’ll have to check out their settings.

NorthernMan54 commented 4 years ago

That would definitely cause a problem

hepcat72 commented 4 years ago

I checked out the settings of all 4 AirPort Expresses. I don’t think that they’re set incorrectly. I recalled from looking at them that I used to use the “participate in a WDS” setting. I switched from that to “join a wireless network” because somehow long ago, my printer was inaccessible and I discovered that it was connecting to one of the expresses and wasn’t being shared across the network. The only other option is to create a network. However, I noted that the internet tab has a grayed out menu where bridge mode is an option. So I may try switching it back to wds and see if that enables the menu with bridge mode. In the meantime, I added dhcp reservations to my Extreme for each of the expresses.

dxdc commented 4 years ago

@hepcat72 @NorthernMan54 Just out of curiosity, in case it's not network related, one issue I came across (which could be related to the below 2 issues) is the use of some kind of event firing that wants HB Event status before it is fully loaded. I was able to replicate this on my system fairly simply as follows:

Consider a simple flow, like this: image

If I set Inject after 0.1 sec on the timestamp, then restart NodeRed, the HB Status will return as disconnected and will never recover after restarting NodeRed. However, If I change this to Inject after 30 sec it seems to work great.

There must be some issue about requesting a status too early, which causes a perma-disconnect. It seems unlikely to be triggered from events caused within Homebridge (e.g., suppose you have a state change caused by a light switch going on) since presumably it would have to be registered before it would fire appropriately.

NorthernMan54 commented 4 years ago

@hepcat72 try starting homebridge, wait 30 seconds for it settle down then start node-red. These issues should go away. As I don't store the homebridge device list within the node, it needs to be be wrapped from all the homebridge instances before things can work correctly.

dxdc commented 4 years ago

@NorthernMan54 That seems to be a good suggestion for system startup, but if homebridge restarts (suppose due to error), wouldn't it cause the same issue? And, NR wouldn't have a way to determine whether or not Homebridge devices are still connected.

Would it be possible to set up a disconnect event type, which could then be tied into a homebridge restart? Or, even something simple like polling /hap-device/... periodically and setting a timeout.

NorthernMan54 commented 4 years ago

If you watch the node carefully, it has a 15 minute refresh timer for just this scenario. I run my home with multiple RPI's with multiple homebridge instances and it reconnects automatically. It even reregisters for event notifications ;-)

dxdc commented 4 years ago

Terrific! Wow... you must have a lot of devices set up, but great to know how reliable it is. I didn't test it to that point, just something I noticed when starting up.