larryllix

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.

I am still formulating another method using the MS II devices but haven't worked on it yet. We should be able to have the direct link with a light device to allow a fast on time with motion. Then ISY can detect the NS On signal and interfere with the MS --> Lamp scene link. I haven't tried it yet but this was introduced with one of the V5 beta releases. The delay inside the MS II would have to be very short as they present other problems in that they will not reset for the same time delay without motion either. Yuk. Design flaw IMHO. After the desired time the scene would have to be modified by ISY again. Hopefully, this wouldn't wear the eprom in the lamp device (guessing about 2-3 years?) out but it could be the cost of doing business like this.

With Insteon, I have turned off Battery Writes and disabled my folder Battery Device AutoUpdating. You can do the right click|write updates manually, when you need them. The automatic Use my open time window method was causing my ISY to hang and bog down until the next even caused it to correct itself. OTOH, ISY scene modifiers were attempting to write to battery devices in v5.0.16C. I assume that was fixed in V5.1.0 so this problem may not exist now.

I only use the MS1s as I have no Zwave. The Insteon scene is the only MS ==> Lamp that I have heard of that responds with a fast enough speed for room entry lights. I have three MS2s. I use many WiFi devices also but not for MSes. I have found and purchased many extra MS1s to replace any MSes that burn out. I have used some LioN 9v batteries that have burned out some MSes now with their 11.6v output. Not doing that again. The MS II is useful for non-immediate light requirements, security, and occupancy (home/away) detection, and I have now moved my 3 x MS IIs to those usage styles. I don't use any other fields in the MS IIs, as I find them mostly nonsense and unreliable, so far. Any other protocol of MS will have to go through ISY and will never be as fast as the Insteon/Insteon scene interface.

I have done that many times without problems. Likely save the power supply by soft-starting the power supply. I wouldn't try it with motor loads though. The dimmer circuitry never achieves 100% waveform.

I watched level 1 for about 15 minutes and the only major thing I see if my WC8 board variable stuffing a state variable, time integer MMDDhhmmss every 20 seconds along with one or two other weather variables when they change more than X counts. The odd stat update comes in and ecobee NS updates every 3 minutes. Nothing revealing but I will look for level 3 items next time I am in that area of town.

Installed and running. ISY seemed a little busy for about half an hour with continuous "Busy" box? Didn't find any strange issues, programs or devices that were weird. Backed up and all looks good.