apostolakisl

Looks like the driver is built into the fixture, so that rules out hiding the driver somewhere you can't hear it. Doing Teken's test sounds like a good place to start. Obviously, if that fails then you know you have a fixture problem, not a dimmer problem (or both). Also, don't buy a house with 30 feet ceilings helps.

Possibilities 1) LED power supply is defective (have you tried calling them?) 2) Swtich to 2477S (instead of 2477D dimmer) 3) Locate the led power supply remotely where you can't hear the hum

My bet is you already have a wall wart that works, assuming that like me you don't throw them out. 12v power supplies that put out 1 amp or more are pretty common. Even if you have one that is running something else, you could temporarily use it for you ISY. Of course any voltage within the spec range will work, but 12v wall warts are all over the place.

?

OK then. Yes, something like 1213 would not be obvious.

Sorry, my bad, had it swapped. 1015 would be 15th week of 2010. I answered by memory and should have actually looked at it. It is typically pretty obvious since you generally know roughly how old the unit is. You get into trouble when something was made in the 12-15 week of the year where year and week are no longer obvious. But if you look at multiple devices, certainly one of them will make it obvious.

I stand corrected, the program does flash the light, though not necessarily every time both flashes. 1) It works the same with status and control as would be expected under the "atomic" nature of ISY and the lack of any wait or repeat. 2) The program summary page indicates that the program ran in less than 1 second and indeed ends prior to the light flashing even the first time. This is consistent with the atomic nature of ISY "then clause" and no waits written into the program. ISY must hold the Insteon commands in a separate que. I don't know what the que limit would be. I also don't know if the failure of 2 flashes every time is because of out of order commands or failure of the rapid fire Insteon commands. Again, ISY does not gaurantee that commands in a then/else are executed in the order written in the absence of a wait. This is per LeeG from ages ago and then confirmed by me running some math equations where order of operations affected the answer. Usually it ended up top to bottom, but not always. 3) Making it into two programs does not serve any purpose, though it doesn't prevent it from working (I ran it as one program).

There was no reason to make this two programs. But, by "works", I don't know what you mean. The KPL light does what?

Yes, there is a 4 digit code on a white label. example: 1015 means tenth week of 2015 And you should consider getting a new PLM or look at the instructions on how to repair your PLM (on this forum). I bet it crashes again within a week or two.

At one point in time, the atom was thought to be the smallest piece of matter with no further possibility of division, and hence it was named from the Greek word for indivisible (atomos). The word "atom" conjures thoughts of protons, neutrons, and electrons. But in programming, we are looking at the root meaning, not the common meaning. Hence, an atomic clause is a clause that runs as an indivisible unit. Another great example is the word "plastic". Again from the Greek (plastikos), it means "moldable". The word now conjures thoughts of hydrocarbon derived hunks of stuff that surround us in so many products, but that is not its root meaning. A common misconception is that plastic surgery somehow involves hunks of plastic when in fact it is surgery that "molds" the shape of tissues. No pieces of "plastic" involved.

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.