ELA

IndyMike, I am aware they did not implement RS232 handshaking. Further the RS232 interface used is full duplex so collisions at the RS232 interface should not be possible. Agreed there has been a lot of speculation regarding the root cause and no need to start a crusade. I experienced 3 All-On events, before implementing delays after IR sensor activations, a long while back. I had one event that I am pretty sure was caused by an ESD event into the power line near an Insteon device. Hard to explain that one. I totally agree with your efforts to warn people about the hazards associated with using Insteon for critical or secure applications. I would monitor my garage door but would never use Insteon to activate- open/close it.

Thanks IndyMike, I had not heard about the RS232 interface as the possible culprit. Kind of a large oversight if that is the case since RS232 handshaking would prevent that if they had implemented it.

My best understanding of the All On phenomenon is that it is caused by data collisions at the signal level. I have not heard of a PLM issuing a phantom All On command itself. It was my understanding that Insteon was removing the ability of devices to react to the All On ( Group broadcast to group FF) over time. Until all devices firmware's were updated the All On phenomenon could remain an issue. What I have not heard about is: whether or not the ability of a device to repeat a Group Broadcast message to group FF was also being removed? One would hope so.

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.

I had not heard that before. Can you please explain why/how they are noisy?

IndyMike, Did you use one of the Israeli made Insteon Jammers If not curious how you accomplished the "jamming".

Hi IndyMike, Great information. I had never used them and had wondered how they might dissipate the required wattage in a small package if resistive. Makes sense to use a cap. rather than a resistor. They must be a fairly large cap. to present enough of a load and thus they be a large signal sucker. What did you mean when you said will absorb Insteon signals even when downstream from the dimmer? Just when the dimmer is on, is that correct? Auger66 , Please excuse the rest of this post slightly off topic. I have researched the subject of Flickering LEDs lights and found it to be very common for several reasons in addition to Insteon signals. Some people are reporting Flickering lights due to TWAC signals used in some smart power meters. As I read up on that I found it very interesting how TWAC is distorting the 60hz sinewave at the zero cross point. While nice for the Utility company it seems like a potential problem for so many devices expecting a "clean" zero cross signal reference. One interesting post was from a Lutron salesman that has all Lutron dimmers in his newly constructed house, used for demos of the products he sells. All his LED lights flicker. Source of the issue is as of yet undetermined but the TWACs signal was discussed as the potential source. Of course that only happens for short periods of time, at certain times of the day, when TWAC communications is active.

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

When you add it to ISY do not specify a device, enter only the address and use "add Insteon Device". Forget the backup. If that does not work .... Have you ever used SHN or a terminal program for RS232 communications? Docklight used to have a free version. Not sure if that is still true. You can google it and download both the program and the basic Insteon command set to get started. If you do not have a serial port you will need a USB to RS232 converter. If you have not done any of this before it is a lot to explain. Hopefully others can contribute.

As Brian said your EZICOMM(PLM) is not bad. If you really want to pursue it further you could use the SHN utility or a terminal program such as docklight. These allow you to send and receive messages that the ISY does not normally display. I would be interested in how the EZICOMM is reporting its "Device Category" and "Sub Category". Q) When you add this device does it display only one item , as you showed early on? If so then my best guess is that the EZIOSA8 is not communicating with the EZICOMM via the RS232 connection between them. Therefore the EZICOMM is not reporting as a EZIOSA8 but rather just as a standard PLM. Requesting the Version information "0x02 0x60" from the EZICOMM would confirm if that is true. It is possible to communicate directly with the EZIOSA8 module (RS232) via a terminal program but that may be a little more complicated that you want to attempt? Short of more in-depth data send/captures you might try a different cable between the EZIOSA8 and EZICOMM if you have not already. There is a length limit on that cable so use a short one for best case testing.

As Brian pointed out the EZICOMM is communicating with the ISY. What wall wart are you using to power the EZIO8SA? Is it possible that the EZIO8SA is not powered properly? Can you measure the voltage at the +12V to GND terminals on the EZIO8SA? Make sure the EZIO8SA is powered correctly and connected to the EZIOCOMM at the time that the EZIOCOMM is plugged in. The EZIO8SA sends communicated with the EZIOCOMM on power up to enable it to be recognized as an EZIOCOMM rather than a standard PLM. I have an old EZIO8SA that I have not been using. I just added it to the ISY without issue. All 8 outputs and 6 inputs were added and displayed. I could turn on and off the relays without any need to adjust any default config. settings. I would focus on "adding the new insteon device" until all 14 I/Os are added successfully rather than restoring any old setups.

In Support of Brian's comments to the fact that each Insteon PLC device is a "signal sucker" of sorts to all other Insteon PLC devices: Below is a listing that quantifies how severe of a signal sucker common household devices are. Actual current measurements were taken at the Insteon PLC frequency. Those currents were then normalized to the same current demand level that a single Insteon device presents to the power line. If a person believes that adding an EMI filtered plug strip, or any device with an across the line filter capacitor, can be a signal sucker; then the chart shows that any a single Insteon device is a signal sucker to that same level. As Brian pointed out, in marginal situations, two devices next to each other could aggravate a communications issue. Yes dual band devices and re-transmissions help negate the signal sucker effect of each Insteon device to some extent. Still none the less true that each Insteon device is a signal sucker.

Hello Mr. Bill and thank you for asking, It uses a MKR1010 wifi enabled microcontroller. Running Arduino wifi code. I like that it allows you to define your own network commands. Makes it very flexible. I have several MKR1010s running various items in the house including automated cat feeders. The project was driven by a desire to be able to display all my IR/door sensors with a map that made it easy to see which were active at any time. I was using an 8 button keypadlincs leds as their status up until now so it is a nice improvement. I am sure there are more elegant displays but it was a fun project.

Video view when completed: https://media.giphy.com/media/mK0xyRyxuw69p0DuOJ/giphy.gif

Wanted to share an idea for an ISY based Visual Display board using addressable LEDS. With thanks to Ajax for introducing me to the addressable LED idea on this forum. Happy 4th! I had a need for additional indicators for my various sensors around the house. I was using an 8 position Keypad's leds up until now. That of course was limited to 8 LEDS. This new display is a matrix of 512 addressable LEDs in a 16 x 32 pattern. Enough to make crude graphics, display text, and report IR/Door sensor status. I am posting a few pictures of the project and a few displays. The house outline is in demo mode to show all sensors on. I am still working on a best way to diffuse the lights best.

Thank you both for sharing. I like the idea of an automatic intake in case no windows are open.

I have had a quietcool WHfan for many years and am very happy with the sound level. The specification for sound level appears to be better than for the airscape WHfan. ( depending upon model of course.) I considered automating the controls just because I could. However dont whole house fans require the windows to be open? Do you automate the window opening as well? I have my annunciation system tell us when the outside temperature is lower than inside so that we can open the windows and turn on the WHFan.

The constant current technique to measure resistance is limited by the basic R=E/I equation. Thus the maximum R that can be measured is therefore limited by both the voltage that the meter is using and also the constant current source value. For that reason some meters will change the constant current source value depending upon the Resistance value they need to read. A lower current source allows for higher resistance readings. When a meter reads "OL" it is being limited by either its voltage or current source. Using the diode setting on a meter is measuring the junction voltage of the diode and is not related to resistance. Unlike a resistor a diode is a non linear device. You can also use the diode setting to measure some LEDs. Red and Green LEDS have a lower junction voltage and a meter on the diode setting usually has enough voltage to both light the LED and display its forward voltage. You can make a constant current source very easily using a 3 terminal voltage regulator. I have one that I use with a 30volt power supply. That along with a volt meter allows it to measure Zener diodes and higher voltage LEDS such as White and Blue. These tools all work great when measuring parts on the bench. Measuring "in circuit" is often much more difficult because of what we call "in-circuit effects" Parallel pathways for current flow that adversely affect the accuracy of measurements.

Have you turned on the battery node in the MSII? Turn on a level 3 event viewer and confirm that the MSII Query is sending the required data required to load into your variable.