larryllix

I am using v5.0.10. YMMV.It's been a few years since I have seen the "old" method, but it should be obvious. If you can't see temperatures in degrees then you may be trying to use the logical output contacts.

Sounds reasonable and good to me but you should post this in the Product Requests thread.

This is a hands on learning process... Just start a new program called say..."Temp.high" by selecting the tabs "Progrms" and "Details". Now at the bottom left click on "New Program" and then type over top of the generic name it creates in the program tree. Select "Condition" box In the If section use the pulldown menus to formulate the line (in successive pulldown menus) Ignore the "And" menu Select "status" Select your stats name" Select "temperature" Select ">=" Select "80" Click "Add to if" at bottom Click "Action" Selecet "Your devices" Select "your fan name" Select "On" Click "Add to Then" at bottom Click the "Save Changes" button on the bottom left of the admin console Test it, by right clicking on the "Temp.high" program name in the program tree (left) and select "run Then", checking if the fan started running. Create another program named "Temp.low" Repeat the above but using "<=" and "75" and add it to the If section Repeat above for Then section with a line 'fan name' and 'off' Save that program and test 'Temp.high' as above, checking the fan stopped. Watch it for a few cycles using hair dryer hot and cool on the stat to test function. Don't cook it! Your done! Now laugh at how easy it was. You really can't do anything very bad and delete is a click away. Let us know how it goes.

Do you have a Nest thermostat installed without the "C" wire?

I have never looked at my LED on the ioLink. I only look at the status in the admin console.My closed status show On when the door is closed and the reversal option is not checked. Just looked. It's on the ceiling up 12 feet. Green LED is on, while the door is closed. I have no wiring in the C, NO, or NC, as I don't control my garage door from the ioLink. No real need for it and too dangerous until the All ON gremlins are resolved. The contacts can be wired either way but programming just has to match your status changes. There is no advantage to either NC or NO usage. There is no advantage to LED on when the door is closed or open. It's just an indicator of a closed contact.

All my Echo/Dot vocal commands go through ISY, with it's more supreme intelligence. If I had it turn the stat off, I would probably have a timer and sensing of bad temperatures to turn it back on, again. As it is, I don't allow my Echo/Dot to control my thermostats. I fiddle with them spring and fall and use the automatic feature in them to regulate the temperatures. This took some time to get there, though, making sure they were installed mechanically correctly, without draughts, and setting experimention. In addition, deep windchill compensation, intelligent recovery, and intelligent SETBACK, programs using ISY, helped. ISY is your friend.

I used the N.O. for the ioLink and programmed my own programs with no Status reversal that causes so many middle of the night problems. It wouldn't matter to me. I would just call my status point with the proper logical name. GDO.closed or GDO.not.closed GDO.open could work, also... but a very small open crack could cause my automatic garage parking program, in my Lamborgini RPi, to sense it was OK to slide underneath it.

OMG! Post #3 was all lies!You older than 35 also?

Programs are in the pulldown menu in the ISY Portal. Verbal on runs Then, Verbal Off runs Else Sent from my SGH-I257M using Tapatalk

None of that works with my Echoes or Dots. I thought maybe certain names for timers may be the answer but sadly no. I tried your "set egg timer for three minutes" exact wording but I only get the generic timer with the response "Three minutes. Starting now"

The echo verb list is very limited to basic words. You'll need a program to operate the mode changes.

Second thought... One program will not work with a dead band gap. Every time the stat reports a different temperature that condition isn't true it will run False. Three states are needed for a deadband, and Then / Else only offers two states. Two programs can offer three states. >=80 program Then code, <=75 program Then code, both >=80 program False code and <=75 program False code (no code = deadband)

Sure. Easiest is two programs. One greater than or equal to 80 deegrees to turn the fans on, and one program less than or equal to 75 degrees to turn the fans off. The two programs could be combined with a dual logic to trigger Then and Else but it would take some thinking to generate the negative logic to run the Off/Else command. Even if the program misses the trigger point either one will still run with the next temperature change send as a self-backup. Not sure what options are available in admin console right now.

You own Amazon and Aphabet and yet you stillwork for Apple? BTW:Your linked webpage hangs my Chrome/Raspbian browser when it attempts to load the video. IE 11 and Chrome/Android works fine.

....and what Stu said but make sure any conductor coming into your house has a good ground wire to the same point as your electrical service. This means phone, cable TV or whatever is connected to your Router. Sounds like it came in on one service and got your equipment, looking for ground. Sent from my SGH-I257M using Tapatalk

For that price we could buy pears or even seven Echoes. 'Total control, end to fail', again. Sent from my SGH-I257M using Tapatalk

Have you tried the transistor open collector intoo to IOLink? Usually, open collector outputs pull almost to 0 volts output unless heavily loaded. They do in any logic chip I used. The IOLnk sense input should have a better tolerence than that. I am guessing it will work. I don't see the purpoese of building a latching circuit. ISY programs can be ade retriggerable and tming can be set with one line of ISY code. If .....control IOInk.input is switched ON Then ,,,,Wait 30 seconds /this will get retirgged ever input pulse If ....status IOLink.input is On Then ....Wait 30 seconds /this will only get triggered when ioLink status changes. The ioLink has options for the output latching or momentary, following input and divorced. Check the device page options in admin console.

We use our rear doorbell sound for a "dryer is done" alert. Trouble is after a few years it still makes us think "who is at the door?" for a split second. Usually you can extend the drop out time of a DC relay with a series diode, resistor, and large capacitor across the coil.

If you advanced enough to write http handling code I really recommend you go to v5.0.10. You should have no trouble with it. Any bugs are monor gui layout things and it would be so simple for you to create a solution to this problem, rather than use workarounds. Then you wouldn't be rewriting you techniques later.OTOH: If you are like me you will enjoy the challenge to resolve it both ways.

Ad hominem comment? I don't know what you are going on about. If you would search the forums, you would find I have posted about a dozen different programs, attempting to teach others techniques, for getting and using temperatures into variables, including averaging three different sensors with outliers being disallowed from the formula, You don't need to preach to me about the value of getting temperatures into variables and your comment in bold seemed very out of context here. Regardless, I had forgoetten that people using less than v5.x, such as this user, do not have this capability, and need to use network resources to dump values into variables. Carry on. I have never had to use that workaround

What time is your general query set to run? Do you have a whole house scene set up?

Port forwarding is for translation through a firewall from WAN to LAN. If you are trying to access your ISY from inside your LAN to inside your LAN then port forwarding is not your tool. You need to lock your ISY ip_address down. You can do this inside the ISY or the best way is to put an entry inside your router. The router DHCP table sees MAC addresses and substitutes IP addresses for them. You can control what the router issues in the reservation table.

Wrong syntax and technique for programs. See my post again. It will do exactly what you want.

I compact my dates and times to a format like this. MMDD.hhmmss. I do this on a regular basis in V5 and keep it in an Integer variable with init to. Then I keep another flag variable set to 1 showing initialisation and init to 0. When ISY boots up I check the flag variable to see if it is initialised status and if not I create my running date.time variable. Now I send both Integer variable and my running date.time variable in a notification. Now, the notification sends the last known time (Integer date.time), as well as the current running date.time. By subtracting about 3 minutes, 30 seconds from the difference, I know how long the power was off. It's not real accurate, being based on the reboot time of ISY but it works as rough indicator. Lastly, I set the initialised status variable to 1. If you are not running v5.xx you will need another date time source. It gets a little more complicated to create than just massaging system variables.

If this device acts as any supported Insteon or Zwave device, it has a status page, and programs can be written and triggered by almost any parameter on that device page. Then it is only a case of dedicating a memory location, and writing a program to trigger on any change of value pf this parameter. If ....Multi.sensor >= 0 /reasonable low limit AND ....Multi.sensor <=99 Then ....$Variable = Multi.sensor /reasonable upper limit Else ...send notification to YOU Multi.sensor is ridiculous Hint: If you want to trigger further programs on the end result you will require the usage of a Status Variable .Now you will need an Integer variable also for the intermediate value, so that you don't rigger programs twice and on the false value. Then ....$iVariable = Multi.sensor ....$iVariable *= 1.8 ....$iVariable += 32.0 ...$sVariable = $iVariable