larryllix

Yes, and yes. The Off time is what nullifies most of my appkications. As long as motion for the timer setting it will never reset and send a new On. I have one in my laundry room on USB power and it makes no difference. If the light goes out until you stand still for X minutes delay the lights will never come back on. I was using them in high usage places due to the USB power but now have removed them and only use for security alerts where duration are not a factor. I wish Insteon would correct this bad design but it seems it was done to support their dumber system and thwart ISY users. The next product logic change will confirm or deny this hypothesis IMHO. Hopefully UDI will discover some new logically corrections to stop these things from hanging the Insteon comm channel in the near future. I don't query them (MS II) anymore. It can cause a disaster in ISY / Insteon systems and the alternate field information is random garbage at times.

@greazer Nice! You should mention your information is about the MS II. Most of it does not apply to the original Insteon MS. The off time duration is not mentioned. I found that aspect makes the MS II mostly useless for lighting, but great, and seemingly more reliable, for logic applications in ISY.

@TAllenYou didn't include any text or person you were posting to in order to alert them. Type '@' and then their name, select the box below like I did yours at the beginning of this paragraph.

Nice! I do use folder conditions for a few purposes (night security zone enable, security MS zones enable, permanently disabling monitoring programs) but they have a few drawbacks. - they are hard to debug, programs underneath cannot be manually tested while the folder is false - they can stop a program midstream and leave devices turned on or off - they are obscure/hard to see and not something I would look for when debugging algorithms. Once you have a bank of basic device/scene/level handlers in a folder the triggering programs get much simpler without the rest of the code. Some of mine turn on Insteon scenes, along with MagicLight controls via NRs through custom software, sometimes three different colours or more, all from one master scene number inserted into the control variable. Divorcing the two sides of the process across a variable works very well to simplify the thinking. Another nice thing about the isolation via a variable is you can pound the variable as many times as you like but unless the value changes none of the devices get pounded with useless Ons or Offs.

1) You don't. Scenes do not have a status and cannot be determined with any accuracy. If you want to know what the last scene was use a variable as I suggested in a previous post. 2.) I don't know what buttons you are referring to. If they are KPL buttons or other Insteon buttons, they do not have a useful status. Their status is always Off but they generate events that can trigger ISY programs. You variable can remember their last operation. 3.) I am not sure if you can copy a scene but you can create a scene very easily inside the admin console. It's most;y a drag and drop process. I only use a few Insteon scenes but I use dozens of different room lighting scenes, all controlled by one state variable. If you want to remember which lighting scene was on for some temporary usage, save the state variable into another variable and when you are done save that variable back into the state variable. As describe previously, all lighting is controlled by that one state variable. The first thing that usually happens with newbies to ISY is "OMG! it takes so many programs!". That is the nature of the beast. Each program is one basic logic statement unlike linear program languages. Most developed systems use hundreds of programs and hundreds of variables. It is not costly for the system. Best of luck. Keep experimenting.

Not sure I can completely understand the logic there but...you seem to be very logically equipped so..... For my deck lights I have 13 WiFi bulbs controlled by my own NRbridge software, driven by ISY NR commands. I have them divided into three groupings, for scenes that I can control from ISY similar to Insteon Scenes, to avoid the popcorn effects, display three different colours, and animate them in a rotational looking effect when desired. I use a single State Variable to control the scenes, exactly the same way as my Gathering room example above. In another folder, I have a bank of programs that all install a scene source variable with the various colour scenes for the deck ceiling potlights, based on the date. Each day at a neutral time I set the controlling source variable to $cDIM so that my deck night lights program uses a copy of $cDIM to illuminate my deck and porch. On festive occasion dates, at a time just a few minutes later than the usual dim white setting, I override the deck lights source variable to festive themes. eg. Canada Day, Christmas, Easter, Halloween, Independence Day, etc... When the main program (sunset + XXX minutes) until 11:00 PM day of week dependent, I copy the scene source variable into the deck light scene control variable causing whatever colours I want to show up around my home.

Using Integer variables as constants. $sGathRm.lighting = $cBRIGHT $sGathRm.lighting = $cOFF $sGathRm.lighting = $cRED I also use an old de facto standard from other languages, using all caps to denote constants. Don't forget to set all" init to" variables to the same value so they are not forgotten in power outages. I also define constants for room numbers so when I record motion, leak detector batteries, or other events I have a method of marking the room the even happened in. Now we just need ISY to support a string substitution function in notification outputs so a real piece of text can sub back in for the names/strings we can use inside programs.

I use a State variable to control lighting inside my Gathering Room. I also use about 15 Integer variables to define constants to make it more user friendly. eg. $cPARTY, $cDIM, $cBRIGHT. $cOFF etc.These contain many coloured scene themes as well. my lighting is a mix of RGBW strips, RGBW bulbs, Insteon, etc.. Each value/constant contains a permanent value of say 11,12,13 etc.. anything will do. I have defined a bank of scene handlers/programs based on that state variable and hidden them inside a folder. eg. If $sGathRm.lighting = $cBRIGHT Then set Insteon scene xxx on set WiFi bulbs to 100% set LEDenet strips to white, 100% Else ----- Once this is done you can have many programs, conditions and Alexa vocals controlling that single state variable that controls all the lighting in that room. Much easier. Also, if you want to "borrow" a light for something...eg flash a bulb because a garage door is left open. You just save the value of the state variable, and then restore it back to the original value, after "borrowing" it, and all is back to where you left off again. Confused yet? Just ask!!

Maybe somebody will write a better NS to control spouses? I don't think the protocol quite matches. When I Dim the lights, she wants to go "Out" and keeps disconnecting. Maybe the handshake isn't working?

Alexa thinks every item in my house is a light or a switch. It only knows what I tell it, via ISY Portal. "Alexa...turn on louder" turns the A/V volume higher. I don't connect things directly to Alexa, only from ISY via the Portal. "Alexa...turn on the fan high" or "Alexa....turn on the high fan" tuns on the fan in that room.

Right now amazon has the Echo Show 8" on sale for cheaper than the full Echo. I recommend that one if you are only going to get one unit. However I don't recommend the Echo Show 5". It's screen is too small and useless unless you stand right in front of it. My son has one and it isn;t worth as much as a simple Dot. The Echo Show 8" out hears every one of my Echo Dots, even when standing right in front of them and the Show 8" is at the other end of the house. Shopping lists onscreen and results of movie lookups in print in front of you are worth a lot. My Echo Show 8" sits on top of the tower A/V speakers and still hears better than all other Dots with the TV blaring through those speakers.

I was hoping you might comment on the non-native English thing as the OP is concerned about it. I know you have mentioned it before. Has that resolved itself at all?

You can also right click on any program and use the find and replace menu to swap the old name for the new device's name in all programs. Check your scenes after. They would need to be swapped manually.

I have about 11 Echo Dots and 1 Echo (full size) in my home. I also have about 6 Google Home Minis and one full size GH. If you want them for music playing, lean towards GH or Echo full size. If you want them for mainly HA then lean toward Echo Dots, for the price...about 4 for 1? With ISY994 and ISY Portal the Echo Dot can replace dozens of Insteon remotes and switches plus be available for stats on Movie Stars, movies, conversions during cooking, setting event into your mobile phone calendars, and keeping shopping lists etc.. Shopping lists work like this... ..."Alexa! Add carrots" " OK... I have added carrots to your shopping list." This list is available on your cell phone and synchronises between both our phones as the items are checked off. We never forget a paper list or forget to write the item down any more. This is totally independent of ISY994. I started making techniques to change colours and colour schemes of my lights using dozens of Insteon buttons and combinations of selection methods. Once I got an Alexa Dot they all went into the junk bin. That sounds like this. ..."Alexa! turn on Independence Day deck lights" "OK" This caused every third deck light around the home to turn red, next third to white, last third to turn blue. I have dozen of different colouring and white light scenes styles. Get a few amazon Dots and more when they are on sale. I also have an 8" Echo Show that displays webcams and those lists of shopping items and appointments when asked. When a garage door is opened, my Dots announce which door and when they are both closed as well as when the dryer is finished and when any battery devices signals a low battery by speaking the announcement on many devices. For non-native English speakers @asbril may be able to shed some light on both systems.

Strange that is the same time (8:00 AM) my MIA daily report of HVAC setback status was being sent.

Google has become very undependable for almost everything these days. Every time google decides to change their security they do not advise of security changes and this is what you get. Then you think it is something you did. Many companies, including UDI, do not use the same name behind the scenes. This causes the user to not accept the sign-on from some name they do not recognise. If you ever reject any security check...good luck ever getting it back. I gave up on google randomly failing me, a few years ago. Now I use the generic email server, but I have developed a few notifications that just stopped working, about 4 months back. The rest of my notifications still work so I haven't tracked that one down yet. Same ISY, same IP address, same server, same message as before????

I had trouble with my ASUS AC68u AC1900 router. From what I can figure out it ran short of NVRAM and would not remember, or handle more than about 54 devices at one time. When I had the third party WRT firmware installed it really gave problems as they added even more features and flooded the NVRAM. When I had a power failure, at times, both my polisy and/or ISY could not get an IP address. I found ISY and polisy just gave up after a few tries and tried to function with a IP address of 0.0.0.0. Then nothing worked. At times other devices would not get an IP address issued but other devices seemed to not give up asking the DHCP server and got dynamic addresses most of the time they were needed for the short term. Now, two routers later, my main router is reporting about 67-70 devices simultaneously and ISY and polisy don't seem to fail at booting up from a house power failure recovery. I have never seen any specs on any router that specify any of these hidden problem limitations yet. Now I fear when my main router goes down, all my devices attempt to switch over to my old router again via the mesh switching system and it can't handle things, and then crashes or other nasty lock-up things. I now see why WiFi is not a good HA medium.. Ohhh...when all this was going on the workaround for me was to assign the IP addresses in the devices as well as the DHCP reservation table. That way there was no failure in an IP address grab fight.

Values of device fields and variables do not trigger programs unless they change. The variable will never be written to (program will not run) unless the value changes anyway. However that method may work better for a power up situation.

Two programs using a State variable. State variables can cause programs to trigger when they change value. First program to sync your state variable with one of the device values. If weather temperature < 99999 Then $sVariable = weather temperature Else ----- Second program compares the two values If furnace temperature > $sVariable Then do whatever you want here Else ------

I would advise to upgrade sooner than later. It isn't that bad for 99% of the people. Most, if not all, failed conversions, are marked with yellow icons for the programs devices that the auto process couldn't figure out. Inside the programs are explanations, usually with clues about what the original was. Scenes can sometimes drop devices or settings, but I think that has been improved. If all goes to hell in a handbasket you can always load your previous version back in, and restore your backup. On average, the process takes about 10-15 minutes, plus the time to do a new and fresh V5 backup. There are also ways to save your programs into a readable text file. Forgot the syntax, now.

@Michel Kohanim @gviliunasV5.1.0 did not fix the Insteon Scene update battery write problem for Insteon. V5.1.0 scene updates still attempts to write to battery devices. This becomes a big problem as the logic doesn't work. If "Battery Device Writes" is disabled, the system saves up the updates inside ISY, as designed. Now, if the Battery Writes option is ever enabled, by accident, or mistake, all the cached writes are attempted to be written to the battery devices, and can never be cleared from ISY. Rebooting ISY does NOT make ISY forget the cached writes and cannot be cleared with any normal means. hmmmm. I didn't try a power cycle yet but I just finished making the rounds to manually put about 6 MS 1s into linking mode, then disabled the option again. maybe later, if it happens again. if programs are written to update battery devices, ISY attempts to not clog up the Insteon comm channel by spacing out writes with time gaps...good ploy. However, by the time ISY gets to most devices the "Linking Window" time has expired and more battery device updates become cached. This process eventually bogs ISY Insteon comm channels down, with owing updates and retries until ISY processing almost stops. The busy box never goes away in admin console. if the delayed "Battery Write" option is enabled, manually writing updates to battery devices, from the admin console, are also blocked. This results in the user having to enable the "Battery Writes" option to accomplish the clear the cached updates and then all other owed updates get dumped on Insteon battery devices again, bogging the Insteon system again. Please hurry with the bug fix!!! Thanks!!

It seems v5.1.0 has introduced another problem with this item. Adding another MS 1 I found trouble manually updating the device, even in linking mode. Remembering I have the Battery Write option disabled, I re-enabled it so I could manually write the options back to the MS. What a mistake. Now I have about 5 MSes with green 1011s beside them and lots of constant busy boxes in admin console. I haven't experimented to see if UDI fixed this problem with v5.1.0, but I thought I had all my owing battery device writes cleared out before I disabled the delayed "Battery Write" option, a few days ago. If I cannot find a workaround for this bug, I will be going back to v5.0.15 before this seeming botched attempt at making it work better was created. I use Insteon Scene adjustments each evening and morning to adjust the 100W equivalent bulbs in bedrooms to an acceptable level and this may indicate the write to battery devices upon scene updates, may not have been fixed in V5.1.0. More testing needed here. This stuff grinds my ISY to a snail's pace as I have about 12 MSes that really exemplify the problem. **SIGH**

Nice! I am glad I am not 1010 anymore! * 10102

You may be right, but MIchel had advised me it would be fixed shortly. I also wondered that it was intended to just have the "Battery Writes" turned off and leave it in as it seems to work OK and give the user manual control over the process. The open linking window time technique doesn't appear to work at all because the "Battery Write" disable also locks out the program auto-update technique out also. The time gap between updating a scene via ISY and an MS seeing motion can really cripple my ISY every day and sometimes for weeks in a seldom attended room. Manual updates for a battery operated MS seems to be the only logic that is ever going to work anyway. In the past many of the ISY fixes were never listed in the updates posted.

I have moved my MS IIs away from direct light applications now so my drive to find a resolution has left the building, for now. I think UDI fixed the write battery devices with scene link updates in v5.1.0. I know it was on the table as a bug but I haven't tested it in v5.1.0 for the above reason. Yes, I don't like all these cheap work-arounds because I, like IIRC you are, prefer more structured programming approaches that I wouldn't get tossed out of school for.