apostolakisl

only runs on windows. I also see it is up to $65 now. I have version 4, not sure what I would gain going with v5. I used to be $20 I think for 1 camera and $50 for the full package. EDIT: Looks like you buy a license on ebay for $50. Still haven't seen any compelling reason to stop using my v4.

2 basic options 1) buy a polisy from UD. Polisy will have polyglot installed already. Polisy has a lot of horsepower and is rumored to be the future of ISY (ie, it will replace your ISY). But it costs a lot more and this new version of ISY that theoretically runs on it is ambiguously in the future. 2) buy a raspberry pi and watch the videos located on the polyglot section of this forum. This is much cheaper but will require a bit of your time. Theoretically about 15 minutes if you knew what you were doing, but you don't, so expect a couple hours. But once you have polyglot running, you will likely find several of the node servers to be useful.

I have an IP camera that is monitored by blue iris software. Blue iris will email you (or do email to text) of snapshots upon various triggers you designate. In my case, I programmed blue iris to look for an object that starts in one location and moves to a second location. The end result is I get notified every time someone approaches my house (but not when exiting). Since ISY links to blue iris (via node server) I also have other events happen upon that same trigger. The blue iris/isy connection is two way, so since you already have your doorbell linked to isy, you could have isy trigger blue iris to send the image. Or, you could have blue iris send the image based on various motion attributes and get notified when someone like the amazon guy drops off a package but doesn't ring the bell. Or when a thief comes to pick up that amazon package. So, if you wanted to use blue iris 1) pay $50 for blue iris 2) have an always on pc 3) have polyglot running with the blue iris node server. Hopefully you already have 2 and 3. If you don't have 3, then why the heck not. The node servers are awesome.

It was not that. It is the protocol, not the frequency. https://globalcache.zendesk.com/hc/en-us/articles/360029674152-Integrating-iTach-WiFi-units-with-Ubiquiti-APs

I don't know about the wifi versions they currently sell, but the one I bought several years ago uses some form of wifi that is problematic. I totally forget the details, but my Ubiquiti stuff would not connect to it unless I "downgraded" my wifi security protocols. It was a lot of hoops to jump through and I decided that it would be better to keep my wifi running on a more secure protocol and switch to the ethernet version of the GC. I have found that the ethernet version just plain works better too. I have very close to 100% success rate now and when I was on wifi it was definitely less. Mind you, the GC was only 10 feet from my wifi, so it was not a signal strength issue.

Never checked my antenna sockets either. Actually didn't even install the antennas until my wife started complaining about the fact that they were sitting on the counter. I also found that my polisy was giving me an up-time initially that was a number that was far larger than correct. At some point after reboots or firmware updates or something or another, it became correct.

Your program should only be true at the moment of switching off one of those two devices, while simultaneously being within the time range. Times alone can not make that program true. If the program is firing true without an off press of the paddle, then something is either not presenting correctly in the forum or something is wrong in ISY. However unlikely, a simple step I would take is to delete the program and write it again. If something translated over wrong when you upgraded firmware, then deleting and re-writing should fix it. Aside from incorrectly firing true at the "from" time, does it still operate correctly when you press the "off" paddle at the various times? EDIT: Just to clarify, I said "should only BE true . . ." This isn't really correct. I should have said "should only TRIGGER true" The program status will list as "true" when sitting idle between the two times and after either of the switches "off" paddle was pressed. Despite being "true" it will only execute the "then" clause at the moment of pressing the "off" paddle.

Using an ipod as your remote I don't see any reason to use any nodeserver since none support any ipod AV app I've seen (if one exists, then excuse my ignorance). REST interface is it assuming the ipod app allows for that. If his receiver has a node, then that would be something to consider, but the ipod presumably is already linked to it and I don't see any use for ISY being able to monitor the receiver. The remote is the conductor of this orchestra. ISY would just be there to relay lighting commands to the switch. In fact, you could skip the Insteon light switch and get one that responds to ir and avoid setting up REST commands if the ipod doesn't do them.

has anyone else tried this? I tried it and it did not work. I used a brand new PLM and an old one that I had recapped that for whatever reason had a dead radio. I isolated the one with a dead radio behind a UPS and made a short 3 foot "crossover" cable. I tried doing just the RS232 contacts, just the TTL contacts, and one with both TTL and RS232. Either way, I got no communication to the PLM behind the UPS. The PLM does communicate when not power line isolated behind the UPS. I doubt it, but perhaps the older PLM is the issue? But that PLM does communicate with ISY via the serial cable and it does communicate with other Insteon devices using the power line comm.

If you have a receiver on the list of receivers with node servers, then you can do it. You would need to upgrade to the latest ISY firmware and either get a polisy or rpi to install polyglot on. If your receiver is not listed on polyglot, then it would be a ton of work and/or not really even be possible. Still, your receiver doesn't know what content is on the screen and if it is paused or playing. The remote does. This is what a smart remote does, it puts everything into the proper state with a single press. Not a fan of things like ipads to control your AV system since they aren't dedicated and tend to have the wrong app up, needs to be plugged in to charge, no hard buttons (have to look at it rather than just feel the buttons), and is expensive. Harmony Hub is a lot cheaper than an ipad and is perfectly matched to the task at hand. However, sticking with your ipad is probably very doable and perhaps easier to configure since it requires only the use of REST commands. I assume that your ipad AV program has the ability to send REST commands. So that is all you would need to do. Set it up to send REST commands for light bright/dim/off in concert with the hitting buttons for play, pause, off, or whatever you like. This requires no programs or changes to ISY at all, no polyglot, no nodeservers, etc. For example, a simple command like http://user:password@isy.ip.address/rest/nodes/1A.23.3B/cmd/DON/25 sets the light at node 1A.23.3B to 10% brightness. (x/255=brightness where x is the number you put at the end of the command) https://wiki.universal-devices.com/index.php?title=ISY_Developers:API:REST_Interface.

I still don't get the reason to ever use motion sensor to light a movie theater. Someone gets up to go to the bathroom or get a soda, the lights come on? Movie theater lighting is typically automated to what is playing on the screen, not to the movements of the people, just like at the local movie theater. And/or you put a button on the remote to manually dim/brighten the lights. Movie theater lights are not supposed to be off when the movie is running either. They are supposed to be very dim. Just like at the real movie theater. That is so you can get up and go to the bathroom even during a dark scene without bothering everyone else. It is also more comfortable on the eyes to have a slight amount of ambient light. And commonly movie rooms are for watching sports. People are constantly in and out during sports events with half times and commercial breaks. I automated my lights to go dim whenever a movie/broadcast event is playing. If I hit pause or stop, the lights go back to full. Or if I hit the button that directly controls the lights I can go bright, dim, or off. I just can't imagine a role for motion detection that wouldn't do the wrong thing more often than not.

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.