using SQL-logger db to analyze insteon signal errors

Posted on
Sat Dec 30, 2017 3:56 pm
dduff617 offline
Posts: 659
Joined: Jul 05, 2006
Location: Massachusetts, USA

using SQL-logger db to analyze insteon signal errors

I was thinking about querying sql-logger db to extract hopefully-useful statistics related to Indigo's Insteon signaling errors.

So I'm trying to figure out how to find this type of error. Here are some examples:

Code: Select all
id          ts                   iserror     typeval     typestr                  message                                                                   
----------  -------------------  ----------  ----------  -----------------------  --------------------------------------------------------------------------
206         2017-12-20 00:10:27  True        1           Error                    resending previous command (reply mismatch)                               
211         2017-12-20 00:10:34  True        1           Error                    resending previous command (busy or unexpected command)                   
1757        2017-12-20 12:33:57  True        1           Error                    "Hot Water Circ Pump Main (new)" on; send failed (no acknowledgment)     
1831        2017-12-20 12:50:12  True        1           Error                    resending previous command (reply mismatch)                               
1832        2017-12-20 12:50:13  True        1           Error                    resending previous command (busy or unexpected command)                   
1940        2017-12-20 13:01:10  True        1           Error                    " motion PR Light" beep request; send failed (no acknowledgment)         
3033        2017-12-20 19:59:29  True        1           Error                    " motion - Slave 0-1 stairs KPD" keypad button 2 off; failed (checksum in
3046        2017-12-20 20:01:04  True        1           Error                    " motion - Slave 0-1 stairs KPD" keypad button 2 on; send failed (no ackn
3258        2017-12-20 21:32:35  True        1           Error                    "NBR Ceiling Track Lights KPD" keypad button 6 off; send failed (no acknow
3388        2017-12-20 22:31:47  True        1           Error                    "RND Upper Wall Light KPD" keypad button 8 on; send failed (no acknowledgm
5035        2017-12-21 10:04:49  True        1           Error                    " motion - 2FOY Cans" on (scene 17 cleanup); send failed (no acknowledgme
5291        2017-12-21 12:11:22  True        1           Error                    "GAR Entrance KPD" on (scene 26 cleanup); send failed (no acknowledgment)
5306        2017-12-21 12:16:36  True        1           Error                    "GAR Entrance KPD" off (scene 26 cleanup); send failed (no acknowledgment)


A few quick observations specific to logs, and SQL-Logger plugin:

The "type" field for all the Insteon problems I observe seems to be always just "Error" (this is where plugins and things typically put the plugin name for example). Seems like it would be nice if there were a category (type) value for Insteon failures. Supporting this idea, I do see for example that Z-Wave errors have their own distinct type ("Z-Wave Error"). Is it the case that "Error" is in fact used only for Insteon transmission errors? I'll have to dig further to see if that proves to be true.

The error report sometimes (but not always) contains info about which module is the involved in the comms error. This is info I'd really like to have for identifying problems (failing or dead module, bad signal propagation to/from a given module, etc.). Its not ideal to have to parse the device out of the "message" string (vs. having in a separate field), however I can live with that and I realize that the eventlog_history table is designed to be very generic.

The log event sometimes seems to leave out key info that would let you tell what was going on, for example the error with message "resending previous command" tells me neither what the command being sent was, nor the target (device) of the failed communication, unless I go back and analyze the full stream of all events. Actually, I question whether it makes sense for the "resending" log message to be of type "Error". Seems to me the actual error was the preceding (failed) send event, and the resending command is just in informative activity log message rather than an error per se.

I'll keep working to see what I can pull out of my log db about Insteon problems and perhaps group at least some of them by device. Quick at-a-glance reaction is that a disproportionately large fraction of my errors seem to involve keypadLincs. But otoh, it could be that this is because I'm using Insteon commands to keypads that may log errors differently than other generic device on/off commands (e.g. by using extended commands to turn on LED buttons, beep, etc.).

I'll also have to figure out some way to estimate the total # of commands (including non-errors) being to or from a device and then see if I can combine this with error data to generate an approximate failure rate. Otherwise, i suspect it is going to be trivial to show that the most-used modules generate the most errors, but that's not exactly the point of what I'm trying to do.

I'm wondering if anyone might have taken a crack at this already?

Posted on
Sun Dec 31, 2017 1:11 pm
matt (support) offline
Site Admin
User avatar
Posts: 21411
Joined: Jan 27, 2003
Location: Texas

Re: using SQL-logger db to analyze insteon signal errors

You are correct that currently the information logged isn't detailed (or consistent) enough to accurately collect information on INSTEON failures. We have on our feature request list both improving logging details (and control over how logging works in general) as well as storing device level statistics on command failures.

The "resending previous command" is a low level INSTEON communication failure caused when the INSTEON is too busy (probably processing INSTEON incoming commands) to be able to communicate with Indigo. Indigo doesn't log that the command has failed to send because Indigo is still in the process of just trying to communicate with the PowerLinc to get it to accept the request to send the command. That is, that is a very low level failure (and is indeed an error and should be logged as such) that is happening at the Indigo <-> PowerLinc communication level (not the PowerLinc <-> RF/Power Line level). I do agree it would be useful if Indigo logged more details, at least the device target for the command.

Image

Page 1 of 1

Who is online

Users browsing this forum: No registered users and 3 guests