apostolakisl

This is a bedroom ceiling fan being used for comfort in hot months, lets not confuse the subject. No bedroom ceiling fan I have ever seen does anything but move the air in the bedroom around in circles, within the bedroom. There is one reason and one reason only that a bedroom ceiling fan such as that would be a comfort item and that is because it causes windchill and aids in evaporative cooling of skin. While I suppose it could help dry out a sweaty bed, I have my doubts that a bed would be so full of sweat that in 16 hours it wouldn't dry out by itself. Maybe if you lived in a swamp with no AC. And all I have to say about that is ewwww. The fact is, the fan is going to burn about 100 watts. 100% of those 100 watts is going to end up as heat. If no one is in the room, then there is no one to feel the wind chill and the room has what amounts to a 100 watt space heater running.

It would be an odd home that running a bedroom ceiling fan would cause air to circulate beyond the room itself in any meaningful quantity. . . to say, move cooler air from a different room into that room. But even so, why would you want to move cooler air from the part of the house you are in, to a room you are not in. Considering that you have then moved the warm from the room you are not in, to the room you are in. And again, made all of the house hotter on average. If indeed your ceiling fan does draw cooler air from other parts of the house into your bedroom, then it would only be logical to run the ceiling starting shortly before you plan on going to bed (assuming you are mostly only in the room to be in bed).

I guess physics is different where you live.

Aside from any program issues, your physics is wrong. Ceiling fans do not cool rooms, they heat rooms. The electricity running the motor makes heat. Ceiling fans are for the purpose of creating wind chill. Wind chill only works on warm objects located in cooler environments (ie human bodies), not empty bedrooms. The fan moves the warm envelop of air that surrounds your 98 degree body away from your body so that your skin is in contact with cooler air (assuming the actual temp is less than 98). In addition, the air around your body is more humid from evaporating perspiration, and the fan moves that humid air away exposing your skin to drier air allowing for more evaporative cooling. So I would scrap the whole program, you don't want the fan running unless someone is in the room. Either turn the fan on manually when you enter the room and off when you leave, or use an occupancy detector.

If you answer the questions I posted, your current situation would be more clear.

Restore PLM does go out and write changes to all your devices. I just did it a month or two ago on 5.0.15 with a new plm. When you did the restore plm, did it go through and write to all of your devices? You would have seen the little green 01010 next to all of your devices and then it would have gone through and, one by one, said "writing" in green, then it would have gone back to normal. And if indeed it did that and cleared all the green boxes next to your devices, then all the layers are working. Your ISY to PLM and PLM to devices has to working to write a change to a device. Also, you don't have to have the correct PLM on your ISY to directly control devices from ISY. So even if the links got written wrong (or not at all), you can click on a device in the left hand tree and control it. If you can't then either the new plm is bad or there is some sort of comm issue. You only need the PLM/devices to have the correct links for ISY to see the device changing status. The deal is, your PLM has a one-on-one scene with each and every device in your house, so when you change the status of the device, the PLM (and by extension ISY) also is part of that change, just like when you link two light switches, when you change the one, the other changes. Also note: If ISY does not have a PLM connected, it will tell you and go into safe mode. So if you are not getting that warning, then ISY sees the PLM, Furthermore, the PLM has a working serial port and you have a working serial wire between it and ISY.

Elk relays all have a no and nc connection. So you use one side for open and the other to close. At least that is how it works for the elk branded wsv which ihave. And I set elk to turn h2o off 45 minutes after armed away. So the valve gets regular usage and the water is off almost always while not home. Also check the elk specs for amp draw allowed. You probably can power all of your stuff on the main panel.

I have GRI 2500 devices at home. I just bought a bunch of 2600 for the office. The 2500 are a straight-up 2-wire zone connection. They are NO circuits and thus alarm on closing the circuit (opposite of most alarming zones, but Elk allows for that). The down side to 2500 devices is that they are not supervised. If a wire or device fails, there is a good chance that the zone will stay in an open state, and thus you won't know about it without testing. The upside is that it is a simple 2-wire connection. The 2600 units require 4 wires, two for power and two for the security loop and exist in a NC state. So, like any other NC security zone, you can supervise them with EOL resistor. The downside of course is that you need to run 4 wires and have a 12v power supply available (Elk has ample power built-in for most any residential install). They function similarly to a 4-wire smoke detector. With supervision, there are very few situations where a failure in the system doesn't either show a trouble or alarm condition on the panel.

Yes, you have to have the xep. Arm/Disarm from ISY program, no. But you can arm/disarm from ISY console without the Elk module. You could indirectly arm/disarm by having ISY change the status of an INsteon device to something specified in an Elk rule, triggering the Elk rule to arm/disarm. Elk can send you notifications of being armed/disarmed via email, email to text, or a phone call. This is all Elk . . . ISY not involved. Elk rules work very very reliably (If I really need something to happen for sure, I don't use ISY, I used Elk rule even with the Elk module). As far as limitations, I don't know, I mean they are different languages and each has its up and downs. I have my leak detectors hard wired to Elk. And yes, my Elk speakers announce a water emergency, call central station, and shuts the water off. I consider the water thing a security system thing, not home automation, and it resides entirely on Elk. My ISY has no role at all in the water thing. EDIT: Just to put this in context, I had my ISY and my Elk for several years prior to the module being a thing. So I did jump through a number of hoops to get the two working together. EDIT2: And it has actually worked as advertised. I did have a leak behind a dishwasher that was running water into the subfloor under my hardwood floor that the Elk picked up. Without it, my first signs of an issue would have been my kitchen floor popping.

While I can't speak specifically to an Insteon water detector, Elk rules can respond to the status of (most, many, all???) Insteon devices natively(light switches for sure, I've done it) without the ISY Elk module. If you export your Insteon config from ISY and import to Elk, the devices will all be there ready to use in either the "Whenever" section or the "Then" section. From there, you can hardwire the water valve to the Elk, or you can use an Insteon i/o link to control the valve. Again, not 100% sure if Elk can talk to Insteon devices natively that aren't standard light switches. Again, none of this requires the Elk module. When you import the Insteon network into Elk, the Elk will use the ISY as a passthrough device relaying the lighting commands to the PLM. Go to the 27 minute mark in this video. https://www.elkproducts.com/m1-integration-partners/insteon Though I still think the $99 is worth it for the module.

If you have an Elk and an ISY, I highly suggest spending the $99 and getting the Elk module for ISY. It is very complete and allows you to streamline all of your programming into ISY instead of using Elk rules. Elk rules are not the greatest, especially when it comes to organizing and editing after the fact. However, if you choose not to do that, and you intend on using both Insteon and Elk connected water sensors, then you will need to use Elk rules to do everything. Elk has built-in ability to control Insteon devices and you can export your Insteon configuration into Elk https://www.elkproducts.com/m1-integration-partners/insteon Once that configuration is in Elk, you can use Elk rules to manage both Insteon connected devices/sensors and Elk connected devices/sensors. I haven't so much as looked at that stuff for about a decade now since the ISY/Elk module was released.

why don't you screen shot us the Elk XEP configuration page on your RP2 and the Elk Configuration page on your ISY. (black out your Elk code). I have a feeling something is just not set correctly.

I have the latest firmware and mine is working fine. In fact it has never not worked on any firmware version since I got the Elk module when it first came out years ago. And I have installed most of the firmware alpha/betas along the way. Every time I didn't have connectivity I soon realized it was because I forget to disconnect from Elk RP.

that isn't going to fix it. A router assigned static address is no different than a device set static ip address (except that a router assigned address prevents you from screwing up and setting multiple devices to the same ip). They both result in the device being at that ip all the time. And this is only an issue after reboots when you might get a new ip address depending on your routers reserved ip time for dhcp and how long your device was offline. I assume you have confirmed your isy and elk are both on the same subnet. ie, they both have the same first 3 sets of numbers (like 192.168.1.x) If both your Elk and ISY are getting dhcp assigned ip from the same router, and you don't have a fancy router with vlan's configured, then they will be. And the other big thing, you CAN NOT BE LOGGED INTO ELK RP2!! When the Elk panel is logged into by ElkRP2, it will not connect to anything else.

when your elk and isy are on the same lan, you use the non-secure port. Go into Elk m1xep setup under TCP/IP settings (in Elk RP2) page and enable the nonsecure port (2101). Then set the ISY to use port 2101 and also input the code you use to arm your system.

You probably didn't have it do a "run then" on the second program. The two program solution will work. Though you have another problem in that if you turn the light off while you are at home and between the hours of 11pm and sunrise, the program will turn the light back on again. In the end, simply removing the "status . . off" line is a very good and simple solution. The only reason it would not be to your liking is if the light were already on for some reason and you wanted it to stay on, it would shut off 5 minutes after geo-fence turns to 1. Like. . . . maybe. . . . your wife is having cocktails on the driveway with the light on (on purpose), you drive up, the light stays on, but 5 minutes later it shuts off. Your wife curses at your GD HA setup and you get no action.

I don't see much point in having automation of home thermostats, especially in homes with families. The lag time between changing a thermostat and the temp changing is just too long to be useful. If you live alone, and have a sizable commute, it would be reasonable to use automation with geo-fencing to, for example, trigger your system when you leave work. But with a family that is in and out of the house all day long, it is pointless. I have found it very helpful at my church. Again, this is a location that spends good chunks of time empty and everything doesn't happen on a regular schedule. So it is very helpful to be able to quickly (and remotely) change the schedule and be able to manually trigger things from afar when a usage that wasn't on the schedule comes up. I also have different algorithms that are triggered depending on the type of use and I have staged the system based on outside temp, inside temp, and humidity. For example, if you turn on the system and conditions are mild, only 2 units will come on. If conditions are nasty, 5 units come on. If 2 units trigger, but after 30 minutes things aren't coming around, my algorithm adds more units.

https://www.techhive.com/article/3327501/how-to-use-alexa-routines.html

Funny, I didn't know about Alexa routines. I'll have to look into that. Google routines are set from the "Google Home" app. From the home screen in google home app (the names they picked lend to confusion), just click the "routines" button, then "manage routines" at the bottom. You can have a routine do other things besides control devices, like tell you the days weather or your expected commute time.

Have you tried making "routines" instead. They don't require special words like "turn off" or "lights". They just follow the words you set. I very much like google home for that, especially when controlling things that aren't getting "turned on" nor are "lights". Also, I always have a google home in my pocket (my android phone of course).

@Scottmichaelj The lag has, in my testing, been at least one minute and no more than 2. I am not sure, but this looks like it runs on the pc, not in the cloud. So if the pc isn't on or logged off of gmail, I don't think it works, still have to confirm this. The one thing that it definitely does do that is not exactly kosher, is that if you are logged into two gmail accounts on the same pc, it will forward emails as texts regardless of which account the email came in on. For example, I logged into both my wife and my account on gmail on the same pc at the same time. I set the forwarding rule for both of our accounts. I sent an email to me, and it forwarded to both me and my wife via text. And vice-versa. Hard to complain for free. It looks like I'll need to keep two pc's running with gmail open for me and my wife.

You should consider getting away from opening all those ports for your cameras and whatnot. DDNS is nice, especially if your ISP changes up your IP, and it easier to remember than some random set of numbers. However, using DDNS or just your plain ip address to connect to your home requires opening ports. The more devices you have open to the internet via open ports, the more avenues of attack you open. If one of those devices has a security flaw, then someone could potentially crack open your whole network. This has happened with some popular IP cams in the past. The portal eliminates opening ports by maintaining a tunnel between your ISY and UD's server. This tunnel is initiated from your ISY, so there is no open port. When you want to access your ISY, you go to UD's server and open another tunnel between you and them (you log in via https). The session is then linked between your home and you through UD's server, all secure tunnels, no open ports. Alternatively, you can get a vpn router for your home and make a single connection to your router which then opens you whole network to you, again, with no open ports aside from the VPN port which the router manages (UDP 500 is the only open port detected from outside my network using Ubiquiti USG). This is going to be the only way to view your IP cameras without opening ports for all of them. Nobody does portals for video feeds, presumably because of the high bandwidth. I suppose you could live stream to youtube, which in essence is a video portal of sorts. But I don't think youtube just lets you live stream forever, but I could be wrong.

I have been using ISY to send email to text using the standard carrier texting. ie @vtext.com for verizon. But I use a google voice number, and you can't do that with google voice. I found a work-around. There is a plug in for gmail called CloudHQ. Cloud HQ automates the process of using your gmail to send texts, and it works for a google voice number. You don't need to know what carrier the person has, you just put in their phone number and CloudHQ does the rest. As far as I know there is no limit. CloudHQ has a feature to automatically forward any email to your phone as a text. So I set it up to forward all emails that come from my ISY to my Google Voice number. So far so good. You just set the rule for forwarding. I use my gmail smtp server for ISY sending, so I input the gmail address as for the "from" field, and in the subject field I put "ISY". So now, any text from my gmail address that includes the letters "ISY" in the subject get forwarded to my GV number as a text.

The portal, at least last I checked is like $12/year. So it is hard to not buy that considering how nicely it gives you access to your ISY without opening any ports. Alternatively, should you want to keep ports closed but have remote access and not use the portal, you can set up a vpn router. I have done both. The portal has many other advantages as well, particularly the integration with amazon alexa and google home. Ubiquiti sells a really nice router (usg) that makes vpn a snap for $129 (b and h).

I'm having the same problem. And it is doing screwing things, like I give the command for one light to turn on and it turns on a different one. I tried unlinking and relinking and it still has the issue. I can give some commands and it says "it looks like universal devices is unavailable right now". And I give a different command and it works, or maybe it works but turns the wrong thing on.