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.
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.
:+ 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.
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.
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.).
I have an older Proliphix and was able to get them to enable the cloud based solution for me (Energy Manager). Its easier to control remotely from there, and i can get graphs/csv files on the temp sensors, run times and errors.
Funny thing though, proliphix home page is now a place that sells laptop locks. Did they go out of business?
Hey there. Welcome to the community.
Funny you say that. I stumbled on to that detail myself not too long ago, and wondered the same thing!
What I know is: A company called Yardi Systems (A company in the property management tools business) bought the Proliphix thermostat products a few years ago. All of the Proliphix thermostats actually still point to UEM.proliphix.com for firmware updates etc, so I’m guessing that Yardi and the the seller made some kind of transition service agreement in which the seller got to keep the domain, but agreed to delegate (or maintain) the UEM subdomain for Yardi continued use.
Do you have an NT series or the IMT series? I can’t believe you got them to re-enable their energy manager application for you! They basically told me I was an ‘just’ end-user and that I should go talk to InTHrMA, which is essentially a similar service (serving end users, not companies) started by a guy to create a better/cheaper version of the energy manager cloud service than Proliphix did.
I’ve subscribed to InThrMa for a number of years, but because of OpenHab, I don’t think I’ll continue to do so since OpenHab allows me to do the same things using the HTTP binding, and the well documented Proliphix REST API. Here is my mobile phone showing a graph of the zone temperature plotted against the hydro supply and return temperature.
Frankly, It’s baffling to me that the Proliphix company was not more of a commercial success, because the Proliphix IMT550 is without question one of the most capable, flexible, feature-laden (e.g. PID function), NON CLOUD SERVICE DEPENDENT thermostats ever made. This is a TEN YEAR OLD device mind you. Name me ANY other piece of ten year old computer technology that can say it’s still among the best in show.
I think its the nt130. I was drooling over this type of thermostat for years, but they were always like $400. I found this one on ebay a couple years ago for like $35.
They told me i was an end user too (i have a feeling that business owners are less likely to whine to them about tech support stuff), but i had an ace in the hole. I’m self employed, selling online with an EIN and i own a rental property. I’m technically a business. They agreed, and i got a password in a couple days.
They still charge for the service though, no? They didn’t in the beginning, then they started charging, then they started turning away people (like me) who wanted to pay them.
Are you planning to integrate Your NT with OpenHAB?
I actually bought an original NT thermostat from Proliphix when it was the only such device available. When I found out that the device didn’t support NTP (to prevent time drift) I sent it back, and waited some months for the up-and-coming IMT series they told me about. Now I’ve had my IMT-550c’s for over a decade.
I have to say, I find it much faster/easier to access and manage my 3 zones using the OpenHab Mobile UI than the thermostat’s WebUI, and better than the Proliphix site and also Better than InThrMa.
My wife NEVER used any of UI’s because they were klunky. She DOES use the OpenHab app and likes it. If I had time, I’d write a dedicated binding now that I’ve learned the API, and the idiosyncrasies of driving the thermostat. Especially if Yardi were still actively developing it.