mcisar

I'm in the position of having to downsize and I'd like some advice on decommissioning an ISY system that has both Insteon and ZWave devices and is also connected to a local nodeserver as well as the cloud. The plan (at this point) is that the Insteon and ZWave devices will stay in place so they all need to be unlinked from the ISY and reset to factory defaults for the future user. The fate of the ISY itself is up in the air at this point... do I sell it and just buy new when the time comes??? How much of a hassle is it to dissociate it from the nodeservers/cloud/my UD account/licenses? The old time is money thing... if it's going to take me a couple of hours of messing around to get it ready to sell it's not worth it and it's better to just put it in a box for now. Thoughts? Any hints/tips are appreciated, I don't want to miss anything particularly in the proper unlinking of devices so there are no issues when it comes time for someone to relink them to something in the future. Mike

I had been trying to reconcile some issues with having my echo turn on/off devices and dimming them when they were members of a scene. Essentially if I can recall the original issue was that when the scene was added to Alexa as a scene, I could control on/off but not dim/bright at all. At some point someone had suggested that when adding to my echo I should add the scene, but add it as a device instead. This has solved 99% of the problem but I'm left with one glitch... hoping someone can tell me whether it's just something I've done, or a hiccup in the iSY/Alexa integration. On and off both work as expected, dim and brighten seem to do their thing by roughly 10% per hit so that's fine as well. However the one hiccup that I see is that if the device is off and I tell Alexa living room light 50% I don't get 50%. It seems that anything value 50% and above turns the light (scene) on at 100% and anything 49% and below gives 0%. So in order to get the light to 50% I end up having to tell Alexa to turn it on, and then tell it 5 or 6 times to dim to get it where I need/want it. Thoughts?

I have had two Yale ZWave locks operating with no issues. Decided I was finally going to sit down today and modify my "door is unlocked" notification to include the user that unlocked it. Thought I had everything right in the notification but wasn't getting the info. So, went to look at the device(s) (ZW002_1 and ZW003_1) and noticed that the user number field shown for both was blank all the time. Scratched my head for a moment "could have sworn there was stuff in that field before... haven't looked in a long time, maybe a bug". Did a quick upgrade from 5.3.0 to 5.3.1 and same thing, user number field always blank. Fired up the event viewer and I see USRNUM and some ALARM events coming through... but on ZW002_306 and ZW003_306 instead of ZW002_1 and ZW003_1 I'm taking a wild guess that something didn't go quite right when I upgraded from the 300 to 500 ZWave dongle (that was a month ago)... maybe??? In any case... how do I put humpty back together again? Sun 12/06/2020 12:58:39 PM : [ ZW003_1] ST 100 (uom=11 prec=0) Sun 12/06/2020 12:58:39 PM : [ ZW003_306] ALARM 1 (uom=25 prec=0) Sun 12/06/2020 12:58:39 PM : [ ZW003_306] DON 100 (uom=78 prec=0) Sun 12/06/2020 12:58:39 PM : [ 53 46 79 5] ST 0 (uom=100 prec=0) Sun 12/06/2020 12:58:39 PM : [ 53 46 79 4] ST 0 (uom=100 prec=0) Sun 12/06/2020 12:58:55 PM : [ ZW003_1] ST 0 (uom=11 prec=0) Sun 12/06/2020 12:58:55 PM : [ ZW003_306] ALARM 6 (uom=25 prec=0) Sun 12/06/2020 12:58:55 PM : [ ZW003_306] DON 100 (uom=78 prec=0) Sun 12/06/2020 12:58:55 PM : [ ZW003_306] USRNUM 11 (uom=70 prec=0) Sun 12/06/2020 12:58:56 PM : [ 53 46 79 5] ST 255 (uom=100 prec=0) Sun 12/06/2020 12:58:56 PM : [ 53 46 79 4] ST 255 (uom=100 prec=0) Sun 12/06/2020 01:01:37 PM : [ ZW002_1] ST 0 (uom=11 prec=0) Sun 12/06/2020 01:01:37 PM : [ ZW002_306] ALARM 4 (uom=25 prec=0) Sun 12/06/2020 01:01:37 PM : [ ZW002_306] DON 100 (uom=78 prec=0) Sun 12/06/2020 01:01:37 PM : [ ZW002_306] USRNUM 0 (uom=70 prec=0) Sun 12/06/2020 01:01:37 PM : [ 53 46 79 6] ST 255 (uom=100 prec=0) Sun 12/06/2020 01:03:05 PM : [ZWAVE-WAKEUP 3.000] Query device ZW003_1 Sun 12/06/2020 01:03:07 PM : [ ZW003_1] BATLVL 34 (uom=51 prec=0) Sun 12/06/2020 01:03:08 PM : [ ZW003_1] ST 0 (uom=11 prec=0) Sun 12/06/2020 01:04:34 PM : [ ZW003_1] BATLVL 36 (uom=51 prec=0)

Looking for recommendations for a few of lighting items. There are so many options out there... what's good, and what to stay clear of. I have an ISY994i with Z-Wave and Insteon, and should by the end of the weekend have Polyglot installed, also have Google Home and Alexa floating around... so anything that the ISY can talk to through any of that gear is fine. They all need to be full color changeable, the white variant should be either adjustable or warm-white, should also be dimmable. 60W or 100W equivalent output. They are probably primarily going to be used in warm-white mode, and dimmed red for night-light use. - Good old A19 style for those table lamps she just won't part with. - Surface mount or recessed flat-face "puck style", these'll go in a couple of hallways. - Stair lighting... looks nice to have them under the lip of each step, but thats a lot of work. Has anybody run a LED strip down the length of the molding at the side of the stairs, how does that look? - Finally I need something to use more as a tabletop and bedside indicator than a lighting source per-se. I'm picturing something coke-can sized and shaped or thereabouts, with a frosted white lens. Needs to be bright enough that the color could be seen in bright daylight in a room, but it doesn't have to be bright enough to actually light up the room itself in any manner. These ones will only be used for color indications (red, something I really need to deal with, potential meteor impact, lava in the back yard, nap time... yellow something that needs checking, garage door open, etc) so their white representation is irrelevant. Thanks in advance for your input!

Thanks for all of the quick responses. Will try to pick off some key points... A couple of the lights that are being turned *off* in the program are in other scenes, the lights that are being turned *on* are not in any scenes at all (my naming convention "dev" to connote the device itself). All of the lights are insteon, locks are zwave. The program and buttons all work perfectly and do what was intended day-to-day, its just the random trigger after the power outage that's concerning. I'm just building my system and as I get more and more devices I don't want worry that if there's a power outage while I'm gone for 2 weeks that some oversight in my programming has caused half of the lights in the house to be turned on and left on. It was not just random lights that came on, nor some random lights that happen to be in the program. The state of the devices was as if the program had just run (including to the point of hearing all of the locks trigger), and the keypad lights being illuminated. Obviously the lights normally turned off by the program were already off so there was no indication there, but the KPL buttons did turn off after the 10 minute timeout so that pretty much proves that the program was running. There's nothing else in the programming that calls this combination of devices, nothing that calls this program, and nothing at all that calls the scene which houses the buttons except the push of the buttons themselves. I had originally thought maybe the scene somehow was showing as "on"... but I've just confirmed that manually turning the scene on or off from within ISY does not trigger the program, it only lights the KPL buttons (I'm guessing the program isn't triggered because by this mechanism the buttons become "on" and are not "switched on"... still wrapping my head around that). If it's not something bad I've done in the programming as far as I can figure that means that either the ISY re-ran the body of the program "just because", or the program was triggered by somehow receiving a spurious "switched on" from one of those two KPL buttons. Not so sure I want to beat up all of my electronics by turning off the main breaker to recreate the situation, I suppose I could try to kill the power just to the circuit the KPLs are connected to and see if it replicates.

I had a bit of an oddity happen last night, trying to diagnose why. Long story short I have a "bedtime" program executed by a keypadlinc key on one of two keypads, turn some lights off, turn some lights on, lock some doors, etc. One of the first pieces of automation I did on my system and it works great. Except last night... at 2am the power goes out, I get woken up by the beeping of the UPS' in the computer room but just grumble and roll back over and go back to sleep, 20 minutes later *wham* all the lights in the bedroom and hallway are on, i hear the door locks beep saying they're locked. Need a hand in diagnosing exactly why the program decided to re-fire when the power came back on, and how to correct so it doesn't happen again The program is initiated by a keypress on one of 2 keypadlincs, the keys are in "non-toggle on" mode for trigger purposes because off isn't really applicable (it's not a toggle, its not a scene... its just a "im going to bed, do some stuff"). The 2 buttons (BedLR1 and BedLR2) are grouped in a scene (BedLED, as responders) for the sake of turning on the indicators on both keypadlinks so I remember I'm going to bed and have 10 minutes to do so The program considers itself complete after 10 minutes and turns off the scene and thus the button LEDs. Any of the lights turned on by the program are manually turned off as we proceed through our human "get ready for bed" routines. The program itself is below (the removed parts are just other lights and devices getting turned on and off)... Bedtime Prg - [ID 000D][Parent 0001] If 'BedLR1' is switched On Or 'BedLR2' is switched On Then Set 'BedLED' On Run Program 'Lock Doors' (Then Path) Set 'Front Porch Light Dev' Off ... (removed) Wait 2 minutes Set 'Front Hall Light Dev' Off ... (removed) Wait 10 minutes Set 'BedLED' Off Else - No Actions - (To add one, press 'Action') So, what little dangling tidbit could have made the program re-fire it when the power came back on (and FWIW the power went out many hours after the 10 minute timeout)? Thoughts? Cheers, Mike

Oberkc that's kind of what I was thinking, but with a loop of some sort around the locking/checking (and I suppose when it comes right down to it the status check could come first, if the door is already locked we don't need to lock it). I'm just not sure how to do the loop I want in ISY-speak. so essentially to "flowchart" it... :start is door locked --> yes, end program --> no --> have we tried to lock it 3 times yet --> no, lock it then go back to start to check again --> yes, send a notification saying something's wrong :end program

DennisC, there is definitely a place for the type of monitoring you are talking about but I find that too many notifications can get you acclimatized or overloaded to the point where you just don't see/hear them any longer. Open the door to check the mail "door is unlocked" "door is locked", take out the trash "door is unlocked" "door is locked". Because of my work I already get way more than my share of notifications from monitored equipment so it's kind of a matter of "don't tell me when something goes right... just tell me when it goes wrong". If I'm really curious for some particular reason I can always double check the status but otherwise I'm happy for ISY to do the checking for me with the knowledge that it'll let me know when there's something I need to know (ie. ISY tried to lock the door 3 times and it's still unlocked... check this out). There's nothing right or wrong about one method or the other, just a matter of preference.

Hoping someone may be able to give me a quick example of how to "fancy up" a simple program. I have a very basic program written to lock a Yale lock, I trigger this program using one of my keypadlinc buttons. I'd kind of like to spruce up the program to give me a little more peace of mind but not quite sure how to start. Ultimately I'd like to have it... lock the lock check the status to see if it's locked if it's not locked try again a couple of times checking the status after each try if it still is not showing locked send a notification to warn me whether its just not showing as locked for some reason, not responding or jammed... or low battery if thats possible. Thanks!