larryllix

Just looked at mine. Two USB ports, three Ethernet and a DB-9, likely an RS-232 or serial port. I believe the existing PLM is a TTL level serial port though. Maybe use a USB/TTL serial port adapter??

The Polisy has three Ethernet ports. One is required to connect to your LAN/WAN. One could be used to connect to an Insteon Hub which contains the same PLM circuitry inside. The Insteon Hub plugs into a receptacle. I believe this have been planned for a long time. Insteon hangs UDI out to dry while dedicated Insteon fans need to buy more equipment from Insteon to continue using their products. UDI has possibly sensed, or known this, for years and moved on to also support Zwave. OTOH: Insteon could be replacing the PLM with a newer improved version. Users are never included in this loop. Distributors would be stuck with old devices.

This would be no surprise from our friends at the Insteon death camp. Good thing Polisy has two extra Ethernet ports to support the Insteon Hub as an I/O appliance.

I thought the value of 2 was a little odd, but we haven't seen an originating program yet. On that note: I was using value 2 to initiate "request for voice output" via ISY Portal to Alexa speakers in 30 second spacing arbitration programs. BTW: That didn't work because ISY Portal issue a "not true" logic to Alexa routines which causes a 30 second lockout and then the value 1 failed each time.

Cool thing about variable logic is, it eliminates the multiple hits triggers from that variable. If all triggering programs all set the variable to the same value (=2 = no change in value) the program to reset it will never see more than the first "hit " (value = 2) no change in value This means the second program to lock out the "reset timer" program would not be necessary as it can free run using a variable. Variables do not play exactly the same logic as device events do. Good for "once and only once" style logic.

hmmmm. I have worked with event based systems that worked like that. IIRC I was informed that ISY does no scanning. It would be easy to maintain a trigger stack and use much less CPU overhead...maybe Forum posts have circulated that a program will stop and conditions re-evaulated at every Wait and/or Repeat, based on the wiki being misstated the way the logic flow works, IMHO. This is causing confusion. Programs containing Waits do not restart endlessly.

Why not go to ISY v5.3.3? Zwave things are still very new, and ISY is developing better Zwave handling every version.

Yeah. The event would get cached in a low level (O/S) i/o buffer, until the ISY processing engine (high level processing) can process the cached trigger. This will only happen during a Wait or Repeat in any program (giving up it's time slice) or it is sitting idle, not processing any user programs.

Not exactly correct! If had you set $stemp_test = 0 while or before it was Waiting it would have jumped to the Else clause during the Wait time and done nothing further. The With/Repeat construct allows the ISY logic engine and system to have it's 'processing turn' (gives up the program's time slice for the Wait time)

Upgrade went off perfectly for all except last (instruction) line to manually shutdown (instructions need sudo added) Thanks much!!!

Your Insteon scene turns the lights on at 100% as they were programmed. Then your program duplicates the Insteon scene and set the lights to 35%. You need to set the scene response to 35%. I don't use many scenes like that, so other than holding the paddle to fade the scene down, I can't tell you how. IIRC you can set the Insteon scene levels with ISY program lines.

As I understand it, ISY does not test or retest anything without a trigger or call from another program. The wiki statements are clear that the conditions are retested every occurrence of Wait or Repeat. I don't believe this to be true, or ISY would be bogged down looping by restarting every program with a Wait line being executed. Eg: If condition1 Then then code Wait 1 second <----------- this line is stated to have condition1 retested and Then or Else would restart each time. then code additional <------- this line could/would never get run Else else code This wiki article has been causing a lot of confusion among newbies here. This thread is only one example of many. The error is implying "does" vs. "gets permission" or "may".

Inseparable The wiki states. @Michel KohanimThat is incorrect and should read. "...all such statements are executed before the conditions of the program can may be retested" The following wiki paragraphs are nonsense based on a false assumption.

A Wait line in any program releases the capture of it's time slice to the ISY engine so that the ISY engine can process other time slices, including evaluation of programs conditions and trigger events. Wait does not cause conditions to be evaluated. It only allows triggers to be handled. If there is a new trigger in the same program's condition lines in it's If section, the program will stop and start in the section Then or Else depending on the If section's logic outcome. Without a Wait or Repeat line in a program it will execute atomically without any interuption. I/O and other ISY events will not be processed during that time period.

I would say v5.3.3 fixed this. Works much better without tying up ISY CPU time.

Does your UI and software for the ISY match version numbers?

Make sure to disable the "battery device writes" option button (at top) as it may start to creep back in again. OTOH: that concept may have been removed that parameters inside a MS must be updated to change a scene setup and not be a problem at all. This is the way is was previously and it got changed (concept bug?) for some reason during version updates.

@Brian R. I totally concur with this. I had a lot of problems with this "waiting writes" to battery devices to the point of my ISY bogging commands down to almost 2-3 minutes delay at times. V5.3.3 resolved that. I won't say 'all" yet, but after a week, v5.3.3 looks to have fixed it.

The Pro version is not related to the firmware version. Pro is a module that enables more features inside ISY, along with increased program and variables capacity. There a few more features but I cannot remember them all. Sent from my SM-G781W using Tapatalk

Here is the quirk I found. I had created a program to always wait 30 seconds between successive Alexa Routine requests, by setting a State variable = 2. I was using the State variables also as a request flag = 2 to get Alexa to say XXXXXX, while variable = 1 would trigger the Alexa Routine to say XXXXXX, and variable = 0 would reset. My ISY Portal pseudoMS was set for 1 as the active 'On' state and 0 as the pseudoMS as an OFF state. Here is the problem. When I set the variable = 2, ISY portal would send a PseudoMS event of Off to Alexa, even though 0 should have been the only valid Off psuedoMS interpretation.. Now, when ISY programs would see the request and then set the variable = 1, Alexa would refuse to say XXXXXX because it already had an event in less than the 30 second delay requirement. Of course Amazon support staff have been looking into this for the last 6 months, but I am not expecting any response within the next ten years or so. The moral of the story is, if you send anything to Alexa app routines, regardless of which state change, you have to wait another 30 seconds to cause any routine to run.

Well the third generation Dots are mostly unintelligible, with their mutated bass boost on a 1.5 inch woofer, and the 8" Show is starting to invade my space with advertising so this might make it easier to dump Amazon completely. Trouble is, now where do I go? the big advertising spy company, Google? They could get good money for my sexual habits recordings! Sent from my SM-G781W using Tapatalk

So now we discover Amazon devices are extending our LAN via a 900MHz network, giving access of our Internet service to neighbours and strangers passing by? I will be sure to never purchase any of the newer Alexa devices. It seems they have installed this "network extender" in devices and then enabled it without user's awareness of the seriousness. I thought I didn't like the dirty dealings of amazon.ca before? I have already had it out with amazon a few times over false advertising, lying about shipping and other aspects of purchases, including some immoral issues they are involved with. It just keeps getting better with these guys.

Agreed, but Apple peeps seem to expect and allow that "total control end to end", a little more than Android people do. Then there is those that think everything Internet is good for humanity, no matter what or whose privacy they violate. In the end, Amazon has just violated a huge personal security trust. They constantly attempt to grab your WiFi password "for your convenience, connecting future Alexa devices" and now they have installed your WiFi password into another person's equipment. hmmmmm.... maybe my WiFi passwords need to changed every few months also. Where does it stop?

Now it makes much more sense why Amazon crippled the Alexa app for Win 10, such that any Amazon device user must install the app on their mobile device. I was told 50 years ago. Don't trust big government Don't trust big unions Don't trust big companies. Amazon has a bad reputation for "leaking" and distributing personal data, on several occasions. I was never notified of any Amazon Sidewalk anything. This is the first I have ever heard of it. Maybe they mixed it into 10 GB of other spam so nobody would notice??

Condensing @MrBill's concept, you should be able to do this in one program. Trouble is $iMusic may need to be initialised at power up. With the variable iMusic init to to 0, the initialisation should not be required. By default, the iMusic will be set to 0 without any initialisation. This only works for 0. This will detect 0 to 1 only. AnyOtherValue to 1 will not run whatever process. Program Detect 1 to 0 [enabled] If $sMusic = 1 AND $iMusic = 0 <---------- check old value Then do whatever $iMusic = $sMusic <------------ keep last value for change detection Else $iMusic = $sMusic <------------ keep last value for change detection