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 ... 6 7 [8] 9 10 ... 15
Developers / Re: Developing a Weather Plugin, videos
« on: July 19, 2013, 08:23:36 pm »
hmm. always trying to make my life a living hell, hm? ;)
It's a talent...  ;D

Hey, I was just asking...  But if you could pull it off, it would probably make a lot of folks happy.  That way, anyone who had a local device (1-wire, Davis/Oregon Weather station, etc) could still benefit from local, relevant data, plus get a long-range type forecast with other meta-data (Radar/Sat imagery, 5 day forecast, etc).

Otherwise, there's always work-arounds... I've got a basement with lots of gaffers tape available...  ;D



Developers / Re: Developing a Weather Plugin, videos
« on: July 19, 2013, 06:21:51 pm »
Thanks Thom and Posde!

I'm familiar with MythWeather; in my case, it can leverage Environment Canada forecasts, and I have used it in the past.

Would the weather plugin be able to handle an aggregate of weather sources?  Let's say an internet forecast (like from Env. Can), plus real-time (or near real-time) conditions data from a local weather station or something like WeatherBug or WeatherUnderground?



Developers / Re: Developing a Weather Plugin, videos
« on: July 19, 2013, 03:28:49 pm »

Another question, more on the weather side this time.  I'm working on a GSD based driver for the ISY-994i from Universal devices.  It has a "climate module" (a paid for feature), which basically retrieves weather data from Weatherbug and exposes it via it's subscription channel (the means I'm using to integrate it to LMCE).  It works with their irrigation module (another feature module) to handle irrigation systems based on calculated water loss (using a variety of algorithms). It has the following data available to it:

   * Temperature 28.7 °F
   * Temperature High 33 °F
   * Temperature Low 28 °F
   * Feels Like 29 °F
   * Temperature Rate -0.5 °F
   * Humidity 78 %
   * Humidity Rate 3 %/h
   * Pressure 29.86 inches
   * Pressure Rate 0.05 inches/h
   * Dew Point 22 °F
   * Wind Speed 0 mph
   * Wind Average Speed 0 mph
   * Wind Direction NNE
   * Wind Average Direction NNE
   * Gust Speed 0 mph
   * Gust Direction ESE
   * Rain Today 0 inches
   * Light 0 %/h
   * Light Rate 0 %/h
   * Rain Rate 0 inches/h

I've been mulling away thinking about how to integrate it properly.  The thought I had was to create a "Generic Weather Station" template, use that as a child device of the ISY, and push data into it using events.  Would that be a sensible way to proceed, or do you have other thoughts on that?

Thanks for your time!


Climate module:
Irrigation module:

Developers / Development process and tickets
« on: July 19, 2013, 03:17:23 pm »

Process question:  In your example, would the same ticket number used to commit the template initially (thus reserving the template ID), be used when later committing the C++ code?  Or would a second ticket need to be created, because (ideally) the first is closed when the sqlcvs commit is completed?

On a similar note, let's say I had a GSD based template with a working (but not feature complete) driver, which I want to get out into the wild.  Would later commits use the same ticket, or a new one?

Just trying to understand what would work best for the core devs... Thanks! 


OK... so I need to take screenshots of all those shiny new templates I've created because my DB is so out of date I need to update the sucker and then add them back and *then* submit. hmm...

One trick I use is to create a text file for each parameter (i.e. #373), and copy/paste from/into the WebUI.  That way, I can use an editor with Ruby syntax highlighting, and keep a copy aside for back-up purposes.

Hope that helps!


Installation issues / Re: DHCP server not starting - SOLVED
« on: June 03, 2013, 04:53:52 am »
Hi pw44!

Thanks! I can confirm your fix worked on my 10.04 installation.  apt automatically created a usr.sbin.dhcpd3.dpkg-dist in the apparmor directory, because LMCE has modified the standard config to let it read bind's files.  With your fix applied to the config file, here's the diff that LMCE had in it

Code: [Select]
/etc/apparmor.d# diff -u usr.sbin.dhcpd3 usr.sbin.dhcpd3.dpkg-dist
--- usr.sbin.dhcpd3     2013-06-02 22:45:15.825854835 -0400
+++ usr.sbin.dhcpd3.dpkg-dist   2013-05-23 21:38:06.000000000 -0400
@@ -49,7 +49,4 @@
   /var/run/eucalyptus/net/*.pid lrw,
   /var/run/eucalyptus/net/*.leases* lrw,
   /var/run/eucalyptus/net/*.trace lrw,
-  # Let dhcpd read bind's config files
-  /etc/bind/** r,

Thanks for researching the fix!


Users / Re: Joggler orbiter tinkering
« on: March 29, 2013, 03:05:44 pm »

Speaking with my sysadmin hat on, you'll need to create the user joggler first on the core, using the password that you used to create the joggler user on the Joggler device.  A group jogger will be created automatically, based on the standard behavior for useradd. Then chown will work properly.  You may need to play with making the UID's and GID's match on the joggler and the core, if there are going to be shared files over NFS; otherwise you may run into permission issues.  This is based on a quick read of the wiki page; I don't own a joggler.  



Developers / Re: Building Dynamic Orbiters with JSON/AJAX/HTML5
« on: March 28, 2013, 01:54:07 am »
Good day folks!

I just thought I'd point out a home automation controller with a well developed REST and SOAP/WSDL implementation that might provide some food for thought.  It also has an AJAX library specific to it that leverages it's REST/SOAP interfaces, that's used as an embedded controller Web UI (it's main Admin/configuration app is Java based, but will likely be ported to something more HTML5 based in the future)   look under the Official SDK section.

I'm pointing it out because it exposes lighting control, climate control and weather, energy measurement, etc via those REST/SOAP interfaces using XML.  It exposes enough information that various GUI's can determine it's configuration and that of all the child devices, and present a GUI based on that information.  It might give you folks some ideas...



P.S.  that's the device I'm struggling to write a GSD driver for, so if Hari feels like whipping one up for Ago Control, I'd be happy to test.  I can't 'C' my way out of a wet paper bag ;-). I've been playing with Ago a bit on my Pi.  Want to have some free time for hardware hacking so I can play with your Blink-M stuff (once I build a few clones). /M

Developers / Re: Question about GSD...
« on: March 20, 2013, 04:16:52 am »
Hi Thom,

I'm not that IRC saavy/equipped; I should probably add that to my list of things to learn.  I'm also not sure how well it'd work via my iPad since I bounce between Safari, Textastic, and iSSH.  Long story...

Anyway, based on my understanding of the devices' SDK, it needs a channel for the subscription for the SOAP events with a periodic heartbeat response, and commands are sent via the REST interface (so, two connections).  Based on my understanding of the conn_object, it's a single channel implementation, but bi-directional.  This all is with the caveat/disclaimer that I don't play a programmer on TV or the Internet;  I'm a sysadmin who's managed to learn enough about programming to be able to glue various bits and pieces together.

So, I have this little private method which works beautifully, and I can control manually-defined children lights of the device quite nicely.

Code: [Select]
def sendISYcommand(command)

$host = ""
$port = device_.devdata_[69].to_s
res = Net::HTTP.start($host) {|http|
req =
req.basic_auth device_.devdata_[114].to_s, device_.devdata_[115].to_s
response = http.request(req)
xml_data = (response.body)
log("====== / sendISYcommand response body ======")
log("====== sendISYcommand response body / ======")
doc =
s = REXML::XPath.first(doc, "RestResponse/status")
return s.text
I'll worry about http/https via the port data later when the driver is close to completion.  Pulling device data like username & password works well.  I'm just looking to find a means to obtain the IP cleanly for sending these REST commands.  My next project is the conn_object for the subscription, and figure out all the other xml parsing that'll go along with it.

Thanks again for your time and guidance.


Developers / Re: Question about GSD...
« on: March 20, 2013, 02:52:45 am »
Hi Thom!

Why?  To be different, of course!  ;)

Seriously, though, the device in question has a SOAP interface used to subscribe to events emitted by the device, and a REST interface to control it.  I have a basic set of commands working to control it via REST, using a hard-coded variable for the IP.  Before I go writing code to query the device table directly, I'm asking for a less ugly, more Thom-approved method.   ;D

I plan on getting to the subscription stuff next using the conn_object.  It's slow-going teaching myself SOAP, XML parsing, and ruby all at once, plus figuring out the relevant LMCE infrastructure.

Thanks for your time!


Developers / Question about GSD...
« on: March 19, 2013, 03:25:45 am »
Good day folks!

I'm working on a device template using GSD for an IP enabled device, and I was wondering if it's possible to obtain the IP address of the device from device data?  I'm building various URL's for device control, and it would be cleaner to be able to retrieve the IP address from the device's data...

Thanks for your time!


Feature requests & roadmap / Re: Anyone using Ceton's Infinitv4 PCIe?
« on: March 07, 2013, 04:49:50 pm »
It works with MythTV, but not the version in LMCE 10.04 (which is MythTV 0.23).  MythTV 0.25 is minimum requirement, which is still doable on LMCE 10.04.  I believe that MythTV 0.26 requires versions of libraries that are in Ubuntu 12.04, and not the Ubuntu 10.04 that LMCE is based on.




Actually, if you're able to make the C++ 1-wire device template more flexible, to accommodate more of the OWFS supported devices, that may solve the problem.  Right now it's hard-coded to expect a serial type device, which rules out all the network, i2c, and other types of OWFS bus masters <>

In my case, I'd like to be able to use my Raspberry Pi as a networked OWFS control node.  I have some quick and dirty bash scripts running that do owreads into a variable, and then do a messagesend to a manually created device on the core.  Works well enough for proof-of-concept, and I can see the little Thermometer icon on the floor plans.

Just a thought...



Developers / Re: Questions about device table...
« on: January 06, 2013, 03:30:37 pm »

Thanks for the detailed explanations and good advice.  I'll keep it all in mind as I continue to learn about LMCE, and work towards implementing some of the things I'm working on.

Thanks for your time, and all the best for the New Year!


Developers / Questions about device table...
« on: January 03, 2013, 03:23:17 pm »
Happy New Year folks!

As I'm poking around under the hood trying to understand how some things bolt together so I can look at implementing some things I've been thinking about, I've got a few questions about how things work in the device table.

1. What is the purpose of the 'state' field?

2. Is the intention of the 'status' field to show a near-real-time status of the device in question?  Typically, what is responsible for updating that field?  Based on what's shown in the wiki, it's almost as if each device class or plugin is responsible for updating status.

3. As there is a MAC address and an IP address as part of the device's data, would it also not be prudent to have a hostname field as part of the device data?  It would make some aspects of managing the LMCE internal network a lot easier if that data were present in the device table, rather than derived and hard coded in external scripts or elsewhere in the database.  I'm looking at playing around with the 'workstation' aspect, and it would sure make my life easier if the hostname were there. (Note: there is a "#188 computer name" data point, but that seems like a WINS name field to me, but I could be mistaken).

If the core devs don't see an issue with that, I'll put a feature request ticket in for that schema change.  The core devs would be the ones with a full understanding of the possible effects that change would have, so I would think they'd want to handle any change to a core db table like device.

Also, one final question:  I manually changed a MD from a MD template to a workstation template in the Device table, and that seems to work.  Is that data recorded anywhere else besides the device table?

Thanks for your time, and happy home automation for 2013!


Pages: 1 ... 6 7 [8] 9 10 ... 15