larryllix

Do you have a condition in your folder?

WoL is an option inside the Win low level setup and could be disabled. Also, as I was informed here, when polISY/eISY was newer and didn't support WoL, some devices use a different command protocol than the older WoL style that ISY uses.

Looks like more of the same problem. You have changed platforms and the names of the programs have not been arsed into the proper links to make your system work. As per @paulbates in the other thread. Try editing each program and saving it. Don't forget to hit the "save" button after. IIRC you must edit the program before saving it or the ISY AI may assume it isn't required. This is the problem I was attempting relay in my last post. Internal linking inside ISY is done by numeric location, not names. Programs don't run other programs by their names, but rather by their numeric location. When moving ISY contents to another platform, the problems, I had, were due to not "recompiling" the system and expecting it to work with everything scrambled into new locations.

Be very careful and aware that links inside ISY are based on the numeric location of items such as programs, variables, and networking module elements, etc..., and not their names. If you have deleted a program and reinstalled it the reference number will likely be different and things like ISY Portal/ Alexa/GH connections will not work anymore. They do not work by names.

I do not use any looping timer programs without as many as four times each day that restart each program. In addition they all use the [Run at Startup] to restart them upon power failures or reboots. DST time changes have been argued about here for almost a decade. There are many different types of cases where no one algorithm is not going to work. I really doubt a complete solution will ever be offered. Any X minute loop programs will never execute any logic between 2:00 AM and 3:00 AM when the clocks move forward, be totally confused, and cannot offer a solution, that pleases all cases, when every minute between 2:00 AM to 2:59 AM occurs twice during the same night. It would seem the only solution for automation programs using loop timing is to stop the governments from changing the clocks twice per year.

@Geddy I think you hit the head on the nail there. There is no such ISY syntax as And ( switchB is on or switchC is on ) It seems like the OP is using multiple "Switched on " logic statements, dependent on each other, which can never be both true at the same time. Again ACTUAL PROGRAM NEEDED

One thing I did a lot of work on was "Intelligent Setback" during heating. After having many different brands and models I have discovered that no thermostat has that feature. I experimented with a lot of algorithms to accomplish this but none were really perfect. The calculation of times based on outside weather and inside temperatures got out of hand for ISY calculations, and screwed up occasionally. Later I went to a multiple stage system where ISY would use distinct weather points to pick one stage that determined the setback time. Next, I discovered that playing with temperatures was too complicated and required to many "what-ifs" in the programming so I settled on using climates in the ecobee stats, and ISY just picked one at the smartest time. That proved to be the safest method as I had a few run-aways with ISY controlling temperatures and, using preset climates eliminated that risk factor. However, there were severe limits in my previous home. It was so efficient that it needed no heat in the winter if the sun shone and, it had so much thermal mass, heat would be turned on about 2 AM and off at 5 AM to get heat for the next afternoon. Getting it to cool down again for the nights sleep became a problem as turning the heat off at 3 PM caused us to be too cool to watch TV, at nights, but still too warm to sleep at 11 PM. Of course, multiple zones and stats don't ease the complexities of it all. But along came a solution...moved to an apartment with one ecobee and now try to reject the pressurised building air, they love to run at the sweating temperatures. Open a window and you create a relief where all the building heat/pressure exits through your unit. I run a window A/C all winter despite sub freezing temperatures now and it competes with my 2-3 gallon a day humidifier. Am I crazy yet? I check the door peephole for white coats every day.

I have a drop in MagicHome RGB/RGBW/RGBCW bulb and strip controller software that can be dropped into EISY and almost eliminates any popcorn effects on groups up to 10 devices. It takes some doing to get it setup up but scenes can be created inside ISY programming on-the-fly. No previous setup required. MagicHome/LEDenet devices are WiFi and some are dual BT and come with an included remote. I have a dozen of them in drawers now. LOL Anybody interested PM me.

I think if you investigate further you will find that the ecobee thermostats can do all that without any outside interventions. There are sync options with multiple options to synchronise built in, including fan cycling periods, vacation modes, climate selections etc.. etc..

I formerly tried to control my ecobee stats for various things I thought they wouldn't do properly. Later I learned the thermostats are smarter than my ISY and allowed my ecobees to control my ISY and stopped messing with the ecobee smarts. Every time you override the ecobees smarts it upsets their history of response times vs climate settings, and they become confused and have to start accumulating history vs temperature response times again. I have found the vacation modes in my latest ecobee more reliable and easier to set than my ISY programming so I allow the ecobee stat to be the boss and set my ISY modes. I can count on two fingers the number of times I have had to manually override a temperature setting in the last year and a half now. If you want to sync two ecobee stats, just select the sync feature and select which options you want to synchronise and ecobee will do it itself. Sync.stat.vacation - [ID 0093][Parent 005C][Run At Startup] If // Run at Startup enabled 'Living Room / Ecobee.stat - LivRm' Climate Type is Vacation Then $sHouse.vacation = $cTRUE $sHouse.armed = $cTRUE Else $sHouse.vacation = $cFALSE $sHouse.armed = $cFALSE

As per @Geddy above. I agree with the Wait lines. I would install a wait 1 second every second line of control commands with Insteon. IIRC the Insteon cache is limited and when overflowed just has to forget the latest line. Remember Insteon is a handshake, and confirmed protocol, so every time you command a device a response has to come back to determine is a try again command has to be sent. This all takes time and if there is any failure, more traffic will ensue, all from the same original command line. Meanwhile your next commend is waiting to be sent, so one can see why the cache may be limited to a small size. And...don;t forget when a command is sent, every Insteon device will simultaneously echo that same command until the intended target responds up the mesh echo limit setting inside every packet. Wait x seconds/minutes/hours also gives up the control of the CPU process that your ISY program holds, so that I/O and other multi-tasked programs and I/O drivers can get their turn to process what your front-end programs are asking ISY to do. ISY is a partially volunteered time slice engine as were early Windows operating systems. ISY programmers can control this with Wait and Repeat statement lines.

I don't like basing things on long timers. They tend to fail or crash or I stall them by editing. I would just trigger a program to save the tally, and possibly ckeaout all the registers each 12:00:05 each first of the month. Of course I keep my own date variables based on ISY's provided system variables so that is easy. Sent from my SM-G781W using Tapatalk

I doubt that a human, manually coding without some automatic indexing code could ever run into that limit. ISY comes with GigaBytes now.

Yes. I had requested some form of indexing variables, years ago, but other expansions got in the way. Sent from my SM-G781W using Tapatalk

I did a few things like this by using a block of ISY memory locations and creating a shift register that operated each day on a schedule. A lot of hardcoding in ISY since it has no indexing function but....something like this. Program Shifter if whatever Then set mem30 = mem29 set mem29 = mem28 set mem28 = mem27 ...... set mem1 = mem0 set mem0 = Day.data Esle -- Data over 30 days old will be lost but last 30 days will be available for a summation. Program total30 If ---whatever Then 30dayTotal = mem30 30dayTotla += mem29 30dayTotla += mem28 .... 30dayTotal += mem0 $s30dayTotal = 30dayTotal <--move to state variable for processing Else ---

Naming the programs with meaningful names is usually the key. For programs I use for Alexa, mine are all named xxxxx.initiate. When I go to the ISY Portal and do a search, they are easily sorted from the rest and unlinked ones are easy to spot. For the case of programs, as above, I usually suffix the sensing program with xxxx.trigger, or xxxx.sense. Of course there are always exceptions and combination programs and it is a work of art trying to keep the names meaningful, but it usually pays in less confusion down the road when additions are wanted.

You have your timeOff set to 10 seconds which was my point I was trying impress on others. If yu set it for say...10 minutes and it ever timesOut internally you will require 10 minutes of dead time before the MS II will be useful again. This affected the way people could use the MS II from the original MS 1. I used to set the MS timeout for say 10-15 minutes as a backup to the program timer of say 30 seconds. You can't use them that way anymore. Same with people depending solely on Insteon links between devices. If they set a 10 minute timeOff in the garage and it goes through it's cycle to Off, the MS II is dead until it sees no motion for the 10 minutes. They used one timer for both cycles and made the timer retriggerable for both directions. I my MBR I use one for two bedside table lamps but I can occasionally detect that dead gap time. However I am using the same short cycle, on only programming as you are. As per you, mine are plugged into USB PSUs. Love that part! Perhaps the new Insteon people have corrected this goof, assuming you have recent models. It would be interesting to prove this on your new MS II units.

The MS II was released with a design defect. If the MS timer inside it ever times out and and thinks the lights are Off, the MS II has to see no motion for the length of the timer or it will never send another On signal. Block Off signals make no difference. The only work-around I have found is to set a very short On/Off timer duration in the MS II, send On codes only, and hope the blanks spots are never noticeable. I have three MS IIs but still use my original MSes due to this defect, in applications for lighting control. I only use my MS IIs for occupancy detection with very short time delays. When the MS II came out there was a lot of discussion about this defect but most older posts have been lost AFAICT. I had hoped the new Insteon company would actually fix this engineering defect but in view of no response or acknowledgement from several contacts regarding this, I have lost hope. Without real sensors for the Insteon system it has just become a remote control system.

The polISY internal Zmatter board is not available anymore. The USB dongle works with polISY or Eisy plugged into a USB port. Sent from my SM-G781W using Tapatalk

Only the USB dongle is available. As I was informed...It was found later, that the PSU branch feeding the internal board was a little too light to supply the polISY internal Zmatter version. However, the USB version (same board) draws power from a different PSU branch with more reserve capacity.

As per Techman above, you can select an option to send On only. However, this comes with a caveat on the Insteon MS IIs. I find I need to set the timeout on the MS quit short, as that timer is used for both time off and time to re-enable sensing. IOW...once the MS timer times out, the MS becomes blind until it stops seeing motion plus the timeout time set. With a long time set, there will be no lights as long as something moves during that time period, plus the timer time. With constant movement, the On signal, and lights, will never come back on. Yes, it is a design bug in the MS II, that was never fixed, IMHO. This was reported to the new Insteon company but hasn't seemed to have been corrected, that I have heard. Sent from my SM-G781W using Tapatalk

Selecting all three boxes in the Java clearance should clean everything out. Them reload the IoX finder fresh. Sent from my SM-G781W using Tapatalk

That sounds like an optional add-on parameter option of X seconds (followed by a Stop command automatically) could match the style of many other device command styles in ISY admin console.

It would be well worth our while for you to backup your polISY, and then attempt to load the eISY image into your polISY and test this.

ISY itself also has day of month and month codes. Only trouble is the parameter is not available for triggering programs, and needs to be polled to dump them into program triggering State Variables. I use them in so many programs for year-free, date based, occasion based programs, it is worth while and only dependent on ISY itself, not on any other cloud, node server, or hardware device connections to function.