larryllix

Jumping to v5 will usually find you with some programs an scenes where the code lines could not be upgraded properly and UDI knew it. They will have their program icons marked in yellow, and lines either replaced by comments, or lines in question marked with comments. Some scenes may have to be corrected and re-saved. When done the corrections save a backup in v5 format. They are not compatible. If it gets unbearable, just reload your last v4 and restore from your V4 backup. Allow about 1-4 hours best-worst.

If you made a a good backup, you are never lost with ISY.

No. You need v5!

I would assume so, somewhere but I have never used one.

ISY is not an interactive system, and therefore can't do anything with the failure to respond-on-time, anyway, except to log it in the error log, and possibly not bash the next Ethernet packet out until a response is had or the timeout expires.

@GDavis01Increase your timeout to about 800 mSec. It sounds like you are right on the boundary of the response time, depending on router traffic. @kclenden ISY seems to support SSL encryption, due to offering HTTPS and port:443. I assume that implies the same.

Nice! I would still add something like Wait 2 hours Set light to off to the end of program 1 to cover those contingencies where things get out of sync, as a just-in-case light shut off. It could also be handy if you want the light on for security, You could just open the door once only, and it would time itself off automatically.

IMHO if the door sensing is using "control/switched On" it should avoid oscillation. The control/switched logic test always evaluates as False unless the testing is due to it's own condition change. Lots of Else sections will run but that should not affect the apparent operation. Using status would likely cause oscillation (while the door is open) because you are changing the status of the device inside the same program that is triggering on it.

No. When you disable a program it will stop it (IIRC only at Wait or repeats) but enabling a program doesn't cause any running. I use many second programs that disable and enable the first (one and only one logic) and it would cause problems refiring them if they ran again upon enable. I think most would oscillate then.

Cool idea! My needs have changed on this. I got a new vehicle that the door opens awning style, and I don't control my GDOs. Some people in this neighbourhood never close their GDOs, and if somebody came into the neighbourhood, neighbours would have a complete description, so it isn't much of a problem. Small rural cluster culture.

Thanks! That doesn't look easy to interface to a GDO and I can't see any pricing. Actually, my original drive was having a side opening back door on a RAV4 and the garage door coming down on the edge would have demolished that door. It becomes very protruding when they open sideways. Other than that, completely useless format. I raised my GDO beams up to the level of the lower tip of the vehicle door in an attempt to avoid that accident. I realised it helped endanger the very child problem we have been discussing. However I live in the rural and have no small children in the area. Worst is coyotes, skunks, and cats, but I would be proud to squish one of them.

I bent a side door by backing into the GDO track. I bent the track back with my hands and it's been fine, not showing any dents for last few years. It was minor. The Rav4 door had the corner metal rolled over but bent it structurally, slightly. That one cost me almost $3K to replace the door with a junkyard, lower model (no coatings) door. Mind you the bodyshop people all told me the window tracks are welded in and cannot be made to not bind, on a scrollable door window. Then there is all the power gadget switches. While I was at the bodyshops I saw several bans with the awning type doors with dents in them. I was told by different shops the door were write-offs, as the painting of half the vehicle was the larger part of the costing, anyway. Insurance coverage (big deductibles) was part of the solutions, I am sure.

The one that bothered me was: now having a hatchback style opening back door on a CR-V, I have seen several rear vehicle doors at body shops, last time I was there. They become a very expensive repair into several thousands of dollars to replace. I have several laser pointer type parking guides on the garage ceiling, and the first spot that falls off the dash gives a tested clearance, including the hinge hardware, clear of the vehicle by a few inches, while the door is open and during any part of the opening arc.. Just another consideration for blindly closing garage doors. OTOH: That could also happen while you are closing it from the wall PB,.

I am a big variable advocate where they make things easier or more complex algorithms available but.... Try something like this. If door open is switched on (not status) AND Light is Off (this is status) Then turn light on WAIT x hour ( all else fails clause) turn light off (anyway) Else turn light Off Framing this with a time of day logic will complicate things and require at least two programs with interlocking enable/disables

Not too much of that Guinness! I was looking for a multiple beam sensor originally. Do you have any links to one of those?

All my cameras have a few seconds of delay. If I saw a child entering under the door, it would a few seconds later and then the remote control command would likely take a few seconds more to stop the door travel. That doesn't even account for the human delay to find the dongle or click spot..

That would be nice but like all the other high-tech industry, they would ave to produce a new video every week or two.

...and if they addressed by Insteon ID, they will definitely be different. I know the nice names are only converted at human read times. ISY uses all indexed references.

Insteon protocol is supposed to include an anti-colision algorithm mechanism in every Insteon device. Either way enough packet stacking would likely cause problems for battery devices, that are blind to it. I think.

I think the PLM and devices have limited stacking facilities to create a polite transmission order but with a lot of Insteon traffic, that feature can potentially make it worse for battery operated devices that cannot detect powerline collisions. It seems Insteon battery devices just do a dumb algorithm by just banging the RF signal out a few times at random. This could make things even worse yet.

I use a lot of variable for lighting moods. Increasing the variable by one can brighten the lighting scenes (not Insteon, but combinations of Insteon, WiFi bulbs and strips with colours). When "borrowing" a lamp for flashing or other temporary uses, it is easy to restore the lighting in effect before the "Borrow" by replacing the variable value. It's not usually your children. It would be the neighbour's baby carriage pushed by the older sibling under your garage door. The existing safety mechanisms in GDO could still break a child's. neck or back. They are not designed for that kind of protection. Paying law suit would not help you live in the neighbourhood, or sleep, if something like that happened.

You may encounter people here telling you not to close a garage door without visual confirmation there isn't a toy, or a young child under the door. I don't control my garage doors. I do notify the humans if they are open though. While any door is open I continuously flash one lamp in the corner of my Gathering Room, with red flashing. If the Gathering Room lights are off and the bedroom lamp is turned on (automatically) I flash that lamp at full brilliance. I normally run that 100W equiv. lamp about 10% at nights. The bedroom lamp is flashed by an ISY program loop, while the Gathering Room lamp is flashed by a self-contained bulb code, so ISY doesn't have to do it. Programs can just go down a list of items to fix. There is no need to detect whether they are on or off, just set them to the position you want. With garage doors that is usually different, as the control toggles them open/close but there should be programs already in place that you would just call as subroutines, and those programs would decide what to do. So it could look something like this. If bedtime detected Then set lamp1 to Off Wait 2 seconds set lamp2 to Off Wait 2 seconds Run GDO1 close program (if) Wait 15 seconds Run GDO2 close program (if) Wait 15 seconds $sSayGoodNight = 1 <---- trigger alexa routine Wait 5 seconds $sSayGoodNight = 0 Else -----

Wait and Repeat statements ALLOW the system engine to re-evaluate all program triggers, if any condition has changed. This includes the same program's If section as the one containing the Wait or Repeat. Think of them like a surrender of their time slice in a multitasking system. If any condition changes in a program containing that same condition the program will stop what it is doing (if running) and run Then or Else, depending on the outcome of the If section. Disabling does not disable the program, only the triggers in the If section. This affords subroutine style usage. Calling a program as a subroutine does NOT wait for it to return but the second program will launch simultaneously. There is no guarantee of running order. Simple in-line if-then constructs can be done with the ISY Repeat-while construct. Clumsy and ugly but it can be done. It takes the involvement of another variable. In many past threads users have wanted to change the program structure into a When-If-Then-Else sectionalised structure. Some want the same but each If line can be enabled/disabled individually. UDI is slow to respond to these requests as the bit off Zwave with it's constant updates, and dumping the java for HTML5/CSS/js admin console. Lastly, Integer variables do not cause event triggers. State variables do.

I have one of those I bought under a different name in a surplus store here. I don't detect any Insteon signal problems with it for Insteon devices connected beside it. I have never used Insteon devices plugged into it, though. Nice bars, with a little more space between each socket. I use a FilterLinc on each GDO and an I/OLinc plugged into each unfiltered receptacle on them. One Chamberlain MyQ GDO had crippled my whole Insteon system, so I know the FilterLincs must block Insteon interference very well.

Nahh. UDI doesn't believe in home automation. Today is Saturday. Michel's day to replenish his food supplies. Sent using Tapatalk