larryllix

I got curious and decided to punch some holes in a LampLinc to let the faint sound "out of the box". At the risk of letting the magic smoke out too I was curious to see how these things are constructed inside. Here is the case cracked open Note the small sounder is glued into the case front and has short wires. It has to be split open front cover to guts but snaps back together after. After removing the heatsink to expose more PCB details. This can be a PITA to get back on as they have used a lock and nut underneath where it isn't reachable. Some gentle bending of triac leads had to be performed. Here is the PCB from the left, and right views. After drilling a few "vents holes" to let the small piezo sound out the front looked like this. Yeah should have not done this in the air but they are small enough to keep bugs out and fingers out. Was it worth it? Now I can hear the sound from about 10 feet away in a very quiet room. If there was music playing in that or the next room, wouldn't even notice it. Conclusion: Waste of my time. Hope it was good for you!

I was referring to the bringing up of an old post and referring to the poster instead of subject matter. The complaint itself exemplified exactly what he was complaining about himself and not helping anybody. Sorry my post wasn't clear to what post I was referring to.

I was thinking the same thing. is this just a troll?

We get a frustrated soul newbie about once every month or so but almost everyone of them work it out and swear by it later. Stop being an EE and start using your knowledge as a technician. This stuff isn't in books as documented rules. You will make it work. I am sure you have had harder jobs and come out on top. Lots of knowledge and creativity here.

Yes, the new method is a PITA and I have at least one that does a combination of flowchart and old factory reset. Only half the chart works.

When adding a lamplight to ISY no button pushes are required, only the IP (Insteon Particular) address.

I reported about a year back that my 2441ZTH worked down to about -2 degrees C. The reported temperature went into the 127 (254 bit count = -1) degree range with negative readings before it died frozen. I didn't check the minimum setpoint setting IIRC.

7 units are v.41 3 units are v.44 all purchased from two years ago to a few months ago. Oldest IP address 28.40.XX to newest 36.94.XX Not sure which ones did what now but most have had their batteries replaced from new and maybe 5 have ever reported LowBatt. I have to assume the rest acted strangely, with flashing LED, intermittent operation or just quit working. I currently have two that reported LowBatt about a month ago and they still work fine. I haven't bothered yet as both those units had new batteries about two months ago. One has to be factory reset and relinked every time I replace the battery.

Just as Teken reported above. I have received LowBatt notifications from triggered programs. I have recorded LowBatt triggers in my Lowbatt list program several times, I have had MS units go berserk or stop detecting from dying batteries and no notifications, but I have never seen a LowBatt status = On in my ISY device pages, yet. Just very strange and I was accepting various reasons for this. Now I am back to wondering why again.

Thank you LeeG! I wonder what ever happened to my maybe 8 or 9 LowBatts though? This is why I wrote a recording program because I have never got a valid notification but have recorded a few after installing code for it. hmmm... I'll be watching closer next time.

The Network module and PLM are not related. The Network module uses your Ethernet port and is not Insteon related.

Thank You for that. Insteon comm delays can add up to very noticeable delays with certain techniques.

Bad hardware can definitely give the HA enthusiast a bad taste in his/her mouth. usually this can be resolved but can be difficult for the no-techie, for sure. Years back a guy developed a signal repeater / booster for X10 and people using it still swear by it 100%.

Thanks Brian. This seems correct. The IM chips talks TTL "Rs-232" other onboard components but the PLM talks RS-232 levels. The inversion certainly wouldn't make good comm partners. More SH docs from your link above. I probably confused the IM with the PLM. My bad.

Oh gawd! My brain fell down and I can't clap anymore! I never learned to clap without waking myself up. When I finally did, everytime I clapped, to turn the lights on, I would pee the bed.

Thanks for the information though. It looks like I received the updated contact version. Now I just have to decide whether to install Door control or just watch it. I have a BuzzLinc in the exit room so I could save one I/O Linc by sharing it with the garage door status.

You just hope the companies send out the "Logic Girls", with the nice features you need, for in house calls, to set up your system for you.

Thank Michel. Should that also apply in reverse as being discussed starting with a device?

I would be sure others here, with the old ones, would be willing to swap with you. I seem to have received the newer one. The reverse logic labelling would drive me crazy and I would just buy two newer ones. Obviously, whoever created the reverse logic feature created an unworkable flop.

As oberkc stated above it really isn't the ISY slowing things down. It's about the time for the protocol to go back and forth. When you have a direct link (scene) between your keypad and the light module the command is sent and the light module starts to respond immediately. When you send command to ISY, the PLM has to send it to ISY. Now there is some processing time for the program to trigger and execute and send back the response. But when you send the command, three hops happen. This means that three more echoes of your signal are heard, and have to be waited for, before the PLM can take it's turn to send the command to the light module. This all takes some time. I mostly build scenes between MS units and Light modules as the delay is even more apparent. Mostly they appear immediate then. I try to leave ISY to do Off timing where timing is not a critical. There are a few tricks to pre-modify the light's response to the commands by tweaking the scene values before the command is expected. For most other things a slower response doesn't matter.

I found X10 very reliable for module hardware. I found X10 reliable for operation reliability when it was within a reasonable distance from the sending unit. I found X10 rf bridges horrible. Almost every problem I ever had was due to the RF/X10 units sending out garbage. I had noise flooding from almost every unit I ever used, sooner or later, They would translate commands into All On (sound familiar?) in the middle of the night about once per year. I view SH as the same company that produced X10. It wreaks of exactly the same attitude and still has it's mitts in the X10 market, in disguise. My guess is most the SH management are from BSR and/or X10 or they just changed their name.

Thanks Brian. The handshakes are done with ACK and NAK single characters but at a higher layer of the protocol than Xon and Xoff would be.. I see possible problems with this simple protocol. There is no confirmation of any commands before action is taken. A single byte synchronisation code is dangerous and out of message framing errors can occur easily. I see why SH would remove the All On capability from their devices. The timeout on the message packets is also dangerous for a CPU that can get busy handling other tasks. The next byte coming could be interpreted as a new message command if a 02 is in the data. With a EDIT: re BLH below TTL level 19,200 baud interface down a cable, I am surprised we don't get more messes.

Interesting! This means that the device query, not being able to query a battery device, instead of changing the status to blank, 'cause ISY doesn't know, sets the status to Off without any confirmation of status.

Are you saying that a general Query will not reset the Lowbatt status to off? LeeG stated "The Motion Sensor Low Bat node does not go back to Off state on its own. Once the battery has been replaced right click on Low Bat node and select Query. This will cause the ISY to reset the Low Bat node to Off. Below are two examples where I right clicked and selected Query on two Motion Sensors. Note that no actual Query command was sent to the Motion Sensor. The Query request simply directs the ISY to reset the Low Bat node to Off." I tend to believe that, as an explanation why I have had almost a dozen LowBatts recorded, or MS units went nuts, and yet have never seen a LowBatt status as On yet. I don't get that many power failures to buy the blank status on those but I am just trying to understand why I never see this status as On, yet, with 10 MS units. Does this means that a single device query does different things in ISY than a general Query??

grrrr..... The Colour palette always hangs the browser when colouring text in a code box and I lost everything. At the risk of complicating things here this is a series of programs I use to track MS Lowbatt signals. Each MS unit requires program like this. Only the constant to define the room need be changed. The $cXXXXXX integer variable is my way of using constants to avoid confusion from coded number usage. Each room is assigned a two digit number that is used for leak detectors, MS units, notifications, movement detection logic for unoccupied sensing etc... They are just Integer variables that have the init to and value permanently set to distinct numbers. The $sAlarm.level = 1 (State Var) sets off my alarm system and a level 1 only beeps my BuzzLinc for 1 second. MS.LowBatt.Libr - [ID 0074][Parent 00CD] If 'Library / Motion.Libr / LowBatt.Libr.MS' is switched On Then Wait 5 seconds $sMS_LowBatt.room = $cROOM.LIBRARY $sAlarm.level = 1 Send Notification to 'Text Larry' Send Notification to 'eMail Larry' Else - No Actions - (To add one, press 'Action') . . . . This is the recording program that keeps track of which MS units have issued LowBatt signals. A variable is keep that is shifted left two decimal places each occurrence and the new MS room added to the least significant end. With a code of 211929 the rooms would be 21=gathering room, 19=lower landing, 29=mud room. (1x = basement rooms, 2x= main floor rooms, 3x = out building units) After replacing batteries the variable list can be zeroed out again manually .As a future project I may send a line in the notifications to clear out list type "ABAB" or something similar, on the KPL keypad. I do send this variable value with each notification as a reminder that the list is stacking up. The MS units seems to operate for along time after LowBatt is sent out. MS LowBatt Recording - [ID 0078][Parent 00CD] If $sMS_LowBatt.room is not 0 Then $MS_LowBatt_Room.list %= 1000000 $MS_LowBatt_Room.list *= 100 $MS_LowBatt_Room.list += $sMS_LowBatt.room $MS_LowBatt_Room.list Init To $MS_LowBatt_Room.list Wait 2 seconds $sMS_LowBatt.room = 0 Else - No Actions - (To add one, press 'Action') Else autoruns when $sMS_Error_Room gets returned to 0