io_guy

if you have a program or app that is to take actions based to current events, you don't want it reacting events that happened hours previous or days previous. A simple example might be an action that happens WHEN a door is opened , as opposed to IF a door opened I don't see the issue here. On connection, your program's code should just ignore the first value change, since it's current status. I have a ton of programs that do this. You could also pull original values via REST and compare. There's 100 ways to skin this cat.

Don, Can set_alarm be used on all cameras or just MJPEG? What about 264 (both previous and new in-house firmware)?

I use two IOLincs for my garage and an EZIO8SA. All working great.

I felt the same way however things have changed a little. When the original repraps came out they were pretty much printed plastic and meccano. Nowdays, to get bigger print areas and higher accuracy, they are extruded aluminum, steel, wood, etc. The amount of printing is quite a bit less. My original reprap was "ok". But when I started using our commercial unit at work I couldn't go back. The newer home-user models (with much less plastic) provide much improved accuracy (and the heated bed helps a lot too). Don't believe the hype on .1mm@.012mm. This is simply the resolution of your stepper - the accuracy of a home extruder will not get you near that range for any consistent period, especially without a heated enclosure.

The Printrbot is also a good option for a home unit. I've built several of the original style and the new "simple" looks great (and cheap). I would recommend making sure the unit you choose supports ABS and not just PLA. PLA is very brittle, especially for parts that see a little flex.

They either have a special NDA with Nest for their beta API or they Reverse Engineered the cloud connect like the other HA companies did. I see a huge number of requests for UDI to make modules for various devices here on the forum. What everyone needs to remember is the ROI. If 100 ISY users purchase a Nest module @ $40, that's a whopping $4000 for ISY. It's doesn't make sense financially for them to do this. If you look at other HA companies, they rely on 3rd party developers to fill that void. In my opinion, UDI's time/resources would be better spent creating an API interface of their own to allow 3rd party developers to more seamlessly interact with the ISY. ----------------------------------------- Anyway, If you want to connect your ColorTouch, here's an option: viewforum.php?f=103

If your sensor makes its way back into the house you could use a Raspberry Pi and OWLink.

My T5900 arrived and am talking to it without any issues. Will release VenLink by the end of the weekend.

Good news. Venstar have gotten back to me and are shipping me a development unit. Once I get it I should have "VenLink" up and running within a couple days. I'll provide access to all items within the API - VenLink will set each of the values as variables within the ISY. All control commands to the Venstar can be sent directly from the ISY, but I'll also include a more user-friendly way through VenLink.

I've contacted Venstar about getting a test unit. If they'll supply, I'll write a Link program.

This can also be done with DSCLink since version 1.1.4. There is a repeater option in the config to send all DSC alarm data though the relay server.

Odd. I just grabbed it from my comp again (didn't close the browser), not sure why it didn't post properly.

There is no iTach receiver for ISY. The only way I know is using a GC-IRE connected to a computer running GCLink (what I'm currently doing). I personally wouldn't use Insteon IR modules for anything (but that's just one guy's opinion).

An IP2IR (or WF2IR if you want Wi-Fi) receives commands from the network module of the ISY and sends out IR. You can setup virtually any type/number of IR commands. To use it, you would write an ISY program. When it sees the "Night" press, it sends a network resource. I do the exact thing in my setup. There's a couple topics on the forum describing how to set the iTach up. There's a little learning curve, but once you understand it, the device is awesome. viewtopic.php?f=20&t=5087 viewtopic.php?f=20&t=11938 Receiving is tough, because of hardware placement. The Insteon solution is the easiest in terms of placement (power lines are everywhere) but I see a lot of people having trouble with it). Ideally the IR could be wired directly to the ISY and just use the ISY's IR receiver.

Any chance you can still return the unit? If so go pick up an iTach IP2IR. Way more flexible and works great.

What was the reason you switched? Would you mind sharing a few pros and cons for CAI vs Pi? The CAI uses the processors IO bus for software one-wire support over likely i2C or GPIO (this may be incorrect but I can't find a maxim chip on the thing anywhere). For me, this was unreliable - the sensors would sometimes not be detected on startup and my wire lengths were limited. At the time you also needed a separate program (WCLink) to connect it to the ISY. This has changed with the latest firmware, but it's still a little ugly to handle. The CAI board is tapped out for memory and new features. Since switching to the Pi (must be close to a year ago now) and a hardware controller, I have had zero failures with the system and that is with a one-wire network twice the size. A hardware one-wire controller on the Pi can use virtually any sensor, not just temperature. You also then have a Pi to run anything else on. Personally I run about a dozen home automation programs on mine, linking various devices in my house.

The always on computer can be a 2W raspberry pi. No cloud required to access directly, DSCLink uses the TPI. No system, cloud or TPI can disarm your system without a passcode.

For $125 you could buy an EVL3 and Raspberry Pi and install DSCLink. Then you can have full control of your system from the ISY and the cloud. Same thing can be done with the Honeywell.

In my link programs (I think you're using one), you can enable the relay server which will accept restart and shutdown commands.

Personally I've fully switched to the Pi. I have 2 webcontrols collecting dust and will never turn them on again. Yes they are cheap with abundant IO, but in reality all their IO is difficult to use, interfacing is a pain (yes the newest firmware makes it a little cleaner) and for me anyway, they have been terribly unreliable. My CAIs 1-wire bus would drop out about once a week requiring a power cycle. The new Pi solution uses a hardware 1-wire controller which has yet to crash on me. It also supports many more devices types and numbers. With the Pi being a full Linux system the possibilities are endless on what could be added to it. I personally run six "Link" programs on mine, a web-based remote control for my TV, NTP server, Samba server and it doesn't miss a beat.

You can't. The network module does not currently support any actions on the return info.

Zoe, Can you give a little more info on the API's capabilities? I previously wrote an app to interface Enviracom with the ISY by reverse-engineering the protocol and using the serial adapter. http://automationshack.com/envlink.html It actually worked pretty well but was a cumbersome setup and was recently replaced with an ecobee. The big plusof this setup was the interfacing did not have to go out to the cloud. I've now written a similar program for my ecobee. http://automationshack.com/ecolink.html ecobee's API is probably the worst experience I've had in home automation. It is cloud based and realtime data is unavailable (runtime data only gets updated every 15 minutes). I'm hoping the new Honeywell API is a little more straight forward than ecobee's and enables faster feedback to help control HA systems. Also, will any future "IAQ" type systems be available to use this API? I need a system with a remote interface module (my previous was a VisionPro IAQ, ecobee is the same) - too many wires and sensors for local hookup. If the API and hardware agree with my setup I would definitely explore writing another Honeywell program.

What your trying to use is the YNCA protocol, I'm using YNC (you can do more with the YNC but yours should be fine). To work with YNCA, it's completely different. The command you're trying to use would work by setting the network command as: tcp protocol port 50000 c-escaped The body would be: @SYS:PWR=On\r\n This works fine on my system.

Path should be: /YamahaRemoteControl/ctrl User agent should be removed. Content-Type should be: text/xml <?xml version="1.0" encoding="utf-8"?> should be the top line of your body as per my previous post.

What I pasted was the actual code you would put in the network module. For a list of all the commands, you can go here: http://files.remotecentral.com/library/ ... index.html I only use a few (10) of the 100s available. You can pretty much control every setting of the receiver.