[RELEASE] Error Monitor - Keep an eye out for errors that may pop up in the log

Introducing 'Error Monitor'
Keep an eye out for errors that may pop up in the log.

Features:

  • Simple setup
  • Display a list of errors on your dashboard!
  • Get notified by Push
  • Use built in Switch to trigger a Rule/Cog/Piston

Error Monitor has a couple of failsafe features built in.

  • If the error message is the same as the last error message, it won't send the push unless you tell it to.
  • If the same error message is received 10 times in a row, EM will close the connection and put a warning in the log. This is to prevent the hub from slowing down.

Apps can be found on my GitHub or by using Bundle Manager

When reporting problems...

  • Be sure you are on the latest version. I won't troubleshoot an older version.
  • Turn on debug and screenshot the issue happening in the log. One line or just the error doesn't cut it. I need a log.
  • Post the screenshot of the log with an explanation of the problem.

Thanks

11 Likes

Awesome! Thank you!

I have one question: can there be a "ignore by app or device number" option? Just a thought.

1 Like

The original plan was to include some options but at the end I wanted a stripped down, easy to use monitor. Any error is a bad thing, so I went without including any filtering.

My full blown Log Watchdog with filtering options is done but it can be dangerous. :wink: This also got a complete rewrite and it works awesome. Just didn't feel comfortable letting it out into the wild. Yet... Will see how it goes and I'm sure at some point I'll let it go.

2 Likes

Makes sense. This by itself I think can be a major benefit for those of us that are OCD about our home automation.

I am curious about the other and what makes it "dangerous".

Great app and idea. Thanks.

Just a quick query.
I use pushover and have 3 hubs.
Does the pushover message just say the error or does it include a prefix for the hub ID and then the error message.
Not seeing any errors yet (don't want any either) but just wondering. :thinking:
Thanks again.

It becomes dangerous when the actions taken to address an error cause more errors that the app tries to address, whch then cause more errors and before you know it….

5 Likes

Yeah, that makes sense. The red tags can be very angry! Best to just be told they are there. :joy:

Too many child apps can overload the system. Also, with filters you can 'request' too much info, which again can slow down the hub.

It has the "app/device name that caused the error - date/time - the error"

Steps have been taken to avoid this... code is trapped in try catch statements that spit out warnings instead of errors. Also if the error is the same as the previous error, no processing occurs. Stops the loop-de-loops. :grin:

7 Likes

What can I say, this has already thrown out an error that I knew nothing about.
A file in File Manager for Hubigraphs was corrupt for some reason.
Now sorted.
Thanks very much for this.

3 Likes

It's not working for me anymore. I just checked logs myself and their were errors that I was never notified about. I just the device info and they weren't in there either.

Edit: I noticed it said "disconnected". I do an automated weekly reboot on Sunday morning. I assume that had something to do with it? Will this need to be done every time?

There are many things that could make it disconnect, a reboot being one of them. I'll look into it.

1 Like

I think I might need some clarification of the functions of the device that the info is sent to.

The app says it will turn on when there is new info. When does it turn off? I have one api that connects to a flaky API so it often produces errors but they are the same ones typically. I see in the device attributes that it's grabbing them but I don't get any notifications. I went in and I manually turned off the device and got notification again.

Not saying things aren't working per se, just that I am unclear on finer points of function.

It stays on until you manually turn it off. This way you're not flooded with notifications.

Examples:

  • No one likes their phone to keep getting a push every 5-10 minutes while out at a restaurant.
  • Your spouse is home but you're not. House keeps announcing there is an issue with something... You might have a bigger issue when you get home!

Make sense?

2 Likes

This all makes a lot of sense.

So it might make sense if I make a "acknowledge error" button or sorts?

1 Like

Honest question: I see a method named webSocketStatus in the child device and in several other apps you have written (Event Engine, Event Watchdog, Log Watchdog), but I can’t find anywhere where this method is being called. Is that intentional or am I looking in the wrong places?

Oh no, I also ran into a string of errors:

It's in the driver, initialize section...

def initialize() {
    if(logEnable) log.info "In initialize"
    if(disableConnection) {
        if(logEnable) log.info "Error Monitor Driver - webSocket Connection is Disabled in the Device"
    } else {
        if(logEnable) log.info "Error Monitor Driver - Connecting webSocket"
        interfaces.webSocket.connect("ws://localhost:8080/logsocket")
    }
}

New version available...
1.0.1 - 03/31/22 - Adjustments

Ah, it’s part of the Hubitat websocket interface. That’s what I was missing. I was looking for it to be called explicitly in your code, but I guess Hubitat calls it for you.

Thanks!

2 Likes

Bryan, this does exactly what I always tried (and failed) to get done with Log Watchdog. You nailed it again. Props my friend.

3 Likes

I am still not getting notifications. If I go clear all data then I do. It's very odd.

Download the Hubitat app