ELA

Hello and Welcome to this forum, Are you willing to become an Automation Hobbyist? If not then I would recommend you stay with the Hub. I may be incorrect but I would think that most here would consider their automation interest a hobby. It definitely demands a bit of your time if you want to explore all the powerful features that an ISY/EISY can add to your existing automation installation. If you are willing to spend the time required the people on this site are great at offering their time to help you along the way. As already mentioned it would be helpful if you described a bit about your existing installation. I would suspect that you had to spend some time getting your existing installation up and running reliably. You say you are having some issues now with the Hub. Are you sure it is the hub? Many experience issues with getting their communications between devices reliable. If existing issues are communications related, then changing to an EISY alone may not be all that is required. Having to resolve communications issues can make you a hobbyist :)

Techman, What I was sharing has nothing to do with programs. The older style MS Sensor by default sends both ON and OFF commands. Link the MS sensor to the PLM via ISY994 - no programs created. Activate the sensor several times and read the excel log. You see both On and Off commands logged. Install jumper #4 for ON only mode. Activate the sensor several times and note that the log contains no commands from the MS sensor. This is what occurs in my ISY994 rev 5.0.15 firmware. I have always assumed this was a bug in the ISY firmware and that it was likely fixed in later versions. I was curious if this might be the case in the EISY and its versions of firmware or if it has been fixed.

Techman No I am not asking for assistance in debugging programs. I was sharing that two of my IR sensors, that are configured to report both day and night, and to send only the ON command, do not show up in the log. That fact can make debugging more complicated. I am just a little curious if that particular IR configuration, coupled with certain firmware versions, and failing to report to the log, is unique or if others may also have experienced this.

I am still running an older ISY994 running ver 5.0.15 firmware and noticed that some IR sensor on/off activations do not show in the log. I have 8 IR sensors total and 6 of those 8 report all on/off actions to the log. Those 6 are configured to only trigger at night. The 2 that do not report to the log are configured to be active both night and day and send On only. I have found that a little frustrating when trying to debug program issues. I am not sure why that the lack of reporting happens for that configuration. I always assumed it was a bug that was fixed in newer releases but perhaps not?

You suspect? NEC 250.118(A)(13) says it is ok.

Hello Merlin, Do you have any plug-in modules such as a Lamplinc? Did not see any in your list. Here is one test that might help you progress using a plug-in module ( maybe consider getting one if you do not have one). Create an isolated test network using your new filter. With the filter plugged into a wall outlet plug a power strip( ideally one not advertised as a suppression device) into its filtered output. This somewhat isolates everything plugged into that power strip from the rest of your home power. Now plug your PLM and the one pluggable device ( I will refer to it as "lamplinc") into that power strip. Now see if you can communicate between the PLM and that one device only. If you cannot then you may need a new PLM. If you can communicate between the two use the level 3 viewer and confirm that the "hops left" are 2 or 3. Next put the PLM back into its normal location ( no more filter used). Put the Lamplinc next to it in the same outlet. Use the level 3 viewer to see what the hops remaining are. If that does not work try the same at another outlet location. If it does work then you can start moving the Lamplinc to various other locations and use the hops remaining as an indicator of the quality of the communications at each new location. This could help you zero in on a problem area of the homes power distribution. Watch as the number of hops left decreases greatly.

Some newer Refrigerators utilize a VFD on their motors. At an increasing rate they are tripping GFCI's. This is being recognized and Leviton is now offering a Wifi connected GFCI to report when it has been trippped. Here is a link: https://store.leviton.com/products/20-amp-smartlockpro-wi-fi-certified-smart-gfci-receptacle-outlet-white-d2gf2-kw?variant=43908872175846

Sure there are lots of ways to test a PLM to see if it's ANY GOOD. Its important to note that there are many different operational aspects of a PLM to be tested in order to assure that it is TOTALLY GOOD. Brian detailed a good method to test the serial interface of the PLM. As he pointed out that requires quite a bit of effort , but is doable with a serial terminal test program such as Docklight. Docklight is a great tool to have. An easy way to test the power line communications aspect of the PLM is to add it, like any other Insteon device, to your existing ISY/PLM setup. Use the Add Insteon device option, enter the address, and have it auto find the PLM you want to test. It will add to your existing network as an unrecognized device if it is operational. You will have limited ability to communicate with it as an unrecognized device. The Beep option should work as a test. You can then also monitor the comms using the level 3 viewer looking at the hops used. You can move it further and further away from your system PLM to stress its ability to communicate over longer distances within your network using more hops. I have some more advanced tools at my disposal to test Insteon devices. I have done a lot of pre-testing of new devices before adding them to my network. One reason that pre-testing can be important is for identifying new devices that are not always TOTALLY GOOD. I once returned a brand new 2413S PLM because its power line signal strength was only 1/2 that of what a new PLM should be. While that PLM might work ok in some Insteon networks it may also work very marginally in many other networks.

Thank you Athlon, Hopefully Blackbird will update when they test theirs. I suspect the 0.8w is correct and that is the power wasted when nothing is displayed. It might be interesting to see a screen shot of the current values when full on. I found the Kasa site somewhat lacking in details. From what I could derive the string is 150 leds total, with each cuttable section consisting of 3 leds, as a "color zone"? One control IC per 3 leds.

Hello Athlon, I am curious about the screen shot reporting of current , voltage and power. It shows 0.8W ( assuming when off)? Do you happen to know if that is accurate? The reason I ask is because Addressable LEDs can be pretty inefficient when powered up but nothing is being displayed. For the 5 volt LEDs I am using each LED also has its own IC that receives commands and controls that LED. Those ICs take 1ma each. So with a matrix/string of 512 LEDs that is 0.5 amps x 5volts = 2.5watts. That is when nothing is displayed. It is for that reason on my displays that I added circuitry to turn off ( interrupt power) to the string when nothing is being displayed to save energy. The microcontroller remains alive for wifi connectivity, just the LED string/matrix are unpowered I am curious if the Kasa product attempts to so something similar or not?

Addressable LEDS I expect that the ISY will only call up preprogrammed sequences. I have used several Addressable LED strips and matrixes that I interface and program via a wifi capable arduino microcontroller. That allows one to have total control over unique sequences and ability to use your own network command set interface with the ISY. https://forum.universal-devices.com/topic/32992-addressable-led-visual-display-board/?do=findComment&comment=313775 I am currently working on a 48 x 48 ( 2304 LEDS) panel matrix.

Hello rssorensen, That is an interesting issue. Is it a GFCI breaker or receptacle? If a breaker how long would you estimate the wire is from the breaker to the Insteon outlet? GFCI device? Does the GFCI ever trip randomly ( not during an ISY Query)? In theory Insteon signals should not trip a GFCI. There have been reports of it though. GFCIs are not all created equal. Some older units are prone to nuisance tripping. If it is an older unit you might try replacing it. If you ever experience random tripping it is possible that you have a continuous leakage ( long wiring length) always and that the Insteon signals add to that and cause the trip.

Smorgasbord, I spent a little time refreshing my memory by retesting as it has been a long time since using a terminal program with EZIO8SA8. I am attaching a pictorial of the serial cable needed ( Brian provided pinouts earlier). If you every bought a 2413 PLM by itself you should have received one of these cables with the PLM in its box. First Connect the EZICOMM to the terminal program and see if you can communicate with it . ( this is to assure you have the terminal program setup correctly). Brian supplied the terminal program parameters ( baud etc) earlier. If you send an "02 60" you should get a response as shown: If you have that working then you will need to swap pins 2 and 3 ( Rx and Tx) at the DB9 connector to be able to talk direct to the EZIO8SA module at its J2 connector. As soon as you power up the EZIO8SA you should see it sending the message as shown. That is the EZIO8SA trying to change the EZICOMM's Category and sub -category values to "07 04". Since there is no EZICOMM connected in this scenario it sends it over, and over and over again. If you do not get this then the EZIO8SA module is likely not working correctly. The EZICOMM(PLM) does not store any updated Category and sub-Category value upon power down. So the EZIO8SA needs to provide that updated Category and sub-Category each time the pair are powered up together. Hope this helps and good luck. If there is an extra duplicate screen shot at end ignore it. I could not remove it for some reason.

Thanks Brian, That confirms it is not reporting as an EZIO8SA. My notes show it should report as "07 04" and that is what I see with mine. My notes also indicated that when I later factory reset the EZICOMM(PLM) it then reported as "03 2A" Also note that the message link response was NAK ed. " 15" .