Release Date: 11/17/2008
Size: 0.1 MB
Popular Rank #: 927
Languages: English
Requirements: Compatible with iPhone and iPod touch Requires iPhone 2.0 Software Update
URL: Lightswitch - Melloware
ZWave Commander is an ZWave Controller Client for the iPhone/iPod Touch and is a native iPhone application that allows you to control your ZWave devices anywhere in the world. Ever wanted to lock your front door while lying in your bed? How about turn the outdoor floodlights on but didn’t feel like walking back downstairs to turn them on? Now you can! All you need is an ControlThink USB ThinkStick device connected to your Windows PC (or MacOSX Parallels) and ZWave Commander will allow you to control all your ZWave devices. ZWave Commander consists of two pieces…a server piece which runs on your Windows PC (or MacOSX Parallels) and the client piece which runs on your iPhone or iPod Touch.
The purpose of this program is simple: to allow control of your ZWave devices from your iPhone/iPod Touch with the touch of a finger.
IMPORTANT: Requires a Windows PC (or MacOSX Parallels) application running and a hardware ControlThink USB ThinkStick to control your Zwave devices.
FEATURES:
Control your ZWave devices from your iPhone/iPod Touch anywhere in the world
No special expensive ZWave remote needed.
You are already using ZWave Devices and already own an iPod or iPhone so now you can take it to the next level.
Any word on MCV making the changes necessary to get a version working with the Vera? I was so excited about it I bought the commander before realizing I had the wrong dongle.
Now that I have a Vera, it would be great to use Zwave Commander with with it!
Any word on MCV making the changes necessary to get a version working with the Vera? I was so excited about it I bought the commander before realizing I had the wrong dongle.
Now that I have a Vera, it would be great to use Zwave Commander with with it![/quote]
It seems we are at a stalemate. I sent Micasa my simple API for them to add to their router firmware and they are insistent I re-write my entire app to use their new Lua scripting engine. I refuse to do that since I already have my PC app working, a hardware vendor Qhorus working, and hopefully another hardware vendor in the near future called Z-Command. To rewrite my entire app just to work with Micasa I just don’t have the time to invest. So Micasa is the only one that has not been open to adding my simple API to their router on port 6004.
There’s more to it than that. We have to put the resources where they get the most bang for the buck. The protocol Vera uses for control is UPnP, which is the only universally adopted protocol, and which has in use by thousands of companies. With Vera, a Z-Wave light switch shows up on the network as a standard UPnP light, and any UPnP control point can see it and control it. Therefore, it’s true that we are more inclined to work on making Vera work well with the myriads of existing UPnP control points that use the UPnP protocol, as opposed to implementing Melloware’s proprietary Z-Wave command protocol. However, it would be simple enough to do a Luup plugin to support the Melloware protocol. The reason we haven’t put the effort into it is because Z-Wave commander doesn’t support door locks, sensors, thermostats (until recently), i/r devices, etc. So, we’d end up making the Z-Wave commander plugin, but most users have more devices in the home than just lights, so they’d end up still having to use the web interface. Adding support for the Melloware is still on our todo list, but it’s just that there are other tasks that are higher.
I didn’t realize the limitations of the Z-Wave Commander as that is a big point to consider. That being said, I do like the interface that Melloware has designed. Hopefully some of those learnings can be incorporated into the MCV solution.
Not trying to detract from your sales Melloware. I have already purchased your app.
I was trying to refrain from commenting on this, but I completely agree with MCV’s position here:
it is totally backwards that a backend should adapt and implement some frontend’s API
UPnP (while I still don’t like it too much, as I was involved in the standard’s development to some extent) is an open standard and is the best approach for any kind of control API, compared to any proprietary API
don’t want to bash Qhorus or Z-Command, but they apparently don’t have any other choice if they want to gain some popularity…
[quote=“denix, post:8, topic:164135”]I was trying to refrain from commenting on this, but I completely agree with MCV’s position here:
it is totally backwards that a backend should adapt and implement some frontend’s API
UPnP (while I still don’t like it too much, as I was involved in the standard’s development to some extent) is an open standard and is the best approach for any kind of control API, compared to any proprietary API
don’t want to bash Qhorus or Z-Command, but they apparently don’t have any other choice if they want to gain some popularity…[/quote]
Denix,
I understand MCV’s decision. They have chosen UPNP as their standard and it’s a good one. They have every right to care about their core product more than adding support for Zwave Commander.
Now that I have said that, let me make sure you have some facts straight…
A) MCV contacted me about my iPhone app and not the other way around. Since they contacted me about supporting my app for their hardware don’t you think the responsibility is on MCV’s side to support my app and not the other way around? So if I contacted you out of the blue and asked to borrow money, wouldn’t you want to set the terms of the loan since you are the lender? Or would you allow this anonymous borrower to dictate they don’t want to pay any interest for the loan? No bank would be in business if that was the case…
B) I have 10 users a week begging me to add support for Micasa Verde but I have to disappoint them and send them to threads like this one. So clearly the market is there, clearly the community wants it, and clearly they want Zwave Commander for MCV.
C) Qhorus, Z-Command and now two other hardware vendors have pinged me about adding support to their hardware. So they perfectly understand that beggars can’t be choosers, and if they want support from my iPhone app they will conform to my standard and not have me write 5 custom flavors of the same application (1 for MCV, 1 for Qhorus, 1 for Z-command etc). Doesn’t that also make sense?
D) Qhorus, Z-Command and others are smaller vendors not as large or with the venture capital of MCV. They are smart to minimize their costs and support my app rather than spend money, time, effort on their own applications which are not part of their core product. It is just smart business in my opinion.
Sorry if this thread comes off as negative. I am not a negative person at all, just wanted to make sure everyone here had all their facts.
My question to this situation is two fold, 1, would it be possible/feasible to get this to work using LUA? Is it possible to open the port and all that. And 2, is the API simple enough that someone could write an LUA script for it to work.
Yes, to both questions. I don’t recall the Melloware protocol right now, but if I remember right, it was pretty simple. So for someone who knows Luup, it’s < 1 days of work to add a Luup plugin to do this.
Good design presumes being modular and pluggable. MCV did their part very well with Luup engine. To me it makes no sense at all that UI can possibly dictate API to backend; and well designed UI should be easily pluggable into anything using simple adapters. You don’t modify your app, you just create adapters to adapt it to any possible backend.
As a user, I look at it this way. If Melloware can come up with a product that’s useful to me as a MCV user – I’ll spend the money on it. Maybe I will wait around for MCV to “upgrade” their existing iPhone application – which works for scenes and on/off, but not so good for the thermostat – but the most annoying thing is that it simply takes forever to log in (vs an always-on control). So I resort to logging into the native findvera.com page. Maybe eventually I’ll have something I can use.
If someone comes up with something better than MCV as a complete gateway, I’ll spend the money on that.
I couldn’t agree with your more. Which is why Zwave Commander speaks the universal language of TCP (transmission control protocol) with a simple ASCII based command structure. That way I can support Mac, Windows, Linux. I can support Visual Basic, C, C++, Fortran, Perl, Python, Ruby, Delphi, Pascal…etc etc etc. EVERY language and operating system speaks basic TCP sockets using ASCII packets. You can’t get more plug and play and language neutral than that. Can the same be said for UPNP and Luup? That answer would be no since UPNP is a complex protocol built on top of UDP which takes an extraordinary amount of coding and knowledge to implement. Most languages don’t even have UPNP api’s or they have poorly implemented ones or even worse NON-open source API’s available. So if you happen to use Visual Basic 6 you are out of luck on UPNP. Python? Forget about it. Ruby? Forget about it.
So to quote you above “well designed UI should be easily pluggable into anything using simple adapters” is exactly what I have built. Thank you for making my point for me!!! Can the same be said for UPNP? Yes and No. YES its pluggable but NO not easily. YES it an adapter pattern but NO it is far from simple.
will turn on the given device. It’s not just for controlling Vera’s devices. You can pass other UDN’s (like your UPNP access point), and Vera will forward it to the external device in the ‘official’ upnp way. To find Vera on the network, if you don’t support broadcast packets for discover, you just open this page:
and it returns the IP address(es) of any Vera’s on the same network local network. There are also simple http get’s to retrieve the list of actions a device supports, etc.
Of course those extensions aren’t part of the UPNP spec and are specific to Vera, but they do allow any language/platform to control UPNP devices, and at least the actions/arguments are still the ‘official’ ratified UPNP ones.
Let me start off by saying I understand both points of view.
Then let me add this, if there is enough demand, an iPhone/itouch native app will be written.
I have written a complete interface via my telephone so I may control devices thorough asterisk with a simple IVRS menu.
Let me posit this. How many people are truly interested in an iPhone/itouch app?
Even though I did not directly ask if any one wanted my agi scripts for the touch tone interface, no one ever inquired.
So how many people would be interested in an app native to the ixxxxx devices? @MCV:
can you provide all of the HTML based commands to assist in doing it either via a plugin or by having the app directly query Vera?
The wiki page: http://wiki.micasaverde.com/index.php/UI_Notes#user_data_and_lu_status lists all the categories and devicetypes to determine what device is what. Also, there’s some pseudo code at the bottom showing how the polling works. If MelloWare wants to do a Vera-compatible version, send the shipping info to sales [at] micasaverde[dot]com and we’ll send a complimentary vera.
Thanks for your prompt reply.
I am personally happy with web iPhone interface. However a native app would be nice.
So if there is interest to warrant it. I will start on it.
