larryllix

Unfortunately as posted by others Nest will not give out their local API. It is rumoured there are hacks out there but that would take a third party CPU to run some hacking software to get parameters into your ISY. Cloud works most of the time, but relying on IFTT is probably the least secure you can get.

Other than some edits into sane names, this has become the bible of leak programs, http://forum.universal-devices.com/topic/11566-leak-sensors-a-suggested-complete-program-package/?hl=%2Bsuggested+%2Bleak

This has become the bible for many of us. Most may have modified (edited to meaningful names) it after installing but it has been tested for a long time. http://forum.universal-devices.com/topic/11566-leak-sensors-a-suggested-complete-program-package/?hl=%2Bsuggested+%2Bleak

You could use an ISY program to translate the dim signal into an Off signal. IIRC all SwitchLinc paddles send out all the dimming signals despite their own load controls circuits not capable of dimming. If ....SwitchLinc is switched dim Fade Down Then ....set SwitchLinc Off Else ...--- Edit: Corrected termimology

UDI has spent countless development months on Zwave. If there is a rock in the garden a plant's root has to grow around it. Good companies don't disclose business relationships publicly, while there is still hope.

From the other thread: I guess I don't understand the purpose or the point of the ISY finder applet but in three years of using ISY the finder has never found my ISY yet, and tried on many different computers. I have always had to manually add my ISY's IP address to the Finder. Then, if there are two possible addresses listed I have to manually select one every time to load the admin console.

In the other thread you started for this, you stated your ISY was assigned a static IP address that was not included in your router allowed IP address range. If the IP address is not part of your router's LAN it will not likely route any of it's data through to the Internet. Turn DHCP back on in your ISY and reboot it, as a trial for the portal. Right now your ISY is not on your LAN sub-net and nothing should respond to it.

If your ISY is not on your router accepted IP addresses for your LAN it probably won't pass the data requests through it and back, from the Internet. Turn off your static IP address and then reboot your ISY as a trial.

I have had routers that would not allow traffic to devices on my LAN if they were not inside the router's IP assigment range. Acted like a Steve Jobs product "Total control...end to end!"

Two routers will likely confuse your whole network. Only one DHCP server should exist on your LAN. Your new router needs to be set up to match your previous IP addresses established in your softwares. Turn the old router off, and configure your new router to the same same subnet address range as your old router was. Install an IP address reservation for your ISY into the new router's DHCP IP address reservtion table and turn on DHCP in your ISY (losing the static IP assignment). Let your router assign it or you will likely have clashes later and your whole LAN can go nuts.

It probably needs more radiant heat isolation between the humidty sensor and the electronic circuitry. Every time the transmitter sends a signal or executes some algorithm the extra heat drops the sensor RH%. My log file is 5.25 MByte since July 7 - July 27. I get a heartbeat from a Venstar stat every 45 seconds, ecobee3 stat every 60 seconds, WC8 weather station (8 values every 20 seconds), NRBridge RGBW LED software, and regular humidity reports from two 2441ZTH stats and updates from 4 CAO tags for humidity, temperature, battv, & X,Y,Z position every minute or so. I think UDI must have installed some log file size management, as last time I looked at it, it took almost an hour to load into Wordpad on a small machine. BTW: In v5.x I have noticed there is an an option checkbox for both my 2441ZTH stats "Send Humidity". I have no idea what it does or if it even functions. The option checkboxes do not stay set when loaded, each time.

That's only about one update every 45 seconds. The ISY CPU will outperform anything a totally flooded Insteon protocol channel could throw at it.

It seems to me that the constant humidity update may have been designed to act as an Insteon heartbeat from the stat. Unfortunately ISY has no program feature using triggered events to detect the signal if the value doesn't change.

I used a KPL, that I used for my security system code. I have installed detection for several different codes to reset my well pump and washing machine as well as toggling my security system programs. For the washing machine leak, and well shut off, I send the reset code with the notification. 'Well pump shut off. After checking basement for leaks, reset the pump by pressing code AAAA on the laundry room keypad. For the washing machine BBBB. Sent from my SGH-I257M using Tapatalk

Questions. 1) Are your garage doors involved in any scenes? 2) Do all the Insteon devices in your house go on with these events?

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.