ELA

I performed a factory reset on the new I2CS Appliancelinc prior to a third attempt to Auto-Discover and this attempt went flawless. A forth attempt (just for test purposes) resulted in the ISY hanging once again. This might be due to operator error on my part? Q1) I believe the best way to remove a device is to delete it from the ISY prior to factory resetting of the device, is that correct? This being to to remove all links on both ends? Q2) If you factory reset a device first, then delete it from the ISY, does this fail to remove the links in the ISY -PLM? I was surely seeing some strange behavior in the ISY and wonder if at least part of that was partial links not removed. I was seeing the ISY lock-up and never time out (> 10 minutes) which seems very strange. I would expect it to time out no matter what, unless the code was hung. This appeared to be the case because I had to power reset it 2-3 times in this testing process to get it to stop presenting the "Initializing System Window". The last time this happened I saw that it was hung attempting to work with an address shown on the screen that belonged to a MS(PIR) sensor ? The new Appliancelinc was not added to any scenes, and why would it hang up on the forth attempt but not the third? I then had a successful 5th auto-discover linking and am leaving it as is. I am up and running fine now so no need to pursue this any further. I am just reporting this back in case is not all due to errors on my part. I do have a new Switchlinc Dimmer (V5.6, suspected I2CS) to install on Sunday so I will see how that one goes. That will be a replacement of an existing older switchlinc dimmer (non I2CS).

Yes LeeG the ELAM issues the 0x0D command. I will attempt the auto-discover again this evening. here is the beginning of the log from my third attempt last night, using manual linking. Wed 04/04/2012 10:29:55 PM : ---- Initializing the linked devices ---- Wed 04/04/2012 10:29:55 PM : ---- All Linked Devices are now initialized ---- Wed 04/04/2012 10:29:55 PM : ---- Add remaining devices ---- // Flags .. get engine Wed 04/04/2012 10:29:55 PM : [iNST-TX-I1 ] 02 62 1C F3 17 0F 0D 00 Wed 04/04/2012 10:29:55 PM : [iNST-ACK ] 02 62 1C.F3.17 0F 0D 00 06 (00) // I2CS = 02 Wed 04/04/2012 10:29:57 PM : [iNST-SRX ] 02 50 1C.F3.17 1B.FD.23 2B 0D 02 (02) Wed 04/04/2012 10:29:57 PM : [standard-Direct Ack][1C.F3.17-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Wed 04/04/2012 10:29:57 PM : [1C F3 17 0 ] Calibrating engine version Wed 04/04/2012 10:29:57 PM : [ 1C F3 17 1] Adding device to ISY t=02.0C.0000 Wed 04/04/2012 10:29:57 PM : [1C F3 17 1 ] Start : Adding device to ISY Wed 04/04/2012 10:29:57 PM : [1C F3 17 1 ] Finish : Adding device to ISY was Successful No nak bit and a valid "0x02" response. This makes me think that the appliance link must have been "aware" or at least partially linked from the previous 2 attempts? I will do a factory reset before any further attempts tonight.

LeeG, I do not know if my Fanlinc was I2CS. I do not think it was but I will check on that. I never attempted to add it to my ISY prior to upgrading to 3.2.2 , ... knowing that I needed that version. I did power cycle both the PLM and ISY before my second failed attempt last night. I had some time so I tried communicating to the new Appliancelinc with my ELAM (isolated bench test). As expected it gets response messages (to a direct msg send) but they are not acted on since the ELAM is not in the I2CS devices link data base. When I added the ELAM to its (appliancelinc) link record then the direct commands were accepted and acted on. What this allowed me to see is that if the device is not in the link record the response sets the MSB of the flags (broadcast/NAK bit), Flag byte =0xA1. It also puts a 0xFF in the Cmd 2 byte. So what is very interesting is when compared to my original failed log, ... The I2CS appliancelinc returned the 0xFF in cmd2 but it DID NOT set the NAK bit ??? This seems to be an inconsistency?

Hi LeeG, I do not think this would be an network communication reliability issue. When I linked it manually all the comm was very good and the process completed very fast. If it would not have linked manually I would have put the device right next to the PLM just to be sure, but manual link worked great ( as best as I can tell). I was short on time as it was bed time last night and I expected the process to only take 5 minutes.. I will delete it and try auto-Discover once again tonight. I am unsure of firmware level but I just replaced the PLM a few weeks ago. I believe it is V99 firmware. Now you have me thinking... As we introduce I2CS devices how does that work without upgrading the PLM to be I2CS compatible? When I have time I am reviewing the successful manual link log. It looks like the get engine request returned an "0x02" in cmd2. Guess this must indicate I2CS device? I just looked at the failed attempt and the get engine returned 0xFF in cmd2?

Can you use auto-detect to link new I2CS modules in V3.2.2? I updated my ISY99 to 3.2.2 last Sunday. All went well. I added an existing Fanlinc, created a couple of scenes and all went well. Confirmed Running 3.2.2 in both listings in "about". I did not log into the ISY until last night again. I had a lot of trouble even getting the ISY up and running. Only initial white screen (no 2nd Blue screen) would come up. Authentication input would fail to work. I will not expound on that for now but wanted to mention it. I eventually got it running after reloading Java (perhaps just the cache needed emptying? ... I had emptied cache after the install on Sunday). Now all seemed to be running as it should. Did a few queries to be sure of comm. I then tried to link a new Appliancelinc (2456S3, V 4.6). I used auto-detect. A few intial commands were sent and the Appliancelinc went into link mode (fast blinking white LED). The ISY then hung in a loop "initializing system". It timed 0-100% on that screen 3 times (over 10 minutes) and I could not exit. Rebooted computer. As soon as I entered the ISY again it was still hung in that loop. I rebooted the ISY. Now I could not get a query to work. Exited and reentered ISY. Now all is fine. Tried a second attempt at Auto-detect linking and it failed in the same manner. Had to reboot the ISY and reenter program twice to get query working again. On my third attempt I did not use auto-detect and instead picked the 2456S3 device. I also manually put the appliancelinc into link mode using the set button. This time it linked fine. What I expected to take 5 minutes took over an hour. All I really wanted to accomplish was getting a log of the new device link to confirm it was I2CS. I think there may have been a few things going wrong at once and I did not want to focus on all of them. Just the question of auto-detect for I2CS? Here is the log from the very first attempt that failed and hung: Wed 04/04/2012 09:48:53 PM : ---- Initializing the linked devices ---- Wed 04/04/2012 09:48:53 PM : ---- All Linked Devices are now initialized ---- Wed 04/04/2012 09:48:53 PM : ---- Add remaining devices ---- Wed 04/04/2012 09:48:53 PM : [iNST-TX-I1 ] 02 62 1C F3 17 0F 0D 00 Wed 04/04/2012 09:48:53 PM : [iNST-ACK ] 02 62 1C.F3.17 0F 0D 00 06 (00) Wed 04/04/2012 09:48:54 PM : [iNST-SRX ] 02 50 1C.F3.17 1B.FD.23 2B 0D FF (FF) Wed 04/04/2012 09:48:54 PM : [standard-Direct Ack][1C.F3.17-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Wed 04/04/2012 09:48:54 PM : [iNST-TX-I2CS] 02 62 1C F3 17 1F 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 F6 Wed 04/04/2012 09:48:54 PM : [iNST-ACK ] 02 62 1C.F3.17 1F 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 F6 06 LNK-ON (01) Wed 04/04/2012 09:48:54 PM : [iNST-SRX ] 02 50 1C.F3.17 1B.FD.23 2B 09 01 LNK-ON (01) Wed 04/04/2012 09:48:54 PM : [standard-Direct Ack][1C.F3.17-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Wed 04/04/2012 09:48:54 PM : [LNK-BGN ] 02 64 01 00 06 Wed 04/04/2012 09:49:26 PM : [ Time] 21:49:26 0(0)

While it might seem unlikely I have had the same thing happen to a dimmer in the kitchen. I am guessing the someone hit the paddle very near the bottom and also engaged the air-gap at the same time. This has happened twice on a dimmer in my home. I do not know of a way to disable it.

Thank you much LeeG, I hope to experiment with this when I have time. As it is now I use hardware jumper config in my MS's. If I could easily update the configuration without having to access the PIRs I would then use the firmware configurations option. Thank you UDI for making my PLM restore so easy in terms of automating the process. Very gracefully handled! Quite the test of ones communications reliability I imagine in some cases. I located one low battery when restore to that device failed. It was as big of a trouble as I suspected up and down the ladder though for the RF devices. It would be a very nice feature to be able to update the PIRs via a motion activation if it could be added at some point in the future?

Thanks LeeG, Now you have peaked my interest . It sounds as though you are saying that it is possible to write a link record ( or configuration updates?) to a PIR device within some window of opportunity after motion detection then? Any specifics you could possibly offer? If it is not too complicated I would like to experiment with it in my custom tester.

Thanks for the replies, Thank you LeeG for the additional instructions. I had hoped you would say that I could simply wave my arms in front of the PIR detectors and they would wake up long enough to relink The replacement just arrived. Let the fun begin.

Michel, I have always felt that the ISY was a good quality piece of hardware/software. Thanks for sharing the statistics that prove that to be the case. To be fair to the PLM it does have the nasty job of having to directly interface with the potentially harsh 120VAC power distribution environment in order to accomplish its PLC communications. I would love to hear the failure statistics along with the root case analysis of PLM failures. If mine were not under warranty I had intended to further diagnose why it failed. While I did test and confirmed no PLC transceiver ability I am guessing it had even an even larger problem in that it would not Factory Reset either. Maybe we need redundant PLMs to backup the most excellent ISY stats I am somewhat dreading replacing my PLM. I read several threads on how to Replace a PLM so that did not seem to be much of a chore. The ISY appears to do a great job of handling that task. But I had not considered the RF devices and now that bothers me. The need to get on a ladder and take apart (&wake up) 6 PIR sensors and two triggerlincs does not excite me one bit.

I am sure my ISY does get lonely since I moved it out into the garage. Especially now without the company of its tag-a-long PLM. I agree with you Illusion. I don't really want to have an inferior, or less feature full product, that I never use and its warranty runs out sitting on a shelf. That was kind of my thinking in keeping a 2413U on hand. I could either use it for test or as a replacement for the system PLM. I prefer the USB version when doing testing. I figured I could swap out the daughter board if needed to the RS232 version for the a system replacement. I thought the PLM would fail after the two year warranty and I could use the RS232 daughter board from the defective unit ( a slight gamble there as well). It is nice to have a spare PLM for testing so it can serve a dual purpose. (e.g.) It was great to be able to use the spare PLM to send a direct message to the suspect PLM in order to confirm it was defective. I also monitored the line with a OScope just to be absolutely sure the PLC transceiver section was not operating. A Pro model would be great. Or at least a more robust model for use with the ISY. I would certainly be willing to pay a little more for a reliability increase.

My ISY->PLM just died. I have a new 2413S on the way from SM under warranty ( only 1.7yrs old). I thought I had a spare but that was a 2413U. I had intended to swap the serial daughter board from the bad unit into the new 2413U if I ever had an issue ( assuming the serial brd was not the problem). However since they are sending me a new 2413S under warranty I was not able to swap the serial daughter boards. This leaves me down for a few days and I really miss my ISY!!! Over time I had migrated towards a heavy emphasis on ISY directed items such as PIR detection actions, curtain control, and some scenes. Not having my ISY now has me reconsidering some scenes that I might now reconfigure so they to not require the ISY in order to still be active. My point here is that if you are heavily reliant on your ISY you might want to be sure to keep a spare PLM on hand ( if you do not already). Of course the ISY is so awesome I am assuming it will never be an issue I know the older PLMs tended to fail with a limited lifespan. I was not sure if the new ones would last longer. 1.7 years was much too short and I will now be sure to have a compatible spare on hand.

Great write up Brian, Thanks for your attention to detail and for sharing.

I vote for "Spill the guts!" And let us see all the gory details! Really though ... if you return it wouldn't it be worth a call to alert them of the issue? I know how frustrating it can be trying to get them to understand there is an issue so no one could blame you if you simply returned it.

Hi Brian, I know this is probably not really important information with regard to the 8015 probe but I did measure the minimum response time of the 2450 to a pulse on the sense input and the unit tested would activate at 40 milliseconds. Of course this value my vary a little from unit to unit but just for anyone's future reference. At the 40 msec it would send all four messages. This is pretty fast although probably a little slow still for the 8015. Will you followup with Smarthome as to your findings on the 8015 and return the unit? I am still curious, did they forget to load some parts or what? A device that will track the 60hz ac input with a square wave out seems to have limited usage? Especially if it is not pulling below 1 volt?

Agreed that a interposing relay is always an option and a good suggestion. Brian, You had spent enough time investigating that I thought it might be interesting to understand more about how "someone at SM" thought that the 8015 could be used with the 2450. You stated that an AC input to the 8015 produced a square wave output. How close did the "low time" come to ground, was it below 1 volt? You also stated that a DC input produced a pulse that came close to zero. Do you have an estimate of the time that that pulse was below 1 volt? I would like to know if the short pulse of the 8015 could possibly be enough to cause the 2450 to at least send an on/off command. OmegaQuest did not "see" a transition in the ISY status but it might have been too fast for him to observe (that is if the 2450 sent a on followed immediately by an off). If there were no log entries then I guess that answers that. We are talking about milliseconds here and I have no idea if the ISY would be able to trigger in a program if the 2450 did send back to back on/offs. I am just wanting to get a little more understanding. I intend to run tests early next week when I have access to the required equipment to determine the minimum pulse input required to cause the 2450 to recognize a pulsed input ( both in terms of relay activation and sending an on/off command).

Thanks LeeG, I should have stated, "what is the reaction time of the 2450 input". Minimum pulse time required? I do not have much time this morning but I set up a quick test. When I pulse the sense input (as fast as I can with a quick touch of a wire to input) I see the led flash briefly and the unit does send a command over the power lines. Perhaps this unit reacts to a faster input (communications wise) than it takes to energize an output relay. It would be nice to know the actual time requirements to active the individual components (comm. vs relay out). I could do this early next week for interest sake if Brian does not beat me to it If there is an ISY involved in this setup maybe a program can be used to catch the faster input and drive the output relays with another command (to pulse the relays for long enough to trip the doorbell?

Excellent information Brian, Thanks for including that test. As always a picture tells a thousand words and whenever one has access to an Oscope that is the way to go. I have a 2450 I/O linc but have yet to play with it much. I bought it for possible future use and so there is much I do not know about its operating modes. Do you know what the minimum pulse time might be that is required to utilize the 2450 latching mode? Is the pulse time of the 8015 too short for that mode?

Hi Brian, Thanks for that investigative work and report back. Sounds like the scope would be helpful. One thought I had is that perhaps the 8015s output "sources current" rather than sinks it? PNP rather than NPN output? You noted earlier that there are three connections and perhaps they were designed for the other equipment interface you referenced and not really compatible with the I/Olinc? Would you consider connecting a dc source (+5) to the 8015, and then a resistor (maybe 10k) from the output terminal to ground and then measure the output across that resistor ( while varying the input)? This would be a test exclusive of the I/O linc, or just using its supply and not its input circuit.

I will be looking forward to reading about your findings Brian. You are such a good fellow to buy one to experiment with. You would think they had a bridge inside so that polarity would not make a difference? Maybe only half-wave rectification based on the manual listing a polarity? I had an issue finding the 8015 manual. Can you please direct me?

While monitoring a different IOLINC sensor post I had grounded my IOLINC input and measured 1.7ma. That implied an approx 3K pullup. That along with your 800 ohms pull pull down also indicate an approx. 1.0VDC threshold. I had been watching this post in hopes I might be able to offer something helpful. Ouch ... Who would have thought to ask if the meter was on AC or DC Now you might go back and do the 18 volt battery test you mentioned in the beginning once again.

Thanks for the redirection to this post TJF1960, It certainly appears that there is an issue with the V98 firmware given that Smarthome has released a V99 already. This is very upsetting to me. The fact that Smarthome can release what appears to be a buggy firmware version and we have to be fortunate enough to read a post like this one to know we puchased a bad release? In my case I have already disassembled that particular V98 PLM and made a slight modification anticipating making another test device using it. Looks like I am stuck with this turd. May still make an ok tester but hopes to use it as a backup for my system PLM seem to have just gone down the drain.

Hello Tim2U, Unfortunately I do not have a low voltage probe to be able to test and answer directly. As a follow up to Brian's comments on this probe being isolated: You said you measured 9V out of the alarm. Was that open circuit, before you connected the low voltage sensor, or with the sensor connected? The reason I ask is that Smarthomes specifications are incomplete and they do not list an input impedance or current for that sensor. Listing only a voltage does not assure it will work with any 3-24V source. To be sure you either need to know the current requirement or you have to measure with the probe connected ( at alarm side) to be sure you are attaining the correct voltage level. (sorry if you posted that result and I missed it). Also what is your result if you substitute a 9V battery in place of the alarm as input to the low voltage sensor?

Good question Teken, I had not thought about that before. Now that you asked I wonder if that might be a bit of a challenge since the triggerlinc runs on one 1.5V battery. I examined the Motion Sensor battery sense circuit recently. No problem there since it runs on 9V. There is a large margin from 9V down to 6.8V before a low battery is detected. It might be a bit tricky setting the threshold for 1.5V operation?

Have you asked him?