larryllix

Nice! Yeah I had thoughts of that also. Perhaps ISY Portal does not handshake as a sign to the command processor that it is not done successfully yet? Of course this could be a handshake from ISY to ISY Portal but somebody is retriggering the program. Your idea could prove the handshaking speed, but not likely the culprit. Trouble is this may never prove it is happening due to being infrequent. hmmmm...maybe a hit counter? but then how would I know what the previous count was at? Reset each midnight? Send a text message with the count after a 60 second wait time and then reset at the end of a few suspect programs? Maybe push the time lag concept to a malperformance time?

This is only an infrequent happening and running one program from another does not stop multiple triggers, if that is what you are implying. I thought about trying to flip trigger flagging variables but many programs do this problem. That is assuming ISY Portal will set a State variable from a vocal???

@bmercier I have a program that turns on/off many lights in my gathering room. It is composed of several Insteon scenes and several NRs that trigger routines in my RPi to turn off several banks of different style WiFi lamps and strips. Some lines require Wait 1-2 seconds between some lines to allow I/O time to function (especially NR that do not get variable substitution upon invocation) Here is what I see happening. Alexa! turn off/on gathering room lights! ...(long pause) Insteon lights turn off/on = first few lines of ISY program Alexa replies "I don't know what went wrong" ...(10-20 second pause) WiFi bulbs and strips start turning off/on Alexa replies "OK" This (and from other malfunctions) appears that some handshake is not reporting correctly between the Alexa cloud and the ISY Portal cloud when the first vocal command is passed to ISY Portal, but the command to run the ISY program is already passed successfully and in progress. Then Alexa command response timeout expires and Alexa reports "I don't what went wrong" or some other failure vocal report. Alexa tries again. ISY Portal again triggers the ISY program, stopping progress and starting the program again. Handshake functions or Alexa cloud gives up after two or more retries. Again the Insteon lights are turned off/on (but no change is observed, as first program lines have run previously). Now the program lines complete and ISY program is completed, turning off/on WiFi lights via NRs. Is this making some sense? This has been a long term problem as far as I can tell. This problem may be between the ISY Portal and ISY, instead. I have no way of telling.

That never functioned. See Michel Kohanin's posts for instructions to do it manually via "SSH dialin'" to polisy. Automatic updates coming later.

Sure. I bought a desktop PC with a serial port, parallel printer port and eight USB ports but I haven;t seen any software that uses them for decades. IOW: The polisy computer was was hardware designed with these ports. It doesn't mean ISY994 software will ever utilise them. UDI purchased an existing design, and had minor customisations made to it, to keep the costs down for their users. Nobody will ever use BT either. It's range is typically 6 feet. How would that be useful in HA?

Yes, I believe that is the original intent, according to Michel's post above. In the end, who knows but UDI has to roll with what Insteon does. If Insteon discontinues the serial port PLM, UDI has a USB PLM interface in the works. If that collapsed also, then an Insteon Hub using Ethernet, would be in order. If the Hub disappeared, then Insteon would be basically dead IMHO, or developing a whole new structure/basic interface. UDI may be able to obtain the licensing to produce their own PLM design, previously designed in the past. They all plug into the wall in order to not only get power, but to transmit their Insteon signals onto the powerline. UDI is smart and has rolled with the punches, as needed, so far. I trust them but they don't typically publish their plans or thinking ahead of release. That is the modern way to protect your technology, since patents have become a joke.

DB-9 DE-9 is the small "D" shaped connector (hard D shaped ring) with 9 pins on the back right of the polisy box. The original RS-232 (serial port standard) connector was a DB-25 connector, if you remember what the full serial port connectors looked like (yeah, 25 pins). It was later replaced by the DB-9 connector, as smaller computers came into being. I don't remember what the "B" "E" represents.

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".