nathan

Hi, eISY now uses the default port of 8080 without the ability to change it. There are a number of third party libraries that I use (ISYLogger, ISYlib-python) that have this port hardcoded. I intended to fork these to fix it but as a short term fix I used pf in FreeBSD on the eISY to redirect port 80 to 8080. Is there any reason why this shouldn't be done that I'm missing? It feels like it could be done to keep the eISY compatible with existing configurations, until they can be reconfigured/rewritten. rdr pass on re0 proto tcp from any to any port 80 -> 127.0.0.1 port 8080

It seems something still isn’t right with these locks and the new test builds. I used to be able to trigger programs on USRNUM but it seems like this is no longer triggering. Does anyone else have this issue? Edit: After saving the program again, it works correctly.

I decided to finally try a test build and it appears to have resolved my ZWave lock issue. Everything seems to be functioning so far. Thanks for the hard work!

I am also having problems like others with locks. My Yale YRD110s are not reporting status on state changes (either manual or via ISY) but work via a query. I tried various ZWave sync/repairs and also unlinking/linking the lock itself but that did not resolve it. I am going to try a factory reset of the lock like others have suggested. Other than the locks, everything else seems to be working. Edit: Factory resetting the lock has not resolved it for me. I opened ticket #10610 with UDI to see if they have any advice. Second edit: Downgrading to 5.0.16C did not seem to work with just a firmware downgrade. ZWave devices simply return errors in the ISY console and the device types appear to be wrong. I did not try to restore the 5.0.16C backup and went back to 5.3.0 which seems to work the same as it was, just work the locks that don't refresh. Final edit: Michael@UDI has confirmed this is a known issue and is being worked on. You probably don't want to upgrade if you rely on locks via ISY until this is fixed, at least Yale/YRD110 style locks. Final edit edit ?: Michael confirmed that restoring 5.0.16C and then 5.0.16C backup would put me back in working order. I just did that and things are working again. I will give the latest version a go again once the Yale fix is in. Follow up edit: 5.3.3 Test build has resolved this for me.

Weird. I did not read every post on this thread but I did search for the world "heal" on every page before posting and I couldn't find a single reference. Glad to hear it isn't something weird about my setup. To be honest, I still can't find the post in this thread talking about this after another quick search. Since this is now the major release, can something be added to the main post explaining this removal? This was a common pattern for years and is still referenced by the UDI documentation. I can't imagine I'm going to be the last person to be confused by this. Thanks

Has anything changed with global heal/network under the Z-Wave menu? I just upgraded to 5.3 from the RCs and I've lost this menu. I have repair links/update neighbors under each individual node. I believe this used to mean that the ISY did not think it was the primary controller.

Hi Michel, Sorry to hijack but I found this thread after trying to find others with my CLOSE_WAIT issue that I've been debugging. I'm not sure your explanation is right about CLOSE_WAIT. CLOSE_WAIT happens when the other side of the connection closes (sends FIN) and then the local kernel keeps the connection in a CLOSE_WAIT state until the local application calls close() on the socket. I think there is a bug in the admin console that was introduced at some point that is causing the application to leak connections and never close them. It seems like every device status report causes the admin console to issue a SOAP GetSystemStatus, which the console uses the response to change the flag indicator and block the UI if there is too much pending. The Insteon T-Stat makes this especially bad since when it is queried, it seems force the admin client to generate 10+ GetSystemStatus requests back to back, which then leak and get stuck in the CLOSE_WAIT state. @J_Barrettyou seem to be implying that your problem is resolved? Are you still getting connections stuck in the CLOSE_WAIT state? Thanks

Seems to me that you will decrease the reliability of the system by trying to add this type of redundancy, it is hard to get right and know that the other system is dead without more complications like a quorums and kill switches. Why not wire in a parallel backup coil based thermostat to keep the heat set to a minimum? Use a completely separate temperature logging system (wireless tags?) in addition to whatever the ISY is doing. Redundant reporting but not redundant control beyond the simple coil t-stat.

Now working here too.

Definitely not fixed here either. It has been broken since at least 10AM EST.

I'm glad you were able confirm. I can stop wasting time poking around now. Thanks!

Hi, As of today, all my echos are saying "Sorry, xxx is not responding" when attempting to turn an ISY device on/off. The portal sees the ISY fine. I've tried rebooting the ISY, turning off and removing all of the ISY skills in the Alexa portal but this continues to happen. Is anyone else having this issue recently? Yesterday, everything was working and there were no changes on my end.

+1 on having this problem. I was on v1 just like everyone else, switched to v2, I see dupes after forget all....one shows with a (device) suffix.

I was hoping there some some signal that would be sent over the Insteon network when the light bulb is powered on (i.e.: motion was detected by the non-insteon fixture and the bulb was given power). I could then use this to trigger other auxiliary devices, like a camera. Sounds like it would be the right behavior for my application. Either way, since the bulb can only be a responder, I'd have no indicator of it being on the network (powered) vs. off the network (not powered) so my idea is a no go. Thanks for all the feedback.

Hi, Is it possible to use an Insteon PAR38 bulb in a motion flood to detect when there is motion? i.e. It would turn off when there is no motion and then supplied 120V when motion is detected. Is there some event that would be triggered when the bulb initially turns on? I don't have an Insteon bulb in hand so I don't know how it behaves when it is initially supplied power and if an event is triggered. Anyone have any insight? Fixture is a RAB. I know others have used micro module to sense, but I was trying to approach this from another direction.