Author
Topic: LinuxMCE and Misterhouse (Read 19137 times)

Also we need mechanism to make those modules as contributions and reusable for other users... AFAIK, we're miles from that point, except of limited functionality of Ruby and GSD..

That's what sqlCVS is supposed to be. Getting that online as we work to scale the community in so many other ways (like opening the project and getting it upgradeable with new Ubuntu releases) could become the biggest community contribution.

What could boost this entire effort would be a program that imports MisterHouse HW handlers into LMCE, if that's posible. Though just more accessible tools than the GSD form would also help.

I am aware that these things could be solved with some development, but I don't have the skills and modifying a little bit of perl to bridge MH and LMCE was very simple and very convenient.

Chris

1. Yes, dig into the criteria section of the Events on the Web Admin

2. the appliance control is the oldest and most reliable part of LMCE.

3. X10 is by its very nature, very slow, so yes, inherent lags in the messaging system will exacabate this. I can tell you that there is a lot of debugging code being executed right now that if disabled would vastly speed up this part of the system by orders of magnitude, with that said, even on my Z-Wave installation, selecting and triggering a single light only takes about 40ms, with other lights happening roughly half a second after the message is sent to each in a queue, this can be improved.

4. we need to implement this, again, not hard if you actually dig in a little. The system already can deal with it, the commands and events just need to be implemented.

5. write a driver. I use a DS9490R and it works just fine.

You're telling me you can deal with the mess that is Perl, and you don't want to even look at Ruby? I would suggest looking at a GSD template before making such a determination.. which leads me back to my original point, actually look at the system before slapping on duct tape to other things.

You're telling me you can deal with the mess that is Perl, and you don't want to even look at Ruby? I would suggest looking at a GSD template before making such a determination.. which leads me back to my original point, actually look at the system before slapping on duct tape to other things.

I am expert in the "mess" (powerful complexity) that is Perl. Which is one reason why I haven't learned Ruby: I've already invested enough in Perl, I'm good at it, it's powerful, there's a huge amount of existing Perl, there's a huge community of Perl experts and just average programmers. The only reason to learn Ruby is that some idiosyncratic systems use it instead of Perl (or C or shell script or Java).

Is there a reason that LMCE has to use Ruby? Why can't it expose an API with language bindings (starting with Ruby), and run any executable that has a language binding? Perl is very embeddable, has lots of support and prior art for doing so. And lots of existing Perl code that does real stuff right away, whether integrating other SW systems or gluing HW.

Matthew: We could use additional bindings for other languages, are you volunteering?

OK, I'm volunteering to help in that effort. Though I usually don't take constructive criticism on a users list as an offer to help, just to help focus the developers. Posting on a developers list is different... So now I guess you've got me to post something starting the subject over on the developers' list, in "Language Bindings".

I've never produced a language binding before, so I'd prefer to work with someone who has. If no one else offers, I can try to work on a Perl binding sometime in January.

the GSD is the device that embeds ruby, you may want to look at this to produce a work-alike device for the language you wish to interpret.

We should move more detailed discussion to the "Language Bindings" thread I split from this one. Specifically about which source files incorporate the GSD. I'd rather add a language bindings layer (if it doesn't exist) to GSD itself, or just add Perl, rather than make another device largely redundant to GSD.

You're telling me you can deal with the mess that is Perl, and you don't want to even look at Ruby? I would suggest looking at a GSD template before making such a determination.. which leads me back to my original point, actually look at the system before slapping on duct tape to other things.

I understand what you are saying, but until the messaging system in LMCE is vastly speeded up I cannot think about using it for my motion triggered lights and to repond to my X10 wall switches. They need to be as quick as possible. The other major problem is that the beta nature of LMCE means, that while the HA code may be mature, immature code elsewhere means the system is frequently rebooted or runs into problems. As I said, if the lights stopped working as often as the TV does then I would be in trouble. I can also relax now and mess around with LMCE without worrying about the basic services in my home.

When I tried connecting my X10 interface to LMCE the lights would turn on several secs after I clicked them on the floorplan. Running MH this process takes less than a second - not ideal I know, but acceptable. By the time this is fixed I imagine LMCE will be able to recieve X10 commands and the whole thing will be more mature. In this case my "duct tape" is appropriate, as once the system is fixed MH will not be necessary. Duct tape is ok for a temporary fix.

You're telling me you can deal with the mess that is Perl, and you don't want to even look at Ruby? I would suggest looking at a GSD template before making such a determination.. which leads me back to my original point, actually look at the system before slapping on duct tape to other things.

I understand what you are saying, but until the messaging system in LMCE is vastly speeded up I cannot think about using it for my motion triggered lights and to repond to my X10 wall switches. They need to be as quick as possible. The other major problem is that the beta nature of LMCE means, that while the HA code may be mature, immature code elsewhere means the system is frequently rebooted or runs into problems. As I said, if the lights stopped working as often as the TV does then I would be in trouble. I can also relax now and mess around with LMCE without worrying about the basic services in my home.

When I tried connecting my X10 interface to LMCE the lights would turn on several secs after I clicked them on the floorplan. Running MH this process takes less than a second - not ideal I know, but acceptable. By the time this is fixed I imagine LMCE will be able to recieve X10 commands and the whole thing will be more mature. In this case my "duct tape" is appropriate, as once the system is fixed MH will not be necessary. Duct tape is ok for a temporary fix.

There are so many bugs fixed in the 0710 release, not to mention all the Linux bugs fixed in the underlying Kubuntu, that I'll be interested to hear whether its messaging performance is adequate. The developers team has also said they'll be opening development on a self-hosting build env with that release, so we'll be able to take a crack at any of a number of ways to improve it to suit our own requirements. While the release date has been moved from "the end of November" to "Real Soon Now (TM)", I hope to see it in January.

I understand what you are saying, but until the messaging system in LMCE is vastly speeded up I cannot think about using it for my motion triggered lights and to repond to my X10 wall switches. They need to be as quick as possible.

I understand what you are saying, but until the messaging system in LMCE is vastly speeded up I cannot think about using it for my motion triggered lights and to repond to my X10 wall switches. They need to be as quick as possible.