apostolakisl

I have had the same experience with some commands. The command works as intended, but google says it didn't. Usually the world works the other way.?

Presumably for the reason listed above . . . it would pop out of the bracket backwards when pushed on. A gang box cover like I described would effectively make the gang box flush and flat with the surrounding wall and solve that issue. A standard single gang box "blank" run through your handy table saw to trim the edges back to the same dimensions as the gang box itself would cost about 50 cents and take about 1 minute to cut . . . provided you have a table saw ready to go. Then it would slip inside the sheetrock edges and, provided the gang box is at least a little deeper than the sheetrock, be flush, with the possible addition of some washers in the event that the gang box were mounted very deeply. I don't see any reason why this wouldn't also pass code. It is a code compliant plastic gang box cover that you are using.

How about cut a piece of flat plastic to the dimensions of the front of the gang box and screw it down using the two screw holes in the gang box top and bottom. That would give you the back stop.

OK, so I don't have any of the RemoteLinc2's. But just looking at the product, I see the optional wall mount bracket. Seems like you should be able to use that to screw the remotelinc and a decora switchplate cover into a single entity, then use some hot glue around the edge of the switchplate and glue it to the lip of sheetrock around the single gang box. Hot glue holds quite well, but not so well that you can't pull it off if you need.

@RandyJS No doubt a dying PLM will lose all its links and can sometimes be temporarily brought back to life by a restore PLM, I have had those exact experiences. But that didn't affect anything in ISY itself. All the devices, scenes, programs, etc were still there, they just would fail to actually control any Insteon devices since the PLM wouldn't send out the signal. So I think something is different here. Perhaps the SD card in his ISY is failing? I don't recall anyone on this forum posting anything quite like this before. If it happens again, I would think about a new SD card.

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