larryllix

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.

There may be a caution for other buyers of "new" Insteon devices off eBay. This is not about the hidden sensor but rather the mount on the frame unit. I purchased a "new" door/window sensor from eBay about a year ago and it killed the AA battery inside every week to 2 weeks for the last year. I checked the actual battery capacity a few times and yes they were always dead. I finally order a new door/window sensor from aartech.ca, now that they have stock from the new Insteon about 6 weeks ago and the AA battery is still working fine.

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.

One of the problems with monitoring equipment is when you see some failure, what can you do about it? Now the same events are happening and you can't fix it but it can ruin the rest of your 56 day cruise. Sent from my SM-G781W using Tapatalk

Sounds like a need to 'get even'. Sent from my SM-G781W using Tapatalk

Perhaps a clause in our "Living Wills", should I be become infirm, and/or disabled, in my later years, that there is funds for a home automation expert to come into my home and install every gadget imaginable so I can be serviced by AI? properly? "Alexa....get me a can of beer" "Alexa.... do what I am thinking" .....I never could pronounce some of dose vords property. (we have to think ahead)

4. Remo e the system and save the $10k bargaining chip against your home price that the new owner will demand to pay an electrician to remove the 'complicated gadgets'. Of course this is an area dependent subject but most home automation people do not want somebody else's mess and only want what they themselves have put in, as a hobby. Sent from my SM-G781W using Tapatalk

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.

In that case my OnOffLinc must have created it's own link. It was only ever linked to the PLM but it somehow turned on a group of Insteon devices to a preset scene set up by my ISY994. I think the signal clash being interpreted as a valid command and repeated as an All On command disproves the usage of any decent CRC method.

I had a OnOffLinc module produce scene on commands randomly in response to control commands On/Off. This plagued me for a few years until one day I recognised the pattern of brightness levels on a few lamps and investigated. l always figured I had some bad program turning on a lighting scene (it appeared too smart). Not finding any clues agan, despite many attempts to find it in my programs, I browsed through the ISY logs this time. I found the ACK signal from my Insteon humidifier control plug-in device logged as a bunch of noise. I searched back a few weeks and found it occurred previously at that same time. I manually sent commands to turn the humidifier on and off several times and then checked the logs to find an occasional lack of confirmation from the OnOffLinc and a bad packet in it's place. A simple power cycle and factory reset of the Insteon device appeared to fix the problem and I haven't ever experienced it again, for many years now. IIRC, 'All On' was just another pre-installed Insteon scene code in early Insteon devices, and this was just another Scene control that was being put out by a defective device. No RS-232 involved. So much for the packet security checks Insteon claimed in their white papers. BTW: RS-232 typically uses X-On and X-Off codes to do handshaking. The modem hardware signal lines were never defined to be dynamically operated.

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.