larryllix

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.

As our ecobee stat developers here have discovered, ecobee stats are not to be polled more than once every three minutes or ecobee may disconnect you until you stop and beg for forgiveness. The eISY approach may be a much easier plan of attack for you and I would be sure you could use the power of (eISY) love to your advantage in many other areas in your home.

@paulbates Hopefully you can find some clues in here. I am not sure if the system variables were here when you were frequent. clock.sync - [ID 0003][Parent 0002][Run At Startup] If // Run at Startup enabled Time is 12:00:10AM Or Time is 6:00:10AM Or Time is 12:00:10PM Or Time is 6:00:10PM Then // update $sSys.MM.DD $Clock.scratch = [Current Day of Month] $Clock.scratch /= 100 $Clock.scratch += [Current Month (Jan=1, Feb=2, etc.)] $sSys.MM.DD = $Clock.scratch $sSys.MM.DD Init To $Clock.scratch // update $sSys.hh.mm Repeat Every 20 seconds $Clock.scratch = [Current Minute] $Clock.scratch /= 100 $Clock.scratch += [Current Hour] $sSys.hh.mm = $Clock.scratch // update $sSys.hh.5mm $Clock.scratch.noFrac = [Current Minute] $Clock.scratch.noFrac /= 5 $Clock.scratch.noFrac *= 5 $Clock.scratch = $Clock.scratch.noFrac $Clock.scratch /= 100 $Clock.scratch += [Current Hour] $sSys.hh.5mm = $Clock.scratch Repeat 1 times Else // Run at startup will evaluate False Run Program 'clock.sync' (Then Path)

Serial connections are slowly disapearing everywhere while USB is becoming very common, although using different connectors and faster speeds/protocols. RS232 is really pushing the limits using 115,200 baud signals while USB 3.1 is capable of 10Gbs and still growing. For future compatibility I would stick with USB.

I write and test all my python3 programs on a Win 11 laptop. After testing, I port it over to my polISY and it runs just fine, exactly the same as the laptop compiler/interpreter. I have found a few times that updates to my polisy has left my own software on the polisy slightly confused somehow and it needs a reboot. However, that didn't happen the last polisy update. I am not sure something in the python threading I use, may not be completely happy under freeBSD, rather than Win 11.

That doesn't seem to be available for Canadians. Aartech.ca doesn't recognise the coupon code and UDI won't ship to Canada, that last time I attempted a purchase.

Put a CAO (or other brand) Tag and Tag Manager on your system. It can detect a temperature rise which will not only detect power failure, but any kind of failure, including human failure to close the fridge door.

The usually method we tend to see is to offer a factory discount through the vendor either by coupons to send into the manufacturer in another country or a discount aartech can advertise to promote their wares. Let them pay the shipping charges on their lump wholesale purchase. It must be much cheaper.

Sure. An Eisy with Zmattter comes to $648.61 incl. taxes. Then you may want to add Insteon support using a PLM. It's getting very expensive compared to my original $99 ISY994 outlay. I already have 2 x ISY994s and 2 x PolISYs. The PLMs would be reusable.

Ecobee typically puts deals on stats with the remotes included. The remotes are good for occupancy detection but not lighting control due to their very slow response. I have mixed feelings about using remotes for temperature regulation and have enabled some and then disabled them again. There are a few logical problems with the technique. However, the remote temperature detection is good for setting up your air flows etc. as good information. Jimbo's ecobee NS is excellent and very reasonable to purchase.

Their monitor screens with the canned responses have no AI. However, many humans have no logic either. It's just a paycheque if they can pass the English exam.

I always ended up with same technique for these sensing feedback type controls. First program does a continuous timer cycle with insurances to make sure it always triggers starting on startup and several times per day. Only calls second program. Second program is disabled and only determines if a long run cycle or short or no cycle is required For my humidifier the cycle was always 5 minutes shorter than programs 1's cycle time and also checked if it was heating season. ie. 55 minutes run every 1 hour to allow wick to soften more and absorb to the top of wick. Sent from my SM-G781W using Tapatalk

ditto here. I had to bounce it off Akexa support a few years back. I got the same ghosting as most others but then they began working again. Of course the first time it took months but a year or so later they started working again the next day. As always amazon support never got back to me. This hasn't happened to me in the last two years? now...fingers crossed. If you have checked both ends of the logic and the routines have the enabled switches on then it is Amazon's server at fault. I can't believe this crap is still happening after so many support complaints regarding this same problem. Sent from my SM-G781W using Tapatalk

While I have found no need to reboot my polisy after an update for the ISY software to run correctly, I have found most times my own personal bridge software tends to act weird until my polisy is rebooted after polisy firmware updates. I see no reason for the two softwares to interact as the both run as completely separate tasks with their own threading. However they do share the python 3 compiler/interpreter. Sent from my SM-G781W using Tapatalk

Read my post again. This sounds like exactly what I described. Check if your Alexa app routines related to your ISY Portal pseudo devices are still enabled. Again. When you disconnect accounts, Alexa disables routines that are using the devices that do not exist during that MIA period. I found many times that I had to redefine the devices being used in the Alexa app when I disconnect accounts. A few have discovered it can be done for very short periods without connection damage in the past. Other routines using non Portal devices would not be affected as they were never deleted.

If you have ever disconnected your accounts temporarily the Alexa app may have disabled all your routines due to pseudo devices MIA for a short while. I previously found my routines disabled in the Alexa app for various reason. It doesn't seem to happen in the last few years though.

Polisy updated to v5.8.0. It must have updated later somehow after I viewed the lack of install for over 10 minutes??? Very weird. However, the IoX Finder complained about the mismatch between polISY and the A/c and asked if I would like to update my IoX Finder....very nice touch!!! Still an old outstanding bug needs fixing.