Repair failed node neighbor discovery (report failed)

So your question about the Zooz devices made me go look at them. I noticed the one for the washer has a Power Reporting Interval of 00:05:00 whilst the one for the TV (I use it to detect when the TV is turned on/off and trigger blinds accordingly) had the same interval set to 00:00:10. I upped that one to the same as the washer.

You need to let things run for a while, just after a reboot you won't have the best idea of these stats.

Also please post App stats after you let this run a while.

Again, where is this hub? Near someplace warm, like near a TV or modem/router, in a closet, or something?

How many of these various reports do you have set? Typically you only want to use one or maybe two of the many reports available. Typically most use Watts change, and maybe an interval. Turn off percent change, energy, and everything else.

The hub sits out in the open, on a halfwall upstairs where my server gear is. All open-air.

Both Zooz are identical settings-wise now:

The most recent thing I added was the HubConnect Hub Info app.

Nothing?

  • I've purged the system of the ghosts (it seems to run less reliably now, esp at mode change when it's sending commands out to 10 or so lights and six iblinds all at once).
  • I've changed the polling of the power report on the Zooz power monitor that goes to the TV. It makes the scenes much less responsive when turning the TV on now but if it helps...
  • I've answered all the follow-up questions re location, etc.
  • I've flipped the hub upside down to facilitate ease of heat dissipation thru the vent holes
  • The current temp has been riding at ~98-101°

Any other thoughts or recommendations here?

Still sounds like your hub is being overwhelmed. For giggles try removing any zooz stuff, just for a day... (Exclude it and power it down)

Can you post a copy of your current full z-wave details page without the ghosts?

Much better. Has it quit since you did this (kept temps lower)?

Like I said above:

And the Device stats screenshots.







It has not quit though it still had an issue last night taking down all the lights, locks, and iblinds at Night mode. Tonight I'm testing putting a one minute delay ahead of the iblinds.

App stats



Device stats









I think I would try a couple things.

I don't recall you saying this was a problem before. This can be very hard on the Zwave network to do this. There was an app published recently to help solve this issue. You might try this and see if it helps with that particular problem.

For your Device Stats, there are some things that are writing a LOT of stuff to the database. For example, do you really need to store 630 old events for your Sensor: Office Multi ? Or 3500 Ambient API events?

There are lots of these devices in your list that where you probably could/should greatly reduce the number of events stored (Ambient API, Ambient via WU, Outdoor Ambient Panel) as a couple examples. Go to the really heavy used device's Device Stetting page in that list, and crank the Events and States settings down. My weather app, I only keep 3 events. Basically that is the equivalent of yesterday, today, and tomorrow for the dozens of items stored in that driver. Personally, I only keep 1-2 of most events and states, there isn't really a need to keep hundreds or thousands of crap you won't ever look at again.

My other advice is that I personally suspect that Maker API has a memory leak. That is a very heavily utilized app in your list. Others have said this in the past too, but nobody ever seems to be able to catch this happening. I would try deactivating Maker API temporarily, and see if it helps. If it fixes the problem, I would work with support to have them pull logs from your hub and try to track down the bug.

1 Like

I'm all about running leaner - where do I pare this down? I'm missing where I can crank down the Events and States settings. Is it here:

image

If so, what settings would you recommend?

Therein lies the rub for I use Multi-System Reactor as my rules engine so anything I want to control must be added to Maker API.

Events, 10
States 10
Too many 300

For some of these that collect a lot of states you might want to go even lower. Unless you NEED the history, you could even set these to 1 and 1 and 300. I did that for a few things that were very chatty and that I didn't care to see history.

I can't advise on whether using Multi-System Reactor might be causing any issues, but is there a reason you haven't used the various built-in rules apps?

Re MSR I'm a former Vera user and it's rules engine was awful. Enter Reactor, a plugin that did all the things and more. When the dev decided to build it out as a standalone app I jumped right in. My Vera was rapidly becoming obsolete/EOL'd by the vendor and Hubitat caught my eye. Since MSR was written with Hubitat as an integration out of the box it seemed the perfect marriage - and it has been. MSR is very powerful and I was already familiar with the process to rulemaking. It handles the logic, sending commands over to the Hubitat which can now focus solely on performance vs thinking AND performance.

Unfortunately as previously stated, the Maker API combined with MSR may be the culprit(Not saying it is).... A side note, RM5 in incredibly powerful once you wrap your head around it. On a personal note, I try to introduce little outside things to my HA network. I find it easier and more efficient just to let HE handle everything. (Obviously it's JMO)...

1 Like

I don't know how MSR would play any role here as it's completely off-board and just passing commands. If there is an issue within Maker API then it's going to impact anything using it, not a specific app.

That being said, the issue only create up in recent days. Rule#1 of troubleshooting: "what changed?" and that was the ghost removal.

I can say that I added the app you noted and that helped turn off lights and close blinds immensely last night. One attempt and everything did what it was supposed to do - many thanks!

1 Like

In another thread, it was posted that the events and states should be set at 11. Anything that was 10 or less would put the hub into a continuous cleaning loop. Or at least that was the case around 2.2.8 when the DB would continue to grow and grow and grow.

Same for me. I also came from Reactor for Vera and literally EVERYTHING is in MSR. I do not use Rule Machine except for a couple of variables that get set, and then used within MSR. If you are not running a newer version of MSR, there was an issue found and ToggledBits added in a delay between commands. Build 21331 introduced a 25ms pacing delay to not overwhelm the HE hub

Yep, I was party to that issue that led there. I generally stay on the bleeding edge of MSR (has resulted in being burned maybe once or twice :wink: ). ToggledBits is one of the most responsive devs I've ever worked with, not gonna lie.

1 Like

Hmmm... interesting. Wonder if this is still the case.

Looks like this was resolved in a later release and is a non-thing any more.