larryllix

@bmercier@MrBill Just an update. I may have found an answer for this. Here is the program I am testing with. So far it always has responded with a 4 count , which would be a normally expect result. I will leave it in place for a while yet, to test at a time when and if this ever happens again. PortalTestProgram - [ID 0037][Parent 0001] If // ISY Portal retriggerr tester Then $PortalTestcounter += 1 Wait 2 seconds $PortalTestcounter += 1 Wait 2 seconds $PortalTestcounter += 1 Wait 2 seconds $PortalTestcounter += 1 Wait 2 seconds Send Notification to 'eMail Larry' content 'PortalTriggerProgramTestReport' Wait 30 seconds $PortalTestcounter = 0 Else - No Actions - (To add one, press 'Action') I have a Portal TV unit on top of my TV. It supports Alexa things also. Previously I had to turn the Alexa feature off because - it hears better than the other Alexa boxes - it doesn't play nice, arbitrating properly, who will answer, and gives itself preferential treatment - it answers through a micro speaker with a terrible squeaky voice sound. - it doesn't support all the Alexa functions After checking the setup, I found the Alexa features still disabled. However it was offering help instructions when talking my other Alexa speakers. A toggle of the Alexa option and it has seemed to shut up again. I believe this may have given my Alexa via ISY Portal the double triggers that have been double starting my programs.

Have your tried a "Restore" on the devices in the admin console? Insteon links get lost sometimes and parts of the communication will stop working while other parts still work just fine. Restore will write the links back into the device that ISY thinks should be inside the device. Right click on any device in the device tree, and you should see "restore" in the dropdown menu for that device.

Michel already stated that NRs would be supported, but not further advanced. When ISY moves over it should already/still contain the NR module. @whyworkOnce ISY is inside the polisy, it may use http/s packets to communicate with polyglot but it will be all internal and not leave the box.

If you run the If for a program with no code in the If section, Then will be run, as a True logic outcome is assumed.

It happened again last night but the program it happens with is not consistent. I will attempt to trap a few programs with counters to ensure they have been double triggered first. Sent from my SM-G781W using Tapatalk

This means every program using a Wait timer in it may double trigger from most vocals. This may be a long time hidden problem for so many here using ISY Portal, and experiencing irregular vocal command failures. I will look at some work-arounds to compensate usage of programs with ISY Portal.

Thanks Benoit. Is there any chance of this multiple program trigger being fixed in the near future? Immediate(not wait for program completion) handshake back or ignore the second (third, fourth?) duplicate trigger of programs? If not I will need to find some work around with ISY, likely state variable program event triggers.

That is a requirement of Canadian Code now, and I believe also in the USA. Neutrals are required to every electrical box.

Not legal in Hawaii yet?

I think you just prevented that by responding in the thread. LOL

v5.3.3 has the battery operated write caching resolved mostly. I would recommend v5.3.3 as the latest version. IIRC v5.0.16c contained many bugs on the battery device front.

Read this thread starting from the beginning. What is hash crap?

I doubt it but with linux (RPi) and freeBSD (polisy) you can run the update/upgrade lines again and it will sort out what isn't up to date.

Sounds like you just did a major upgrade. I have seen my RPis take 5 to 6 hours for a major upgrade, including most packages and an OS upgrade. Sent from my SM-G781W using Tapatalk

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.