Repair failed node neighbor discovery (report failed)

[gwp1]

@neonturbo

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?

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:

If so, what settings would you recommend?

@neonturbo

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

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.

[neonturbo]

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.

@gwp1

I use Multi-System Reactor

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?

[gwp1]

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.

[rlithgow1]

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)...

[gwp1]

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!

[3rdStng]

@neonturbo

Events, 10
States 10

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.

@gwp1

I use Multi-System Reactor as my rules engine so anything I want to control must be added to Maker API

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

[gwp1]

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 ). ToggledBits is one of the most responsive devs I've ever worked with, not gonna lie.

[gwp1]

@3rdStng

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.

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

[gwp1]

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