apostolakisl

I don't see where it would do any harm to test it. It is a simple matter of writing one program. Using ISY to respond with lighting commands off of DSC nodelink will not cause any harm to your DSC's ability to be an alarm system. My experience with delays via programs is that when the program trigger is internal to ISY or from a network trigger (ie DSC nodelink), there is a negligible increase delay as compared to a direct insteon link. Where I see delays is when an Insteon device triggers ISY program which triggers another Insteon device. Furthermore, when it comes to motion sensors, the delay I see is primarily the difference between actual motion and reported motion. The system powered DSC devices may be faster than a battery powered Insteon device.

There could be something else that is set to a static IP address that is the same as the DHCP address given to ISY. You could try changing the router's address assignment for ISY to something else.

Well I don't know. I would move the second ISY back to the main property and connect to the same switch as your computer to rule out any issues with the fiber converters or remote switch. If it still doesn't work, I would leave the ISY-B connected right there until you get things working before moving it to the barn. Probably the next step would be factory reset the ISY.

What is your ISY's IP address and what is your computer's IP address? Are they on the same subnet? In other words, are the first 3 sets of numbers in the address the same?

I suppose it could be the SD card, but I would think that you would get error messages, not just missing functions. The fact that scenes work does not mean anything. Scenes are all Insteon device to Insteon device. ISY is only involved if it is the root cause of the scene turning on/off. I am thinking it is more likely you are not getting your notifications because the PLM is going bad. I'm assuming your notifications are in response to something that happened to an Insteon device. The PLM is the gateway between Insteon and ISY. Bad PLM means ISY loses touch with Insteon devices. The PLM is a VERY common failure point. The ISY is a VERY rare failure point. The SD card is only slightly more common failure point. As the saying goes, when you hear hoofs, think horse, not zebra (unless you are in the Savanna).

As oberkc stated "correct" Any scene you create using ISY is written to the devices. A 3-way is a scene. It is a scene regardless if ISY writes the scene to the devices or if the devices write it themselves in response to all those complex paddle pushes required when doing it from the switches themselves. ISY is an intermediary between 3rd party devices and Insteon devices, not between ISY devices. The exception to that is if you are using programs to control Insteon devices. Programs of course can be used to do all sorts of things that direct Insteon to Insteon links can't do. But whenever possible, you should use scenes (direct links) as they work essentially instantly and take the least amount of resources. The only difference between a 3-way (or any scene design) created manually vs created by ISY is that the PLM is a member of the scene. But just like any other device in a scene, none of them are intermediary's. No device in a scene requires any of the other devices. So if you remove the PLM, the other devices still work the same. Just like if you have a 4-way scene, you can remove one of the switches and the other ones will still work the same.

He seems to be confused on the word "direct". You really should be using the word "manual" linking. The two switches will have the exact same linking (to each other) regardless of whether you use ISY to set up the links or do it manually at the switches. BUT, if you have an ISY, you will just be screwing things up to not use the ISY to do the links. ISY will not only link the switches to each other, but it will link them to the PLM and include the linking topography in the ISY database. Without the links included on the PLM and in the ISY database, then ISY will be out of the loop. You won't be able to see or control the lights from ISY. So that sort of defeats the whole idea of ISY. It is also just a big PITA to do it manually, especially if you want to tweak ramp rates, on levels, and stuff. And finally, if they aren't in ISY and you need to replace them or factory reset them, then you don't get to just click "restore" on ISY and be done with it.

Just remember that the fridge will need to be replaced at some point and you want to have a space that is not so custom that it becomes insanely complex to replace.

I don't know exactly what you have, but I would not build in anything like this. The low-priced coolers with the condensors built-in to the walls of the unit must have the walls free and clear of any obstruction. Units that can be built-in have condensors that are fan cooled either above or below the cabinet. The temperature of the condensing coils directly affect the unit efficiency and (directly related) load on the compressor. Higher temp = higher pressure = more power draw = more wear and tear on the compressor. The temp of the coils when the compressor is not running isn't of much relevance. I suppose if you are only sort-of building it in and leaving and inch or so of space, then running a nice fan with a proper circulating pattern that brings in fresh air and exhausts the old air away from the inlet air would work. But that doesn't give you a built-in finished look. Maybe you could install some attractive louvers on the sides and make it look good. This all gets to be more work than just earning the money it takes to buy a real built-in.

I just got everything and hooked it up. It isn't working, at least not so far. I have one unit at my office and one at home connected via vpn. The two units see each other. When I hook up in a crossover fashion, no data is delivered. When I hook it up non-crossover, lots of data flows between the two units, but I can't get any Insteon control. The data quantity transmitted seems to correlate with Insteon activity. Ideas? Not sure why wiring in crossover mode isn't working. I haven't tried both ways of doing it "straight". I'll give that a try next time I'm at the office. settings below. The rx/tx number go up into the 10's of thousands quickly when wire the other way.

That program should do as you expect, so there is something else going on. I suppose you could delete and recreate them. You could also add some indicators both before and after the wait, like have it send you an email or chirp some switches to track what is happening when. BUT more importantly, the 10 minute extra run time is not a good idea. It is not helping and may even slightly be hurting your reliability. If running the fan after the compressor turned off was a good thing, then it would already do that. You will notice that even the most expensive, high-end, fancy appliances/AC/anything with a compressor, does not run the fans on the condensor unit after the compressor shuts off. At best, it is a waste of electricity. At worse, it is damaging things by introducing additional metal fatigue. Temperature changes are bad, they introduce stress, particularly at joints. Rapid temperature changes are worse. So once the compressor shuts off, ideally you would hold the condensing section at a constant temp until it turns on again. Your extra fan time is causing it to cool faster. Now the fan while it is running is a fine idea, though it may not be cost effective. That just depends on if the additional life it gets out of your system isn't nullified by the extra cost of electricity. But it will keep it from getting as hot which means less temperature change and also the compressor will run at lower pressures if the condensor is cooler. In summary, I would tell you to have the fan shut off simultaneous to the compressor.

Exactly where I am. I just looked up if the ubiquiti usg even has upnp and discovered it does, but it would seem you can only enable it via a command line entry. As far as I can tell, they don't have it in the gui, I assume because they consider it something you shouldn't do. It would seem, from a few searches, that upnp conversations often center around peer-to-peer gamers. Something I don't do.

I don't have UPnP on my router and everything finds everything. Either way, worse case scenario is that you have to enter the ip address of ISY into the ISY finder instead of it just finding it.

UPnP has nothing to do with one device accessing any other device inside your own LAN, ISY included. If you want to access ISY from outside your LAN, subscribe to Universal Device's portal. It is cheap, secure, and includes connectivity for Google Home, Amazon Alexa, and IFTTT (webhooks). In comparison, UPnP opens inbound connections from the internet, the portal on the other hand opens an outbound connection. This is totally different and at the very top of secure ways to do things. The only way you can be hacked on an outbound connection is if the thing you connect to is compromised. Like going to an evil website or one that has been hacked.

Harmony has the 40 ISY IR codes pre-installed. In other words, the harmony IR blaster will send the 40 IR codes to ISY. If you want to more completely integrate ISY and Harmony, you need to install polyglot and the harmony node server on ISY.

@oberkc is correct. Global Cache device emits IR, it does not receive IR (except in learning mode). The ISY itself receives IR commands, if you have that model. I have an IR transmitter from my older harmony that "shines" at the ISY and the ISY then responds to it. ISY has 40 built in IR codes it recognizes and the harmony database includes them. The new harmony hub can be directly integrated with ISY using plolyglot/harmony nodeserver. The hub is fully integrated, the remote and ISY are fully synchronized. This is over IP, not IR. So if the remote does something, ISY knows, if ISY does something the remote knows. Both are always in the same state. In other words, if you have ISY activate your "watch a dvd" state, the remote also will be in that state, so you can then pick up the remote and it is set to control your dvd player.

Anyone running nodelink on Polisy?

As long as an echo delay of 30ms or so doesn't screw with it, I'm thinking I'll be good.

Didn't even think to look at the cable they provide to see the connections. Well obviously only rs232 is used since those are the only conductors in the cable. Cool. Should work. I also read that the PLM echos each byte back to the host. Hopefully this echo and any ensuing latency as a result of the internet component doesn't cause timing issues.

Just was looking at SH docs about the pinout on the PLM. It appears that it has a TTL connection as well as RS232. The gizmo I have coming only is for RS232. Not sure that this is going to work. Anyone know anything more about this? The RJ45 has pin 1 and 8 as RS232 while 3 and 6 are TTL.

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