Just because it’s been poorly implemented, with an unexpected/undocumented (like everything) behavior, doesn’t mean it’s not a bug.
Read the description/logic I put into the text to see what I mean.
@mcvflorin, @guessed, @garretwp:
Thanks for all the information / feedback. It was definitely food for thought over the weekend as I thought about the problem.
And @garretwp, just as long as it keeps working with AutHomation, I’ll be happy. 
I use your app every day, and I can’t say enough good things about it! It’s truly an awesome piece of work. (I hope MCV is sending you a truckload of free Vera devices to compensate
Back to the subject at hand…
I think what got me off in the wrong direction with this plugin was seeing that MCV had added their vendor specific (schemas-micasaverde) services to the standard zone thermostat UPnP template. Without documentation to the contrary, MCV’s approach lead me to believe that I could (and actually should) do the same thing to add my vendor specific functionality. That also appears to be the way that UPnP was designed - vendor specific features are just added as new services to the standard UPnP templates, but the UPnP deviceType remains the same. (please correct me if I’ve misunderstood UPnP)
In MiOS, adding the extra services to a standard device doesn’t seem to be an issue. (again, correct me if I’m wrong) But what I didn’t realize was that I couldn’t add a user interface to support these features, without changing the UPnP deviceType to something other than “urn:schemas-upnp-org:device:HVAC_ZoneThermostat:1”.
The problem is that changing the UPnP deviceType seems to break the spirit of UPnP, and in theory at least, would mean that my thermostat wouldn’t be recognized properly by other UPnP control points. (not sure if any other vendors / devices actually support UPnP thermostats, but I’ll assume they do) And although setting the category is a “work around” within the MiOS world, it’s would be a shame to break things on the UPnP side.
With all this in mind, it sounds like a good solution would be to:
- Keep the standard UPnP
- Keep the the additional vendor definitions in
- Change to use the standard Vera thermostat UI (D_HVAC_ZoneThermostat1.json)
- Implement the hold on/off function in a D_BinaryLight1.xml child device of the thermostat (the advantage would be that this function could then be controlled from any Vera client app)
- Add any other vendor specific functions that can’t be mapped to existing UPnP device types to another child device with a custom UI.
The disadvantage would be that the controls for a single thermostat would be spread across a handful of devices in the Vera UI. But, maybe that’s not such a bad thing anyway.
Anyone else have thoughts on this approach to the problem? Pros? cons?
Thanks!
Hugh
I was having a problem and so support took control of my unit. After they finished they restored a previous back and since then I have two big problems. First, the two plug-in thermostats do not get the correct data nor can i control them. All the settings seem to be correct. Also, I can’t seem to access my vera locally - i have a static IP which has not changed yet I can only get in from mios.com - I have no idea what they did when they were in…
EDIT***
Rebooted router and all is well again.
I currently have 2 3M-50 Wifi Thermostats installed and functioning in my home. I have 1 functioning in VeraLite. Is it possible to add an additional thermostat to vera using your app?
Thanks in advance for your assistance - Tammy
I took a look at the logs, and I’m seeing a lot of communication timeouts with your thermostats, which could very likely be the cause of the issue. It’s not uncommon for the 3M-50 to timeout occasionally, but the Vera plugin will automatically retry when this happens. In your case, however, the communication attempt is failing even after 10 retries. (at which point the plugin doesn’t retry again)
The errors look like this in the logs:
02 06/14/12 17:12:28.714 luup_log:5: RTCOA INFO (callThermostatAPI:279) - retrying request, path = /tstat, retry #10 <0x2ca0f680>
01 06/14/12 17:12:28.791 luup_log:12: RTCOA ERROR (doHttpRequest:215) - Received bad HTTP response <0x2ce0f680>
01 06/14/12 17:12:28.791 luup_log:12: RTCOA ERROR (doHttpRequest:216) - URL: http://192.168.1.98/tstat <0x2ce0f680>
01 06/14/12 17:12:28.792 luup_log:12: RTCOA ERROR (doHttpRequest:217) - postData: nil <0x2ce0f680>
01 06/14/12 17:12:28.792 luup_log:12: RTCOA ERROR (doHttpRequest:218) - Status: timeout <0x2ce0f680>
01 06/14/12 17:12:28.793 luup_log:12: RTCOA ERROR (doHttpRequest:219) - Body: nil <0x2ce0f680>
01 06/14/12 17:12:28.793 luup_log:12: RTCOA ERROR (doHttpRequest:220) - Headers: nil <0x2ce0f680>
01 06/14/12 17:12:28.794 luup_log:12: RTCOA ERROR (callThermostatAPI:284) - Received no response (timeout?), path = /tstat <0x2ce0f680>The fact that the thermostat plugin retried communications 10 times and failed means that it’s having a fairly serious communication problem.
Have you had any issues controlling the thermostats through Vera or the cloud? Have you received any notifications from the cloud that it could not communicate with your thermostat?
Does your router have a signal strength meter in the user interface that you can use to see if your router is getting a good signal from the thermostat?
Hugh
[quote=“T.Chess, post:64, topic:170555”]I currently have 2 3M-50 Wifi Thermostats installed and functioning in my home. I have 1 functioning in VeraLite. Is it possible to add an additional thermostat to vera using your app?
Thanks in advance for your assistance - Tammy[/quote]
Tammy,
The plugin supports multiple thermostats, you just have to create additional “instances” of the plugin. It’s just a couple of clicks to do so, and this post has a brief description of how to create the additional instances:
http://forum.micasaverde.com/index.php/topic,9505.msg69836.html#msg69836
FYI,
I’ve released version 2.0 of the plugin that prevents the plugin overriding the user interface for z-wave thermostats. To fix this issue, I had to change the UPnP device type of the plugin from “urn:schemas-upnp-org:device:HVAC_ZoneThermostat:1” to “urn:schemas-hugheaves-com:device:HVAC_ZoneThermostat:1”.
In early testing, I discovered that this change meant that some third party applications no longer recognized the plugin as a thermostat device. Therefore, I created a new feature, enabled by the “CreateGenericDevice” advanced setting, that creates a secondary “urn:schemas-upnp-org:device:HVAC_ZoneThermostat:1” device to control the thermostat. (i.e. if you enable this option, you will end up with two thermostat devices in Vera that control the same thermostat)
If your thermostat devices disappear from your third party application after upgrading to this version, enabling “CreateGenricDevice” will cause them to “reappear”.
Let me know if you run into any problems,
Thanks,
Hugh
Bug 1501 strikes again 8)
Yep, and having to create a second device as a workaround definitely falls into the ugly hack category.
Radio Thermostat 3M-50 - IP changes in Vera 3
I have my Radio Thermostat 3M-50 set statically to 192.168.1.6 in the router but it constantly changes IP addresses in the Vera 3. I change it back and all works perfectly but then it changes to 192.168.1.4 or 192.168.1.5 etc…
Anyone else seen this?
Installed the plugin and have two 3M-50’s. Created the second device set the IP’s and the temperature and other data is updated once. THEN the status display says “RTCOA Wifi Thermostat[19] : Startup Lua Failed” once for each thermostat. Any attempt to control the device gives that it’s not ready.
Looking in the LuaUPNP.log file I see the line “01 06/20/12 2:09:39.280 [[31;1mLuaInterface::CallFunction_Startup-1 dev
ice 19 function thermostatInitialize failed /etc/cmh-ludl/L_RTCOA_Wifi_util.lua
:56: attempt to perform arithmetic on local ‘value’ (a nil value)[[0m <0x2b34f6
80>”
System is VeraLite with current firmware, tstats have firmware 1.04.83
Any suggestions?
[quote=“jcbottorff, post:71, topic:170555”]Installed the plugin and have two 3M-50’s. Created the second device set the IP’s and the temperature and other data is updated once. THEN the status display says “RTCOA Wifi Thermostat[19] : Startup Lua Failed” once for each thermostat. Any attempt to control the device gives that it’s not ready.
Looking in the LuaUPNP.log file I see the line “01 06/20/12 2:09:39.280 [[31;1mLuaInterface::CallFunction_Startup-1 dev
ice 19 function thermostatInitialize failed /etc/cmh-ludl/L_RTCOA_Wifi_util.lua
:56: attempt to perform arithmetic on local ‘value’ (a nil value)[[0m <0x2b34f6
80>”
System is VeraLite with current firmware, tstats have firmware 1.04.83
Any suggestions?[/quote]
Sorry, looks like I broke some variable initialization code in the latest release and I missed it in testing. Until I release a fix, you can get the plugin working by doing the following for each of your thermostats:
- Open the settings for the thermostat, and on the advanced tab, scroll down to the bottom.
- In the “New Service Field”, type urn:hugheaves-com:serviceId:HVAC_RTCOA_Wifi1
- In the “New Variable Field”, type InitialPollDelay
- In the “New Value Field”, type 0
- Click the “Add” button
- Close the settings dialog
- Click the “Save” button in the upper right hand corner of the Vera UI
Hugh
[quote=“hugheaves, post:72, topic:170555”]Sorry, looks like I broke some variable initialization code in the latest release and I missed it in testing. Until I release a fix, you can get the plugin working by doing the following for each of your thermostats:
…[/quote]
Yup, that seems to fix it. Thanks!
Radio Thermostat 3M-50 - IP changes in Vera 3 - using pluginI have my Radio Thermostat 3M-50 set statically to 192.168.1.6 in the router but it constantly changes IP addresses in the Vera 3. I change it back and all works perfectly but then it changes to 192.168.1.4 or 192.168.1.5 etc…
Anyone else seen this?
Still having same issue - any suggestions?
[quote=“TommyRox, post:74, topic:170555”]
Radio Thermostat 3M-50 - IP changes in Vera 3 - using pluginI have my Radio Thermostat 3M-50 set statically to 192.168.1.6 in the router but it constantly changes IP addresses in the Vera 3. I change it back and all works perfectly but then it changes to 192.168.1.4 or 192.168.1.5 etc…
Anyone else seen this?
Still having same issue - any suggestions?[/quote]
TommyRox,
I can’t provide much help on this issue as it seems to be more of a generic Vera 3 networking issue. (and I don’t even own a Vera 3 to try and reproduce it) If nobody else responds, you might have better luck posting a question on the “General” forum, or just opening a support ticket with MiCasaVerde.
Hugh
Thanks for the response Hugh…seems to just the thermostat all other devices I have are holding IP’s
Yeah, that is weird. Makes me think there is something different about the way the thermostats request their IP addresses from Vera.
I did think of another option though. You could bypass Vera’s DHCP / IP assignment entirely, and just configure each thermostat with a static IP using the thermostat itself.
To do so, browse to http://IPOfYourThermostat/advanced.shtml , which is the advanced settings screen for the thermostat. Assuming you want to use 192.168.1.6 for the thermostat, and your Vera is 192.168.1.1, you could use the settings in the attached screenshot.
Note that if you assign 192.168.1.6 (or any other IP, for that matter) to your thermostat using the static configuration, you’ll need to make sure Vera doesn’t try to assign that IP to another device. This means you’ll need to adjust the DHCP / auto allocation range on the Vera so that it doesn’t use that IP.
Hugh
Hugh,
Hope all is well. Your scheduler looks really nice…
Also, the MakeGeneric device type fixed a lot of problems for our code relative to energy management. Thanks.
- I set “GenericDeviceType” to 1, yet the Device Type, and it created the new device. Can we create the original device? My guess is no, and the we must unpin to not show on dashboard, as the parentID of the Generic device is tied to the original device, and therefor deleting the origina device is not possible. Can you confirm?
- “power settings” to show power usage that is reported to the MIOS service would be a great addition.
- A nice to have: on zWave devices there is a green message that shows successful transmission underneath each device. Anyway to do that on your T-Stat…
Thanks
Sean
[quote=“smilligan, post:78, topic:170555”]Hugh,
Hope all is well. Your scheduler looks really nice…
Also, the MakeGeneric device type fixed a lot of problems for our code relative to energy management. Thanks.
Thanks
Sean[/quote]
Hi Sean,
Things are good. It’s nice to have power / AC back after a few days of 100+ degree heat. (I live in Virginia and the recent storms didn’t do much good to the power system here
I didn’t know you were running into some issues, but I’m glad the generic interface has helped. It’s a shame there’s not better documentation on the run-time behavior of MiOS, otherwise I would have made this change much earlier.
Unfortunately, you are correct in that you must retain the original device, even if you enable creation of the “generic” device. (due to the parent / child relationhip, as you mentioned) However, if you don’t want your end users to see the original device, you can completely hide it in the UI by setting the “invisible” attribute on the device. This not only hides the device on the dashboard, but also anywhere else in the UI.
There’s no “point-and-click” way of setting invisible that I’m aware of, but you can do so as follows:
In the UI5 Vera UI, click Apps → Develop Apps → Test Luup Code (Lua). Then paste in the following code, changing “999” to the device ID that you’d like to hide:
luup.attr_set("invisible", "1", 999)Click the “GO” button to apply the changes. (If you have more than one device, you can use multiple lines to set them all at the same time)
Can you provide some more details on this one? Are you talking about setting the power consumption values for the device, or a brand new feature?
According to the MiOS API doc, this is supposed to work based on the job status that’s returned to Vera by the plug-in. However, even though I’m returning the job status, Vera doesn’t appear to show anything in the UI for non-ZWave devices. When I have a minute, I might see if I can get a response from MCV to see if I’m just “doing it wrong”…
I am very new to all this. Just ordered vera lite. I would like to pick up the 3M-50 at home depot.
- Can I use this thermostat with vera lite
- If yes, what else (interface) do I need to make this work with vera. Is it just a software type plug in that I download, or do I need a physical device?
Thanks