Home Depot sells the 3M Wifi Filtrete thermostat for $100. There's at least one posting in the forums that suggests someone is taking advantage of the Filtrete's public API using "scripting" (I'm assuming Python). Anyone have any insight into this?

Might also be a good plug-in/feature for Indigo given the availability of that device.

Yep - it's on our radar.

Just posted a proof-of-concept plugin supporting this thermostat. Be sure to read the post before running out and buying one.

That's great, thanks! I have one of these and have been trying to find time to develop a plugin. I'll give it a try when I get home from work.

Terry

The plugin doesn't find my thermostat. It is on the network and controllable via the Radio Therm iPhone app. Furthermore I can issue http commands to the tstat and receive expected messages and control. Enabling debug really doesn't show any additional information, but below is a message from the event log. I've tried rescanning, reloading the plugin, and restarting the mini that Indigo is on all with no change. The error below is from a disable/enable cycle of the plugin.

How are you attempting to discover thermostats on the LAN? FWIW the tstat is 10.0.1.22 and Indigo is at 10.0.1.100. Wireless is provided by an Apple Airport Extreme and Indigo and the airport are both connected to the "core switch", a Cisco Catalyst 3548XL.

Terry

Code: Select all

  Radio Thermostat                   No 3M50 thermostats were found on the network - make sure your thermostat has power, wait several seconds, then select "Rescan for Thermostats" from the plugin's menu

Feb 27, 2012 8:08:01 PM
  Radio Thermostat                No thermostats were discovered on the network - select "Rescan for Thermostats" from the plugin's menu to rescan
  Radio Thermostat Error          Error in plugin execution UiGetValues:

Traceback (most recent call last):
  File "plugin.py", line 545, in getDeviceConfigUiValues
<class 'Boost.Python.ArgumentError'>: Python argument types in
    ServerInfo.log(str)
did not match C++ signature:
    log(CCString message, CCString type='', bool isError=False)

  Radio Thermostat                No thermostats were discovered on the network - select "Rescan for Thermostats" from the plugin's menu to rescan


I'm using their documented discovery protocol - it's a multicast message/reply system. I wonder if for whatever reason your network is blocking multicast for some reason. I have a fairly short timeout on the multicast - I'll increase it some in the next release. Maybe your network is just slower to deal with multicast than mine is. The problem with longer timeouts is that it slows down plugin startup so I want to make it as short as possible.

If you want to try it yourself, change the 2 second timeout in line 98 of plugin.py to 5. It's this line:

Code: Select all

socket.setdefaulttimeout(5)

A typo is causing the stacktrace - I'll get that fixed in the next release. In any event that error has nothing to do with the thermostats not responding to the broadcast.

I will release an updated plugin in the next hour. Just redownload it from the File Library.

jay wrote:I'm using their documented discovery protocol - it's a multicast message/reply system. I wonder if for whatever reason your network is blocking multicast for some reason. I have a fairly short timeout on the multicast - I'll increase it some in the next release. Maybe your network is just slower to deal with multicast than mine is. The problem with longer timeouts is that it slows down plugin startup so I want to make it as short as possible.

Good call, I AM in fact blocking multicast on the switch port that goes to the AP Extreme. That also explains why the iPhone app will discover the thermostat; wireless-to-wireless communications never pass through the Catalyst.

Thanks Jay!
Terry

jay wrote:Just posted a proof-of-concept plugin supporting this thermostat. Be sure to read the post before running out and buying one.

Yikes !

Sounds like a real "quality" product....

I put 3 of these thermostats in this week in my house. I had some c wire issues to sort out (including a not so fun trip to the attic), and some wifi issues (my issues, not the thermostat's) that I had to deal with. The Wifi issues had been bothering me for some time, so this project prompted me to clean up my wifi network.

All 3 are working as expected so far. I'm curious if you guys made note of what firmware version you were testing with initially. Mine all updated to 1.04.77. So far, I'm not seeing some of the problems you mentioned. For instance, manually adjusting the set point doesn't seem to take it out of 'Auto' mode, and everything seems to see that the set point was changed.

I'm just getting started setting them up with your plugin, so maybe some flaws will be exposed after I get a little deeper into it. The plugin found 2 of the 3 thermostats. I haven't figured out yet why it's not seeing the 3rd. I have all 3 feeding temp data to my Zabbix install, so I know it's communicating OK over my network.

I don't see any particular concerns with the quality of the product. Time will tell on that one I guess. It seems to be maturing a little through firmware upgrades. In my opinion, based only on a few days with them so far, it's a good deal for $100, if you're looking for a thermostat that is network connected. This gets me to the point that I can compare temps the thermostats see (in hallways), with temps in our main living areas, and make smarter decisions about what the thermostat set points need to be to balance comfort and energy savings. There are other options, but I liked this price point, knowing I needed 3 of them

You might want to try increasing the timeout as described above to something even larger than 5 seconds - it may just be a bit slower to respond. Also, since it's using multicast, it has to be on the same subnet.

I'm really hoping to see improvements - we'll just have to see what happens as time goes by. Be careful of the Auto settings though - it may appear to be working at first blush but I've found that it's quite unreliable. I believe the last version of the firmware I was testing with was 1.04.73. I got an email from them saying that an upcoming release was going to completely rework how Auto works but that it was rolling out for other thermostats first.

I increased that to 10, then reloaded the plugin. Didn't seem to make a difference. They are all on the same subnet, and the one that is not being discovered is even connected to the same wifi point as one that is discovered. I'll spend more time with it this weekend to see if I can figure out what's going on. It responds promptly from the command line, so I don't think it's a slow response issue. It is interesting, that when I scan for thermostats, it only ever finds one at a time. It has never listed even two at once.

In the long run, I'm not sure how much I'd rely on Auto, if I'm controlling the whole system through Indigo anyway. Although I haven't set anything up yet, it seems like I have enough indoor/outdoor environment data, to be able to decide programmatically if they should be in heat or cool mode, and set them appropriately with actions. If I were letting the thermostats manage themselves, Auto would be a more important mode for me.

I also think it's nice that other communication modules can be plugged in to the unit besides wifi. If I add z-wave or something else down the road, the flexibility of this unit seems like an asset. Thanks for making the proof of concept plugin available.

I compiled the sample discovery program (in C) included with the API, and when I run that, it quickly discovers all 3 of my thermostats. Seems like the network and thermostats themselves are responding appropriately.

The 'try' block to read the response from the multi-cast, is only returning one:

Code: Select all

try:
  self.debugLog("\tGetting service query responses")
  reply = sock.recv(10240)

I pulled just the socket code out to test it, and a 'while True' clause finds all 3 of my thermostats:

Code: Select all

while True:
  print sock.recv(10240)

I'm not very familiar with python, so I'm not sure what the right loop structure should be, especially when dealing with sockets. I'll poke at it some more, but wanted to feed this info back, as it seems to be specific to multi-thermostat situations.

Some progress here. I have now scanned for and found all 3 thermostats. I replaced this code:

Code: Select all

try:
    self.debugLog("\tGetting service query responses")
    reply = sock.recv(10240)
except:
    indigo.server.log("\tNo 3M50 thermostats were found on the network - trying again")
    try:
        reply = sock.recv(10240)
    except:
        indigo.server.log("\tNo 3M50 thermostats were found on the network - make sure your thermostat has power, wait several seconds, then select \"Rescan for Thermostats\" from the plugin's menu")
        socket.setdefaulttimeout(10)
        return deviceList

With this code (I also initialized 'reply'):

Code: Select all

self.debugLog("\tGetting service query responses")
while True:
   try:
       reply += sock.recv(10240)
   except socket.timeout:
       break
      
self.debugLog("\tResponses received.  If you don't see your thermostat, make sure it has power, wait several seconds, then select \"Rescan for Theremostats\" from the plugin's menu")

Yep, that's definitely a problem. I'll fix it in the next release. PITA to not have multiple devices to test with...