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

⚙️ Custom Apps and Drivers Custom Apps
1

*** BPTWorld apps are no longer being developed or maintained. Thanks ***

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
2

Awesome! Thank you!

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

1 Like
3

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
4

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

5

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.

6

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
7

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

8

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
9

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
10

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?

11

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

1 Like
12

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.

13

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
14

This all makes a lot of sense.

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

1 Like
15

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?

16

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

image
image1170×2532 216 KB

17

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

18

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
19

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
20

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