HouseBot

I have been using HouseBot for almost 7 years now, and have very much enjoyed it. With an impending move, I find myself re-evaluating my home control. With a wife, a kid, and a business, I have less time to spend on my passions. Scott has created a brilliant home control framework. It just needs more plug-ins and more frequent updates of those plugins.
For shtz and giggles I took a look at homeseer. I’m looking at over $600 for the software and the plug-ins I need, and I know that it will not offer me the customization that I want. So, how to bridge the Gap? Crazy idea…..How about an app store for HouseBot? It worked for Apple and now Android. I was thinking around $10 for a plug-in. Having available plug-ins for the most popular devices would open HB to a wider audience. It would also give regulars here at HB motivation to release their work.
Any thoughts?

Do you mean that HouseBot may get more attention by plugin developers when people start getting money for posted plugins?
Those plugins would have to be exports I guess.

I also use HouseBot for 7 years now and created all the plugins I need. Ik guess many of them would be interesting for lots of other people but over the years these plugins started to integrate with other plugins (like an alarmsystem pluging controlling lights etc) so I would be a bit difficult to detach all the integration stuff to be able to post it as a stand alone plugin.
The beauty of HouseBot is that it actually doesn't need any plugins. You just create them yourself. However, that does require some knowledge which is not for everybody. So to make HB more open to the people, standard plugins for all types of AV and domotica equipment could be an interesting thought. Maybe if people could actually earn some money off of it, these plugins would be more intersting to make.

Maybe a good thing for a poll but not too many different people read the forum in summertime;)

I think it is a good idea. However, my major limitation for creating more than one-off plug-ins for HouseBot is the fact that I can't develop in a .NET environment. I think if Scott were to do one thing, it would be to broaden the development environment for HouseBot. I know that there is the .NET bridge, but this is limited in what it can do. With a .NET SDK, I think more people would be able to dabble and create plug-ins to the benefit of the whole community. This is one of the reason I started looking at other software packages (but abandoned this, as the core of HouseBot is just so darn rock-solid reliable). A benefit of this is that it could off-load the burden from Scott in terms of requests for x-y-and-z. I for one would be more than happy to code something that I may rarely if ever use (just for the fun of it). Getting $5-10 per download would be bonus.

Osler

This is interesting. I really think the future of Housebot is going to rest on the client and what may materialize there. Currently a windows only client does not offer too much in the way of portability and control especially since Windows Mobile is struggling . I agree that Housebot is very stable especially considering the other Windows based HA software out there that is available and the affordability factor is a definite plus for this system as well.

I honestly think that if HB could get into the iOS and Android arena it will not only grow in popularity but would thrive as an HA platform. I like the idea of the plugins but unless the effort that is currently underway by Timoh succeeds and software remotes can be ported to Android/iOS or some other robust client control is developed I think we will be hard pressed to see an 'app store' of individual plugins for HB thrive.

my .02

edgar said...

I like the idea of the plugins but unless the effort that is currently underway by Timoh succeeds and software remotes can be ported to Android/iOS or some other robust client control is developed I think we will be hard pressed to see an 'app store' of individual plugins for HB thrive.

I like the notion of success, but edgar did qualify it with a "but". It's still very much on my roadmap, but I never imagined in a million years that changing diapers is full time job! Previously, I used to come home from work & tinker with HB. Now I come home from work, get a baby handed to me, and that's it... I'm done for the evening.

I expect not only my web browser remote to help out for HB uptake, but also the protocol behind the scenes. In essence I'm going to be providing an open swremote protocol to the community. That should hopefully spur on development since people will have a richer way of interacting with HB at a low level.

I'm hoping to get back on the bandwagon in August as I will be off for several weeks on paternity leave. If I can get the protocol out the door, it'll probably be more valuable to people wanting to do more, than the actual web based remote will be.

Tim

I think if Scott were to do one thing, it would be to broaden the development environment for HouseBot. I know that there is the .NET bridge, but this is limited in what it can do. With a .NET SDK, I think more people would be able to dabble and create plug-ins to the benefit of the whole community.

Second this, I would love to turn my DSC Alarm control into a 'real' plug-in. But VB is all a know, just don't have time to start messing around with C

Why not use vbscript. You can do just about everything you could do in VB and if stuff is missing, you probably find some COM object to get it going again. My whole system is based on many and very large scripts to interface all the devices using its (bi) directional com ports. for almost all equipment hosting an rs232 port you can find the protocol and command set online. With it you can build your own drivers using a script device with a script and a null device to host all the (status) properties. Many script examples are posted on this forum. Even media like Meedio and databases like Access or SQLite can be controlled using vbscript and HouseBot. You can use HouseBot to control the devices and display its status as well as make different devices work together.

That's exactly what I did with my Caddx panel. VBScripted it. It works like a charm!
HB talks to the VBScript. VBScript talks to the serial port. Serial port is connected to alarm panel.

In fact, having a robust remote control protocol as mentioned above, wouldn't help you much for talking to devices that have simple ASCII/Hex protocols over serial ports. You would still need to write an interface layer between HB remote protocol and your serial port/alarm panel.

Tim

I did not intend my post to be about what you can currently do with HB. With a little ingenuity, you can pretty much control any device out there. But rather, I intended this to be about what can be done to make HB more appealing to the masses.
I do use VB script to control and monitor my DSC panel. I had one system in place, and then I completely re-did it. The second time I tried to make it as portable and streamlined as possible. It has two mdb files, a log and a device list file. Two scripts that run, one that receives data from the panel and puts it into the log, the other script process the data out of the log. Then it has HB null devices for the physical alarm devices that also correspond with the devices listed in mdb file .....etc etc
As much as I tried to make it simple and portable, a novice would have to spend at least an hour to get it up. Let’s take the Insteon plug in for example. Go to hardware devices, add insteon, give com port, go software devices, add insteon, follow wizard, insert insteon address…..and Presto! You have insteon control. It is that type of plug-in that I would love to see available for many of the popular devices out there. Although I know very little about the HB SDK, I assume it allows you to do this. Am I correct?

Yes, the HB SDK allows you to do that. It is C++ and appears old style. Last time I tried I had some trouble linking all the stuff using the latest Micro S. Visual Studio C++. I guess C++ is the only way to go since the C# and .NET bridges all seem to have problems. In C# I couldn't get it to work and Osler can tell you all about .NET;)
So yes, it can be done but:

If Scott were to do it, he would need the hardware to test it.
My AV receiver is an Onkyo. That protocol is backward compatible with all other and older receivers so you could make one driver for Onkyo receivers. LG TV's are the same except for source switching. That differs per type and the owners manual doesn't address this. So you would need a list to choose from and still need all the hardware to test it because imo you can't sell stuff that doesn't work. For almost all equipment you can find the protocols and I interfaced a lot but in any case I stumbled against problems I didn't foresee while creating the driver before I had the actual hardware. It almost never works without testing it.

Writing drivers using the SDK would also require a test setup of HouseBot since you kind of pollute your database while testing. The thing I like about vbscript is that I can just open the editer, change a byte and test it whereas a C++ driver would need to be compiled again, HB would need to be restarted to load the dll's etc. So development is more of a pain.

I still think that common drivers that only handle the device without integrating to other devices can be written in vbscript. It just needs a very good export. You could export the script + device, null device, themepanels etc. I posted multiple exports used by others that should work out of the box. The other beauty of script would be that others could tweak it to their own likings whereas you can't tweak a dll.

In a perfect world, you have a seperate device driver for all the different hardware and seperate scripts or tasks to connect them. People could buy the device drivers exports but still have to create their own interface layers to make it custom to their own setups. I guess software like HouseBot, Homeseer etc almost always requires an above average level of knowledge about software and hardware to get it going OR to just get that extra bit which makes it your own custom setup.

Still agree qith you though. Last year I bought an RFXCom receiver, installed the HouseBot driver and voila.. up and running. It saved me a lot of time creating my own driver and most others wouldn't even go that path. The RFXCom hardware was tested remotely through a virtual LAN/ COM port so Scott didn't need to have the hardware at home. In this case it was easy but in case of an AV device, alarm system or ... you need to be sponsored by somebody delivering the test hardware for free.

Hi All,

The future of Housebot will depend on its available Plug-Ins.

I was reading a earlier message praising the fact that we didn't have to pay much for this software, since we didn't have to pay for all these useless plug-ins.

A list of requested plug ins should be made, and a price established per plug-in, ( $ 40.00 / ) whoever is interested in making the plug-in could pocket the money.

This is the only way this software can grow, otherwise it is doomed, to remain as it is or die.

Dom