apostolakisl

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

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.