LinuxMCE and Misterhouse

[Matthew]

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.

[chrisbirkinshaw]

why the hell are you guys doing this? especially when pluto does what misterhouse does, better?

1. Can I do this level of scripting in LMCE?

X10 motion detector triggered --> is it between dusk and dawn? --> is the light already on? --> switch the light on
Switch A5 pressed --> dim lamp A3 to 50% and switch lamp A4 off

2. Misterhouse is the only stable part of my system. It sits on a separate low-end PC which is never touched. If the lights were as reliable as the TV my girlfriend would leave me!

3. When I tried controlling X10 lights using LMCE directly there was such a huge lag that the system was useless.

4. There is no support for receiving X10 commands in LMCE (I actually receive RF commands via an MR26 and powerline commands via a CM11 in Misterhouse)

5. LMCE cannot talk to my iButton temp sensors using the simple homebrew passive serial adapter


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

[tschak909]

why the hell are you guys doing this? especially when pluto does what misterhouse does, better?

1. Can I do this level of scripting in LMCE?

X10 motion detector triggered --> is it between dusk and dawn? --> is the light already on? --> switch the light on
Switch A5 pressed --> dim lamp A3 to 50% and switch lamp A4 off

2. Misterhouse is the only stable part of my system. It sits on a separate low-end PC which is never touched. If the lights were as reliable as the TV my girlfriend would leave me!

3. When I tried controlling X10 lights using LMCE directly there was such a huge lag that the system was useless.

4. There is no support for receiving X10 commands in LMCE (I actually receive RF commands via an MR26 and powerline commands via a CM11 in Misterhouse)

5. LMCE cannot talk to my iButton temp sensors using the simple homebrew passive serial adapter


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.

-Thom

[Matthew]

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.

[tschak909]

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

-Thom

[Matthew]

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.

[tschak909]

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.

-Thom

[Matthew]

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.

[chrisbirkinshaw]

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.

;-)

Chris

[Matthew]

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.

[hari]

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 dcerouter is fast enough for that. It's not the messaging system. I think the X10 implementation should be improved. Look at what ddamron has done for insteon simply using GSD (http://forum.linuxmce.org/index.php?topic=3309.0).

best regards,
Hari

[tschak909]

yeah, no kidding, even ZWave happens in about half a second for me.

-Thom

[bulek]

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 dcerouter is fast enough for that. It's not the messaging system. I think the X10 implementation should be improved. Look at what ddamron has done for insteon simply using GSD (http://forum.linuxmce.org/index.php?topic=3309.0).

best regards,
Hari

Hi,

if I'm not mistaken, I remember reading something about intentional timeouts built into X10 interface of LMCE, because something was not working reliably.. But could be wrong...

Regards,

Bulek.

[Zaerc]

I think the whole X10 implementation could desperately need some work, or maybe even needs to be rewritten completely.

[PeteK]

Dan's got it working with his Ruby Insteon code and I'll have it for the PLC Insteon interface soon after the 0710 release.