matapan Posted June 8 Posted June 8 With all the discussions around self driving and AI, doesn't it seem like there is enough of a knowledgebase developed now to identify Insteon issues as they occur? use cases: on demand - identify a problem adding a new device, communication issue between controller and device real time monitoring: looking for potential device failures - notify user/administrator of potential failure and provide steps for replacing device, including PLM What do you think? After all, we're on the precipice of robotaxi services becoming a reality. How hard can it be to capture all the collective knowledge amassed on these forums?
Techman Posted June 8 Posted June 8 Most of your suggestions would require the Insteon device to report an issue to the controller, that's something that's not possible with the current Insteon device firmware. The UDI controller can query devices, based on a schedule, and will display an issue in the device tree if it is unable to commnicate with a device. Most issues are either due to device failure or communications failures. There is really no way with the current available technology to diagnose and identify communication issues other than trial and error. At one time there was a company that made a device to monitor powerline noise and display device signal strength but they are no longer around.
vbPhil Posted June 8 Posted June 8 My biggest headache is with scenes. They’re certainly nice when they work but with the electrification of everything now days it’s near impossible to keep all noise off the power grid. Which I guess is the main cause of failures Problem is you don’t know the scene worked unless you’re right there as a witness. Some AI might be nice.
Brian H Posted June 8 Posted June 8 Besides power line noise. You also have power line signal suckers. Many devices with electronics in them. Have an across the power line capacitor to keep internal noise off of the power lines. That capacitor also absorbs both Insteon and X10 power line signal as noise. Best way to find one is unplugging it and seeing if things improve. Since Dual Band also uses RF a signal sucker is not as critical these days but my portable air conditioner killed my old 2456S3 ApplianceLinc until I put a spare Dual Band LampLinc in its pass through outlet on the front.
Techman Posted June 8 Posted June 8 @vbPhil If you have a scene that has issues you can right click on the scene then run scene diagnostics. The report will show you if all the devices in the scene responded, if not it will show you which device failed. You can then troubleshoot that one device.
vbPhil Posted June 8 Posted June 8 9 minutes ago, Techman said: @vbPhil If you have a scene that has issues you can right click on the scene then run scene diagnostics. The report will show you if all the devices in the scene responded, if not it will show you which device failed. You can then troubleshoot that one device. Thanks but the issue is intermittent. Generally they always work but then some won’t for a day or 2.
Techman Posted June 8 Posted June 8 It's probably something on the powerline that's interferring with the Insteon signal. Are all the devices in the scene dual band? What type of loads are the scene devices controlling?
matapan Posted June 9 Author Posted June 9 2 hours ago, Techman said: Most of your suggestions would require the Insteon device to report an issue to the controller, that's something that's not possible with the current Insteon device firmware. The UDI controller can query devices, based on a schedule, and will display an issue in the device tree if it is unable to commnicate with a device. Most issues are either due to device failure or communications failures. There is really no way with the current available technology to diagnose and identify communication issues other than trial and error. At one time there was a company that made a device to monitor powerline noise and display device signal strength but they are no longer around. The kind of analysis I'm thinking of does not require the device to self report a failure. That would be nice, but the devices are not designed with this in mind yet. It is to look at communication event transactions to see if any fail, then pattern match on known problems or failures to pattern match. On an ISY, a diagnostic could take an event log at the most granular level as input for analysis. The idea would be to find pattern matches of communication events which fail because a response was not received.
vbPhil Posted June 9 Posted June 9 41 minutes ago, Techman said: It's probably something on the powerline that's interferring with the Insteon signal. Are all the devices in the scene dual band? What type of loads are the scene devices controlling? A mix of dual band modules and older wall switches controlling lights. The fact that it’s intermittent I just live with it. I’ve tried chasing these issues down in the past and never find anything other than sometimes (sh)it happens.
Techman Posted June 9 Posted June 9 If the older devices are single band then replacing them with dual band devices would give you a more robust insteon mesh network and there's a good chance it would clear up your intermittent issue. 1
IndyMike Posted June 9 Posted June 9 (edited) @matapan, The best Insteon diagnostics that I have seen over the years were provided by SmartLabs Houselinc. There was a signalling diagnostics feature that would allow you to repetitively test your devices. Houselinc is no longer supported but can still be downloaded and works with 2412S, 2413U and 2413S PLM's. Words of caution - Houselinc must be setup on a SEPARATE PLM from your ISY setup. You will need to link devices to Houselinc and it's PLM in order to test them. This will produce link table mismatches for the ISY. It may (on I2CS devices) render the device unreachable by the ISY. Restore can be used to repair link table mismatches. A re-link is required for the devices that can't communicate. Some devices may not be configured in Houselinc (I3 devices definitely not). Houselinc Download Signaling Diagnostics PDF The following shows an example of the testing that can be performed. I was attempting to demonstrate the importance of PLM placement. The test shown was setup to resemble a typical SCENE command as the ISY would perform it. PLM installed near my desktop computer 6 devices tested - 100 reads on each Start Hops set to 3 PLM retry OFF (similar to scene command). As shown in the Success% column, 3 devices showed "poor" communication with success rates in the 60% range. The summary table shows the results of changing the HOPs, PLM retries, Message Retries, and PLM Location. Conclusion - the PLM location was the largest determining factor in the communication success rate. It's not AI, but it's the best tool that I've seen for Insteon. Edited June 10 by IndyMike
Recommended Posts