larryllix

If you reread the original information from Michel's post it tells the DB9 DE-9 is supporting the PLM now and the USB port is being worked on for future PLM connections. The sudo commands are run from the FreeBSD command line. You can access this by using an SSH compatible terminal program like PuTTY for Windows. You will need the IP address, and your username and password for the polisy. There is no replacement for the serial modem on the polisy. The same PLM should work just fine except it will be full of links that will get destroyed if you "borrow it" for this usage temporarily. I believe ISY has enough commands to rebuilt the link tables in the PLM at both ends though. Sounds like a lot of work.

If this was mostly working before you may do well to ask specific questions here, one at a time. People will be glad to help you out and you have some experience putting the system together in the first place. The MS II units are a different beast than the original MS units and they take more reliance on the MS II timing and not so much on ISY. Just as a shot in the dark.... I would upgrade your ISY to v5.3.3. A lot of quirks were fixed with battery operated device logic in that version.

Awesome! Have you set up any thread/forum to give feedback on quirks/bugs/suggestions found? Do you want any yet?

Strange how Insteon support people keep issuing the same lie about the PLM. That's the second person to report the same lie from Insteon.

I try to keep my state variables to a minimum due to possibly slowing ISY down. I do admit I use some for titling groups of variables. However I do use Integer variables for constants also and that takes lots, but they do not invoke events when they change, and are a cheap resource for ISY. eg. $cTRUE is permanently =1, $cFALSE is permanently = 0, $cROOM.GATHRM = 21, $cROOM.RECRM = 11, $cMODE.DIM = 4 etc... This saves me looking up values for things as well as text messages containing the room number for MSes and LDs (always includes a room chart also)

I forgot about those cables. The signal levels may be a problem if the DB9 is RS232 standard though.

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