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