larryllix

I posted a thread about two horrible new design LDs, I got a year or so ago. Complete junk. They changed a component and didn't refabricate the lid so it wouldn't actually close. Then when the id was opened, if it opened from one the end, the other end's catch would pry on a coil and break it. I kept one unit as I was desperate for a replacement unit, but the nice folks at aartech.ca took the broken one back.

Yeah, wrong device for that application. If the water got that high your pump couldn't fix it in time (it was already failing) and you would have had to toss the LD in the bin, and buy a new one each time. The Insteon LD need extendable legs on the sensor tips so the electronics weren't ruined with bigger leaks. IIRC @Tekenfabricated one like that with long bolts.

The whole point of a leak detector is to get you to look at the water damage location and then you are on site anyway.

Oh you are using Zwave? I think this may only apply for Insteon devices and then only with ISY Pro.

Bad comms and the MS has lost some links between it and your PLM, and cannot write to the MS and get a proper response. Put the MS into linking mode ad the use the "Write updates" on it from the admin console. Turn your Battery Writes option off with the top of the admin console screen button. Unfortunately ISY will forget this setting and start attempting writes to it again after any power cycle or reboot. This can be circumvented if the MS is powered by an adapter (MS II only) or no scene modifying program lines, including the MS in that scene, are used.

Just hit the button to reload the programs or reload the admin console without saving anything.

Just factory reset it and then load the latest version of firmware. Sent using Tapatalk

Your browser is never considered a server, but always a client. The error message indicates a server. I had that error when my ports were not set up right with my ISY and now when polyglot is rebooting after a setup change. But it shouldn't vary with a different browser so a very confusing report. MY mistake. The error must be coming from your browser about the polyglot server. More programmer laziness when reporting errors. They tend to see things from their POV during the programming. Odd the browser would get half way through the webpage and then not comm anymore. I don't think polyglot has used any newer html5 tricks that may not be supported. It all looks like basic old-tech stuff to me. Another update: The last screen shot indicates polyglot cannot connect to the ISY or device also. That is definitely coming from polyglot in it's status box. It would appear your browser may be causing polyglot to crash.

That appears to be a connection to ISY problem and I don't see how the browser in iOS should be related. If Safari were not connected to the polyglot server you shouldn't have a webpage at all.

Alexa has been having some real issues in the last few days. I have been getting "Something went wrong" on every command through ISY Portal but then the action is still completed. This has been happening for several days. Today, we didn't hear this, so something has changed. I put in a beef about their Routines not triggering properly under certain conditions, and they reported back they know they have some problems and will work on it soon. Then things went weird for a bit a few days ago. Now things appear to be returning to normal again. hope, hope.

Mine started after I replaced my PLM. Many devices did not take the update properly and bogged my ISY down, crippling some operations. Years past I have had a few switches start doing that for no known reason and a factory reset mostly cured them. Some were fixed by turning off the LED flash on traffic option. Either way a factory reset should fix any of that. Don't let the air gap switch fall to the On position after pulling it out. The SwitchLincs I have done will not maintain an air gap and need to be quickly switched from out to held in, or the reset fails

Factory reset the SwitchLinc and then restore it. Make sure it actually factory resets. They can start flashing the lights with Insteon traffic or just oscillating between the bulbs and the SwitchLinc dimmer circuitry. It is possible the bulbs filter capacitors just wore out. The LEDs inside are not the weakest link of these bulbs.

CAO is a company name that manufactures or distributes these wireless Tags. http://caogadgets.com/ JImbo has created a NS to support them in ISY. They can also be used with other interfacing methods or alone, without ISY at all.

I am in Ontario also and alexa reports "Sorry, something went wrong" with every command right now. My guess is they are actually responding to my suggestions how to fix the ISY Portal responses that trigger Routines and have made a bigger mess of it. UPDATE: My mistake. I swapped two CAO Wireless Tags names today and Alexa didn't like it. I disabled the Tag skill and then re-enabled again and alexa stopped complaining. All is well again.

Mine suddenly started reporting "a problem" but seems to operate fine still. It doesn't matter what your scene/program/or variable is called. It is what the spoken word is. If you have more that one spoken with the word "kitchen" in it, it will get confused occasionally. At least Alexa will ask. Google will just operate things on a guess when it doesn't hear clearly.

IIRC: Chamberlain has a MyQ box upgrade device you can just add on to the old units. I have two different vintage Chamberlain GDOs and they both destroyed my Insteon comms until I installed FilterLincs. The newer one (MyQ and battery motor) was the worst but tipped me off to what my signal problem was and caused me to track it down.

Yes. You should allow your DHCP server in your router assign IP addresses. This will avoid the "I can't access my ISY" a year from now when you may get an address clash locking you out of both devices.

I had a router that wouldn't allow any access to a device outside of it's assign IP address block. IOW: You could not access any device with 10.0.0.xx address in a router set to 192.168.0.1 - 192.168.0.255. I think it would assume it was on the WAN and routers don't allow LAN addresses through the router firewall onto the WAN.

I haven't been able to follow what you are trying to do but.... the init_to version of the variable is write only to the user...so far. IIRC that has been requested previously but more requests and case uses examples always helps. Search in the future features thread. Use Michel's tag to alert him BTW: I use a prefix like this $cTRUE , $cFALSE for fixed Integer variables that never change.

OK putting the two logics together I may have identified my problem. 1. $SayVar = 2 This is a request for a sequenced state variable trigger --> but sends No Motion semaphore to alexa app. 2. $SayVar = 1 this is my sequence arbitrator initiating the pseudo MS to send the Motion On semaphore to alexa, happens immediately 3. $SayVar = 0 this is my sequence arbitrator program clearing the trigger signal and sending Motion Off semaphore to alexa app. If 1. causes a signal of No Motion to be sent to alexa (var=2), and that causes a lockout of alexa vocals for 30 seconds, it could explain 2. not functioning, immediately after. After much testing to prove this 30 second Routine lockout this was not the way it was working at that (previous) time. Now it would seem that either signal action, MS On, or MS Off, must have a 30 second day before any new signal action is sent or the Routine will not be triggered. More confirmation testing of this is needed. Tomorrow. Thanks guys! I think we are getting this down.

@bmercier and @tmorse305 I have since split my alexa Routine trigger timings, Var = 1 (causes vocal trigger if var was 0 originally) Wait 5 seconds, Var = 0 (causes vocal trigger if var was Not 0 originally) Wait 25 seconds for a workaround of this problem. This should only inject a 5 second delay, until the problem is resolved, when it should trigger the vocals immediately again.

It doesn't seem possible that the alexa Routine trigger could know the previous value of the variable converted to a status point, but it does. It would appear that the alexa system does the math and ISY Portal dictates the conditions.

Please see my findings here

@bmercier I have since discovered a bug in the ISY Portal pseudoMS routines. This is very weird but you will have deeper understanding of how this could happen. I have many $SayXXXXXX variables, that ISY Portal converts to pseudoMSes, all based on var = 1 = motion detected. These all show correctly in the amazon alexa app for each and every MS device, in all cases. However, 1. Changing a $SayXXXXX var from 0 to 1, causes the alexa MS to show "Motion Detected" and trigger the attached alexa Routine 2. ...after which, changing a $SayXXXXX var from 1 to 0, causes the alexa MS to show "Motion NOT Detected" and NOT trigger the attached alexa Routine 3. Changing a $SayXXXXX var from -2,-1,2,3,4, or 5 to 1, causes the alexa MS to show "Motion Detected" BUT NOT trigger the attached alexa Routine 4. ...after which, Changing same $SayXXXXX var from 1 to 0, causes the alexa MS to show "Motion Not Detected" BUT trigger the attached alexa Routine It would appear that not only alexa knows the status of the pseudoMS but also knows how it was caused and does not respond appropriately in the latter two cases above. I have now received a response from alexa support and they recognise they may have some Routine coding problems with no expected repair date yet.