I’ve created a plugin that supports the Radio Thermostat 3M-50 thermostat.
The documentation and source code can be found here:
If you have any problems or questions, please post your question in this thread or create an “Issue” on GitHub.
Thanks,
Hugh
I approved the plugin.
Requiring modules in compressed Lua files should work. There are several plugins that make use of this, one of them being the GE Caddx plugin.
mcvflorin,
Thanks for the quick approval.
In regards to the compressed lua file, if the file is included using the tag, MiOS does find the file, but it appears to just concatenate the file with my other LUA source, causing the LUA interpreter to “blow up”. I don’t know much LUA at this point, but I’m guessing that something about directly concatenating the module file to my other source code creates some invalid LUA constructs.
If I attempt to reference the file as a module using the “require” method, I get the following error in the log:
[font=courier]01 02/16/12 10:20:24.207 LuaInterface::StartEngine failed run: 32 [string “–…”]:11: module ‘L_RTCOA_Wifi_dkjson’ not found:
no field package.preload[‘L_RTCOA_Wifi_dkjson’]
no file ‘./L_RTCOA_Wifi_dkjson.lua’
no file ‘/usr/share/lua/L_RTCOA_Wifi_dkjson.lua’
no file ‘/usr/share/lua/L_RTCOA_Wifi_dkjson/init.lua’
no file ‘/usr/lib/lua/L_RTCOA_Wifi_dkjson.lua’
no file ‘/usr/lib/lua/L_RTCOA_Wifi_dkjson/init.lua’
no file ‘/etc/cmh-ludl/L_RTCOA_Wifi_dkjson.lua’
no file ‘/etc/cmh-lu/L_RTCOA_Wifi_dkjson.lua’
no file ‘./L_RTCOA_Wifi_dkjson.so’
no file ‘/usr/lib/lua/L_RTCOA_Wifi_dkjson.so’
no file ‘/usr/lib/lua/loadall.so’[/font]
This error occurs with the following contents in /etc/cmh-ludl:
[font=courier]root@MiOS:/tmp/log/cmh# ls -l /etc/cmh-ludl/
-rw-r–r-- 1 root root 1941 Feb 15 15:33 D_RTCOA_Wifi_ZoneThermostat1.xml.lzo
-rw-r–r-- 1 root root 417 Feb 15 15:33 I_RTCOA_Wifi_ZoneThermostat1.xml.lzo
-rw-r–r-- 1 root root 4219 Feb 15 15:33 L_RTCOA_Wifi_core.lua.lzo
-rw-r–r-- 1 root root 11557 Feb 15 15:33 L_RTCOA_Wifi_dkjson.lua.lzo[/font]
As soon as I manually uncompress “L_RTCOA_Wifi_dkjson.lua.lzo” everything works.
I realize I’m probably doing something stupid in my code, so if you have any suggestions, please let me know!
Thanks,
Hugh
You’re right, in version 1.5.254/1.5.255 the require function wasn’t overloaded yet. I noticed the mistake on the Wiki page, where it was written 1.5.161 instead of 1.5.261, and I fixed it.
I noticed that there is no implementationList tag in your device file. Do you specify the implementation file when you create the device? For the published plugin to work you need to specify the implementation file in the device file. Add this:
<implementationList>
<implementationFile>I_RTCOA_Wifi_ZoneThermostat1.xml</implementationFile>
</implementationList>Finally got this working after a bit of tweaking.
The instruction you give above has a carriage return in it… that took me a second to understand, but I got it eventually. The plugin started after I put in the IP… just that it took about a minute before the status was there. Controls seem to work ok, but at the moment I only have it hooked up to heat. I will play with it a bit more and let you know if there are any issues.
Also, just as a suggestion, it would be very helpful to have a link to this thread from within the “help” link within the plugin settings. It took me quite awhile to find this thread.
bitNine, thanks for giving it a try and glad you got it working. I’m working on a documentation page for the plugin, but in the meantime, I’ll at least fix the carriage return as you suggested.
It is a little slow to do the first update. Version 0.2 (probably out tomorrow) is quite a bit faster as it pulls the thermostat status right at startup instead of waiting for the next “polling period”.
mcvflorin, I’ll add the implementationList to the next release as well. It seems to work without it. I did specify the implementation file in the apps.mois.com metadata, so maybe that’s enough?
Hugh
mcvflorin,
I tried adding the implementationList tag, but get an error that mios can’t find the file. It looks like LuaUPnP is only looking in /etc/cmh-lu and not /etc/cmh-ludl. Am I doing somthing wrong? (i.e. uploading the files to the wrong place?)
02 02/17/12 11:36:25.426JobHandler_LuaUPnP::m_sMissingFile_set /etc/cmh-lu//I_RTCOA_Wifi_ZoneThermostat1.xml
01 02/17/12 11:36:25.426LuImplementation::Parse can’t load /etc/cmh-lu//I_RTCOA_Wifi_ZoneThermostat1.xml
01 02/17/12 11:36:25.426JobHandler_LuaUPnP::ParseAllImplementations failed to parse I_RTCOA_Wifi_ZoneThermostat1.xml
MiOS always searches the file in /etc/cmh-ludl first, and if it doesn’t find it, it searches in /etc/cmh-lu. That’s why the error message says that it cannot find it in /etc/cmh-lu. I would ask to attach the device file to have a look at it, but I won’t be able to do this until Monday when it would probably be too late.
I’ve hat the Vera open all day, monitoring the thermostat. I noticed that just a little bit ago, the temp still showed this morning’s set point, and temperature. It took me turning on the fan, before it reported the change of the temp back to the control panel.
Any way I can troubleshoot why it would have stopped polling the thermostat, to help you out?
bitNine,
Thanks for the offer. I’ve actually improved the reliability of the polling in the 0.4 release (which is pending approval at the moment). I suspect that will fix your problem.
However, if it doesn’t, I’d suggest turning on the detailed logging in the Vera interface. Then, you can search for log messages in the /var/log/LuaUPnP.log messages from the thermostat plug-in. You should see all the poll requests to the thermostat logged (one every 60 seconds or so), and see if there is a place where the messages stop and some sort of error message.
Thanks
Hugh
Yipiee, this worked!! I have the Filterete 3M-50 on my Vera 3 now. Can see the device both on the vera devices page and in the ivera ipad app. Tried remote functions through the ipad through vera, and it works like a charm.
SSHing into the vera, was easy… adding the app to the vera dashboard, and then adding the thermostat ip was easy too.
Thanks so much for the tutorial hugheaves and guessed for redirecting me to this page. You saved me some money by not letting me get another compatible thermostat.
Exorcist,
Glad you got it working. I’ve personally found my Wi-Fi 3M-50’s (I have 3) work really well with Vera, but let me know if you run into any weird issues or have suggestions for improvements.
Thanks,
Hugh
hugheaves,
thank you for this app, I was able to set it up in minutes, it works. One feature request if you don’t mind - would it be possible to add configuration option to switch between Fahrenheit and Celsius or make this plugin respect Vera3 temperature format settings?
Thank you
[quote=“tofinoo, post:13, topic:170555”]hugheaves,
thank you for this app, I was able to set it up in minutes, it works. One feature request if you don’t mind - would it be possible to add configuration option to switch between Fahrenheit and Celsius or make this plugin respect Vera3 temperature format settings?
Thank you[/quote]
Glad it’s working for you. I’m surprised they you’re having problems with temperature units as the thermostat code just passes whatever numeric value it gets from the thermostat in a “unit less” fashion. But, I’ll admit, I haven’t tested anything but Fahrenheit operation at the moment.
So, what’s happening currently with your thermostat / Vera? Is your thermostat set in Celsius mode, but the Vera UI is showing the values in Fahrenheit? If so, it sounds like the thermostat hardware is using (and returning) Fahrenheit values internally regardless of the thermostat display setting. (Which means I would need to do an extra conversion … not hard but a little messy)
Would you mind telling me which model and firmware version of the thermostat you have? (This information will be on the “Advanced” tab of the Vera device configuration page for your thermostat)
When I get home I’ll try my thermostat in Celsius mode and investigate further.
Hugh
[quote=“tofinoo, post:13, topic:170555”]hugheaves,
One feature request if you don’t mind - would it be possible to add configuration option to switch between Fahrenheit and Celsius or make this plugin respect Vera3 temperature format settings?
Thank you[/quote]
I’ve added in Celcius support in the latest (0.7) release. It should automatically configure based on the Vera3 format settings.
Hugh,
Installed your .7 3M50 plugin on UI5/VERA2 host friday.
Installed quickly, painlessly.
Had it operational immediately.
Really like the “hold” override feature… (We have some energy management LUUP code that provide many governor features to keep ‘meddling guests’ from changing the t-stat).
Some questions:
Of particular interest to us, is the ability to override almost all settings/configurations (Except Set Temp within range) to keep people from “mucking” with the T-stats as there is NO way to secure the configuration with “installer PIN”. This is probably not a high priority for you as it is not necessary for any HOME application.
At any rate, Great Job!! Great Plugin!! I look forward to your future releases.
Thanks
Sean
Hugh,
Hopefully you can help me better understand the following scenario. (UI5 1.5.346 VERALite)
However, the 3M50 plugin continues to show in “Cool” mode. But if i change the Hold mode to ON, it will then update at next polling interval to show “Mode=OFF”
Is this expected behavior? (as the T-Stat is not synched to Vera DEVICE state)
Also, for somereason after the above scenario, the Thermostat seems to stop responding to Web page (.shtml) requests, yet still responds to VERA device commands… (Actually i like this as it precludes others from accessing the t-stat via port 80). After making a change to property such as mode or settemp on the Device Plugin, the html requests start working again.
We have the latest firmware on this t-stat.
------------ update 2 hours later ---------------
We are not able to duplicate this issue. Maybe it is “bedding down” of initial plugin install.
It seems maybe it missed the Mode update when TWO events happen at same time in polling period.
We changed the Forced Hold to 1, and updated the polling interval to 30 seconds.
[quote=“smilligan, post:16, topic:170555”]Some questions:
Of particular interest to us, is the ability to override almost all settings/configurations (Except Set Temp within range) to keep people from “mucking” with the T-stats as there is NO way to secure the configuration with “installer PIN”. This is probably not a high priority for you as it is not necessary for any HOME application.[/quote]
Hi Sean, glad you’ve got it working, it’s always nice to have the positive feedback.
In answer to your questions, I haven’t tried using IP:PORT, but it should work. (the IP is just inserted as a string when building URL’s for the device) I’ll test it here and see what happens, and if it doesn’t work I’ll fix it.
Once you’ve installed the plugin, Vera has a nice feature that lets you create as many additional devices as you want for a particular plugin. To create additional devices, click on the “Apps” tab in the UI, and then click on the “title link” for the plugin. (Radio Thermostat Wi-Fi). This will pop-up a window which will allow you to create as many additional instances of the device as you like.
It’s a shame that the 3M-50 doesn’t have some sort of PIN support. The best you can do is probably place the thermostat in “Simple Mode” which locks out most changes. (at least until a “tech savvy” end-user Google’s the instructions for the thermostat 
Many of the system settings on the thermostat (differentials, heat pump recovery settings, etc.) are not exposed via the API, so there’s no way to keep them set to certain values from the plugin. I only have control over heat / cool mode, hold mode, schedule and temperature set points, and not much else. Is there something among these settings that would be useful to you?
Hugh
Hugh,
Thanks for the info… 90% of our VERA installs are UI4 and to create additional devices from same plugin you specify the Device file under a “Add new device heading”
I had no idea that is how to add a new device for existing plugin. Great tidbit of info.
As for the IP:PORT, i had tried this through a wirefall that was configured to support forwarding on that port to the 80 port of private IP of 3m50. Did not have any luck, but it might have been something i was doing wrong. If you are able to do this without issue let me know and i will test again.
Thanks again for a great plugin that was much needed.
Kind Regards
Sean
[quote=“smilligan, post:17, topic:170555”]Hugh,
Hopefully you can help me better understand the following scenario. (UI5 1.5.346 VERALite)
However, the 3M50 plugin continues to show in “Cool” mode. But if i change the Hold mode to ON, it will then update at next polling interval to show “Mode=OFF”
Is this expected behavior? (as the T-Stat is not synched to Vera DEVICE state)
Also, for somereason after the above scenario, the Thermostat seems to stop responding to Web page (.shtml) requests, yet still responds to VERA device commands… (Actually i like this as it precludes others from accessing the t-stat via port 80). After making a change to property such as mode or settemp on the Device Plugin, the html requests start working again.
We have the latest firmware on this t-stat.
------------ update 2 hours later ---------------
We are not able to duplicate this issue. Maybe it is “bedding down” of initial plugin install.
It seems maybe it missed the Mode update when TWO events happen at same time in polling period.
We changed the Forced Hold to 1, and updated the polling interval to 30 seconds.[/quote]
Any changes made on the thermostat should update in Vera no matter how many changes were made. Keep in mind that Vera has to poll the thermostat to discover any changes made at the stat, and by default only does so every 60 seconds. However, making any changes from the Vera UI forces an immediate refresh of the entire thermostat status.
So, if you made a change on the physical thermostat, but Vera had not polled the thermostat yet, and then you made a change through the UI, that could cause the behavior you observed. Does that sound like what could have happened?
As for the .shtml issue, the thermostat web server is very basic, so it can only handle one request at a time and other requests typically timeout while another request is being processed. This could be why the shtml pages were unavailable … if Vera was in the middle of communicating with the thermostat (and it sometimes sends several requests in a row), other requests will fail.
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules