I’ve integrated Cielo Breeze Plus via Smarthings. It works really well on Sharptools if I have the mode set on AUTO or COOL, but not if i set it on heat.
Auto or Cool work really well:
If I set the mode to Heat, though, I lose the actual setting and any adjustment just leads to an error:
The attribute values seem to highlight different attributes
Does anyone have any thoughts or have you encountered something similar? The actual Heat setting on the unit seems to work a bit quicker than auto, so i was hoping to use that primarily.
Sharptools tile seems to assume heating and cooling are different setpoints. But for an airconditiong in this case, the airconditiong doesn’t care what mode it is in, you just set the temperature.
If you tap the adjust on the lower left, you will see the menu with 2 temperatures in the quick menu. Adjusting the blue will adjust your AC.
@josh I know this has come up a few times and it correlates with my previous questions about this issue. Is there a possibility to add a airconditiong tile, instead of thermostat, that doesn’t care about heat or cool setpoint and just uses the single one available from the attributes? Maybe selectable by the user?
I’d love to be able to “hide” or “remove” attributes from devices. In the case of the Cielo, it has a bunch of attributes that don’t apply to my AC, but I do need to dig through them and in this case, it adds functionality and actually breaks it by doing so.
Just like my Honeywell thermostat. That only controls heated floors, but there’s a fan mode. My heating system doesn’t have a fan, but it’s there because the thermostat is universal.
If a device reports that it supports a ‘heat’ mode, then it should implement a heatingSetpoint per the spec. If it doesn’t support a ‘heat’ mode, then it should not report ‘heat’ in the supportedThermostatModes.
It sounds like the device is reporting that it supports distinct Heat and Cool modes in addition to an Auto mode. In that case, the device should report a heatingSetpoint and coolingSetpoint attribute, but based on the screenshots above only the coolingSetpoint is available.
We’ve seen this with other non-certified device integrations – the device authors take creative liberties with how they implement the devices and they don’t conform to the platform standards which causes issues.
@Shariff_Attaya can you send a note to support@sharptools.io with the Doc ID so I can take a closer look at the device? As alluded to above, I suspect it’s a flawed integration that would have to be resolved by the manufacturer.
That points to a flawed integration by the manufacturer.
There’s a variety of thermostat capabilities and if the manufacturer doesn’t need those features, then they shouldn’t implement them. On the SharpTools side of things, we only show the fan mode control if the device explicitly reports that it supports fan mode.
And of course, all the device attributes are what SmartThings is reporting… which itself is based on what the manufacturer defines.
So the manufacturer could choose to implement a device profile that excludes the thermostatFanMode capability from your thermostat if they wanted to as many of the standalone Air Conditioner type devices do.
But how does that work for universal devices? The Honeywell and Cielo are designed to work with any heater and AC. They’re not meant for a certain device with certain capabilities.
The same remote for my AC comes with several different ACs, the Cielo simply copies the remote. The manufacturer can’t really help this, without creating special drivers for each and every device. I’d think it would be easier for an end-user to select what you want it to do.
In this case, I believe it doesn’t show an attribute for heat setpoint, only Sharptools does that. Smartthings app only shows “cool temperature”, regardless if it’s set to cooling or heating. And it will correctly set the temperature with this.
That would indicate they’ve done things in a non-standard way by overriding the UI in the SmartThings mobile app device display profiles rather than use the proper capability definitions. It’s not the right way to do things and ultimately causes issues like this.
Depends on the case, but they can set the supportedThermostatModes and supportedFanModes accordingly. For example, they could drop the ‘heat’ mode from devices that don’t support it.
So is the heating set point, directly linked to the heat mode?
I just checked the capabilities for my Cielo AC controller in my Sharptools location and it only shows ThermostatCoolingSetPoint. So my head keeps getting stuck in thinking the thermostat tile is linking the heat mode, to a capability that is not shown by the device.
Would it be possible to let the thermostat tile check if heating set point is present and if it isn’t to only and always display the cooling set point?
Since both of them are visible in the quick menu, I assume there is some coding in the tile that sets the tile control buttons to heat set point when the mode is heat? In our case it just needs to always display cooling set point. In auto mode it displays cooling set point…
I’m sorry, I feel like I keep going on about this, but the logic of why it isn’t working as expected goes over my head.
The heatingSetpoint attribute and the associated setHeatingSetpoint() capability is part of the thermostatHeatingSetpoint capability. (And the cooling variants are associated with appropriately named equivalents).
The modes are defined as part of a separate thermostatMode capability which defines the supportedThermostatModes attribute as well as the currently active thermostatMode
When the mode is explicitly ‘heat’ or ‘cool’, the relevant setHeatingSetpoint() or setCoolingSetpoint() command is used.
I can look into it.
To me, the ‘right’ fix is for the manufacturer to update their integration to make proper use of the capabilities, but I’m open to at least monkey patching things even though the manufacturer should use the distinct capabilities.
Because the device is implemented in a quirky way. As noted above, I believe it’s something that should be corrected by the manufacturer as it can result in quirkiness with other integrations as well.
If it implements a ‘heat’ mode, then it should be using the heat attribute/command/capability listed above… instead these devices have implemented things in a non-standard way and continue to use the ‘cooling’ related features even for heat.
And if they don’t have heat, they shouldn’t define it in the thermostat modes at all.
Keep in mind that the issue @Shariff_Attaya has is slightly different than yours. His device actually has both heating and cooling capabilities. So the proper thing would be for the manufacturer to implement both heating and cooling capabilities so each setpoint could be set accordingly – for the firmware on their physical device, it’s up to them how the internally handle that – but from the capability perspective, it should really map to the appropriate capabilities.
I guess the issue arised because the Cielo copies a remote, an AC remote makes no difference in setting the AC warmer or cooler, it’s only interested in the temperature to set, whatever mode it is in.
I thought about copying the Cielo to a virtual AC, but immediately noticed that doesn’t have a heatsetpoint either, only cooling. I thought making a rule for it, if mode is heat, set cooling point and it would be largely fixed
Is this something all AC’s do?
In that case the thermostat tile settings could maybe have a check the user can mark if it’s an AC to do the monkey coding
