apostolakisl

I ordered the stuff. One piece is coming from China (Amazon), so it will be a little while.

I noticed that they have brought back ballast dimmers. I just bought one. This is more or less a professional item. Hopefully they continue adding back in a lot of the more eclectic stuff that pros would want.

The question I have . .. what does it actually cost them to make a switch? If it is $5, then putting them on sale for $20 is doing just fine. If it is $18, then they are in trouble. The pricing strategy is perhaps a bit like airlines. If you need a ticket that has to be right when you need it, you pay out the nose. But if you can wait, then you get good deals. So, perhaps, SH figures they will get the folks who are flexible to over buy on the sales, and get the "I'll buy only what I need exactly when I need it" people to pay out the nose.

I use Agave. It doesn't support cameras. At this point, it also isn't supporting nodes from Polyglot. The maker of Agave keeps talking like he is going to do a big over-haul, but nothing has happened in about a year. Starting to get disappointed about my $100 purchase. Trouble with viewing IP cameras outside of your LAN is that you either have to 1) Open ports - security risk 2) Use VPN - works great, but you have to know what you are doing and have a VPN router. 3) Use a portal. But portals are tough because IP cameras are very data intensive and the portal would have a large load to deal with. I guess some camera manufacturers are doing that now. But also, you are letting the portal people have access to all of your cameras. The nice thing with Blue Iris is you can view all your cameras remotely through their browser based viewer. You can control them, watch them live, and view recorded footage. But even then, you need to open a port or do vpn I would trust a port to Blue Iris a lot more than some Chinese camera however. But I don't open ports anyway, I use a vpn connection. I, perhaps obviously, recommend doing it my way. VPN router, VPN client on my phone/remote pc, Blue Iris. It is the most secure and does not rely on any 3rd party. Everyone could go out of business and I could keep on functioning just the same.

The portal is needed if he is going to use network resources instead of doing polyglot. I'm not sure they even sell the network resource module separately anymore. Plus, the portal has so many other valuable uses. And I'm glad to see that there is a foscam node server. My mistake in not knowing it existed. Just so long as it keeps getting updated with the new camera API's. Trouble with controlling cameras, is there are so so so many of them. If you look at the drop down lists in Blue Iris, there are like thousands of them. Unless you are making money doing this, it would be impossible to keep track of all the API's. But I would still suggest spending the $50 on Blue Iris (or less I think for a camera limited version). It is a very complete program. Only issue is it requires 24/7 pc. EDIT: Just to be clear, using network resources would be a bit more complex and you won't get any feedback from the camera. Network resources lets you send network commands, but it doesn't allow for responses. Also, you can only trigger a network resource from a program. The camera won't show up as a device like it does in the screen shot above (when using polyglot/nodeserver).

I'm gathering you don't have polyglot setup? You need to get a RPi, install polyglot on it, then you can download any number of node servers from the menu in polyglot. There is a whole section of the forum dedicated to polyglot. Network resources comes with subscribing to UDI's portal. You will want to get the portal if you intend on accessing your ISY from outside of your LAN. It allows access without opening ports. It also allows you to configure your ISY with Alexa, Google Home/Nest, and IFTTT

Control, for most devices means someone physically pushed the button. It is what a device sends out when it is the originator of the event. For a motion detector or any other sort of sensor, the device is the originator of the command upon it sensing whatever it senses (instead of a person pressing it). I assume you are using an I/O sensor on your garage. When the input closes, it sends out a closed command (off I guess). Unlike many other devices, an I/O sensor can not send out multiples of the same command in a row, because, by its nature, a closed input can't close again until it first opens. But a light switch could have the "on" paddle pushed bunches of times in a row and would output a "Command on" each time. In contrast, a "status" is what the device status is. Any CHANGE in status results in the device reporting and triggering your program. Your assumption above about the program running constantly is incorrect. The program would only run at the instant of CHANGE. It would execute once and stop until another CHANGE occurred. Unlike command, pressing "on" twice in a row does not produce two status commands since the switch wouldn't CHANGE from on when it was already on. A status command is output regardless of what the origination was. It does not need to be someone pressing the button (though it could). A light switch changes status when a different switch commands it to as well as when you directly push it. With an I/O sensor it is a little different since command and status are tied together by the nature of the device. Now, I can't explain why you would get double texts on closing. This would mean the program triggered false twice in a row. I can't see how that could happen. In input can't become off without becoming on first. You could try using "status" here. In this case, status changing is going to coincide with the command on/off event. I don't have any I/O sensor's myself to play with to help more. I have my Elk alarm panel synch'd up with ISY and use those states to trigger ISY.

A node server would work, but hasn't been written. Anyone brave enough to write that node server would be getting a barrage of requests for supporting more and more camera models so I'm not sure it will happen. There are two things that would work. 1) Use network resources to do the various things with your camera. Foscam publishes their API so you can look up all the commands and create a network resource for each command you want. 2) Purchase Blue Iris software, install on a 24/7 pc, and configure it to your cameras. Blue Iris supports pretty much every camera ever made. Then install the node server for Blue Iris. That node server only knows one set of commands, the ones that tell Blue Iris what to do. Blue Iris then translates and repeats the command to the cameras. Blue Iris can be configured to monitor the cameras and report various camera states such as motion. The node server publishes these things to ISY so ISY can act upon motion. This works very well.

I have just ignored it. Yes, it is mildly annoying that it tells you it didn't work, but since I can see that it did work, I don't worry a whole lot about it.

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.