I have DIRTA-HEAT-E-RS1 and it looks like it has a different endpoint. Do you know anything about it?
Unfortunately not. I briefly tried this integration, but didn’t really implement it in my setup.
Unfortunately, my installer says for warranty reasons they can't install a different thermostat. So I'll have to get the Schlueter, even though I've already ordered the Sinope. 
Might try to get this one up and running and see if I can return the Sinope when it gets here.
So reading through the code, it appears that the current state of this driver implements:
- Get state from the thermostat
- Set the thermostat setpoint, but no other features
...which is the same status as the HomeAssistant integration. According to the HA notes, if you send a temperature command, the thermostat goes into "Hold" mode and ignores the schedule until you hit the button on the physical thermostat. Which is fine if your scheduling will be entirely through Hubitat, but less fine if your goal is to turn it on/off based on presence.
Now that everything is installed, I decided to see how far I could get with the Schluter before replacing with the Sinope. I'm glad I did!
The driver from further up in this thread was a good start. I've added some features, including the ability to set vacation mode via off() and to return to the schedule with auto() or heat(). Vacation mode is the closest this has to off, which sets the temp to minimum.
The thermostat appears to automatically return to schedule at midnight when vacation mode is set from the API, so you'll need to re-evaluate each night whether vacation mode should continue.
Off-hand, this appears to cover everything I need and everything I would have expected from the Sinope, so I'll probably return that one and stick with what the installer put in.
My updated driver is at GitHub - MikeBishop/marcre-hubitat-drivers: Hubitat drivers I've created. @user1040, what is your state of support here? I'm happy to make a PR to your repo if you're still supporting it. Otherwise, I'll add it to my stable of Hubitat projects.
@mbishop - Happy to review a PR. When creating I went back and forth a bit about how to handle off(). I ultimately made it a no-op. My main goal was to get the thermostats working cleanly with dashboard tiles. You can't actually turn the heat off, only down to a 41 minimum. I started out with saying if the thermostat was at 41 it was in off, but that got weird since then it could still be in a heating mode even when off.
As best I could understand, auto mode in hubitat terminology means the thermostat can automatically switch between heating and cooling. Since these are heat only, that didn't make sense. The docs for these options weren't super clear, so I modeled off of what I could see from other thermostat drivers.
Doing some direct methods for vacation/schedule is clean. Not sure if that works with your usage scenarios. Everything I could see in hubitat docs for scheduling was about using hubitat to control the schedule. I don't remember samples about using the thermostat schedule.
I bet it's possible to make it stick in vacation for longer. If I remember correctly the RegulationMode property controls how long the thermostat stays in a configuration.
1 Like
Vacation mode can be set for longer from the device. I haven't managed to do it from the web UI, so I couldn't capture the command. But I bet if I set a vacation from the device and query the status, I'll be able to make an educated guess on setting an end date.
I'll move the vacation/schedule switch to new commands and send you a PR.
Edit: I was confused; the API's vacation mode is what the UI calls holding for multiple days. Easily done from the web client, easily coded.
The point about it being strange to be off but also heating is fair. I've reverted it to reflect heat being the only possible state, and custom commands for vacation and follow schedule. If anyone needs the hold-until-time version, that should be easy enough as well.
PR sent.
I just had one of these thermostats installed, but having some trouble understanding how this integration gets configured.
I installed the thermostat driver
I installed the child driver
I configured a device for the thermostat driver and entered my credentials
I configured a device with the child driver, but it's not clear how hubitat would find it?
I'm a bit of a noob with custom code, so a step by step setup walk through would be very helpful.
I have my thermostat fixed with a static address reservation but nowhere does it ask for that info....
(Edit) To be clear, my thermostat is the DITRA-HEAT-E-RS1 variant, which appears to be different in some way. The parent driver is reporting a login error:
dev:632025-04-24 10:45:47.540 AM
info
Event: Status = Local Connection Failed: status code: 401, reason phrase: Unauthorized
dev:632025-04-24 10:45:47.539 AM
error
Error connecting to API for status. groovyx.net.http.HttpResponseException: status code: 401, reason phrase: Unauthorized
dev:632025-04-24 10:45:47.484 AM
trace
No current session avaiable
dev:632025-04-24 10:45:47.483 AM
error
Login failed with code 1
dev:632025-04-24 10:45:47.482 AM
debug
Login raw data = "[Email:, ErrorCode:1, Language:EN, NewAccount:false, RoleType:0, SessionId:]"
I've also started seeing errors. I added some code to catch the 401 and immediately log in again; the login succeeds, but a subsequent query immediately returns a 401 again. Makes me think they don't like people using their API, or maybe they've started looking for particular headers?
Edit: The web client and the mobile app have also stopped working. Now I'm curious whether it's an outage or if they've locked my account out. It appears the web client has shifted to using an OIDC server, so alternatively they may be phasing out the simpler auth endpoint this uses.
Edit again: And this morning it's back to working. Some kind of outage, I guess.
1 Like
I actually missed there is a driver exists, when Alexa+ stopped working with their Skill, I created my own here it is.
1 Like
This worked great! Thank you
