apostolakisl

It is common for a single business to split itself into separate companies on an official basis. This serves a lot of purposes. Things like taxes, international sales, venture capital, book-keeping, etc. For example, in my work, I own the building in which my business resides. I have these as two separate companies. One is a real estate company, the other is my business.

Hopefully you didn't read that in this forum without someone correcting it. What you can't do is the following: If at 5am and device is switched on The above will never have a true state. Both conditions are "momentary event" truths. Two momentary events can't happen at exactly the same time (at least I don't think ISY allows that, but even if it did, it would be astronomically unlikely).

PROGRAM EXPLAINED: If from sunset to sunrise (next day) and status of iolinc is "on" Then turn light on Else blank The above is correct terminology and will work short of a comm issue as I think was expected. The only error in the original program is the "same day" when it should have been "next day" Explained: From Sunrise to Sunset - - - 1) this statement is true when tested at any time between sunrise and sunset. Otherwise false 2) this statement is a TRIGGER at sunrise (false) and sunset (true) And Status of iolinc is on - - - 1) This statement is true, when tested any time the device is on. Otherwise false 2) This statement is a TRIGGER when it changes from on to off (false) or off to on (true) The program as written above will trigger with every change in iolinc status and with every change in sun status (above or below horizon). Example: 1) Door is already open, sunset occurs - - -light turns on 2) Sunset has already happened (and not yet sunrise), door is opened- -- light turns on 3) The "else" clause is empty, so nothing happens when the iolinc turns off, or the sunrises. You certainly can use a variable for sunrise to sunset status (dark/light), or just reference true/false status of a program that says that, but the result is the same.

If you are the least bit interested in playing around, I don't think you'll find any issues with 5.0.10. The only problem I have with it is that programmatic device query triggers status programs (regardless of whether the status changed as a result of the query). Also, if you have the weather module, you'l need to ask Michel for the 5.0.10E version. I'm pretty sure any bug of significance is contained within the new features that shouldn't impact your current function.

Theoretically you could put a noise filter on every dual band device and fix that. Theoretically. In my experience, this hasn't been an issue. I had 16 Insteon icon devices from many years back that I just replaced with dual band devices two weeks ago. That swap out seems to have completely fixed all com issues. While com was good for me before hand, I still regularly had isy warn me of some missed comm on a daily basis (even if it didn't actually fail). Since replacing those devices, my ISY has not shown any erros of com and I have not noticed any failed commands in usage. At this point I have 38 2476D/S's and 36 2477D/S's plus a handful of other insteon devices mixed about 50/50 dual/single band. In short, my 80 device or so network is about 50/50 and that seems to do the trick. I have 2 filter lincs, one of which is for sure needed, the other I just put on cause I had it.

The beauty of ISY is: YOU DON'T HAVE TO CHOOSE! You can mix and match. Heck, with 5.x and node module, the clever ones will be able to integrate anything with a network interface. As it is already, io_guy has already put together a package of like 20 brands that can plug right into ISY and thus work directly with each other, Insteon, and zwave.

I don't use Insteon for life/safety/security/damage prevention. I say Insteon is for convenience items ONLY. Things where failure is measured in inconvenience, not dollars, not life or limb.

My take is as follows: 1) The current Insteon devices are for the most part fully supported as is and thus whatever I currently own will be fine. 2) Other than PLM's and my very old original switchlincs that all had the failed tact switch, I have only had 2 insteon devices fail. Many of my devices are the ones that got RMA'd back when I switched out the tact switch ones. So they are getting old 3) Having put in a number of dual band switches and such, my comm is damn near perfect. 4) I like the look and feel of Insteon switches So, I'm sticking with the Insteon ones. But the option to go z-wave is always there. EDIT: And more relevant, adding z-wave in no way requires removal of the Insteon. I can implement as much or little as I want. I currently have 1 z-wave device as a "proof of concept". But I don't really like the look and feel of it.

The one thing you might want to test just to be certain is that Unpopulated -> on is indeed a trigger for a status program. If it is not, then you could have the situation where your ISY reboots and the field is left unpopulated. Then, prior to a heartbeat populating the field, you have a leak. Now the leak sensor reports "wet". At this point you would certainly want the program to trigger and run. My recommendation would be to use "if control" logic. This will avoid any issues for certain since the current status is irrelevent when an "if control" program receives the wet message from the sensor.

I'm pretty sure it doesn't matter in most all cases. It isn't possible to test without rebooting my ISY which I don't fee like doing, but . . . 1) IF control programs will trigger regardless of what if anything is listed in the current status at the time of the "control" being sent. So there will be no impact at all on those. 2) IF Status programs I think will still trigger when it goes from unpopulated to anything. This is worth testing. You might get an unexpected run of an else clause on a program such as If status is on Then whatever Else somethingelse In the above example, the else clause might run going from unpopulated to off. Since you expect the else to run with a change in status from on to off, not unpopulated to off.

Good to hear. I'm not sure how the hub is doing this either, but it is best to not have multiple controllers. I use agave and it works nicely. The developer is fairly active at making it better as well.

I believe leak sensors are a once per day status reporting device.

yes, heartbeat. A query won't do it and for at least a while they will be unpopulated after an isy reboot.

The "issue" with no status is not really an issue. Here is the deal. Battery devices would burn through their battery very quickly if they were normal Insteon devices listening and responding to all the time to all the other devices in your house (including isy/plm). Battery devices only participate in Insteon commands when they choose. The choice is written into the firmware on the device and is designed to allow for proper operation and long battery. For the most part, they are transmit only devices. They will transmit a heartbeat at a time of their choosing, and they will transmit whenever their purpose is met (ie when a water detector gets wet or a motion detector senses motion). ISY does not store device status through a power cycele (which makes sense since the status could easily change while the ISY is off). When ISY comes back online, it queries all devices for their current status. However, battery devices are not listening for that query so they do not respond. The battery devices must be "woken up" either by you manually doing it or by the designed trigger (getting wet). Having ISY show status unknown on the device should not impact your program.

Hmmmmmm. Well I am at a loss. I was hoping it would only happen when you rebooted the relay. Another idea would be two swap the two relays and see if the problem follows the relay or stays with the application.

I don't know for sure, not owning one of these, but current sensors ingeneral use induction to detect current and it is certainly possible that if a sufficient amount of current is induced within the current sensor induction coil, then it can use that as its own power source. Basically it is a transformer.

OK, it's becase your 2476D is quite old. When you change the settings, you have to reboot the switch for the changes to take affect. And by reboot, I don't mean turn the switch on/off, I mean pull the tab or shut the circuit breaker off. The newer 2476D's and all the dual band ones don't require a reboot.

Sorry, you are correct. You do have to create a dummy scene and put the device in it as a controller. Or, if the device is already in another scene as a controller, you don't need to do that. In 4.x firmware, I believe when you do "adjust scene" you will see not only scenes in the drop down, but individual devices listed as well. You select the individual device as the "scene" (yes, I know it is not a scene), and then again a second time you select the device. It really is a very bazarre thing to program and it is different in 5.x so make a scene, lets call it "dummy scene" and put "my light switch" in it as a controller. Then in your programming do the following. In scene 'my light switch' adjust 'my light switch' on level to 25%

The fact that deleting the device from ISY and re-adding fixes the problem leads me to believe there is some issue with the relay itself, maybe the links are corrupted after a power cycle. There isn't any reason that removing then re-adding the device would change the behavior of a program. To test this 1) reboot ISY and not the relay 2) power cycle the relay and not ISY 3) power cycle both at the same time, but not the whole house Which if any of these 3 things reproduces the result. And I agree that it is a good idea to put ISY on a UPS (not the PLM). I have mine set this way.

If you reboot ISY only (power cycle it) but don't power cycle the whole house, does it still do it?

A leak sensor that didn't get wet shouldn't need to be reset. I would very much doubt that leak sensors respond to the scene "on" command so it would presumably still be off. If any device in a scene sends an "off", then the whole scene shuts off. My guess is that a leak sensor that is in a scene simply does not respond to that "off" command since they must be reset locally. A leak sensor would really only work properly if it could only be a controller. There is no logical reason for a leak sensor to respond to anything but locally getting wet. Having a leak sensor respond to an on/off remotely is like saying the leak sensor can control its wetness, makes no sense. Assuming standard Insteon logic, any leak sensor in the scene that sends an "off" would turn the scene "off" and thus turn the pump back on. Now, my question would be, if you reset a leak sensor that was never tripped, does it send an "off" or does it just do nothing? If it sends an "off" no matter what, the scene would turn off even if another leak sensor were still wet. Unless, of course, a wet leak sensor keeps periodically sending "on" commands even if it isn't reset (which would be how I would make it work).

A device pressed locally always responds according to the local on level. You have to change that. There is no need for a scene here at all. A scene with one device serves no purpose (except with kpl buttons, but that is different).

Whaaaaat? I don't know if there is something special about leak sensors, but scenes can have as many controllers as you want, anywhere from zero to every device in the scene. The converse is not true, a device can only control one scene, but there is no need for two scenes here. I don't see any need for and/or logic. It is a simple premise, if any leak sensor triggers (sends an "on") the scene turns on. From your description of "resetting" a leak sensor, I'm assuming that leak sensors only send an "off" when manually reset (which is probably a good thing). Run at startup would not be the issue. Once startup is complete, changing the status of the relay would not trigger the program. Frankly, I don't see how this program is triggering since it should only trigger on a change in status of one of the leak sensors. Do you have a program not listed here that calls this program? ie does a "run if", or "run then".

I don't have any leak sensors, but I looked at the manual and it appears that thy can be linked directly to other insteon devices just like usual. So why use a program? Just create a scene with the relay and the leak sensors and put the leak sensors as controllers. It looks like you have the normally open version of the relay, so you need to set the scene "on level" for the relay as "off" (yes that seems weird, but it works) This basically means any time the leak sensor is triggered either from wet to dry or dry to wet, the pump shuts off. This means that once a leak sensor has gotten wet, you would need to fix the leak, dry it off, and then manually turn the relay on. It would not turn back on automatically . .. which is a good thing in my mind. Power failures would have no impact on this setup. Except I suppose if you had a leak start during the power failure, then power came back on, it would not turn the pump off since the pump relay would be unpowered during the power outage and not get the signal from the leak detector. But what are the chances of that? I suppose you could set up a program that when isy reboots it shuts the pump off to be extra careful. EDIT: Just noticed you have the NC relay (it was in the title ). I made my NO assumption based on the fact that your program tells the relay to turn "on", which would open the connection and turn off the pump. Could that be your issue?

Why don't you make a nodelink for it? I know you can do it. The PITA with CAI is just that it has no wifi so you have to pull ethernet to it or use a pricey wifi adapter. I assume it runs some version of linux? Which I'm thinking means you can write the node software right on it rather than having an intermediary.