apostolakisl

Oh come on now, it isn't that hard without the portal! I use IFTTT, not so bad. If I were starting from scratch, I would use the portal, but I already have a bunch of things that access the ISY using REST. Steps: 1) install self signed SSL on your ISY 2) open port 443 on your router and point to ISY LAN IP 3) subscribe to a DDNS company (I use no-ip) 4) open an account with IFTTT (free) and link your Alexa account 5) set up commands on IFTTT - Use "Alexa" for your "this" - Use "webhook" for your "that" - go to http://yourisylanip/rest/nodes to get a list of all the nodes on your system - use "find" function in your webbrowser and search the name of the device or scene you are looking to add to Alexa - the node name is will look similar to this <pnode>45 8D 28 1</pnode> - enter rest command into "url" section of the webhook, all the other stuff leave blank. It will look similar to this https://admin:password@yourddnsurl/rest/nodes/16 47 2B 1/cmd/DOF (DOF is device off) - say "Alexa, trigger <your chosen statement here>" and Alexa will respond "sending that to ifttt" and 1 or 2 second later it happens. The process is very similar using google home.

That's what KPL's are for.

Or use IFTTT and send a REST command to your ISY with the node name of the scene.

1) ISY can't read your mind. You have to have some condition that exists in ISY to have it affect actions. IF that means installing a weight sensor under your couch cushion, then I guess you need to do that. 2) Again, ISY can't read your mind. If the condition exists in ISY, then you can set programs and/or folders to respond to those conditions.

I'm not positive I understand question 1. I guess you are asking about disabling the program if you are already in bed. You obviously need some indication in ISY that you are in bed. Pretty much, that means you need to do something that indicates you are in bed. Like a door sensor on your bedroom door? A KPL button by your bedside? I don't know what, but that just add the status of that device to the program. Question 2. Again, not positive I get your exact situation. But I have programs that trigger on an elk zone opening, turn a light on, wait, then turn it off (all in the "then"). But I add to the "if" if control is not switched on and ( other conditions ) Then light on wait light off Else . . . Using the "control not switched on" allows me to abort the timer by hitting the on switch before the thing times out and shuts down the light. You can also add a folder and put the above program in that folder. In the condition of the folder, put things light the status of a light being on as a disabling thing

No. Insteon devices must be connected to line voltage or the device itself won't power on properly. The dimming part is different, but still, a triac designed for 120vac won't dim properly with 12vac and not at all with dc current.

But this requires 5.x firmware. You can also do If $state variable = 1 Then set fan on wait 30 min set $state variable =0 Else set fan off wait 30 min set $state variable = 1 You need to add other parameters to this program to control how it starts and stops.

See the edit from my first post switching over to status.

Yes, sorry, should have included that. In fact, no matter what you put in the "if" section, you need to terminate the fan using the else to have a shut off command. Whenever the "if" section turns false, the "then" stops running, but that doesn't mean it turns the fan off. It only means it stops turning the fan on and off every 30 minutes and if the fan happened to be "on" at that time, it will just stay on.

You'll need to note that "repeat while" is only in 5.x firmware. Plain repeat is what you'll need to use. Your needs sound simple. 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 Please note: repeat every 30 minutes is used since, for some logic issue in ISY, the 30 minute wait within the repeat doesn't count toward the 30 minute repeat. EDIT: Not sure what you mean by "turn night fan on" command or "turn night fan off" command. You might use If KPL button status is on Then . . . Using Status of the KPL, then you can turn the button on or off via Alexa, or mobile linc, or direct press of the button and this program will run while it is on.

Before uninstalling the device, did you try a factory reset on it? Pull the tab just below the paddle. Typically you need to use a butter knife or similar. It can be tough to pull it out all the way to the point that it stays out. Anyway, after puling it out all the way and letting it sit for 5 seconds or so (you know you got it out if the led shuts off), push the tab back in all the way and hold it in until the device beeps. At this point it should have factory reset. Now do a "restore device" from ISY. I cut the female end off an extension cord and installed alligator clips on the free wires which I use to test switchlincs and other hard wired devices without having to wire it in. Just a word of caution, those alligator clips will give you a shock if you touch them while it is plugged in. I used alligators with plastic covering, but still, pay attention to what you touch. The plastic coverings are colored so you can use red (or black)/white for ease in recognition of hot/neutral. And you do not want to clip "hot". The arcing that may occur can damage the electronics. Clip it up first, be certain that the wires are stabalized and not touching anything they shouldn't (blue tape them down to your work table), then plug in.

You can do both. Personally, I have gone with ISY 100% because my programs are too complicated for the built-in programming and subject to frequent change which is a PITA when you have to go to lots of thermostats in person. I now have 9 thermostats covering 2 buildings at my church running both the sanctuary and the office/activities building. We have lots of exceptions to the rules so using the built-in programming doesn't make much sense. Plus we have several hvac units conditioning the same room and using ISY I am able to stage the units to create a "variable speed" hvac system that runs more efficiently and is better at pulling humidity out. I have algorithms that handle multiple thermostats so I can change how multiple thermostats behave by simply changing one time on one ISY program. But you can always create a base program that lives on the thermostat itself and then use ISY to over-ride that. Since ISY can set the "mode" on the thermostat to use its own program or it can set the mode to auto/cool/heat/off directly and set the temp directly. If ISY takes it off of "program", then you would need ISY to put it back on "program" when it is done with its over-ride. I see two advantages. If you develop a comm issue, the thermostats will still run the built-in program, or if you have an ISY crash it will do the same. I have never had an ISY crash . . . ever, though I have had PLM crash . . .which is effectively the same thing of course. Of course if you develop your comm issue after taking the thermostat off of program and before putting it back to program, then you would still need to manually go around and set them back to program. My ISY programs leave the mode on "auto" at all times and shift the temps as needed.

A float switch that is installed inside a pvc tube that you run all the way down to the bottom of the tank and have drilled some holes in it to let water in and out. Since the water level doesn't get above the salt, with a tube such as this, it won't matter, it will be "protected" from the salt and only contain water when water is present. I would design as follows. 1 inch pvc tube a float made of some material that fits inside of the pvc tube a pole or rod that you can attach to that float which is a bit shorter than the pvc tube/float como a magnet that can be attached to the top end of the pole above caps for both ends of the pvc. Reed style open/close switch as used for alarm systems. Assemble the float/rod/magnet. Drill holes along the side of the pvc to allow water in/out but not hunks of salt. Put the float/rod/magnet assembly inside of pvc, float side at the end with the holes Cap the ends Attach reed switch to outside of end of pvc with magnet Shove the hole assembly into the tank so that it sits below the level of water when the tank is making new brine. Attach magnetic reed switch to io link. Now, when water is in brine tank, it enters holes in pvc and floats the float/magnet/rod assembly to the top of the pvc where the reed switch detects the magnet and closes the circuit. Attach

You can still do this, but need to separate the dates from times.

There are two recent threads about this, one started by me and the other I forget who, but I participated in it. Basics 1) Thermostats are RF only, so you must have either good RF range to the PLM (assuming dual band PLM), or other dual band devices to get the RF onto the power lines 2) The "cooling", "idle", and "heating" are "control" commands. They have no status. It is like a "fast-on". You can not query the condition after the fact, while to all logical thinking, cooling and heating are states, as far as Insteon com is concerned, they are not states, they are one-off events that occur only when the change from idle to cooling/heating or vice-versa occurs. Finally, you seem to be having an issue with comm to your target device, as well as your thermostat. In short, as you have suspected, you need to improve your comm. dual band devices (especially PLM) and best if you can locate your PLM so that the rf from the thermostats and other devices in question can go direct without the power lines in play at all.

I edited my previous post with a more complete logging of the events for debugging.

When it is actually on, and you press off, it should do nothing (run the blank else), so you are saying that it is running true and setting the variable to 2, when it should be nothing? This would be akin to me pushing off when the light is on, and having it go off then back up to 25%. My lights do not do this but extremely rarely, and back when I first created these programs, I tracked it and found that the only time I saw the problem is if ISY had the status wrong as being "off" when it was not. If indeed you can demonstrate that for certain ISY had the status wrong, please report to Michel. I tracked it by a program similar to this. If status device x is off or status device x is not off Then send notification device is %status (use variable sub in the custom notify section to put in the status of the device) To complete the tracking If control device x is switched off Then send notification device x switched off If control device x is switched on The send notification device x is switched off If status $s.AL.FRO.Mon is 2 or $s.AL.FRO.Mon is not 2 Then send notification $s.AL.FRO.Mon = variable sub With that series of programs you can track the events. Like I said, the program you wrote is supposed to work per Michel and ISY logic, if it is not, then it is a bug. You might add a system time stamp to the notifications as well just in case the emails pass through the email server out of order.

What firmware are you running? I can tell you that a few versions of firmware did not have it right, I don't remember which ones, but I'm currently using 5.0.10 and this runs it correctly. I use this program type every day many times per day and it works. I have not installed every single firmware so I can't say for sure all the firmware that do not run it correctly, only that the vast majority that I have installed on my isy do it correctly. The other thing is of course if you did a fast off instead of a regular off.

I mean there is no race situation. There were a few firmware versions where there was a bug in ISY code that made this program not work. But neither 4.5.4 nor 5.0.10 have that bug, nor do must others. Over the years as I have updated my firmware and have had these programs, there has been two times that I installed ISY updates that broke this logic. Each time it was corrected with the next update after I pointed it out to Michel. You can't check ISY status after it inappropriately runs and say that "status is correct". At this point it will be correct, otherwise the program wouldn't have run at all (the program only runs when it receives a comm from the device and thus . . .got the comm and will show the correct status). This is a mistake in status from an earlier button press turning it on which ISY would have not received that causes the false running. If the device is actually in a not-off (on) state, and ISY thinks it is off, and you press the off paddle, the program will run inappropriately as true, setting your variable to 2. This is the behavior you describe and is the behavior I, once in a blue moon, have seen in my system and when I put tracking programs on the status of the switch found that this only happens when ISY has the incorrect notion that the switch was off when it was not prior to pushing the off paddle.

This is not correct. If status off and control off Then do something Is logic that ISY handles just fine. It will be true when the device status is off at the time of the off press and it will be false in any other state. The reason your program is not working is almost certainly a comm issue. ISY probably has the device status wrong at the time of the button press. In other words, ISY has the device as being off when in fact it is not. I probably have this same program written on 25 or more devices in my house. I use it as a "night lite" feature. If I am wandering about the bathroom or bedroom area at night, I can press the off paddle on any light and it turns on to 25%. Below is one example of many and they only rarely mess up and when wrong, it is a comm issue. Bath Night Lt. Can - [ID 0076][Parent 0083] If 'Master Bedroom / Master-Bath Cans L' Status is Off And 'Master Bedroom / Master-Bath Cans L' is switched Off Then Set 'Master Bedroom / Master-Bath Cans L' On 25% Else - No Actions - (To add one, press 'Action')

I have my garage doors wired to the Elk. It is of course a never-failed comm. If you have the ability to hard wire back to the Elk panel, then I would definitely do it. Myself, I didn't think to hard wire for control of the door (only status of the door), so I hacked an RF garage door opener and wired it directly to an Elk relay. This works great for me since my Elk panel is easily within radio range. I have never had a missed command in 8 years. Much better than using Insteon comm.

That is just shy of 1 year ago. The question is . . . when did they make the fixes that supposedly take care of the power supply issue?

I see you can do variable substitution with google assistant in ifttt. Trouble is, rest requires 0-255 as the range, not 0-100. I don't see any way to rescale that. Maybe instead you have it do a rest command to a state variable in isy which triggers a program that resclaes it then (using 5.x firmware) sets light to that percentage. But that just seems like a lot of complexity.

OK, just created my first IFTTT for my google home. It is better. A lot more options. Unless Alexa has updated since I created those around Christmas time.

I'm sure what you meant to say is that "I'm sure I'll get less immature with age"