HouseBot

Scott, I know you have plans to come out with a web interface to HB some day. How hard would it be to convert the existing Software Remote into an ActiveX object? The ActiveX object could then be placed in a web page for remote control.

I've just released a new External Control Plugin that comes with an ActiveX control for interfacing with HouseBot. It's a data only control (no UI) that can be used to build a web page with ASP. If you haven't checked it out, I'd be interested to know what you think.



It may not be too much effort to make the current Win32 remote into an ActiveX control, but what advantage does this give? If you can run the Win32 control over a network/internet now, what value does it have in allowing it to be embedded in a web page? (It's a real question. There very well may be great reasons, I'm just not aware of them).



Scott

Scott, the ActiveX Control Plugin is a great idea, thanks for creating it. I plan on playing with it when I get some more time.



There are two features that I can think of about a web page ActiveX control that would be nice.

1. ActiveX controls will auto install over a network/internet. If you don't have the ActiveX control or the latest ActiveX control on your computer it can be easily installed. This would be nice for people that travel and use various computers such as at the office or hotel etc.



2. ActiveX controls can use the standard HTTP port 80. So getting them to work across firewalls, proxies or routers can be much easier than a service running on a separate IP port.



I think getting to true HTML pages for HB is the ultimate goal but I understand that may take a while. If the ActiveX control can be created fairly easily it may be worth it. If it is going to take a lot of time to develop the ActiveX control, your time would probably better spent skipping the ActiveX control and going directly to HTML pages.



Thanks again for the great program

Scott,



Wanted to throw my vote into the ring as well. I'd much prefer to see the enhancements we discussed for the COM object vs. a built-in web server or HTML generation out of HouseBot.



IIS is a very good web server and the COM object allows for creation of any type of web page that can be imagined.



I also don't see much value in having an ActiveX control since the intention is to use the ActiveX object as an interface to HouseBot and let the web server output straight HTML using whatever scripting language that the user prefers.



This eliminates the need to install anything at all client side which is perfect and removes the need for dealing with client side installs and extra firewall configurations and makes it much easier to leverage a full blown web server for multiple tasks.



I've tried the COM object sucessfully from ASP (obviously), ColdFusion MX, J2EE JSP, .NET and PHP and had no issues at all on any of those platforms. Obviously it also works with VB, Delphi and etc. above and beyond just the 'web' platforms above.



I think the current approach is dead on perfect (with a few enhancements of course) and would much prefer NOT to have to deal with another web server or misc. port to keep track of.



For users who don't want to develop the web pages on their own it would be helpful to have a basic web interface template set but since the COM object makes it sooo simple to interface web pages to HouseBot it would probably be better to create a template set after the COM object development settles down.



This also makes it much, much easier to keep the web side secure and saves a ton of time on developing similar web serving features directly into the server. No need to reinvent the wheel.

MediaStorm, I agree with your suggestion (in another post) to add some more functionality to the new COM control. I am looking forward to those features also. I don't think it will take Scott that long to add that functionality and don't think that doing so precludes other web options.



As I see it the new COM control is great for the power user that wants to create and maintain their own web pages. But my guess is that there are a lot of users that won't go down that route. Scott has spent a lot of effort developing the Software Remote program and many users have spent a lot of time developing themes to use it. If you go pure HTML/COM pages all this work goes away and you are starting from scratch.



I do agree that maintaining one IIS server is easier than multiple web servers if you already have a IIS server set up. I am curious as to what Scott was thinking for long term web support.

- Creating wizards, examples and/or templates for the user to create their own ASP pages

- Or add a built in web server to HB like Homeseer and MisterHouse

Automate..



You're generally on track with where I was thinking.. Given that XP is quickly becoming the predominant OS for the typical consumer and that it has very easy wizards to get IIS running and also that nearly all of the installer wizard type packaging tools easily support adding the proper setup quickly it makes the most sense to use IIS and let MS deal with the security and patches for the web server.



With the additional functionality I requested it would be quite easy to build a generic web site template or even have a wizard generate it. It would even be within grasp to utilize the XML data from a theme layout to closely approximate a remote theme via web pages.



While it is extremely easy to build a simple HTTP server into a product such as HouseBot, HomeSeer et al. It does require additional labor to make it 'safe' and also to support it when firewall issues and etc. come up.



IIS configuration details and firewall info on the other hand can be found quite quickly via a trip to Google or even the built-in help in XP.



I realize that in order to get the maximum benefits from web content the end user will need to be more savvy but that same is true for HouseBot itself. Using a pre-built template set or theme/wizard content would easily provide the same level of 'out of the box' functionality found with HomeSeer and etc. with a minimal amount of effort while still maintaining a strong and flexible backend for those who wish to take things further.



As a side note though, I also think that it is acceptable to make the end user work a little bit more and become more familiar with web publishing in general in order to increase basic awareness of good internet security and safety. Just because you can click a button and publish web content doesn't necessarily mean that you should esp. if you don't fully understand the basics of how to secure access to said content else you find yourself victim to a 'house jacking' or potentially worse when dealing with more complex automation scenarios.



Publishing web content carries similar burdens to that of responsible gun ownership. Without a certain amount of common sense and education one can easily hurt themselves otherwise.

I'm happy to hear that the COM object is proving to be useful. I wasn't sure when I wrote it, if there would be much of an audience for it. I was also considering writing a Java Bean, but wanted to let the COM solution roast for a while. I've also been considering a simpler ASCII based socket protocol between the 'client' piece and the ExternalControl Device. The reason for this would be so you could connect directly from a php script (since it supports socket connections) to HB. This would be helpful in cases like mine, where the IIS server is hosted by a 3rd party that won't allow you to install/register an ActiveX program.



Before I left on vacation, I implemented methods to:

• Get the list of Tasks
• Get the list of Modes
• Get the list of Devices
• Get the list of Properties of a Device
• Get the list of Values for a Property.

I've also created VB Script functions for the same services.



I'm not Mr. IIS/Template, so I really didn't have any plans for some of the things you are suggesting (although they do sound like something I should look into). If it's something anyone else thinks they could implement, I'll be more than happy to add them to the Plugin and give you credit.



Scott

Have you released the version with the extra features yet?

Not yet.



It requires changes in the HouseBot server, so it's waiting on that release. Hopefully at the end of this week, or early next week.



Scott

ScottBot wrote:Not yet.

It requires changes in the HouseBot server, so it's waiting on that release. Hopefully at the end of this week, or early next week.

Scott

Excellent.. Once the new version is out I might be up to tackling a generic template for ASP but need the extra features to make it a reality.

Version 1.62 and the new External Control Plugin is now on the web site.



Let me know how it goes.



Scott

ScottBot wrote:Version 1.62 and the new External Control Plugin is now on the web site.

Let me know how it goes.

Scott

Scott,



I've been having an issue getting the External Control DLL to connect to the server when using the DLL in Delphi.



I finally dug into it and Delphi uses Connect and Disconnect methods to connect and disconnect from the COM server and the External Controll DLL when imported creates an overloaded method to connect which is screwing things up big time.



Delphi corrects the name by renaming it Connect1 instead but its FUBAR at that point anyway.



Could you do me a HUGE favor and change the connect method to doConnect instead? I can write around it but it drove me nuts for a while and might save some others immeasurable frustration down the road as well.



Thanks.

Can I leave the existing function called Connect and just add a doConnect? I don't really want to invalidate anything that others have been working on.



Scott

ScottBot wrote:Can I leave the existing function called Connect and just add a doConnect? I don't really want to invalidate anything that others have been working on.

Scott

Should work.. Delphi does an override method for connect and disconnect since they exist and are used by the COM layer to control connecting and disconnecting from the COM server object.



We can try it with both methods to see what happens. I think it will work. Right now the connect method doesn't get fired to connect via TCP/IP since the override method takes effect to control connecting to the COM server. It renames connect to connect1 but won't instansiate a connection via the function call. Works fine from VB though.



I think .NET uses a similar metaphor and it might make sense to stick with do, set and get for commands, requests and var changes to make sure it stays clean for everything moving forward.



I agree that a change isn't a great idea but at least it is early enough that the change would be minimal at this stage of things and would only require a quick add change from connect to doConnect in the worst case (assuming that it didn't work with dual methods in place).