Neil Cherry wrote on Aug 01, 2008 05:03:

Yeah, more hardware people! Don't say anything to the software folks but they speak a weird language. DOH! Did I just say that out loud ;-)

Our intent is have the iPhone software as open source. I think we're going to be a thorn in Apples side. BTW, my smart phone is a winders mobile 6 phone but no wifi.

It is my opinion that the way we're going to be developing things is that the iPhone app will not communicate directly with the end device. There was some talk about having some of the that intelligence on the remote but if we're going to be supporting a variety of end devices I think the logic needed will be too much for the remote. The server will handle that portion, that's its purpose.

Java folks am I close or am I shoot out the other end?

Yes, you are correct. That's the job of the server. We're re-inventing the concept of a dumb-terminal from ages gone by... only now instead of a terminal, we're talking phones, pda's, remote controls... etc.

Actually, based on the response from Neil and Wade, I better understand the architecture design. I do think a PLM interface makes sense as well - it is the cheapest option (60 USD), and if the server is doing the lions share, then a device like the ISY or the EZSrve may be redundant hw and code... I'm not a good salesmen, but why pay 209 USD for a device that will give the same end user experience as a 60 USD device?

The PLM makes sense because it is a direct serial interface to Insteon at a good price point. There are some complexities, but they can be overcome. I assume macros / events / timers / etc.. will be controlled by the server, so the item that the EZSrve would bring would only be an XML API abstraction to the PLM (developers would like this, end user wouldn't notice). We just mentioned the EZSrve because we are trying to see how we can fit in to the project. I already see a few spots for us, using the EZUIRT for example that is an IR receiver and SENDER via insteon, sensors / monitoring (such as the EZIO line) and some other devices end materials.

For the differences, they are not 100% accurate (but i really don't won't go into a sales pitch - this is DEFINITELY not the place for me to sell our stuff - so only a couple lines), but we can set a static IP address, control devices/scenes, events, we are HTTP based - so an HTTPS phone can access and we do support most Insteon devices with the big gap being the thermostat coming in the next release - we don't support the ELK integration... That said, the ISY is a capable device - not sure on the API for it (truly uninformed), so I don't know how server integration would go.

I heard your interview with Digital Lifestyle, so you aren't catching me off-guard with any of the comments here.

Ben Drawbaugh wrote on Aug 01, 2008 15:25:
Either way, I think that both of these solutions are better than a native Insteon driver, and that both should be supported.

How do you see this working? Are you wanting to fragment the UI and support both the OpenRemote interface system and the ISY interface as well? I guess I'm confused? Or are you just suggesting that the OpenRemote UI should use the ISY instead of a native Insteon driver?

If you are suggesting the former, then I'm thinking why not just use OpenRemote's interface for some things, and then use the ISY interface for other things, and just keep them separate?

And if you are suggesting the latter, then if you are using OpenRemote's UI either way, why does it matter if the OR UI is communicating to the hardware via an Insteon driver vs the ISY. I'm not trying to be critical here at all (so please don't read this with any of that sort of tone)... I'm merely trying to understand where you are coming from here. Is there something the ISY provides that can't be re-created within OR using say Neil's driver (and thus save users $200+)?

Wade Wassenberg wrote on Aug 01, 2008 15:49:
How do you see this working? Are you wanting to fragment the UI and support both the OpenRemote interface system and the ISY interface as well? I guess I'm confused? Or are you just suggesting that the OpenRemote UI should use the ISY instead of a native Insteon driver? If you are suggesting the former, then I'm thinking why not just use OpenRemote's interface for some things, and then use the ISY interface for other things, and just keep them separate? And if you are suggesting the latter, then if you are using OpenRemote's UI either way, why does it matter if the OR UI is communicating to the hardware via an Insteon driver vs the ISY. I'm not trying to be critical here at all (so please don't read this with any of that sort of tone)... I'm merely trying to understand where you are coming from here. Is there something the ISY provides that can't be re-created within OR using say Neil's driver (and thus save users $200+)?

I'm suggesting using the ISY (or EZServ for that matter) as a Insteon device management tool and middleware to eliminate the need for an Insteon driver.

I see NO reason to use the ISY UI for anything other than adding/removing device and configuring scenes.

The reason I say this is because before I bought the ISY I was convinced that Insteon was flawed by designed, and garbage. I have since been convinced that only the SDK and development support is. The way I see it, is that developing a native Insteon device driver must be so complicated (based on how many companies that do a bad job of it including Smart Home themselves) that it isn't worth our time, when even a notice developer like me could just write a driver to interface with the ISY or EZServ web service.

That being said, if it was possible to easily duplicate what UDI and SHN have done, then it'd be great to eliminate the need to spend the extra $150-200. It's not that I don't have faith in anyone's ability to code, it's just that I don't have faith in Smart Home to give anyone the necessary tools to achieve it with a reasonable about of effort.

Ben Drawbaugh wrote on Aug 01, 2008 19:23:
I'm suggesting using the ISY (or EZServ for that matter) as a Insteon device management tool and middleware to eliminate the need for an Insteon driver. I see NO reason to use the ISY UI for anything other than adding/removing device and configuring scenes. The reason I say this is because before I bought the ISY I was convinced that Insteon was flawed by designed, and garbage. I have since been convinced that only the SDK and development support is. The way I see it, is that developing a native Insteon device driver must be so complicated (based on how many companies that do a bad job of it including Smart Home themselves) that it isn't worth our time, when even a notice developer like me could just write a driver to interface with the ISY or EZServ web service. That being said, if it was possible to easily duplicate what UDI and SHN have done, then it'd be great to eliminate the need to spend the extra $150-200. It's not that I don't have faith in anyone's ability to code, it's just that I don't have faith in Smart Home to give anyone the necessary tools to achieve it with a reasonable about of effort.

Admittedly, I haven't delved into the Insteon protocol(s) yet, so you could be absolutely right that it is just so complicated that it is hard for anyone to write anything good against it... however, if I get my hands on an ISY, it's possible I can snoop the protocol and figure out how it does its thing, and replicate that as opposed to following whatever Insteon has published. We'll see.

Wade Wassenberg wrote on Aug 01, 2008 21:24:
Admittedly, I haven't delved into the Insteon protocol(s) yet, so you could be absolutely right that it is just so complicated that it is hard for anyone to write anything good against it... however, if I get my hands on an ISY, it's possible I can snoop the protocol and figure out how it does its thing, and replicate that as opposed to following whatever Insteon has published. We'll see.

There are lots of avenues here, and that is definitely one of them. Another one might be to contact UDI and see how open they are to working together. The entire device is built on Java and is nothing more than an little embedded HA controller.

I know I sound like a ISY fanboy at this point, but I'm telling you after mucking with other Insteon software for two years, I really was about to throw away (read ebay) $2k worth of switches and cut my loses, it was that bad.

Paul Niklewski wrote on Aug 01, 2008 15:48:
Actually, based on the response from Neil and Wade, I better understand the architecture design. I do think a PLM interface makes sense as well - it is the cheapest option (60 USD), and if the server is doing the lions share, then a device like the ISY or the EZSrve may be redundant hw and code... I'm not a good salesmen, but why pay 209 USD for a device that will give the same end user experience as a 60 USD device?

This is my current thinking also, it seems silly to spend the extra money to have functionality that must be in the OpenRemote core program. The ISY will have similar functionality that must be built into the OpenRemote core program. We're also going to be able to support talking to more than one PLM. So the logic needs to be back in the core to handle this. This will get around the Insteon limit to cross linked devices.

This doesn't mean we won't support the ISY. Under the Misterhouse project we had support for all sorts of redundant devices. That's the beauty of Open Source. Have an itch, scratch it then share the solution and it may help someone else. Nobody gets left out.

The PLM makes sense because it is a direct serial interface to Insteon at a good price point. There are some complexities, but they can be overcome. I assume macros / events / timers / etc.. will be controlled by the server, so the item that the EZSrve would bring would only be an XML API abstraction to the PLM (developers would like this, end user wouldn't notice). We just mentioned the EZSrve because we are trying to see how we can fit in to the project. I already see a few spots for us, using the EZUIRT for example that is an IR receiver and SENDER via insteon, sensors / monitoring (such as the EZIO line) and some other devices end materials.

For the initial attack on Insteon I'm still recommending that we go with the PLM. We need to have that complexity in the Insteon controller (java software) anyway. We are still limited in numbers but that doesn't preclude others from writing the code (scratch that itch).

Eventually we'll be interfacing to similar devices (http/https/upnp etc.) and someone will have written something that can be used as a skeleton for such software controllers.

I agree 100%. Having coded for the PLM before, if you have any questions or need some help, let me know.

Paul Niklewski wrote on Aug 01, 2008 19:03:
I agree 100%. Having coded for the PLM before, if you have any questions or need some help, let me know.

The PLM is much easier than the PLC (USB and serial, still a sore point with me and Insteon since the first hardware version). But don't worry there will be questions and we will ask.

Hey Paul,

Thanks for reaching out. I was thinking about this and it seems that having a good insteon implementation is no mean feat and what gives you and UDI an edge in the field. If you can think of a way for the OR community to work with SHN in a way that benefits you, we would love to hear it. Maintaining an O/R software stack under GPL to talk to the PLM seems to be a priority. Having that effort jump-started with a quality contribution could be very interesting. There are many ways to skin that cat, just want to keep the communication open.

Clearly we need an implementation that can be used for free, GPL style, if we are going to distribute it with the rest. That is about the only requirement really, at this stage. Is that something you think you can do? That would be compatible with your model?

In regards to your statement, I can make a statement to ALL open source projects.

The API is copyrighted - meaning, you can use and implement a driver / interface, but if you wre to design an Insteon controller like the EZSrve, you can't copy the EZSrve API side (basically, this protects our investment on the HW/Firmware side). Any open source project or personal project can use the API to interface to the EZSrve, no charge / royalties.

Everything on the OR side can be GPL. We have a very BASIC, VB app (no pun intended) on sourceforge we developed as a stop gap for adoption from other vendors, and that still is licensed under the GPL. So, no issue for anything WE develop for the OR team or the OR team develops being GPL'ed (sans the embedded firmware of course).

The API is free and public, share it, give it away, mail it to your friends.

For community projects, we are available for detailed free development / tech support. We would consider sponsoring a project in terms of free hardware, depending on the shape of the project.

What we get out of it is another sw package supporting our products. Win / Win.

If it becomes a commercial project, where the SW becomes a salable good AND no longer under an open source license, then we can talk with that team and work out an arrangement on a case / case basis.

Definitely looked at it - it is a question of resources. Currently it is on the nice to do list...

If anyone is interested - we can talk.