larryllix

Go Ontario!!!! ? ?

KPLs have so many Insteon links and get messed up frequently. Try a Restore from ISY to ensure the links are all intact.

Same here since about the last ISY Portal upgrade. Alexa doesn't seem to understand the device descriptions well and reports a lot of "I don't know what went wrong". There is also a lot of "I don't know that device", even though the device has already changed state via ISY. It would seem something isn't working correctly between ISY Portal and the Alexa portal handshaking.

Note: If you have to disable and re-enable the connection on the Alexa app and your ISY Portal, all Alexa Routines will be destroyed and without triggers. This means you will have to reselect a trigger and re-enable each Routine again. The Enable switch is somewhat ambiguous as to what position it is in. IIRC it is not clear whether the control is instructive, or the current state, of the routine. Also if you select a IFTTT output you can make a household announcement from a routine. I only select specific speakers though. If you select All speakers it can become unintelligible due to sounding like being in a huge echoic chamber.

Welcome to the UDI forums!! Create a STATE variable named $sSayDoorBellBattery (or other) Write a program in ISY that is triggered by the event at 30%. In the Then section install lines to make $sSayDoorBellBattery = 1, Wait 10 seconds and then $sSayDoorBellBattery = 0 In the ISY Portal Alexa section, define a pseudo Motion Detector from the state variable created, and call it "RingDoorBellLow". Use 1 for the variable Detected value and 0 for the undetected value. On your Alexa speaker say "Alexa...Discover" On your Alexa mobile app, create Routine using the pseudo MS device as a trigger. Create a custom vocal output with the words of your choice. Note: Routines are not accessible on a Windows PC, Alexa app. Battery<30% (If) ------->ISY state variable = 1 ------>ISYPortal name ------>Alexa Routine------->Custom speaker output

I bought my first PLM in 2014. After thinking it would become a problem I have bought two more PLMs since. After testing them, I removed each one and replaced my original PLM and it still runs just fine.

Think how much better the product would be, designed by an HA guy that understands the needs and wants of HA. "end to end...." Maybe Michel could buy it, backed by HA crowd sourced money? Make the eproms in the Insteon devices open source and let the crowd go wild with other styles of comms and compatibilities.

My guess is they are to lazy to hire a sales team. How many new managements and owners have the company had now? Something wrong with the building. Insteon already includes an RF protocol. They just need to decouple it from the grid frequency protocol. Send the RF first, and if it is more than 10 feet away, back it up with the powerline protocol.

I had to disable and re-enable my CAO Wireless Tags accounts to get them back "on Alexa line" again. That was a first time for Tag problems in 2-3 years. I think Amazon has had some server problems that may have been software edit botched lately. My Alexa commands continue to have problems still. They constantly fail saying they are having trouble but still work, and at times just don't work and/or misunderstand devices substituting other room and device names that I may or may not have.

Over half the businesses in my small town have closed up, never to return now. This factor could be an excuse for Insteon's actions, or a further indication they are folding up.

I seem to have developed a problem between the Alexa cloud server and the ISY portal server or my ISY. When given a command, Alexa reports "something went wrong" or other errors most of the time. Most of the time the command is successful anyway, and functions after 5 to 60 seconds, despite the vocal complaint.. It does seem that some times during the day are worse than others, as there are times when everything works perfectly with good speed, and other times it complains every time and can take up to about 60 seconds to function. Occasionally it just fails. We have noticed a lot of Alexa substituting other room names or not understanding what we said, or just failing to function with "OK" feedback. Is there some way to determine what is happening on this system between my ISY and my Alexas? I am not sure when this started but it seems about the time the maintenance was done so it may or may not be related.

So tplink doesn't threaten legal action against the people to remove comments that libel them on forums? It's just like linux. It was rock solid (like MSDos and all the rest ) until they started trying to come up to MS standards with a GUI. Now it crashes like the best of them. My older ASUS router handled all the DHCP table I could throw at it until it actually got used. The DHCP table was fine but the rest wasn't. The third party (super bug fixing) firmware made it worse. Now I stick with the manufacturer's firmware that understands the hardware inside. These WiFi repeating systems have made it worse too. I haven't seen one yet that functions properly or doesn't grind the speeds down to a crawl. WTF are you using uPnP for with ISY? I don't even know why ISY has it as an option.

Ever try a different cable or another Ethernet location in your house, a different port on your router? Kind'o sounds like an intermittent connection. How about factory resetting the router?

Michel for CEO! Michel for CEO! Michel for CEO! Michel for CEO! Michel for CEO!

You can't expect your ISY to talk to anything on the router's subnet when you have excluded IS from that allowed range of IP addresses. You have restricted your router to a tight range of IP addresses and made all other devices blind to your ISY. Unless you set your router to "ad-hoc" LAN (not likely) it controls all traffic on your LAN and all traffic must be handled by your router. Being outside of the IP address range tells the router to ignore your ISY.

My ASUS routers handles my 75 LAN devices just fine. Only the master node router provides DHCP. However my older ASUS router caused really obscure havoc at about 51 devices. Drove me around the bend for about two years. Why are you not using the range of .0 to .254? My guess is that is causing confusion. Also using 8.8.8.8 IMHO may be causing you probems. How can an ISY without an IP address talk to a cloud based DNS server via a router that can't recognise the ISY? Again. Try the full subnet range and use the router address for it's DNS handler. Keep things standard and simple until you get it working.

Try setting the ISY DNS to your router and let it figure it out 192.168.0.1. I suspect 8.8.8.8 (Google) doesn't know what your internal LAN layout looks like.

Who knows it Insteon actually has any documentation to share? Judging by the previous actions of the company it is a one man operation in somebody's garage and all the technology is inside somebody's head, with the greatest of intent to write it all down some day. These devices are all manufactured and tested in China, and likely all the design, and misleading docs for US patent faking was done by the same Chinese workers that built them. A fancy building warehousing parts in California, can give the impression of an established American company and bypass many taxation and political border blockades. Why would Insteon be any different than so many other products in the tech world these days?

I had this happen with recent routers that wouldn't handle that many IP addresses for my extra IP addresses used for another 25 WiFi bulbs. ISY and polisy couldn't get an IP address from the DHCP server after power outages. I was in Mexico and ISY in Canada. After another $1K in routers etc.. I hope it is more secure. Routers like to get updated with bug fixes but then they add more features and the NVRAM was overrun and wouldn't keep that many IP addresses. Upon power outages it was a race for items to get their IP addresses and occasionally ISY994 or polisy lost out. When I got home, I found polisys was using IP address 0.0.0.0 to access my house items.

Don't do anything rash! UDI has no reverse-engineered all the Insteon things. This has only happened lately and Insteon hasn't put out anything new, except the selfish (Hub only) messed up version of the MS II. All the Insteon support drivers are already there and are not going anywhere. If Insteon revoked licensing from UDI they would likely collapse. Newbies are not going to buy Insteon modules for $40-$60 anymore when they are not available in stores where the dozen of other brands are for $10-$25 each. Insteon is only bought by people like ISY994 users and other that understand the value of the Insteon protocol system and will pay 2-3 times the dollars. For the time being, my Insteon stuff works fine and likely always will with UDI. UDI is slow with development but polisy will come...just much later than everybody wants.

ewwww... too many bugs in Chrome. I use FireFox and I am getting to like it much better. Many options like complete advert blocking and anti-snooping options. Google doesn't like it and tries to block the browser in some webpages. I have had to move some of my personal HA NRbridge software back to RPi from polISY. Since the upgrade to polyglot v2 my software started hanging about once per month after running in parallel with polyglot without problem, since polisy was released.

This paragraph is quite misleading. While true, it implies that the state of the if section must change logic. If the If section is true, and any line gets re-evaluated to true or false, whichever section is running will be stopped at the next time slice surrender point. ie. any Wait or Repeat program line, and either section, Then or Else, will then start to process at it's first line. The same process will happen when the Else section running. IOW: Whichever section is running, or none, is not relevant to the result from a new trigger event. The quoted text implies the result is related to what is currently happening in the same program. That is incorrect. Sent from my SM-G781W using Tapatalk

The variable method does look less messy, so I like it better, but it also doesn't reside in one place, making it harder to associate sometimes, but I have had trouble with variables in the past not being ready on time for programs to use them properly. OTOH: That may have been a quirk on some version that should have been corrected by now IMHO.

Run Program2 will retrigger Program2 every time the Program1 trigger happens anyway. It makes no improvement over the retrigger situation. However, if you use the disable/enable technique and set the program to "Run at Startup" it can be corrected after any power failure like this. If [enabled or disabled] [Run at Startup] some trigger Then Run (If) Program2 Else Enable Program1 (yes... self) When the "Run at startup" happens the If section may be evaluated as False and Else will run, and re-enable the program, whether disabled or not. If the some trigger is true at the "Run at Startup" time, Program2 will correct the disabled Program1 properly anyway.

Welcome to trigger based programming! This is expected behaviour from ISY994 programs. There are several ways to work-around this. Here is one. Program1 If someTrigger Then Run (If) program2 Else ---- Program2 [disabled] If --- Then disable Program1 do some stuff wait for timeout if desired enable Program1 Else -----