Plugin: Venstar ColorTouch Wi-Fi Thermostats (REBORN!)

Plugins & Plugin Development General Plugin Discussion
#1

This plugin is an interface for Venstar ColorTouch Wi-Fi thermostats (T7850, T7900, etc.). At the request of another community user, I’ve implemented this plugin as a replacement for a similar plugin that was withdrawn by its author last year (this plugin is an original work and uses none of the code of the prior plugin).

The Github repository for this project is here: GitHub - toggledbits/VenstarColorTouch: Vera/MiOS plugin to integrate Venstar ColorTouch thermostats

Please discuss, ask questions, and report problems in this thread. Bug reports may also be made using the Github repository’s Issues section.

REVISION HISTORY

2019-05-19: Version 1.4 has been released. This version addresses in issue in recognizing thermostat capabilities when the thermostat does not support “auto” mode, or if that mode has been disabled via the thermostat’s interface.

2019-03-03: Version 1.3.

2018-11-11: Version 1.2 has been submitted for approval to the Vera Plugin Marketplace. This version fixes omitted declarations for two services used that sometimes caused problems setting temperatures on the UI.

2018-08-19: Version 1.0. This version is the initial public release and a starting point. There are plenty of opportunities for additional features, and some things exposed in Venstar’s API haven’t made it to the UI yet, but as always I’m always eager to hear your ideas.

#2

This is great! Thanks for creating. A few minor bugs and a request:

Bugs:
-You aren’t able to toggle the fan between “on” and “auto” in a scene

Request: It would be great to be able to set the home/away status from the plugin and in a scene. I see that you have the current state in a variable, but I don’t see a button to change this mode.

#3

To fix this, you can download one or both of the files linked below, and upload them (via Apps > Develop apps > Luup files to your Vera:

If your units are Celsius: https://raw.githubusercontent.com/toggledbits/VenstarColorTouch/stable/D_VenstarColorTouchThermostat1_C.json

If your units are Fahrentheit: https://raw.githubusercontent.com/toggledbits/VenstarColorTouch/stable/D_VenstarColorTouchThermostat1_F.json

Right-click and choose “Save link as…” or your browser’s equivalent to download. Make sure you don’t change the filename in any way when saving or uploading.

This fix will be in upcoming release 1.1

#4

You can set the Home/Away status using scene Lua:

luup.call_action( "urn:toggledbits-com:serviceId:VenstarColorTouchThermostat1", "SetHomeAway", { newHomeAwayState=mmmm }, thermostat_dev_num ) return true -- make sure scene Lua returns true

The home/away mode (mmmm) in the fragment above should be [tt]0[/tt] or [tt]“home”[/tt] for home, or [tt]1[/tt] or [tt]“away”[/tt] for away.

I’ve added Github issue #3 to add a UI for it.

#5

Thanks rigpapa for releasing this.
The version that you sent me has only ever suffered from a router dropout.
That is outside the scope of the PI so I believe and is router related.
Otherwise it’s worked without a hitch and done what it is designed for.

Many thanks for the time you put into this.

#6

To fix this, you can download one or both of the files linked below, and upload them (via Apps > Develop apps > Luup files to your Vera:[/quote]

Thanks for updating this, and it works as expected. And thank you for the luup code to change home/away status until the plugin can be updated. Now I just need to update my scenes to use the plug-in instead of doing wget calls with the API codes!

#7

Version 1.2 has been submitted to Vera for approval, expected tomorrow (Mon 12-Nov-2018). This version formalizes the fix for temperature setting previously released in the stable branch (adds omitted service declarations).

#8

Thanks for the plugin. Needed a new thermostat that supported AUX heat so retired my old Z-wave one. This plugin helped me pick a replacement. Got a Venstar T7900.
Set it up in Vera and the temp icons are clipped unless I hover over them. See attached screen clip.

Not a huge deal, but figured you would like to know.

#9

That icon clipping occured with the last Vera FW upgrade FWIW.Not sure what the Devs changed but as you said it’s not a deal breaker

#10

Yup, it was a small CSS change they made, I pointed them to it. They promised a fix, but that was before the acquisition (that’s how long it has been). Unfortunately, no ETA now that engineering direction has changed.

#11

Hello,

I think I looked through the API and did not see it, but can you confirm that there is no way to engage emergency heating programmatically?

Thanks,
Roger

#12

[quote=“RogerO, post:11, topic:199666”]Hello,

I think I looked through the API and did not see it, but can you confirm that there is no way to engage emergency heating programmatically?

Thanks,
Roger[/quote]

While I’m poking around the API looking for anything related to emergency heat, clarify/confirm for me that when you say “programmatically”, you mean something the plugin could do to put it in that mode/turn it on?

#13

[quote=“rigpapa, post:12, topic:199666”][quote=“RogerO, post:11, topic:199666”]Hello,

I think I looked through the API and did not see it, but can you confirm that there is no way to engage emergency heating programmatically?

Thanks,
Roger[/quote]

While I’m poking around the API looking for anything related to emergency heat, clarify/confirm for me that when you say “programmatically”, you mean something the plugin could do to put it in that mode/turn it on?[/quote]

Eh, I think it’s a non-starter. In both the PDF I have for v3 API and the online guide, the word “emergency” isn’t to be found once.

The troubleshooting docs do make this reference, however, if it’s of any use to you otherwise: "Most of our heat pump compatible thermostats will allow Emergency Heat to be activated by pressing the FAN and the UP buttons. This will display ?EH? in the cool setpoint and lock out all modes except the OFF and HEAT modes. "

#14

Yes, by programmatically I meant through a scene. I sent support an email asking why this is not an option. Will see what they way.

Thanks,
Roger

#15

I’d like to upgrade my Honeywell non-zwave thermostat that has a humidifier control to a z-wave compatible thermostat with humidifier control to use with a VeraPlus. From this thread, it appears like the Venstar ColorTouch T8900 Thermostat with WiFi and Humidity Control will fit these requirements. Before purchasing, i’d like to understand if anyone else has done something similar and what their experiences are. Thanks in advance for the input.

#16

Set-point doesn’t display in VERA iOS app. Is there a fix for this. See image.

IMG_3822
IMG_38221125×2436 239 KB

#17

Thermostat support on Vera is loaded with issues. Plugin support on the mobile apps is loaded with issues. This is the intersection of two really troublesome spots in the Vera ecosystem. I’ll spend a bit of time poking at this today, but there may not be an answer for this until they get these areas straightened out. It’s been an issue for a while.

#18

Greetings @rigpapa,

I am a VL owner for many years and recently purchased a VP as well as a Venstar T7850 thermostat. I have not yet migrated my z-wave devices to the VP. Instead, I have been testing a few new devices with the latest firmware - 7.29 first, including this 'stat with your Venstar plugin.

However, I have been unable to make the VP and plugin communicate with 'stat. So, looking for your advice, etc.

The thermostat is (obviously) wireless connected to my IoT network, while the VP is wired to my HAC(Home Automation and Control) network. Each network is gateway’d on a L7 firewall. Because of communication issues between the devices, I have created an explicit-permit rule to allow all L3+ comms from the VP to the 'stat. As these devices are IP’d on separate L3 boundaries, I have added the 'stat’s IP to the plugin, then clicked the “Discover IP” button.

My FW logs show a single ping session(containing 3 ping requests/responses), but nothing more. It seems that the plugin is not attempting anything further than the ping. I have manually ran a ping from the VP ssh shell to the 'stat with a successful response.

Next I tail -f the /var/log/cmh/LuaUPnP.log file during the IP discover looking for clues. During the initial discovery I see:

08      09/10/19 23:50:50.140   JobHandler_LuaUPnP::HandleActionRequest device: 18 service: urn:toggledbits-com:serviceId:VenstarColorTouchInterface1 action: DiscoverIP <0x746c2520>
08      09/10/19 23:50:50.141   JobHandler_LuaUPnP::HandleActionRequest argument DeviceNum=18 <0x746c2520>
08      09/10/19 23:50:50.141   JobHandler_LuaUPnP::HandleActionRequest argument serviceId=urn:toggledbits-com:serviceId:VenstarColorTouchInterface1 <0x746c2520>
08      09/10/19 23:50:50.141   JobHandler_LuaUPnP::HandleActionRequest argument action=DiscoverIP <0x746c2520>
08      09/10/19 23:50:50.141   JobHandler_LuaUPnP::HandleActionRequest argument IPAddress=192.168.3.60 <0x746c2520>
50      09/10/19 23:50:50.143   luup_log:18: VenstarColorTouchInterface: Searching for 192.168.3.60 <0x77f52320>
06      09/10/19 23:50:50.143   Device_Variable::m_szValue_set device: 18 service: urn:toggledbits-com:serviceId:VenstarColorTouchInterface1 variable: DisplayStatus was: Discovery finished. No new devices. now: Searching for 192.168.3.60 #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x77f52320>

Then I see:

01      09/10/19 23:50:52.178   luup_log:18: VenstarColorTouchInterface: **Unable to locate MAC for "192.168.3.60"**. Device may be unreachable/offline. <0x77f52320>
50      09/10/19 23:50:52.178   luup_log:18: VenstarColorTouchInterface: 192.168.3.60 unreachable <0x77f52320>
06      09/10/19 23:50:52.179   Device_Variable::m_szValue_set device: 18 service: urn:toggledbits-com:serviceId:VenstarColorTouchInterface1 variable: DisplayStatus was: Searching for 192.168.3.60 now: 192.168.3.60 unreachable #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x77f52320>
04      09/10/19 23:50:52.180   <Job ID="15" Name="" Device="18" Created="2019-09-10 23:50:50" Started="2019-09-10 23:50:50" Completed="2019-09-10 23:50:52" Duration="2.37560000" Runtime="2.37184000" Status="Successful" LastNote=""/> <0x77f52320>

I am no programmer…but, I wonder why it is attempting to identify the MAC address during an IP discover? Perhaps I am just misunderstanding the plugins programming. Any thoughts as to what the issue may be? Or anything further that I can provide to help debug?

Kind Regards
Mike

#19

Also, I should have mentioned that the local API has been enabled on the 'stat and verified by browsing from another device. Then also ran a curl from the VP to verify full L3-L7 comms were working as expected:

root@MiOS_50022618:~#
root@MiOS_50022618:~#
root@MiOS_50022618:~# curl http://192.168.3.60
{"api_ver":9,"type":"residential","model":"COLORTOUCH","firmware":"6.71"}root@MiOS_50022618:~#
root@MiOS_50022618:~#
root@MiOS_50022618:~#

-Mike

#20

There are a few things at work here.

The plugin uses Vera’s internal serial/socket handling. This subsystem assumes that the target may be on a DHCP dynamic address and can end up on a different IP address at any time. To deal with that, it stores the MAC address of the device, and when unable to connect to the device, it searches for the device by MAC to find its new assigned address and re-establish the connection. This is automatic, but it requires the MAC address. It also implies that the MAC address can be used later to find the IP address, and the way in which that works basically assumes that the device is on the same network segment as the Vera. Putting the device on a reservation or static address doesn’t alter this behavior.

The SSDP discovery uses multicasts that your filters may not allow, so that could also be an issue. On a “real” SSDP discovery (not IP discovery), the MAC address is provided in the response, so the Vera and plugin don’t need to use any restrictive gyrations to find it.

So, you need to get your firewall to allow the SSDP discovery. Those packets are sent to multicast address 239.255.255.250 UDP port 1900, and the replies need to be allowed as well (to the multicast discovery range and port need to be allowed in both directions). Then you can use standard discovery and the thermostat will tell the plugin/Vera what its MAC address is explicitly.