Messages

76

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.

HTH!

/Mike

77

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!

/Mike

78

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!

/Mike

79

Users / Re: My thermostat template died

« on: August 30, 2013, 04:45:17 am »

Thanks Thom!

I generally like to play well with others  ... 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!

/Mike

80

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:  http://forum.linuxmce.org/index.php/topic,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]

http://192.168.80.xxx/tstat/model

http://192.168.80.xxx/sys

http://192.168.80.xxx/tstat/help

http://192.168.80.xxx/tstat/eventlog


Code: [Select]

curl http://192.168.80.xxx/tstat/model

curl http://192.168.80.xxx/sys

curl http://192.168.80.xxx/tstat/help

curl http://192.168.80.xxx/tstat/eventlog

Thanks for your assistance with this!

/Mike

81

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!

/Mike

82

Users / Re: [SOLVED]: URGENT 810 Software RAID failed after power outage

« on: August 27, 2013, 05:32:20 am »

Beeker,

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!

/Mike

83

Users / Re: My thermostat template died

« on: August 27, 2013, 03:08:48 am »

Sean,

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'

Thanks!

/Mike

84

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)

#TODO:
# 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?

/Mike

85

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.

HTH!

/Mike

86

Users / Re: URGENT 810 Software RAID failed after power outage

« on: August 26, 2013, 03:01:50 pm »

Your disks appear to be identical sizes, but the number of blocks available on sde are less than the others, which is the cause of the error.  More than likely, your older disks were partitioned with a starting sector of 63, which was the old standard.  The user-land disk partitioning tools had their defaults changed to accommodate the newer disks, where you want to partition align on a different boundary (usually 2048).  change your units to sectors, and see what the starting sector is for your sde vs sdd.  You'll likely have to delete the partition again, and re-create while forcing the starting sector to 63 to match your existing disks.

Hope that helps!

/Mike

87

Users / Re: My thermostat template died

« on: August 25, 2013, 06:08:38 am »

Thanks Thom!

Once I hear back from Sean, and the course of action is determined, I'll update he relevant wiki page to reflect the current situation.  It's pretty out-of-date...

http://wiki.linuxmce.org/index.php/Radio_Thermostat

/Mike

88

Developers / Re: Developing a Weather Plugin, videos

« on: August 25, 2013, 04:54:27 am »

You're overthinking this.

Bad habit from work... I'm busy writing techical architecture design specifications where the overarching reference architecture docs the enterprise types are supposed to have gotten to us, haven't been written yet... Lots o fun 

The different weather APIs return textual data as strings. WE HAVE TO DO A TYPE CONVERSION, ANYWAY as part of the parsing process. (This is something that all you guys who write scripting languages all day, don't have to deal with, with your language magically converting everything).

The REASON that the integer values are here anyway, is precisely for the case you outline below, it's so that you can match things in event criteria. The weather plugin expects BOTH the integer values and the textual values to be returned as part of the event.

As for F to C conversions, this is something that is being decided, e.g. to put the F/C in device data, and have the weather devices read this (The weather plugin does not care, it's just a cubby hole), it's up to the weather devices to do the necessary conversions.

Fair enough... I'll kick the tires on it when I get the ISY driver out in the wild.  My plans are to get the CT-80 driver out in the next couple of weeks, the first cut ISY driver out in late September/early October, and then upgrade to 12.04 to work on a bunch of things, including integrating with the weather plugin for the ISY driver and the CT-80.

Thanks for the excellent summary on how the plugin works.  It'll give me a lot to think about over the next little while.

/Mike

89

Developers / Re: Developing a Weather Plugin, videos

« on: August 24, 2013, 05:08:06 pm »

p.s. yes, the Value parameters are full integers. I see NO point in decimal points for weather values, none. If someone can convince me of a valid reason to use floating point values, I will change this.

Thom,

I've been mulling this over for a bit.  Something to consider is that some other sources of weather/temperature data return floating point data (WeatherBug, Environment Canada, Davis/Oregon weather stations, thermostat API's, 1-Wire, etc).  To take the weather plugin to the next level, we'll need to do something with that data.  That usually means doing comparisons...

Pseudo-event code criteria

Code: [Select]

If $outside_temp < $inside_temp and $outside_temp > 0 then
   Disable A/C unit
   enable external air baffle and whole house fan
End

So, if the weather plugin uses integers, all other drivers will have to do type conversions.  Fahrenheit to Celcius conversions (and vice versa) would also need to be rounded to the nearest integer.  So, that may complicate all the drivers that have to interact with the weather plugin.

Just something to consider...

/Mike

90

Users / Radio Thermostat templates

« on: August 24, 2013, 04:29:12 am »

Sean, Thom,

Since this relates to Sean's template, I thought it might be best to post into this thread.

Sean's Template is #2254, titled 3M50 by Radio Thermostat as the manufacturer.  At some prior point in time, Aviator had also created a template, but it somehow got committed as an unfinished template #2243, manufacturer Filtrete, model 3M50.  There was no code attached to that template.  I bring this up for a couple of reasons.  The first and obvious one is that it could cause confusion if someone were to select it manually, since it wouldn't work.

The second reason is that I'm currently working on a driver for the CT-80 thermostat from Radio Thermostat.  It's the big brother to the CT-30/3M50, and uses the same API (but with extra features supported by the hardware).  For my development work, I've re-purposed the broken template 2243 to avoid conflicting with Sean's template.  My local copy has been renamed CT-30/CT-80 by Radio Thermostat. I'm getting close to finishing up what I want to get done at this point in time, so I'll be looking to commit my code soon, so I can return to doing my ISY driver.  My eventual goal is to implement all of the Radio Thermostat API, but that'll likely take a few phases.  So, I'm looking for some guidance from you gents as to how you'd like me to proceed in the near term...

@Sean,
Since you wrote the 3M driver (and I'm basing parts of mine on yours), I don't want to step on your toes.  Do you want to claim custodianship over the 3M driver?  I can commit my changes against #2243 in a non-conflicting way, and you can decide if you like what you see, and how you'd like to go forward.  Or I can post code into this thread or Trac or ...

@Thom,
I'm presuming that two devices can't have the same range of MAC addresses for DHCP, correct?  Would committing my code into the currently broken 2243 be a problem?

Thanks for your time, gents!

/Mike