My thermostat template died

[WhateverFits]

So, I've got a 3M50 thermostat and I wrote and submitted a template for it. Approved and applied. It looks good. Well, I just had to wipe out my machine (painful story involving our local power company) and all of my little devices around the house are popping up and populating themselves nicely with the DHCP detection. I so love that!

Now, here is the problem. All of the commands exist in the table InfraredGroup_Command with FK_InfraredGroup=6097 and the template exists in DeviceTemplate as PK_DeviceTemplate=2254 but here comes the problem: It has FK_InfraredGroup=6096 and the InfraredGroup table has neither 6096 nor 6097. I do believe that this is originally my fault as I think I made a bad SqlCVS submission when I originally submitted this. In any case, I'm clueless how to proceed. Should I manually create the entry in InfraredGroup and get everything tied together properly and submit that? Or is there a better way?

Thanks!

[tschak909]

Let me dig into the database, and see if the data is there.

-Thom

[tschak909]

Ok, so.. this is what happened.

Due to the usual foreign key slippage (this is why it is IMPERATIVE to keep your database up to date BEFORE and AFTER doing any dev work!), the InfraredGroup got bumped up to 6097, instead of 6096.

The reason you don't see it, is because, LinuxMCE does NOT download the entire IR repository, and therefore, you only have rows in your InfraredGroup, and InfraredGroup_Command tables for devices that you have asked for, either in the case of creating a device template, or when you use Advanced > conifguration > device templates, to look at the IR codes of a device, a script called /usr/pluto/bin/WebDB_GetIR.sh is run, to fetch the relevant IR/GSD codes from the server. This is run from inside the web admin.

I have committed the change from 6096, to 6097, and when you go to re-add the device, it should grab the correct data, now.

-Thom

[WhateverFits]

Thanks so much Thom! I'm still learning all these finer points and now I know much better what to do. Also, I've been watching some of your videos and love them! I've never quite figured out a few different things and now I think I've got them.

[mkbrown69]

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

[tschak909]

You are correct. and if there is a problem, we can resolve it.

-Thom

[mkbrown69]

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

[WhateverFits]

I really don't get my toes stepped on easily so feel free to do whatever you see that works best. Need help with your template? Want to combine them into a single template? Want to combine manufacturer names? Anything I can do to help, just let me know. If the code is very similar, it would be nice to investigate how to combine them but not necessary since they are small drivers.

[mkbrown69]

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

[mkbrown69]

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

[mkbrown69]

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

[tschak909]

This is giving me a serious smile on my face. It's nice when collaboration happens.

-Thom

[mkbrown69]

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

[WhateverFits]

Glad I could help start this going! I was out of town for the past few days and didn't see these posts. Feel free to PM me if you need some help ASAP as I don't read the board every day.