Proliphx IMT550C Ethernet Thermostat

Tags: #<Tag:0x00007f616cd9a718>

I’d like to try to create a binding for the Proliphx IMT550C Ethernet thermostat.

I’m a huge fan of this Proliphix thermostat because not only can it be WIRED with an Ethernet cable (i.e. reliable) but it is totally CLOUDLESS just like OpenHAB. It also has integrated relays and sensors that can be used any number of things, including temperature sensing/averaging motion/occupancy sensing, hvac inhibition, multistage heat/cool support and more. They used to be expensive, but you can get them on ebay for about $100. You can also still buy them new.

I imagine it should be quite straightforward due to the device’s simple REST-ful API (for most of its features). The API is similar to the OLD SCHOOL network thermostat the Proliphix NT20 (which seems to be one of the first network thermostats to be commercially available). As such, support for the thermostat already exists in other platforms like home-assistant.io

I’m brand new to OpenHAB but am passionate about IOT. What’s the best way to start learning to develop a binding, or at least help others utilize this incredible thermostat with OpenHAB? Sending restful commands to the stat is the easy part. What I’m having difficulty finding out the HVAC concepts that exist in OpenHAB. For example, are there already existing methods for, say, group-setback for multi-zone facilities etc., or conversely group-setpoint override to simultaneously toggle multiple zones for the HVAC in a space that was in setback? Does Openhab already have methods for keeping state for ‘occupancy’ by way of other sensors things like wi-fi association, explicit occupancy sensors, etc.?

A push in the right direction for a Noob contributor would be much appreciated.

3 Likes

Welcome to openHAB, then. Nice intro, most people want us to do something for them :slight_smile:
On the organizational part of contributing, see http://docs.openhab.org/appendix/contributing.html.

On HVAC concepts… well.OH is a framework in that it provides access to devices on an abstract layer. There’s different types of items and groups, but essentially this is rather generic and there’s no HVAC specific types.
To speak frankly, there is no such thing as a OH-builtin HVAC concept (nor is there any ‘occupancy’ concept).
In OH, users (and not the core or binding developers) are expected to implement these concepts on their own, typically using the OH rules engine. That is, your heating/cooling main control loop is to happen outside of the binding.
So I would recommend you to go for a two-stage implementation: an OH binding which is to translate/expose device-provided functions of your thermostats (in)to the abstract OH layer, and a set of OH rules to show a sample implementation how a user could make use of the binding.

What is available as part of OH is an active community that encourages and helps in sharing rules, from snippets to full example implementation of concepts.
There is a first set of HVAC control implementations to work with specific devices, but no comprehensive concept (which I believe there never will be as specifically on HVAC, there’s so many devices and concepts that are incompatible with each other).
Same goes for presence (or ‘occupancy’). This is another concept sitting next to HVAC control. There are users that already have implemented this. I’d recommend to assume that there is an item ‘presence’ or eventually an item per-room that gets ‘magically’ set, either by some automatism, or by having the user manually switch it via UI.
Check out the tutorials section and use the search function on this forum to find examples on rules.
Here’s a good thread with a sample implementation, including discussion on presence.

3 Likes

:+ to everything Markus said with one little addition.

Given the device is controlled via a REST API, you can prototype the interaction in OH Rules which might be an easier approach to get things up and running and let you play around with learning how OH works and how you would want to expose the various control points on the thermostat to OH without the additional effort required to get a development environment up and running.

You can see an example of this sort of approach with the Roku API here:

It’s just an option. If you are more comfortable in code definitely start with building a binding.

Hey there, did you ever manage to get the Proliphix working with Openhab. I’m looking at thermostat options, and this is one of them, I really want a wired solution, as apposed to wifi. :slight_smile: thanks much

Not yet, but it’s still on the to do list.

This proliphix project will be bumped up the priority list once I get some lighting control hardware that I like (i.e certain Enocean relays plentiful in Europe but not in 902 MHz for North America). Meanwhile I’ve subscribed to the InThrMa service which gives me a taste of graphing and control features that I can try to copy in OH eventually.
a
I do endorse the Proliphix thermostats, which recently got a another firmware update, meaning the devices are still well-supported by Yardi Systems. Proliphix may be a bad choice for someone troubled by the hassle of running Ethernet cables (and optionally sensor & relay wires) from HVAC/zone panel to the 'stat locations, but for me it was easily worth the effort.

The upsides to Proliphix are great. Personally I use the thermostat sensors input terminals to record hydronic supply and return temperatures (showing me for example that I have a sticky gas valve that needs to be replaced), as well as measuring forced-air discharge and return temperatures, or sense contact closure for failing condensate ejector pumps, or water leaks etc.

The other wired option I know if is www.networkthermostat.com. No personal experience, but where I would look if I didn’t like Proliphix.

So I was tasked with the removal of three Proliphic IMT550C thermostats for a company that was moving out of a tenant space. Long short, they didn’t want them back! I just got done installing one at my house and it is simply over kill. But I will say that if you are technical in the least they are really an easy install and configuration. I have a POE switch and had some time ago installed a drop to the thermostat location in anticipation of the installation of the IMT550C. It took all of 10 minutes from start to finish for the hardware. From factory reset to complete configuration was another 20 minutes. The nice thing about these are the three additional sensor inputs and a pair of relays that can be either wet or dry outputs. Gonna be adding in an exterior temp sensor and a return air duct sensor as well. So far I recommend this thermostat as it is a really nice device with no holes in the features far as I can tell thus far.

Guess I need to start more seriously thinking about implementing OH now for this and my AV/ music control in multiple rooms, and general lighting too. For me though all devices are hard wired ethernet with no WiFi devices so this is one of the few devices that fits the bill. I dont care for the devices like the Nest thermostats as they data mine the hell out of you and who knows what holes they open up.

Not overkill IMO. The perfect amount of kill :-). The IMT is the best thermostat made in my (humble) opinion.

For most end-users Proliphix IMT would actually be considered underkill these days, because it doesn’t automatically include an integrated cloud services application/platform (like you said), thus you have to roll your own connectivity solution OR use a 3rd party service like InThrMa… or Openhab!

Naturally, the lack of cloud integration is more like a bonus feature for many readers of this forum. The biggest issue IMO with the IMT thermostat for most people is the need for an Ethernet drop (plus any sensor wires) to the physical location where the Thermostats exist. Not a huge deal in many cases, but it can be a PITA in somecases (like mine–requires tearing up drywall for the upper floor).

Going forward, I think the ideal communication stack for a thermostat will be something like ZWave. A thermostat needs very little actual bandwidth so Ethernet & WiFi are overkill from speed/cost/power-budget perspective. e.g. The IMT is still a GREAT and modern thermostat but recall the Wi-Fi version was released with 802.11b Wi-Fi!! Not g, not n, not ac, not ax, not even 5ghz. In other words, Wi-Fi as a technology evolves much more quickly than a Thermostat. Today Wi-Fi seems to be a simple/convenient (good) choice, but in the future its age will likely become a liability (again).

I expect that new 700-series Z-Wave (Z-Wave Plus V2) thermostats will become an excellent and durable choice once they begin to see the light of day. I noticed this very capable Z-Wave thermostat utilizing the 700-series chipset at the Z-Wave alliance but no idea when it will be for sale: https://products.z-wavealliance.org/products/3884?selectedFrequencyId=2
700 series Z-Wave appears to be a huge step forward in general (e.g. best-in-class range, lower power, smartstart etc.).