Add combined Temperature/Setpoint for thermostats #6444
Conversation
|
|
|
There is now a warning from Great work for the rest. |
|
Thanks, will fix. Also going to make MQTT keep feeding the old devices if they exist rather than always creating the combined one. Users might be using those; they can delete them and rediscover to convert if they want to. |
d02baaf to
f15f471
Compare
There are some hardware types we call directly into their SetSetpoint() method, and for the rest we call WriteToHardware(). But pTypeRadiator1 is handled differently, and uses a RADIATOR1 struct instead of the _tSetpoint. Where we call WriteToHardware(), we do the right thing and use the RADIATOR1 struct both for that, and for the subsequent PushAndWaitRxMessage() call. But on a hardware type where we call SetSetpoint() directly, we fall through to the PushAndWaitRxMessage() at the very end of the function, which sends the wrong type of message for a pTypeRadiator1. Switch it around just to set a bWriteToHardware flag for hardware that isn't specially handled, then we build either the _tSetpoint or the RADIATOR1 struct, and use the appropriate struct for both.
…ter support - Add pTypeThermostat6 (0x49) with four subtypes: - sTypeThermostat6Temp (0x00): Temperature and setpoint - sTypeThermostat6TempHum (0x01): Temperature, humidity, and setpoint - sTypeThermostat6TempBaro (0x02): Temperature, barometer, and setpoint - sTypeThermostat6TempHumBaro (0x03): Temperature, humidity, barometer, and setpoint - Support for creating virtual Thermostat6 devices via Dummy hardware - Display temperature, setpoint, humidity, humidity status, barometer, and dew point in UI - Graph support for temperature, setpoint, humidity, and barometer logging - Clickable device icons and Set button open setpoint popup (not Evohome dialog) UpdateDevice support: - Parse sValue fields based on subtype (temp;setpoint[;hum;hum_status][;baro]) - Apply temperature and barometer adjustments from database - Support partial updates: empty fields preserve existing database values - Only apply adjustments to newly provided values - Calculate temperature trend when new temperature is provided - Call SetSetPoint() when setpoint field is provided (all hardware types) decode_Thermostat6 support: - Preserve fields not included in update using subtype-specific expected_flags - Query existing values from database for partial updates WebServer support: - Add trend field to JSON API output (0=Unknown, 1=Stable, 2=Rising, 3=Falling) - UI displays up/down arrows for rising/falling temperature trends SetSetPointInt support: - Construct _tThermostat6 messages with setpoint-only updates
Add Alexa discovery, control, and state reporting for pTypeThermostat6 devices (all subtypes: Temp, TempHum, TempBaro, TempHumBaro). Changes: - Discovery: Expose as THERMOSTAT with ThermostatController and TemperatureSensor capabilities - Discovery: Add RangeController for humidity on TempHum/TempHumBaro - SetTargetTemperature: Use SetSetPoint on the combined device - ReportState: Report current temperature, target setpoint, and humidity (for TempHum/TempHumBaro subtypes) All four Thermostat6 subtypes are supported.
- Look for selector switch with " Mode" suffix during discovery - Store modeIdx in cookie and hide mode selector from device list - Add thermostatMode capability configuration (HEAT/OFF) - Report thermostatMode in state reports and after SetTargetTemperature - Handle SetThermostatMode directive for Thermostat6 devices
Instead of creating separate pTypeTEMP and pTypeSetpoint devices for MQTT climate entities, create a single pTypeThermostat6 (sTypeThermostat6Temp or sTypeThermostat6TempHum) device that combines current temperature, setpoint, and optionally humidity in one device. This reduces the number of devices created and provides a better user experience with a single widget showing all values. Backward compatibility: Existing installations with separate pTypeTEMP and pTypeSetpoint devices will continue to use those devices. The code detects old devices on first message (when devType == 0) and uses legacy update paths if they exist. New installations get Thermostat6. Users can delete old devices and rediscover to convert to the combined device. Changes: - handle_auto_discovery_climate: Create Thermostat6 device instead of separate temp/setpoint devices when both current_temperature_topic and temperature_command_topic are present, unless old devices exist - Add humidity support via current_humidity_topic for Thermostat6TempHum - SetSetpoint: Handle Thermostat6 devices for setpoint commands, preserving current temperature and humidity when updating setpoint - sValue format: "temp;setpoint" or "temp;setpoint;humidity;hum_status" - Legacy devices continue to work via standalone handlers at end of function High/low setpoint devices still use pTypeSetpoint as before.
|
Thanks once again for your time and PR!! |
|
@dwmw2 How to use this as a virtual device? |
|
It's creatable like any other virtual devices through the UI. The It's possible that we are missing the ability to edit those options; I'll look into that. Thanks for pointing it out. |
|
For python example see tuk90/RemehaHome-Domoticz#40 |
|
Thanks for the references. And I do not have Evohome, so what does these ribbon colors mean? They are not documented in the evohome wiki as far as I can see. |
|
And the setpoint edit function is probably not working because the device is not in the Utility tab. So either it should also be visible there or copy the Edit setpoint javascript function to the temperature view. |
|
The sValue is something like |
|
For the editing part, please test #6477 Setting the Unit is hosed, because it behaves precisely like the Setpoint, which are also hosed. I don't even know how this is supposed to work. If we set the unit does that mean the incoming numbers for that device are in that unit, and should then be converted to the user's preference for display? Or does it mean not change the actual temperature, but only change how it's displayed to the user? A wild stab in the dark at dwmw2@b4ef5bc but without knowing what it's supposed to do it's hard to fix that part. #6477 at least makes it behave the same as the existing standalone setpoints though, for any sane person who lives in the 21st century and would never use a unit other than °C for any of this stuff :) Happy to take a closer look if there's a clear explanation of what it should be doing. |
We have lovely combined devices for Temp/Hum/Baro, and even for Evohome zones we have a combined setpoint/temp with a lovely graph that shows them together. Let's have the setpoint support for non-Evohome too.
This adds a pTypeThermostat6 type, with subtypes for the different hum/baro combinations. Uses the existing graph support for those in the UI and just has to enable it for the appropriate types, as well as the setpoint control.
Hook it up to Alexa, allow users to make them as virtual sensors, make MQTT 'climate' devices register a single combined Domoticz device where they can instead of the separate setpoint/temp/etc, and we have nice shiny thermostat support...