apostolakisl

@diggler I have had this before where it was a mysterious extra link on the device. Try checking the links tables on the devices in question and compare against what ISY says the links should be. If they are different, factory reset the device and restore it from ISY. Michel's action will find if you accidentally have the device listed in a program or scene you didn't realize it was in, what I suggested will find if there are some stray links on the device. If neither of these proves productive, then completely delete the device from ISY, factory reset it, and start over with that device.

dark outside is just a sunset to sunrise program . . . in other words . . .its true when its dark outside. Just drop that line if you don't want it.

Scenes are controlled and respond depending on what is controlling it and what is responding. 1) The "base" scene in ISY is what happens when ISY turns the scene on/off. In this case, ISY (actually the plm) is the controller. Each device in the scene is set according to what you desire when ISY is controlling the scene. This group of settings looks a little different in the menu tree, but it in the background it is the same. The plm is just one more device in the scene and as a controller, you need to define how all of the other devices respond to it. 2) For each additional device in the scene that is set as a "controller", each and every other device must be set as to how you want it to respond. For example, If a scene has 4 controlling devices and 10 total devices (not including isy/plm), then you will need to set what happens to each of the 10 devices when each of the 4 controllers is activated, plus a 5th group of settings for when ISY controls it. That means 46 settings (10 for ISY as controller, and 9 each for the other 4). Unfortunately, a feature was removed from ISY firmwares that allowed you to propogate the base scene settings through to all other controllers with a single click. This feature was removed because, as I understand, there are conflicts on settings because of the ability to mix and match various types of devices in scenes. 3)Finally, each device has its local setting. In other words, what does that device do when you push a button on that device. This is what I set in the above program. If a switch is the lone for a light, then this is the only thing that needs to be set. This setting exists for every device regardless of whether it has any scene associations. When you have a scene open in the main admin console, and you click on any of the controlling devices (those in red), you will see then that this device lists its setting as "Default". In other words, it will "respond to itself" as per the setting you created for the individual switch (it local setting). Note: If a scene has been configured to be a 3-way/4-way where multiple switches are all configured to control a single load, then technically the only device that needs its responding level adjusted is the one switch wired to the load. However, if you want the little column of led's on the other switches to properly correspond to the light level, then you need to set all of them. This is all a bit complex because Insteon/ISY offers so many ways to customize your devices and groups of devices.

I think you are doing something wrong, or perhaps the firmware version you are on or maybe the type or age of the switch? I just tested this and it successfully changes the "on level" but does not change the state. If the light was off, it stayed off, if it was at some random brightness, it stayed at that brightness. My testing switch is a dual band switchlinc v45 and ISY is 5.0.16 Below is the program. I ran the "then" clause at a variety of On Level's while the switch was already at various levels. Every time, the on level changed without changing the current status of the switch. New Program - [ID 017E][Parent 0093] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Set 'Foyer / Foyer-Niche L' On Level 45% Else - No Actions - (To add one, press 'Action')

@bretta I'm not sure what exactly your use is. But in my home, I have switches set up as "night lights". This is all controlled by programs and allows one to push the off paddle when the light is already off to turn the light on very dim. I set it to only work at night, but that is optional. Lauren bath nt lt - [ID 0070][Parent 0075] If 'Lauren Bedroom / Lauren Bath-Mirror L' Status is Off And 'Lauren Bedroom / Lauren Bath-Mirror L' is switched Off And Program 'Dark Outside' is True Then Set 'Lauren Bedroom / Lauren Bath-Mirror L' On 25% Else - No Actions - (To add one, press 'Action')

1) Create variables for whatever you want. Like month, year, week, etc. 2) Create a program that runs at midnight 3) In the then section, specify that each of your variables gets set from the corresponding system value (you have to click the little black triangle to switch between different menus of items for your variables)

Yes, well that is what I would be doing. The office and house are on a router-router vpn tunnel so it would be connected through that tunnel with the latency that comes with that. I don't know if the PLM would be sensitive to that.

Well that looks nice. I guess then I could buy one of these new PLM's and then use my current plm and my spare plm to be the location linking devices. My current plm is struggling a little with the 1000 links.

I'd be very curious to see if this works with PLM's. If indeed it does, and there aren't latency issues that screw with things or whatever, then you could set up Insteon networks all over the world that run on a single ISY. I suppose you are referring to a device such as this? https://www.newegg.com/p/36X-0002-00013?item=9SIAF5H6JW1891&source=region&nm_mc=knc-googlemkp-pc&cm_mmc=knc-googlemkp-pc-_-pla-louis's+marketplace-_-network+-+device+server-_-9SIAF5H6JW1891&gclid=CjwKCAiA5o3vBRBUEiwA9PVzapmj5QEFnUjKAr93zXwFu8n-SR63yEADUEv2xc3vpyG71dMEbz8johoC_1YQAvD_BwE&gclsrc=aw.ds Personally, I wouldn't mind throwing in a few Insteon devices at my office and having my home ISY control them. Found this: https://www.usriot.com/download/M4/Transparent-transmission-between-USRIOT-Serial to Ethernet-products.pdf Looks like it should work.

If building 2 is grounded, then you can not have any copper data connections between the two buildings. But that is not so much of an issue since it appears the plan is to use fiber anyway. Even though it is on the same electric service, you would need to consider it as being on a separate service from the standpoint of low voltage connections. That would hold true for any audio wires, antenna wires, alarm system wires, and so on.

If building 2 is a sub panel of building 1, then you don't have to worry so much about surge/lightening issues. Assuming your electrician did it right, then there will NOT be a ground on building 2 and building 2 panel will not bond ground to neutral. All the conductors in building 2 will be grounded at building 1 maintaining the two buildings at the same potential. So no "extension cord" needed at all, the whole building is basically on one as is. Have you tested Insteon comm from building 1 to 2 as is? 500 feet is pushing your luck, but it is certainly possible especially if you don't have any signal suckers. And it may be that the conduit connecting power is shorter since your low voltage path took some detours that perhaps were not taken by the electricians. Connecting RS232 would need to be done via a dedicated fiber-rs232 device. RS232 will not travel on copper more than maybe 50 feet at the absolute most. I suspect that the devices I linked to on ebay would be a very viable option and keep the flaky risk to a minimum. I don't know of any tricks to repeat z-wave over that distance. I can only think that you would need to have multiple z-wave repeaters every 100 feet or so? If going 100% Insteon is an option, I would definitely start out by playing around with getting the power line comm to work over the sub-panel connection as it is. And then there is just buying a second ISY. If you want the two properties synchronized, then two ISY's is less than ideal. The thing about two ISY's vs getting the two buildings on the same system is that two ISY's will continue to be a thorn in your side for every change you might want to make in the future vs getting both buildings on the same ISY is only an issue up front.

This thread has instructions on linking two PLM's via the RS232

@Tango OPTION 1: I have done this, but only for Insteon. I made what amounts to a 150 foot extension cord and put an Insteon hub on the end of it. It is plugged into building 1 and extends over to building two. This does not connect the electrical systems of the two buildings. It simply puts an Insteon radio at the end of a very long extension cord. The cord carries nothing but a few milliamps to power the hub's circuits. I fused the cord with an inline fuse at 200 ma to prevent someone from trying to actually plug something into it of substance. This works perfectly at repeating Insteon. Once the radio from the hub encounters its first Insteon device in building 2, it then is injected into the power line of that building as well. The max length of this I do not know, perhaps a couple hundred feet? Maybe if you did something crazy like use shielded coax cable instead of electric wire you could get super long runs without the PLC degrading. Of course this would totally be non-code to put 120v on a coax wire. If you chose to go there, I would definitely fuse it at the least amount of ma needed to keep the repeater running. Why a hub and not a repeater? I initially had a dual band lamplinc on the end of it and it was inconsistent. I happened to have a hub that came as a package deal with a bunch of other stuff I actually wanted which in the end made the hub less than free, so I had it and thought to try it. Turns out the hub is much better at repeating the PLC signal. It works perfectly. It is very important that you do not in any way connect building 1 and 2 electrically. No conductor from building 1 can touch any conductor in building 2. OPTION 2: I have read on this forum that someone demonstrated linking two PLM's with an RS232 "crossover" wire plugged between each device's port. Of course a copper wire between the two devices is not going to take an rs232 signal very far. But they make rs232/fiber adapters. So you could perhaps run this even a few miles. This is all theory, I have never done it. The fiber converters aren't cheap either. EDIT: maybe this? https://www.ebay.com/itm/Siemens-Fiber-optic-RS232-interface-used-538-750/131635878117?epid=1401848480&hash=item1ea61c18e5:g:Ui4AAOSwYHxWKmEV In summary, it is much nicer to have the two buildings on the same ISY. Makes programming and control much easier. You have to decide if it is more trouble to get the buildings on the same ISY than it is to synchronize two isy's.

The program I quoted above would do absolutely nothing if the temp updated in 30 seconds. I think you need to take a closer look at what is happening.

I don't know what worked, but this: If 'ZW 125.8 Multilevel Sensor' Temperature > 10.0°C Then Repeat Every 2 minutes Wait 40 seconds $Int_4_ensuite_shwtemp_slow = 'ZW 125.8 Multilevel Sensor' Temperature °C Else - No Actions - (To add one, press 'Action') won't work. Temperature change is a trigger. So every time the temp changes by (I assume .5 is the increment), the program will cancel out and start over. Your repeats and waits will not execute in any predictable fashion.

This will never shut the fan off unless the temp is both above 25 and steady for 15 minutes. If it drops below 25, it will trigger false, and assuming it didn't first sit at 26 for 15 minute straight, the fan would not turn off. It also would turn the fan off if say you took a 16 minute shower where the pipe temp hit its max and stayed constant for 15 minutes. That would also be counter to your desires since you would want the fan to keep running.

This won't work. Every time temp changes your first program will re-trigger and the wait/repeats will reset. The program I wrote is how to do that. If you want it posted to a variable then use the then/else clause to set a variable. But there should be no need for that as you can reference program state the same as variable state.

1) PGM 1 (this is a modification to your first program you already have) If 'ZW 125.8 Multilevel Sensor temp' > 0 Then $State_old = $State_1 $State_1 = 'ZW 125.8 Multilevel Sensor' Temperature °C run 'if' PGM Temp Up vs Down Else - No Actions - (To add one, press 'Action') 2) PGM Temp Up vs Down (set this program as disabled) IF $State_old < $State_1 Then blank Else blank The above program 1 is a tweak to your program you already have. Program 2 will be "true" if temp is going up, false if it is going down. Also, you should add the below program in case you start the shower and don't let it get to full temp IF status fan on Then wait 30 minutes (or whatever) set fan off stop program 'fan on off' EDIT: Also, if you don't like having to drop below 25 to reset things, just change it. You can make it higher, just remember you will also need to make the "click on" temp a couple degrees higher than the reset temp. Like maybe the fan clicks on at 35 and the reset happens at 33.

Do it the way I did it the first time. No need for variables. The "repeat while" only works with variables. Just copy my first set of programs. But FYI, the reason your variable never updates is because "responding" is not a trigger. That program will never run. Also, the "repeat" repeats what is under it, not above it. And finally, you have a "enable fan on/off" line in your program that should be a "run then". If you want to keep your current programs you need to 1) Fix the "enable .. . " to "run then. . ." 2) Change the "if" clause of your first program from " . .. responding..." to if 'ZW 125.8 Multilevel Sensor' is >0 Then $State_1 = 'ZW 125.8 Multilevel Sensor' Temperature °C The above program will trigger every single time the temp changes

You are basically catching temp going up or down by testing for one temp, disabling, then testing for a higher or lower temp with a different program. It is crude, but for this application it is sufficient. ISY doesn't do calculus. Larryllix makes a point about some features of v5. Though the specific example isn't what you wanted since it only runs then fan after the pipe hits 48. I'd have to think about it for a while to see if turning the fan on at 25 and keeping it on until it hits 48 then drops to 45 can be done in fewer steps using v5. Maybe using a couple of "repeat while" consecutively. Below is an idea, I haven't really fully thought it through. 1) pgm 1 if -blank then set fan on repeat while temp < 48 wait 1 second repeat while temp > 45 wait 1 second repeat 1 time set fan off repeat while temp >25 wait 1 second repeat 1 time enable pgm 2 2) pgm 2 If temp >25 Then run then pgm 1 disable pgm 2 Not sure the above is simpler, but it is fewer programs.

You have to have your shut down program become active after the temp exceeds 45. In fact, you would want some hysteresis in there. Something like over 47. You would also need to disable the program that turns the fan on at 25. pgm 1) If temp above 25 then turn fan on disable pgm 1 pgm 2) If temp above 48 then enable pgm 3 pgm 3) If temp below 45 then turn fan off disable pgm 3 pgm 4) If temp below 23 then enable pgm 1 pgm 5) (added in to fix things if your temp goes above 25 but never makes it up to the other temps, like you turn the shower on then the phone rings?) If status fan on Then wait 30 minutes (or whatever) turn fan off EDIT: Though this set of programs won't work right if you don't let the shower get all the way up to temp.

So you'll need to consider the status of the tree. If the tree changes status during the 5 minutes that will also kill the program. The best way to manage that is to use a second program that is disabled. The first program runs the "if" on the second, disabled program. This program checks the status of the tree and contains your "then" stuff above. A disabled program only runs when called, it never runs on a self trigger. So in other words, the only thing that can kill the 5 minute wait is something in the "if" of the first program. Alternatively, you could have a program that shuts the light off if the tree turns on. This might be more to your objective of not having both the tree and light on at the same time since it will shut the light off immediately, not waiting for the 5 minute timer.

Because the front door "status" open is probably closing before the 5 minutes, which resets the program since all status items trigger on any change. "control" items trigger strictly on the designated action and no other. I have no idea what is monitoring your front door, but if it has a "control" option use it. If not, you'll need two programs.

But did you watch the variables change on the variable page? This will tell you if the program is passing through all the steps and what values it is giving you at each step. The 1, 2, 3 lets you know the full program ran. If the temp number never changes, then there is a good chance the "number" contains non-numeric info.

1) Try putting a wait 5 seconds as the first line of "then" (before everything else) 2) Increase other waits to 2 seconds 3) Add a testing variable at each step and just have it count 1, 2, 3 ie $test = 1 after the wait 5 seconds, then $test = 2 after the second wait, etc. 3) Right click on program in tree and hit "run then" 4) Go to variables page in less than 5 seconds, watch the variable change values and see where it goes astray. The only thing I can think of is that you have another program modifying the value midstream or stopping this program. The 1, 2, 3 will assure you that it kept moving through each step, and then the values of TempC will show you what math is happening.