Hey man nice work. Its so fucking perfect
But the tado integration is not working in the new ST app can you try to fix this?? That would be more awesome
Hey man nice work. Its so fucking perfect
I Already tried to get this working, however it’s just not possible with the current state of affairs with the new app, We can load the DH and Smartapp in and they work and retrieve the values etc… but there is no way to produce the custom DH controls ATM, Samsungs advice is that is you want to use custom smartapps, then you should use Smartthings Classic. unless something else changes this wont happen
What sounds different?! Because i integrated Nuki Smartlock and this is the only DTH it work on the new ST app. I can show the values and i can control the lock.
ok, but that uses the lock DH . there is currently no way to produce a custom DH which is what is needed for this smartapp, there is no inbuilt DH template that would work
Thanks for this Fuzzy! The presence detectors are also great.
Is it possible to expose the local weather from tado into smartthings so I can trigger automations when its raining etc?
How can I uninstall this app?
From browser doesn’t work (This SmartApp can’t be deleted at this time because it is installed by one or more users (but I am only one user)), from mobile interface doesn’t work (An unexpected error occurred).
Hi, the values not being a number is actually causing an issue in action tiles for me. When the thermostats are set to off manually heatingsetpoint, coolingsetpoit and thermostatsetpoint are set to __ versus 0°c
- temperature: 18.7 C
- humidity: 58.90 %
- heatingSetpoint: – C
- coolingSetpoint: – C
- thermostatSetpoint: – C
- thermostatMode: off
- thermostatFanMode: off
Are there plans to resolve this?
What DH did you use?
I read this as if it’s set to off then there will be no heating set point. It’s turned off. Tado has an inbuilt frost protection that will kick in if temp drops too low.
Just an observation on my part.
I cant set a number as there is no Set Point retrievable by the skill, if use 0 then this is inaccurate as the setpoint is not 0,
I have not used action tiles myself. what are the issues?
If its because you cant press the + or - to change temp, they wouldn’t work anyway even if it was 0 as the resultant range would be outside of the supported thermostat set point range, you would have to set the mode first before setting the temperature.
That makes sense indeed. It’s not so much an issue in actiontile but more for Smartthings in the background. ST is expecting a number. As it doesn’t see one it throws an error. While this does nothing operationally, This is made visible when used in actiontiles. See screenshot.
coolingSetpoint: schema: $ref: Temperature type: NUMBER setter: setCoolingSetpoint heatingSetpoint: schema: $ref: Temperature type: NUMBER setter: setHeatingSetpoint
name: Thermostat Setpointstatus: deprecated attributes: thermostatSetpoint: schema: $ref: Temperature type: NUMBER
may me worth asking @tgauchat what is the best way to work with this? should i pass Null to these properties when they are off, as i believe they are nullable types?
Specifications may be different in the new API vs the “Groovy” (Classic) API. This DTH and the current ActionTiles connector are not using the new API.
So I consider the “classic” Docs to be relevant - though new Docs may be informative and influential. https://docs.smartthings.com/en/latest/capabilities-reference.html
The are called “Attributes” (by SmartThings), not properties (I’m pedantic with regards to specifications).
The data types are annoyingly poorly defined. There is no mention of NULL:
The Number data type is a guideline indicating that a number should be expected, and not a specific type. Device Handlers contain the implementation of what kind of number object is actually returned.
Being pedantic, I do not understand what the fracken nonsense that paragraph is trying to express…
But taken literally, ActionTiles should and does “expect a number”. If we get anything other than a number, then it is non-conforming to expectations, and therefore, an ERROR.
At face value, the most applicable solution is to use:
0 (or any other Number).
ActionTiles requires a Number because it must be a value that can be incremented and decremented.
More practically, however, is how should SmartApps (especially SmartApps with UIs) handle such errors, and/or if there can be an undocumented ad hoc extension to the specifications to allow values outside the domain, such as NULL, no value, or string indicators (e.g., “–”).
In our Thermostat UI, for example, it could be treated as-is, as a display-only indicator ("–"), but a hidden default of 20°C or 68°F for when up/down is tapped; or up/down just disabled per:
But changing the display and behavior of a basic Thermostat is a still a big assumption to make arbitrarily. @Fuzzyligic is saying that when the Thermostat is not in a “valid mode”, that the “setPoint” Commands are invalid. That’s not an ActionTiles issue - this affects every / any SmartApp that uses setPoint. … Sigh - SmartThings needs to provide better specs for… everything. I’ll check the new Docs, but I’m not optimistic. EDIT: They are not any different: https://smartthings.developer.samsung.com/develop/api-ref/capabilities.html#Data-types
@625alex can be equally pedantic as myself about this stuff, but he also understands the need and value of a practical compromise, so… Guess he can chime in next.
@tgauchat, please enlighten me on the difference between attribute and property over some tea tonight.
We have some thermostat related enhancements coming up shortly. Let’s see if we can make it work better.
How was the tea?
Is anyone using this to add 3rd party temperature sensors and control everything via SmartThings? I have it installed but still largely control through Tado currently, if 8 could add 3rd party sensors for better accuracy and still keep the level of control (presence / distance based) I would be really interested.
You can use webCoRE to control your heating.
I have no schedules set up in the Tado app.
It is left in manual control - Active until ended by user.
WebCoRE then sets the temperature set points for the heating.
The heating then turns on and off as per the heating set points that I have set.
This should be updated on github.
Tado (Connect) is displaying correct temperature from thermostat on mobile smartthings application.
However, it is not properly set as decimal type, since ActionTiles can not pickup decimals (only integer) from current temperature sensor. So this needs to be fixed in this app.
Also, it will be good to be able to have sensor/button way, that ActionTiles can send info about setting back to auto - Tado scheduled temperature, and not manual.
I believe this all is related to Tado (connect) smartthings app, that does not expose “the correct” value and datatypes.
Btw, great app