larryllix

If you look closely enough at my avatar, you will see a photo on one of my BSR plug-in modules that still works just fine.

Both statements may be true. Lately, items coming from California to Toronto area, can take over three weeks, so aarrtech.ca may not want to commit to a buyers, but instead just refuse to take orders until they have stock in hand. Aartech.ca have been very reliable for quick shipments for the $4-5000 worth of product I have purchased from them over seven years but these are still rough times, especially for product availability. Their indicated "2-3 week delivery" label on the product webpage, should be an indicator of what the problem is. An executive for Aartech.ca does post here occasionally. Perhaps he may pipe in here.

From Insteon (US) you will have to pay exhorbitant shipping costs to Canada. My order. years ago was delayed for about 6 weeks and then I was shipped three defective items with very old date stamps on them. Then when each item was found to be defective, I had to pay shipping costs to return each item, even though the iRLinc I purchased had the sensor wired in reverse polarity, a total factory defect and not my fault at all. (DOA). Without a commercial account, the return shipping was going to be around the same price as the part I was returning for replacement. Insteon would not honour my word and just ship me a new sensor cable (likely about $10). Later the other two items were found to be defective and the same warranty nonsense applied. Because Canadians pay their own shipping they are ripped off paying to return the product for replacement under warranty, even though it is Insteon's fault for not having any QC. I would wait for aartech.ca, no matter how long it takes. They honour customer complaints and will even send you a box to ship it back in. They have been top notch to me over the years. My guess is they have to eat the losses for returned Insteon products.

I only know of one Canadian supplier for Insteon. There may be more for UDI products, though. https://www.aartech.ca/isy994izw-irpro/universal-devices-isy99i-zw-irpro-insteon-and-zwave-plus-automation-controller.html On sale right now, but shows delay of 1-2 weeks.

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