apostolakisl

This program is incorrect. 1) The "then" clause of program 2 can't work. Logically speaking, you can not have mutually exclusive commands sent to the same device simultaneously. Even if you could send them, what result could you expect? It would be like you're a soldier and you have four commanding officers yelling at you opposite commands all at exactly the same time. What is one to do? If you separated the commands with "waits", this would allow the the then clause to run . . EXCEPT 2) Program 1 would kill a properly written program 2 (where each then item is separated with a "wait".) The status change in the device would re-trigger program 1 which would re-start program 2 then clause when the light goes from off to on. The purpose of two programs is so that program 2 can command program 1 to disable while it is running. So a program 2 that does not disable program 1 is no different than a single program that puts the "if" and "then" stuff into the same program. Assuming the purpose of the program was to flash a light it would need to be written as follows. Program 1 If status light x is on Then run then program 2 Program2 If blank Then disable program 1 set light x off wait y seconds set light x on wait y seconds set light x off wait y seconds set light x on enable program 1 In short, there is nothing wrong with ISY logic here, the original program is an attempt to execute an illogical programming sequence.

I don't know that whay you say is true. I do know that you can't write a "then" clause with mutually exclusive commands unless you separte them with a wait. A light can't be set to on and off simultanously (twice each no less). In all likelihood, you would see the same behavior each time a "race" program such as above is run. However, it wouldn't surprise me that if you ran multiple programs simultaneously that the processor might treat one of these "race" situations differently and give a different outcome. Regardless, the above program or any like it serves no purpose, so I'm not sure why it was ever written in the first place.

The issue is you have conflicting actions. All items in a "then" clause that are not separated by a wait or repeat theoretically happen simulatneously. So your program is causing some logic issues in ISY being that it is trying to exectue different actions on the same device simultaneously. In addition, a "then" clause should not be considered to run from top to bottom. Experimentally, I have deteremined that it typically does by doing some math functions where order of oprations affects the results, but like I said, not always.

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).