larryllix

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

Hold on! We have some interpretation confusion here. Agreed with all that is stated. I stated I have never seen a LowBatt On status. I also stated that Kentinada's looping status check will not accomplish much. Here is why. If people remember the ISY comes preloaded with a 3:00 AM IST Query that will do just what LeeG and Teken described.... .... Reset the LowBatt status to Off. Doubting that Kentinada has removed that factory supplied program.... If Kentinada's loop just happens to catch the status one more time before the 3:00 AM all points query, that resets his LowBatt status, then it will have some value. There is 50% chance that, a one time, catching of the second status update, will happen showing the LowBatt = On. Having said that I never understood why I have never seen a LowBat status=On but now this makes more sense. Thank you Leeg & Teken for bringing that to our attention. I was beginning to buy the MS sending a LowBatt=Off signal because I know I have recorded a few elusive Ons.

Looks like you might be running. Glad to help or I wouldn't be here.

I don't think that is true. I believe people have confused commands with adding devices to scenes. When you added a device to another controlling device, in a scene, with no controller like ISY to manage it (the original way), you would set the device to the state you wanted (Off, dim, bright, full on) and then linked the two devices together. Now, when the controlling device broadcasted to all units to goto scene #165 settings, the level and ramps you linked with, when the link was created, was what you got.

Yes I agree but... The point is (again) you can recheck the status of the LowBatt every five minutes and you will never see a LowBatt status = on. See posts #3, 6, and 7

As stated a few times above, there is no point in rechecking an MS lowbatt signal more than once. It is transient and never shows up as On. I have10 MS units and have never seen an On for a LowBatt status. However they do usually send a LowBatt signal. Many of my batteries have died over the years.

Sorry. I missed the alternative shut the sequence off properly. Here is the correction Front Door - Chandelier - [iD 000C][Parent 0001] If $sAlarmZ01_FrontDoor is 1 Then Resource 'Centralite-EntryChandelierOn' Enable Program 'Front Door-Chandelier Off' Run Program 'Front Door-Chandelier Off' (Then) Else - No Actions - (To add one, press 'Action') Front Door-Chandelier Off - [iD 000D][Parent 0001][Not Enabled] If $sAlarmZ17_FrontEntryMotion is Not 1 Then Wait 15 seconds <--- you may want to extend this if you don't move fast enough Resource 'Centralite-EntryChandelierOff' Wait 1 second Disable Program 'Front Door-Chandelier Off' Else Wait 1 second <--- add these lines to reset the sequence after motion Disable Program 'Front Door-Chandelier Off'

This sounds like a case of bad SH capacitors again. My guess is, if you have noisy power it accelerates the capacitor aging and the cheap ones they use don't stand up to absorbing more spurious waveforms. If you are handy with a soldering iron it would be worth a try replacing the caps for the cost of these things.

Thanks Stu! I have seen this tooted many times but never at the stage where I am ready to install a GDO kit. Before I get into all the logic what is the better contact to use for the I/O Link. The one that doesn't get flipped in the middle of the night query?

Just got one for Christmas and the contact supplied was N/O. Rev 2.3 #2866-392 When activated by the magnet the contact closes. This should show as an On in ISY, meaning the garage door is closed. The labelling of the point will have to have the word "closed" in it. The software reversal is too dangerous and from reading about it for two years will be avoided at all costs.

IIRC the LED is not reversible and always tells the truth. ie On = closed contact, Off = open contact. My feeling is that you have a different polarity of contact NO vs. NC and you will not be able to correct for it and you will have to replace it or live with the negative logic indication (not reverse it). I have an HRV contact doing this and I named it HRV.inverted so I never forget and start fixing programs.

What are you sensing? What state are the device when you indicated 'On'? Do you understand what N.O. means?

There was a huge discussion of this hoping v5 would pan out some construct changes almost exactly as you indicated. Some thought it would be better to just have a checkbox next to each If line that could disable triggers individually. The When section could make old programs forward compatible easily. I thought the whole syntax should leave the old syntactically incorrect constructs and old programs behind and clean it up but a lot of barking ensued. (not a legal term ) Just a javascript cross compiler on a Win 10 machine could convert anything to anything and restore it back in.

Better your head than ours! Glad to see you figured it out. We keep learning the hard way sometimes but we remember better then.

My newer LeakLincs send different commands from a long tap and a short tap. IIRC one is a Wet On and the other is Dry On. Yeah. I triggered my pump shut off, send notification to my wife out shopping, and flashed my lights and doorbell again until I figured it out. Moral? Tapping the link button does not always reset the programs. Now I send a piece of text with my notifications: "To restore the water pressure press "AAAA" on the KPL" My multi code combination program can decode many codes and reset things. http://forum.universal-devices.com/topic/16135-using-keypad-triggers-for-a-multiple-combination-locks/

Try this one Front Door - Chandelier - [iD 000C][Parent 0001] If $sAlarmZ01_FrontDoor is 1 Then Resource 'Centralite-EntryChandelierOn' Enable Program 'Front Door-Chandelier Off' Run Program 'Front Door-Chandelier Off' (Then) Else - No Actions - (To add one, press 'Action') Front Door-Chandelier Off - [iD 000D][Parent 0001][Not Enabled] If $sAlarmZ17_FrontEntryMotion is Not 1 Then Wait 15 seconds <--- you may want to extend this if you don't move fast enough Resource 'Centralite-EntryChandelierOff' Wait 1 second Disable Program 'Front Door-Chandelier Off' Else ----- EDIT: Some last minute corrections

LOL. Simply put the "Executive" would be a supervising program that has to dispatch to that point in the program. This would usually be some multitasking "overview" program that dispatches to, and makes sure all programs, are run when needed. ISY has a trigger based event processing executive so the user doesn't have to write complex job handlers and be where and when CPU attention is needed. I worked on a large real-time executive software program that did electrical grid protection handling as well as SCADA function reporting and control. It's system just scanned through lines of code top to bottom and repeated at high speed. From a user's view it worked very similar to ISY but there was no broader If constructs, only inline If/then/else that would do similar to ISY's variable substitution. Anyway from the code writer's view ISY does things as if by magic. You just say when and it happens. In linear programming you have to continually "test the waters" on each program to even make things work.

CALL checkmotion <--- linear programming has to have an executive to make this happen, ISY does surprise magic If Motion = true Then if (Time > sunrise) and (time < sunset) then <--- sunrise/sunset never do anything. They are just condition filters do something do something else Else <-----nested If/Then/Else has to be done with programs in ISY Else print "nothing is happening" Gosub somewhere else <-----linear programming will wait for the subroutine to finish before continuing, ISY spawns multitasking and order or operation can be a surprise Next line is always in order.

It definitely isn't the usual top down inline program execution code. I think what you are saying is a training document for newbie users with step by step, do this, do that examples. This type of document could be used for sales promotion materials also. One of the problems is demonstration of execution. Every new user has a few different Insteon devices. If I told you to define a variable and write a short program example that is triggered when the variable is changed, would you be confused when you susbstitute a motion sensor or a hidden door sender? It could be done with a few different angles and probably should be done. Perhaps UDI could provide a user space in Wikipedia for users to write and polish such a thing before launch. I wrote for Wikipedia, for a few years, and suspect the same executive system is in use for UDI's wiki. EDIT: I have a copy of an "ISY User Guide v4.2.8.pdf" somebody directed me to bout a month ago. It does provide some basic programming examples that may be just what we are talking about. Perhaps somebody could provide a link to it as I have the doc and lost any link to where I got it from.