apostolakisl

I don't get it. Why do you want the lights to turn on from motion sensors of someone walking into the room. Do you live alone? If someone is in the theater watching a movie, and someone else walks in, triggering the outside sensor then the inside sensor, the lights will turn on full bright. That would be something the person already watching a movie won't like.

blank "if" + "run at startup" = "then" clause execution at startup. I'm not sure I agree with larrylix on the point about the "if" not working when populated. I suppose it depends on what is in the "if" clause. Certainly things like date and times will work correctly. I would not count on things like device status being there at startup. It usually takes ISY a good 15 to 30 seconds to populate all of that stuff at boot. However, I believe a device "status" clause will trigger itself as soon as it populates. I could be wrong, you might want to try it out.

Yes, I see that, thanks for pointing it out. Still, would rather not have to do the multi click, drop down, thing. The most useful default would be to have it work that way direct from the main activity menu and have the "all activity' be something you need the drop down for.

I don't have any motion sensors in my movie theater. I use the light switch conveniently located at the doorway to turn the lights on when I walk into the room. From there, the lights are controlled by harmony remote. Though most other learning remotes would work, just that the harmony is easy to configure since it has a node server for ISY. Anyway, I have programmed various situations within the harmony to either dim the lights are raise the lights as I desire for whatever state I have put the theater into (using the remote of course). With a more generic remote, you would need to have the ISY within ir range and use the ir output from the remote to tell ISY what to do to the lights. This would require that ISY is in ir range of the movie theater. Otherwise, you might buy one of the wireless ir repeaters I see on ebay. I have no idea how well they work, but the description fits the job at hand. Now, if you wanted to use a motion sensor, then you would need to trigger an ISY program to write the links to the light switch when you want it linked to the MS, then another program to unwrite the links when you don't. There are not difficult programs to write. Again, you would probably use your remote control to tell ISY when to run which program. The key in both cases is getting the info to ISY so that ISY can configure things on the fly for the current situation in the theater. That is either ISY directly controlling the light, or ISY linking/unlinking the light from the MS.

@Michel Kohanim Totally different, but related to the forum display. Way back before the new forum software, when you clicked on "activity" you got a listing of all the latest posts, but it did not duplicate the same thread if multiple posts were made. Now, it shows every post. Trouble is if there is one thing that is super active, you get tons of what basically are repeats and it pushes other topics so far down the list that you tend to miss them. In short, I thought it was a lot better when any one thread would only appear once on the "activity" listing.

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.