Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - mkbrown69

Pages: 1 2 3 [4] 5 6 ... 13
Users / Re: problems with medibuntu?
« on: October 15, 2013, 03:20:43 pm »
The Medibuntu project has folded.  See here:

Medibuntu has now been shut down, the packagers were either obsolete, unnecessary or moved to the official Ubuntu archive.

A Libdvdcss package is now available direct from VideoLan

We'll probably need to determine what packages were being obtained from the medibuntu repos, and then update the apt listings and/or the LMCE software package definitions.



Developers / Re: Need some design advice
« on: October 10, 2013, 01:35:50 am »
... and discuss his design decisions for the agecontrol, sorry, agocontrol gateway into LinuxMCE.

I'm guessing there's something behind the "slip", but I'm missing it...   ;)

Thanks for the pointer though... I have been watching AgoControl, as I think it has potential as a Home Automation sensor platform when running on a PI.  Just don't have the extra cycles right now... Doing the ISY driver, plus building LED DMX dimmers and fixtures plus some props with the kids for Halloween and Christmas.  I'll go bonkers if I pickup another hobby project.  ;-p



Developers / Need some design advice
« on: October 09, 2013, 06:55:36 pm »
Good Day folks!

I'm hoping Thom, posde, phenigma, or anyone else who's familiar with the guts of LMCE can sanity check and provide some advice on what I'm thinking below...

I'm working on my ISY driver, and getting to the parts where it will create devices in LMCE based on what exists in the ISY.  The idea is that the ISY "owns" the devices that are linked to it (Insteon for now, possibly UPB and Zwave in future versions of the driver and hardware), and it will inform LMCE about the devices and their configuration.  Generally, that is easy and works presently in my driver.  The way the ISY works is that there is a Java-based management console that is used to configure and administrate the system, and add and mange connected devices.  The API and subscription channel are used to interact with and monitor/react to events from the ISY, for integration into Home Automation systems.  Most things are fairly straight forward to implement from the LMCE point of view. There are a few devices/features I'm not quite certain as to the best way to implement them, which is why I'm asking for advice.

The first is Insteon keypads (Dimmer or relay switched).  There are 6 and 8 button models; the 6 button has an 'on' and an 'off' button (which appears as one load control switch remotely), and 4 other buttons.  The 8 button model has one load control button, and 7 other buttons.  The other buttons can be triggers for Insteon scenes (which I'll get to next), or can be cross-linked to other switches.  For example, I have a 6 button KeypadLinc in my breakfast nook, that is linked to the switches in the kitchen and family room.  Now, I could create a device template for it, but I think I could simply use the generic Light Switch on/off and Light Switch dimmable templates, and use the configuration field to store the required information.  Here's the part I'm not sure about.  The "other" buttons are a part of the switch, but are not controlling the parent switches load (unless they are part of a scene involving the parent switch).  Is is possible to create child devices of a generic light switch, and would it be a good ideal?  Or should they be treated as peers and grouped or related somehow?

Insteon Scenes are my next challenge;  basically, they are a pre-programmed into the various devices which comprise the scene (using a scene identifier, level, and ramp rate), and then are triggered by the scene broadcast message.  The nice thing about scenes is that they happen simultaneously (all member devices respond to the broadcast message directly), and being programmed into the target devices, they work even if the automation controller goes down.  Scenes triggered via the protocol have an on/off capability, and a relative dim/bright capability (in which all scene members will brighten or dim as the scene button is held, relative to their scene levels).  The thing is, a scene can't be queried directly; it's just a broadcast message on the Insteon network.  Scene members have to be queried directly for their status (and that's covered already in the subscription channel in the driver).  So, I'm wondering if I should create a device template for an "Insteon Scene", which has a data field consisting of the members of that scene?  Or would an LMCE group work?  If an LMCE group would work, can I generate and modify them using LMCE events?  Or should just use a generic light switch for a scene, and handle it all in my driver using the configuration field information?

The last thing I'm wondering about is the ISY concept of "folders".  The ISY has a feature (not Insteon specific) that allows you to group related items (by room, by function, whatever).  A device/scene/program can be assigned to only one folder.  Would that capability translate directly to an LMCE group?  If I were to use groups for ISY folders, are there any problems or gotchas with doing that?  Can I create/modify groups using LMCE events?

The ISY also has "programs" and "variables" which are used on the controller for conditional if/then/else type events and automation.  Those are all visibly exposed via API's and the subscription channel for event status updates.  I'm not even looking at dealing with them right now, is this version of the driver.  I'll look at those later when the driver is mature and stable for production usage, but if anyone has thoughts on those, I'd be happy to hear them!

Thanks for your time!


Developers / Re: New Radio Thermostat CT-80/CT-30 template uploaded
« on: October 07, 2013, 05:45:00 am »

Thanks for approving it!  SQLCVS update/diff shows no problems, as does a visual check of the Template and Ruby code.  It is as I had committed it...

Thanks for the assistance!  Please free to close the Trac ticket as complete; much appreciated!


If you see this thread, you're welcome to look at the template and try it out with your 3M-50 tstat.  The driver should incorporate all your existing capabilities.  I've stubbed in a few things I'll finish up for 12.04 and the weather plugin.  If you have any issues, let me know.  For now, I'll be moving on to my ISY driver to get that relatively complete for others to test.



Developers / New Radio Thermostat CT-80/CT-30 template uploaded
« on: October 07, 2013, 04:44:21 am »
Hi Folks!

I've done an anonymous check-in of changes for the Radio Thermostat Template.  Trac #1931, committed at 22:32 on 2013-10-06.

Could someone please review the SQLCVS commit, and let me know if I did it right?  It's my first time committing using SQLCVS.

Thanks for your time!


Users / Re: virtual machine +tv-card
« on: September 04, 2013, 05:51:39 pm »
Just to give you an alternate idea...

I run LMCE 10.04 as a virtual on a Debian Wheezy KVM host.  My current production MythTV environment is running on the host (Myth 0.25), where I have two HVR-1600 TV cards.  My motherboard won't support PCI passthrough, so my plan eventually is to upgrade the 10.04 instance to 12.04 and Myth 0.25, make it the master and restore my database and files onto it, and then make the host Mythbackend a slave backend to the virtualized master.  So, the slave running on the host would own the tuners, and the virtualized master would just schedule the slave to handle the recordings.

So, some food for thought if you don't want to (or can't) deal with the whole passthru option.



Users / Re: virtual machine +tv-card
« on: September 04, 2013, 05:43:10 pm »
It depends...

The Hypervisor has to support PCI device passthru.  The motherboard chipset and the CPU have to support it (VT/d or IOMMU).  If it's a PCI card, rather than PCI express, you may have to also pass through the PCI bridge chip, and all devices after it (in other words, all PCI devices may need to be passed through, not just the PCI TV card).

When all that is said and done, it may work, or it may not, depending on the quality of the TV card drivers.  Some work fine when the device is passed through, others may not.

I'm not trying to discourage you... just want you to know that it may or may not work, and there's a lot of dependencies to work through before trying it.

Hope that helps!


Users / Re: Radio Thermostat owners: can you help me out on new driver?
« on: September 04, 2013, 05:02:40 am »
Thanks Sean!  Much appreciated.

We're pretty close on firmware versions: mine's running 1.04.83, so I'm guessing you use the Radio Thermostat app, and the "cloud service"? Mine is running what it shipped with; haven't done the app yet.

The /tstat/help output is interesting, but not surprising. It's showing the complete API listing, given that it's implemented in the radio, not the tstat itself.  I was rather hoping it would only expose the functionality that the device was actually capable of, but that doesn't appear to be the case...

Good news is that the driver should work properly for you functionally.  I think I'll have to implement some additional error trapping for some routines to ensure that the driver doesn't puke if it tries to query device capabilities that don't exist. I'll also leave some of the advanced functionality out for a bit, until the driver's been out in the wild for a while.

Hope to get it finished (for now) later this week, and then released for broader testing.  Thanks for your help with this!


Users / Re: My thermostat template died
« on: August 30, 2013, 04:45:17 am »
Thanks Thom!

I generally like to play well with others  ;D... I also really like the whole spirit behind Open Source Software, and like to give back where I can.  It's just taken a while to get familiar enough with LMCE that I can actually start to contribute in some meaningful way.

I found working on this tstat driver to be really helpful in learning different aspects of LMCE.  LinuxMCE is complicated under the hood because it does so much, and the ISY I'm also writing a driver for has a lot of capabilities too.  It was almost overwhelming trying to get them married up.  The tstat driver gave me a break, and a much smaller set of functionality to deal with, so I could figure out things in more manageable chunks, and I learned a lot in the process.

Thanks for your patience and assistance!  It's greatly appreciated!


Users / Radio Thermostat owners: can you help me out on new driver?
« on: August 30, 2013, 04:31:18 am »
Hi Folks!

I'm currently working on a driver for the Radio Thermostat CT-80, which uses the API.  Because it uses the API, it's a possible universal driver for all Radio Thermostat models.  I've based mine on Sean's (aka WhateverFits) excellent 3M50 driver (thanks for the great work Sean!), and updated it for the additional capabilities of the CT-80 plus other API features which should work with other models. There's been a bit of discussion in this thread:,13336.0.html

In order to try and make this a universal driver, I'm hoping some other Radio Thermostat owners could do me a favor, and post the results of a few URL's off of your thermostat.  That way, I can make sure I don't break anybody's usage of their thermostats if they try my driver.  ;). So, if you have a 3M50, a CT-30, or a CT-80, if you could post the results of some URL's, it would let me make sure that I'm not making assumptions on the capabilities of the various models, as the API docs don't go into enough specifics as to what devices have which capabilities.

You should be able to use a web browser, and just paste the URL's into the browser address bar.  I'll also post a curl version people can run from the core via command line.  Just substitute the xxx with the proper address of your thermostat (or the full IP if you're not using the normal subnet range for the LMCE network)

Code: [Select]

Code: [Select]




Thanks for your assistance with this!


Users / Re: My thermostat template died
« on: August 30, 2013, 03:59:34 am »
Ok, I figured out the Orbiter +/- buttons issue.  Just a disconnect between different parts of the driver, and I had to change the URL from /tstat/ttemp to the newer version in the API /tstat {"tmode":1, "t_heat":74}

I'm going to start a new thread to get some information from 3M50/CT-30 owners so I can make sure I don't make assumptions based sole on the API docs and break people's usage of their thermostats.

Thanks for giving me a good basis to build on with your 3M50 driver!  Much appreciated!



Glad to hear you recovered your treasured memories!  RAID is meant for availability in the case of a hardware failure in one of the "spinning platters of rust", to quote a colleague.  It won't ever replace a good backup, which is something you may wish to do in the near future...

Take care!


Users / Re: My thermostat template died
« on: August 27, 2013, 03:08:48 am »

Could you do me a favor and test something from an Orbiter?  I'm selecting the tstat in Roaming Orb, and trying to adjust the temperature setting using the + and - buttons.  I get errors in the logs, and I'm wondering if it works for you (and is thus a problem with my implementation), or if you get the same.  I'm using the exact same code as the 3M driver for set_targettemp and Event 278.

Code: [Select]
Mon Aug 26 20:41:26 -0400 2013 : Error in set_targettemp: undefined local variable or
 method `value_to_assign' for #<Device_183:0xb44bab04>
Mon Aug 26 20:41:26 -0400 2013 : (eval):432:in `set_targettemp'(eval):19:in `cmd_278'
Mon Aug 26 20:41:29 -0400 2013 : set_targettemp called
Mon Aug 26 20:41:29 -0400 2013 : Error in set_targettemp: undefined local variable or
 method `value_to_assign' for #<Device_183:0xb44bab04>
Mon Aug 26 20:41:29 -0400 2013 : (eval):432:in `set_targettemp'(eval):19:in `cmd_278'
Mon Aug 26 20:41:32 -0400 2013 : set_targettemp called
Mon Aug 26 20:41:32 -0400 2013 : Error in set_targettemp: undefined local variable or
 method `value_to_assign' for #<Device_183:0xb44bab04>
Mon Aug 26 20:41:32 -0400 2013 : (eval):432:in `set_targettemp'(eval):19:in `cmd_278'



Users / Re: My thermostat template died
« on: August 27, 2013, 01:51:18 am »
Hi Sean!

Basically, my template is based on the code from yours, with some changes and the additions for the API and the CT-80.  So, it should work for 3M50/CT-30 owners the same way yours would, minus the auto-detection stuff.  Thom can correct me if I'm wrong, but I don't think we can combine the drivers per se; I think one would have to take over from the other, and then the other gets deprecated somehow.

Since you're probably using your Tstat "in production", I can commit my changes against 2243, which would leave your 3M one intact. That would allow you to try it out, and still have a backout plan if it doesn't work for you.   If there's things you want to work on, I'd be glad for the assistance.  I'll summarize what I've added, and what I've got on my to do list...

Improved logging (does a lookup on some response codes to make it more informative)
Get model subroutine
Get/set time subroutines.  Verifies time is within +/- 5 min of system time.
Supports the Price and User messaging areas, and the Energy LED.
Logs system info, and logs the stat's event log
Sends humidity events (including to datalogger)

# Write device capabilities out to #207 Capabilities
# Write device config out to Configuration #59
# Write functions to allow for changes in #59 to update Tstat
# When Weather plugin is complete, add support for C/F detection
# Covert math functions to use conversion sub routines
#  for decimal support in Celcius
# Add LMCE support for functions like message areas & LEDS (interceptors?)
# Add model compatibility checks for all advanced functions
# Complete Eventlog to datalogger functions.

I'm just finishing up the time stuff (making sure it catches some edge cases; the device and API are a little quirky, and I'm currently abusing it with control by LMCE and posting the outside temperature to the Price messaging area using a script called from cron.  The tstat doesn't like multiple device access...

So, what do you think?


Users / Re: URGENT 810 Software RAID failed after power outage
« on: August 26, 2013, 06:08:05 pm »
then run this command, this is the easy way.

 sfdisk -d /dev/sdd | sfdisk /dev/sde

then format it using mkfs

then add
Actually, you don't need to format the individual members of the raid array.  They contain the striped blocks of the md device, not an actual file system.  It's the /dev/mdX that actually gets a file system, which in this case already exists so DON'T do a mkfs on /dev/md1.

Just copy the partition table as per the sfdisk command above, and then add /dev/sde1 into the array.

Things should work a lot better this time around.



Pages: 1 2 3 [4] 5 6 ... 13