Tado Thermostat Binding

[BenWoodford]

I'm currently in the process of writing up a Tado binding, which is here. Currently it authenticates and pulls data using their not-so-public API.

Looking for some implementation advice though, and some queries on how binding contribution works around here.

A bit of background on how Tado works first:

• It's schedule-based, so you have multiple 'blocks' across the day with different temperatures/modes in. Modes include off, away (overrides the schedule based on when you're not in the house), night, home.
• You can set it to manual and specify a temperature and when it should end (user interaction, next schedule block or after however many minutes).

This translates into the following API-wise

"overlay" which is set if you're using manual mode, which then has info on the setting (target temperature and type, though type is irrelevant for now as I'm only doing the thermostat as I don't have their A/C controller) and termination info (TIMER/MANUAL/TADO_MODE which is timer, user interaction and on next scheduled mode change). You also have a "setting" field at the root of the current thermostat status which specifies the current target temperature for whatever the current mode is (off, away, night, manual or scheduled).

As you can see, not the simplest of Thermostats, you can't just set the temperature and be done with.

Which leads me to a problem. You can't really just set it to manual or just manual target temperature or the termination requirements, you have to have all three.

The way I see it, I could make it so that if you change the temperature, it automatically goes into manual mode and uses configuration data to tell what type of mode to use for terminating manual mode. But then that leaves not much flexibility for the user. Having items for all the specific bits of info and commands seems like it would be awfully messy.

I haven't seen a binding that has to handle so many user-defined fields in one go so far, so some insight would be helpful! I may be completely overthinking this, but I'd like some input from someone with more experience of how things should really be implemented.

In regards to contribution: How does contributing a binding actually work? It's on my repo now, if I were to submit it and have it accepted would it eventually be brought into the main repo manually? And then any further work I do in the main repo?

[kaikreuzer]

Thanks for working on this!

The way I see it, I could make it so that if you change the temperature, it automatically goes into manual mode and uses configuration data to tell what type of mode to use for terminating manual mode.

This sounds to me like a good pragmatic approach for a first integration (not having any better suggestions myself...)

In regards to contribution: How does contributing a binding actually work?

It follows the usual Git Pull Request process, see https://github.com/openhab/openhab2-addons/blob/master/CONTRIBUTING.md#conventions. Yes, once it is merged, you would create follow-up PRs for any further updates.

[watou]

Regarding changing a setpoint when there is a lot more involved, this sounds similar to the Ecobee thermostats. See the examples for one approach to setting a program hold using actions.

[BenWoodford]

@kaikreuzer so PR to submit, PR for changes, got it. Best remove my travis.yml before submission then. Cheers!

@watou from reading, the multiple set-point bit is that you have to set hot and cold at the same time right? So it sets them both whenever one changes.

Could do it that way, and only send it if Manual mode is on (there used to be a "turn off the heating" button as well, but looks like they've tied that into manual mode now thankfully)?

What's the more appropriate thing to do here, let users deal with it themselves using rules, or handle it internally so whenever manual on/off, manual timer, manual temperature and manual power (because you can turn off the heating with manual mode too) are set, it sends all of the values up to Tado?

[watou]

What's the more appropriate thing to do here, let users deal with it themselves using rules, or handle it internally so whenever manual on/off, manual timer, manual temperature and manual power (because you can turn off the heating with manual mode too) are set, it sends all of the values up to Tado?

The semantics of interacting with Tado are no doubt different from Ecobee, Nest, etc., but the important point is to try to avoid embedding assumptions in the binding, instead trying to "respect" the semantics of the Tado API so openHAB users can use it flexibly. For all cases where sending a command to an item/channel performs a simple, clear outcome, that's nicely addressed. But for cases where a set of parameters have to be passed to the Tado API that is more complex than a single command, having an action method called from a rule that lets the user choose what to pass without hardcoding assumptions, might be a better path. Without knowing the Tado API, I can't be more specific, but my experience with other thermostat APIs led me to this opinion. Best of success with your binding!

[BenWoodford]

Honestly, that makes my life so much easier so I have no problem going that route!

[BenWoodford]

Upon realising that if manual isn't set, the API has nothing to provide for manual termination type, temperature and expiry... I have a new question now.

Would the best option here be to have config options for them? So you set default expiry and temperature, then if the user hasn't set up persistence for those values on restart then it'll set them to that (but nothing will happen if manual isn't set to On in the items list).

Or, the binding could just refuse to send anything to the API unless all three (four?) values are set.

[watou]

I would avoid relying on the states of multiple items in order to make a complex call to the Tado API in binding code. I would also try to avoid using static configuration data, which may meet the need in some but not all cases. I still think you might want to have rules and actions that can assemble all the pieces needed, so it's up to the user where the additional information is coming from (item states, constants, persistent values, whatever they want). I've not found anyone unhappy with that approach in the Ecobee binding/action.

[BenWoodford]

So don't send it at all then? Let the user deal with it?

[Qonstrukt]

I'm very interested in this add-on and would like to give it a whirl to be able to give some comments, but I'm unable to get this running by just plopping the source of the add-on into my addons folder. Any chance we can find a prepackaged version somewhere?

I'm not sure my question is wanted in this issue, but maybe it'll invite others to pitch in as well?

[BenWoodford]

I haven't pushed any updates to it in a while (busy times), so the code that's currently up there may not be entirely functional. At its current stage you need to enter a fair bit of Thing configuration to get it rolling, and it'll only pull data not let you change anything.

I'm whip up a doc on how to get it working when I have a moment.

[BenWoodford]

Finally had time to look at this again, here's a build that should hopefully work: https://github.com/BenWoodford/openhab2-addons/releases/tag/v2.0.0-SNAPSHOT

And of course, some documentation

The next bit is the hard bit, so I may leave it for a while and see how things progress, I have a feeling Tado may be changing their API again soon with the TRVs coming out. Maybe I'll sort out that Neato binding I've been wanting to work on.

[TS-Tec]

@BenWoodford thanks for your work until now! Do you plan to go on with your development? I am looking Forward for the update to have also control for Tado.

[BenWoodford]

At some point yeah, life/work is just getting ahead of me so pretty busy lately.

I may take inspiration from Alexa on it and simply allow setting the temperature using whatever is set in Tado as the thing to do when you set the temperature manually. Or perhaps at least let you choose it via OpenHab. Not sure yet.

[e36Alex]

Hello,

i installed the tado-binding (copied it to addons folder an created the .things, .items etc. as discribed in github), but alway get the following error in the openhab.log. Also the tado-thing is not shown in the thing-list in paperui.

ERROR - org.openhab.binding.tado

org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.tado [228]
Unresolved requirement: Import-Package: com.google.gson; version="2.5.0"

at org.eclipse.osgi.container.Module.start(Module.java:434)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1562)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]

2017-03-16 20:25:11.413 [WARN ] [ome.core.thing.internal.ThingManager] - Cannot delegate update '56.00' for item 'Humidity' to handler for channel 'tado:thermostat:home:humidity', because no thing with the UID 'tado:thermostat:home' could be found.

Can you help me to get this binding running?

Thanks a lot!

[jofleck]

Are there any news? I wrote a simple lib for sending commands to the Tado Smart AC control in our office. We developed an OpenHAB binding for internal research purposes. We are going to publish it in the next time. I think it makes no sense to have two different bindings for the Tado AC Control and the thermostat. So if you are going to add the send features to your binding I can add the AC thing to it later.

[e36Alex]

i think there a no news and the development of this binding seems to be stopped. during waiting for an answer here, i found a solotion using the http-binding with some help...

https://community.openhab.org/t/problem-with-tado-binding/25120

for me it works great now, but the functionality in a binding would be a lot better, of course. especially with the possibility to send commands, etc....

so if you are going to publish your solution i could offer my help with testing it, for excample.

[BenWoodford]

Sorry folks, been super busy so my pet projects are pretty much completely on the backburner for now.

[fechy]

Hi there, any chance to revive this binding? Got my new Tado and would be great to have it integrated on OpenHab

[martinvw]

There is a PR for a tado binding, see https://github.com/openhab/openhab2-addons/pull/2368

[fechy]

Sorry, missed that one. Thanks

UPDATE: Sadly, not the one for me. #2368 is about AC and I have Radiator Thermostats

[lowie1]

@BenWoodford I've taken the existing binding and fixed the auth issues (tado has changed the oauth process and added a client secret). I've also added the ability to turn the heating on and off. Are you ok with me creating a new pull request incorporating your code?

[lowie1]

@jofleck sorry just read the whole thread and noticed you have created a binding for the AC controls. Perhaps we can just combine the two?

[e36Alex]

great news @lowie1 ! thanks for that!

i am looking forward for trying it out!

[jofleck]

@lowie1 Sounds great :) The next days I'm on vacation. After this we can do this. @kaikreuzer Do you think its a good solution to have two bindings or do you prefer a single binding for the thermostat and the AC controls? To combine the bindings later might be inconvenient for the users because they have to update their configuration

[kaikreuzer]

@jofleck I assume that both devices are accessed through the Tado cloud service, so they use the very same way of communication, is that correct? In that case, I would agree that it would make sense to combine the two bindings into a single one (similar as it is for Nest, where we also support thermostat/protect/camera within a single binding).

Do you see a chance to merge your work with @BenWoodford's?

[Sascha-L]

@lowie1 Could you please upload your latest compiled version? Yesterday I got my Tado devices and I would like to integrate them in openHAB :-) I not able to compile those addons by myself. Thanks! :)

[Sascha-L]

Any news? :(

[Sascha-L]

push

[mebe1012]

BenWoodford I also started to fork your binding today, thanks a lot for the effort and sharing your binding!

For now I just fixed the binding itself, pointing it to the new Tado API.

But: Im owning the Tado radiator thermostats, not a Tado Thermostat. It also works with the binding from BenWoodford, since the API call is the same.

For the first quick integration this binding is also working fine, but for radiator thermostats I have to implement new channels and so on.

@Sascha-L @fechy @e36Alex You can use https://github.com/mebe1012/openhab2-addons/releases/tag/v2.1.0-SNAPSHOT for now if you want.

@jofleck @lowie1 If we combine our work we would have a kick-ass tado binding, supporting thermostats, AC and radiator thermostats! Would be awesome. ;)

Cheers

[fechy]

@mebe1012 thanks, it works like a charm :)

[mebe1012]

@fechy happy to hear that :)

dont miss to get the latest version (and give feedback? ;) ) here: https://community.openhab.org/t/alpha-tado-binding/35454

[jofleck]

Nice to hear that. I suggest that you can continue with the Thermostat and open a PR(?) (I think it's the more common device). After this I can add the AC feature. The API is except a few details the same. I think now I have more time to contribute :)

[PeterPeterPeterPeterP]

I get only a humidity of e.g. 0.65600000 and not 65,6 (%) Is it possible to change? With [%s %%] in sitemaps, I do not know any solution to make the 65,6% visible.

[mebe1012]

@PeterPeterPeterPeterP thats the value tado itself is delivering. I think its wrong to manipulate the values directly in the binding, because if e.g. tado changes the value format in the future, the binding will be broken.

At least I dont think its best practice?

I also manipulate the value afterwards for displaying it, but Im only using habpanel.

For sitemaps you can do transformation on the item itself, please follow the instructions from the following topic: https://community.openhab.org/t/display-decimal-as-percent/12281

Feel free to PM me if you need help.

[dfrommi]

I was also working on a tado° binding that is now available at the Eclipse Marketplace.

Main features:

• All zone types supported: Heating, AC, Hot Water
• Retrieve mobile device HOME/AWAY status
• Autodiscovery of zones and mobile devices after configuration of credentials
• Changes via items are collected for a few seconds before they are sent to tado°. This allows you to do combined changes from the UI, for example change temperature and mode in one call.
• Fills missing overlay parameters from current zone state, trying to not change them, if compatible with requested change
• Uses termination condition template as defined in the tado° app as fallback

The README is quite extensive and I hope you like it.

[mebe1012]

@dfrommi nice work there. Since you're in a more advanced stage of development I'm thinking about dropping my binding. Are you planning to implement the weather information from the tado API aswell?

Cheers

[dfrommi]

@mebe1012 Thanks a lot.

Currently I don't plan to include weather data because the tado° API doesn't provide humidity and in my opinion, that's essential for home automation (calculation of dewpoints, suggestion when to open the window etc.). And if you need another provider anyways to get humidity, then there's really no point in also using tado° as weather provider.

What weather parameters are you interested in?

[mebe1012]

Ah I thought I also saw the outside humidity via the API, but you're right, it's missing. Therefore it really makes more sense to grab the data somewhere else.

You should promote your binding at https://community.openhab.org

[piejanssens]

@dfrommi What is the procedure for installing it in OH? Excuse my ignorance, it's the first time I'm seeing a binding from the Eclipse Marketplace.

[dfrommi]

@piejanssens It's described here or you just download the JAR file from the marketplace and install it manually.

@mebe1012 Good idea, thanks. Done

[Scoobler]

@dfrommi Thanks for the binding, one quick question, I know I can get each mobile devices HOME/AWAY state, but I can't seem to see a state for the system (HOME/AWAY). I have a switch which is turned on or off based on the system state and several rules which use that in their logic, the switch came from a http call to the unofficial v1 tado API, but would like to replace that. I was working with Github: org.openhab.binding.tado and that had implemented the system mode (HOME/AWAY) - would it be possible to add if it's not already there and I am just missing it?

[dfrommi]

@Scoobler So you're looking for a home-based HOME/AWAY state, right? That's actually easy to get. You add all mobile devices that you want to take into consideration and then create a group.

Group:Switch:OR(ON, OFF) AtHome <motion>
Switch AtHome_Alice (AtHome) { channel="tado:mobiledevice:demo:alice:atHome" }
Switch AtHome_Bob   (AtHome) { channel="tado:mobiledevice:demo:bob:atHome" }

The AtHome ON/OFF state gives you the system HOME/AWAY state, as you call it.

[Scoobler]

@dfrommi I will give that a go, seems like a tidy work around.

From the API I think it is "tadoMode" I was looking for. This would save having to add every member of family who has tado installed on their phone to a group by using a setting that tado already has in the API, although that did need a rule to set the switch state as it would be either HOME/AWAY/MANUAL the API would return.

Thanks for the quick response! I've managed to get things working nicely! Watching eagerly for the rule setting class to start working, hopefully it's something someone can help with soon! :)

[wborn]

This binding is available in openHAB 2.3. See also PR #3279.

[jodibb]

Hey guys, Thanks for binding. I'm using it for my valves and boiler. One think what I miss is "open window" detection. It is possible to integrate it? Thanks