larryllix

No. Just get another dual band module and find a use for it half way between large spans between Insteon devices. I use one for utility room (where all the water is) backup heat with a portable heater. Probably never cut in but it works as a signal repeater. This may increase your hop counts and decrease the hops left count but hop counts are not an indication of signal quality, only the system stabilty strength. Irregularity of hops left count indicates flakey comm signals. Some devices send out signals with the Max Hops count = 1, and are received with Hops Left = 0. This can be be a perfect signal.

Its a big business. Previously we had a spammer family living down the street. They owned two of the larger homes on the street with pools. I saw no visible means of support and they all were always blocking traffic while they played street hockey. Suddenly, an article in the newspaper appeared, giving their nmes and addresses about their spamming practices. Google and a few other biggies were threatening to sue them for two $million if they didn't stop. The article reported they previously settled out of court for over $200K with another online biggie for abuse of their email services. That didn't seem to slow them down any. I thought about dumping garbage in their pool every week back when spam was ruining the functionality of email accounts. Tit for tat?

I have requested a special character or sequence to inject a 100ms. delay in Network Resources in the Feature Request fourm thread. I don't think it is going anywhere as the powers that be didn't see much support for it. The original request was to implemet 0.1 second selections to the Wait time pulldown but that was reported as too difficult. Possibly find that thread and add support and/or another techique to implement it. UDI is responsive and somewhat request driven . For the time being I have to use Wait 1 second in ISY programming.

Yes, we have some paid work-at-home spammers here that use very sneaky techniques. That one didn't even post a link but used it in context to get hits via a search. Looks like reporting it worked....gone!

Almost every aspect of ISY is never based on any guesses. When a program turns a device on ISY does not assume it to be on, but rather goes by the status reported directly from the device only. It's a complete feedback system without any guessing. However, scenes may be a different story. AFAIK scene commands are shoved out the port and devices are assumed to be in the desired state. This can be a mistake at times and lead to bad decision logic causing serious side effects potentially.. Typically UDI leaves any assumptions to the end level programmer/user. There isn't anything in devices, programs or scenes that can't be determined with absolute certainty (always provided comms are perfect) Having said that no assumptions need to be made to get the status of things. For a simple MS / LampLinc only the status of the LampLinc need be examined. No changes need to be made to any code to get an absolute status in that simple case. Nobody cares what the MS state is. An extremely simple one line program can get that status into a program status. A simple two line program can get the status into a variable. For three way and multi-way lighting logic there is only one status per load, that can ever be looked at, anyway. Switches only put out one shot signals and do not have any status to read. For more complex scenes with multiple devices, a simple program with lines to match each entry in the scene can do the same thing. If it is not too complicated to build a multi-component scene, then it shouldn't be too complicated to build a simple program to get the status wanted with the tools that already exist. Virtual devices could alleviate a lot of programming problems for users. I haven't seen any in v5.0.1 to v5.0.10 yet. However virtual devices are only going to do what many ISY programmers are already doing with v4.

I use several scenes in my gathering room that are always run from programs. These programs control 6 Insteon Switchlincs, five Hue bulbs, 5 MilIght bulbs, and 4 LEDenet RGBWW sLED strips. Each program is triggered by one variabe that can contain one of a dozen numbers that represent whatever lighting combination I last wanted. Anytime I want to determine the last issued lighting level in the room, Ican examine the variable for it's value. There are occasions where I need to "borrow" a lamp or group of lamps for annunciation purposes. Eg. Flash a corner lamp red on and off indicating the garage door is open. Run a sequence of my Hue bulbs in Red across the back wall behind the TV each night to indicate it is midnight as a "get to bed reminder"...etc.. After this temporary "borrow" I need to restore all the devices back to their "pre-borrowed" state(s). It's very easy to restore the same trigger variable value back into the variable.Of course to guarantee it triggers the program bank responsiblefor all the settings, I stuff a -1 value into it, and then replace it with the value found in it before the "borrow" that I saved in a temporary variable. Having a flag available for an Insteon scene would be useless in this case as I have many more systems than just Insteon. I have no Zwave as I have avoided it so far. Hypothetically a termostat could be included in a scene with a particulat temperature setpoint and/or fan cycle setting. What would constitute the scene being true or not true? In short, if somebody wants to detect a particular and exact state of a group of devices, write a program in ISY (a very capable logic engine) to convert a range of levels for every device, converting the amalgamated logic into one variable or program flag, true or false. That is what ISY programmers are capable of....making specific and custom logic needs available. ISY has a very strong set of generalised tools for an HA system, already. If only one device's status is all that is required then that capability is already available too.

You could create a variable in ISY and a program to detect the level of every device in your scene. If the levels match, within an allowable tolerance, you could use the variable as a flag to say the scene was On. Now you should be able to determine if the scene was on to suit your purposes. If you can fake a scene status using a single device, you should be able to fake a scene status using a variable and that capability already exists. I try to avoid usage of scenes with ISY. I only use scenes where the Insteon traffic quantity would be too slow, or where I need the speed of response. If the Insteon protocol was faster I would only use ISY programs.

I have never done this. I believe in using more home automation style and haven't had much need. There was a thread here, with a complete description of the technique to do it, about six months ago.

Read post #5. It will never be so.

Easiest way is to subscribe to the ISY Portal. The setup page allows vocals to convert to programs, devices, variable, or scenes inside the ISY. Then Echo or Home can attach to these vocals.

Many of the US companies haven't figured out how our metric time works yet, and may be a major hold up, being embarrassed about not understanding the simple math formula.

Many "exclusive rights" were granted to Canadian distributors by US companies thinking anybody wanting those rights was more than welcome to the current zero market they had here. Years later once the Canadian market potential was realised, the agreements were already in place, with royalties needing to be paid to US mother companies. Sony A/V equipment was one good example and why Sony was over double the price here, as the US until better quality equipment was created here. It isn't the Canadian government that is restricting Canada, generally. It's the exclusive rights given away by foreign companies to this part of America. There usually no restrictions if you are willing to pay royalities agreed to. Love Reagan.

I noticed this at my son's house last night. Apparently I was calling one device "Light" instead of "lamp". I was sure I had been using "Light" since inception and it always worked with that. I believe the error is reported incorrcetly, maybe as a too generic error response.

When a router/modem combo is in bridge mode it won't function on your LAN at all. A router's job is to convert data with external Internet axdresses to LAN addresses. Bridge mode turns the routing function off and you just gave a hub (splitter) connected to a modem attempting to spew Internet addresses nto the LAN side. All LAN sides of your routers must be connected together and only one can be connected to the ISP side. Routers are made to reject passing 192.168.xx.yy addresses through themselves. Those are reserved addresses for local networks only. Sent from my SGH-I257M using Tapatalk

It sounds like you have a firewall between the LAN side of your Arris and the WAN side which most likely unavoidable, as in most routers. Try connecting the Arris to the ATT router via a LAN side port. That way you bypass the native firewall iand address conversion n the Arris. Bridge mode never works in my Cisco, Netgear, or Dlink routers here either. The Portal can't work ifvthe devices csnt see each other. Not having Intetnet access is a good indicator. Sent from my SGH-I257M using Tapatalk

My guess us you have three way switches at the other end of all the reds. Toggling them you may find live changing wires. Sent from my SGH-I257M using Tapatalk

I use some logic If the garage door is open and gathering room lights are turned off and the bedroom detects motion, then flash the side table lamp at 100%, that would normally be on at 12% with motion detected, that time of day. Sent from my SGH-I257M using Tapatalk

Not sure I remember the conversation but.... Repeat every 30 minutes ....set Fan On ....Wait 20 minutes ....set Fan Off repeats the loop every 50 minutes, with a 20 minute On time, and a 30 minute Off time. The "Repeat every" is a syntax error and should be changed to "Repeat with Wait" to read. Repeat with Wait 30 minutes. or Loop with Wait 30 minutes @Apostolakisl: Nice one! LOL. We need a thread of the most twisted/cryptic programs. OTOH: some of us do that unintentionally. I never thought of ISY programs as cryptic but they certainly can be. Folder conditions can certainly waste many hours troubleshooting programs that won't run.

Without the Not Switched it can never be false and cancel the timer but... any further logic lines than just the one 'Switched On' line can change all that, so the Else = set Fan off would be required.

When you use theNOT switched logic you will also need to put some code into the Else in order to not leave the fan running forever. If ...(KPL is switched on ...and ...KPL is not switched off) ...or ...other activation Then ...repeat every 30 minutes ......Set fan on ......wait 30 minutes ......Set fan off Else ...Wait 30 minutes ...Set fan off

Fan cycling can get complicated! I have a series of programs that synchronise with the HVAC fan as well as the humidifier (not central) and the HRV fresh air system. This is a energy saver so that the central air handler shares the time for them all. I don't want to post it as it may confuse the heck out a newbie to ISY programming, using time clocks from v5 and dewpoint comparisons etc.. Then I have monitoring programs inside ISY that draw charts to show sequence of HVAC operations helping me immensely to develop this craziness! IOW: Paul's program (above) looks good !

This the java cache cearing you need to do between but it is shown for Windows.

Nice! In the original programs you had a 20% detection, and have sinced removed the logic. What was the objective of that dim level? BTW: I define constant Interger variables so that things look like this. (personal preference) If $sMasterBathFan is $cTRUE Then $sMasterBathFan = $cFALSE You can base logic on the state of another program and avoid the variable usage, but I prefer the variable technique myself. You do get 10, 20, 30, 40, 50 minutes with multiple On taps though. You may want to make a limit on that and a cancelling double tap Off too.

OUCH! A wash in some weak cleaner (Varsol is the old standby but rubbing alcohol may do it), let dry thoroughly without any power, and possibly replace the SD memory card after testing, would usually work depending on how the powered up state affected the wet connections. I would definitely try it but I live in electronics repair for 50 years. I've been known to scrub boards with contact cleaner and an old toothbrush, blow off with compressed air, let dry and power back up many times. LOL but that was mainly for electrical grid, sensitive CPU protection equipment that kept hundreds of $million$ worth of transmission lines safe and lights on.,. not important stuff. EDIT: I forgot to mention to keep any difference of voltage (statics) away from the PCB. This means you don't wear synthetic or wool shirts, you hold the board continuously with one hand while washing it with the other. Then you touch the surface with your body (hand) you will set it in down on to dry, before the board touches the same. Grab by the edge of the board, not the chips.

Have you contacted UDI support? I don't think we I have ever heard of an ISY going belly up before. (turn it over again? )