Version: 4.0.4 (Build)
Openhabian on Pi400 4GB RAM and 64GB SD
RadioThermostats 8X CT-80 various firmware revisions
Objective: I’d like to be able to have a simple control for these thermostats that is basically home or away. Both are basically “hold” and a temperature. I’d also like to be able to monitor temperature, setpoint and hold status on each thermostat. Getting information on an average house temperature would be nice.
Status:
I have all the CT-80’s in communication with openHAB and I seem to be able to control all of them individually from the locations page. I got here originally under openHAB 3.4.x then hit a wall, tried home assistant hit a different wall, and came back to try opehHAB 4.x . The model so far is just a main house and locations by room regardless of floor.
The cards (?) on the locations page (?) are displaying badges for temperature and setpoint provided the thermostat is in heat mode. However temperature is displayed in C and Setpoint in F.
First Questions
I don’t understand why the badges didn’t appear automatically. The semantic class and sematic property for Setpoint and Temperature need to be set in order to see these badges for each thermostat. I used the 10K monkeys randomly typing approach to discover this so could someone help explain what’s going on here?
How can I get the setpoint to display and be entered in C?
How do I approach setting up a control anywhere in the UI (Pages?) to set up a home and away configuration on all the thermostats at once.
RTFM’s welcome but I’ve spend a great deal of time reading and searching without getting very far. These seem to be supported objectives. I’m pretty comfortable on the Unix command line so if there are configuration files or GUI screen shots I’m happy to share just use single syllable words. I grok not openHAB at all.
#2 While the thermostats themselves can be configured to display the temperature in C, their json api only works with F values as best as I have been able to determine. This is why the setpoint channel is made to be F in openHAB. It needs to provide F degrees in whole numbers when changing the setpoint.
#3 First configure the binding configuration for each thermostat so that the setpointMode is absolute. Then you will want to create a virtual switch item to indicate home/away status ie: homeAwaySwitch. Using a rule, the switch state can be used to trigger the update of the setpoint for all thermostats simultaneously:
rule "thermostat home away setting"
when
Item homeAwaySwitch received command
then
// ON = home, OFF = away
if (receivedCommand == ON) {
Therm1_Temp.sendCommand(68)
Therm2_Temp.sendCommand(68)
Therm3_Temp.sendCommand(68)
Therm4_Temp.sendCommand(68)
} else {
Therm1_Temp.sendCommand(64)
Therm2_Temp.sendCommand(64)
Therm3_Temp.sendCommand(64)
Therm4_Temp.sendCommand(64)
}
end
Thanks very much for this response. So this largely makes sense to me except I’m unsure of how to do any of these things. My fall back plan is to just write the equivalent rule logic in two curl commands or perhaps one with command line option of temperature but the logic seems the same.
My bigger issues are: How and where ( at this point I care not where) do I create this virtual switch. I had a look at the “Pages” section of the “Overview” page and I can add a Toggle Card that looks right but what then? Then how and where to I enter the rule code and how and where do I connect that rule to the switch or vice versa.
I am a bit surprised by the code snippet in that I figured the abstraction model could message “allThermostats” or “allHouseThermostats” but that might be too advanced for me.
I don’t understand the absolute vs temporary as the thermostat itself doesn’t have this functionality rather it has a setpoint and hold functions. Does absolute just mean that for any temperature command the hold function on the thermostat is triggered “on”? Anyway I know how to do this absolute change by configuring my thermostat “things” so this will reveal itself in time perhaps.
My bigger issues are: How and where ( at this point I care not where) do I create this virtual switch.
To create the virtual switch, go to Items, click the +, Select Add Item, Fill in the Name, Label and set the Type to Switch and press the Create button. Now you have a virtual switch.
I don’t understand the absolute vs temporary as the thermostat itself doesn’t have this functionality rather it has a setpoint and hold functions.
The absolute vs. temporary mode is built into the thermostat and usage described in the binding documentation. Once the thermostat is in absolute mode, it will maintain the setpoint that you give it forever/permanent hold and ignore the schedule that is saved in the thermostat.
There are advanced concepts for items like ‘groups’ and ‘follow’ that would allow the setpoint for one thermostat to automatically apply to the others, but that is an exercise for a later time. I felt the rule example would give you the most flexibility for now.
This will be a rule and an Item or Items that represent your home/away status.
Presumably then these will have a setpoint with the target temp and perhaps a current temperature sensor. Maybe an ON/OFF switch?
Groups are useful for this sort of thing.
That’s often the hardest part. What Channels/Items are available?
Note that the model is pretty much only useful for three things right now:\
Creating the Overview Page
Providing the information that HABot add-on requires to work
You can get the Equipment and Location that an Item belongs to in a rule.
We can fix that but need to know your current locale settings (in MainUI Settings → Regional Settings) as well as the configuration of your Items.
The badges are based on the types of the Items in a location and how those Items are semantically tagged. That’s what drives all of the Overview pages. Items tagged with “Setpoint” and “Temperature” are going to show up in the badge as a setpoint. And there really is no other combination of tags that makes sense for a thermostat setpoint.
Any Item that is tagged as a “Measurement” “Temperature” is going to show up on the badge as the measured temperature. If there is more than one such Item I believe the average is shown on the badge. I’m not sure of that though. And again, it doesn’t really make a whole lot of sense to use any other combo of tags for a temperature sensor. Maybe “Status” but “Measurement” is more close to what the Item represents.
I remember seeing an outline of how the badges are derived but can’t seem to find it at the moment.
We’ll need to know the Thing/Channel that this Item is linked to as well as how the Item is configured to be certain.°
In all likelihood you just need to define the Item as a Number:Temperature and set the unit metadata on that Item with °C as the value. Depending on your locale settings, it should already be converting the °F to °C which makes me thing perhaps you’ve just defined the Item as a Number without units.
If you only care about how the Item is displayed and don’t care what the Item’s state is (not a good idea but to each their own) you can use the State Description metadata on the Item to define the pattern to something like *.1f °C. That will convert the state of the Item to °C and round to the nearest decimal place, assuming the Item is a Number:Temperature.
We need more details. How do you envision your home/away status being controlled? What needs to happen when transitioning from home to away and back again?
Absolutely but we need more details to advise.
Just about every entity in openHAB will have a “Code” tab on it’s page in MainUI. When sharing what you’ve done it’s best for use if you copy the YAML you find there and paste it into a reply using code fences.
```
code goes here
```
To get to an Item’s “Code” tab you need to click to edit the Item. The Item’s code tab doesn’t show Item metadata. Each metadata has its own “Code” tab.
Rules, Things, etc. will have the code tab without needing any click throughs.
???
This makes no sense to me. Units are separately configurable and calculated. Even if the binding only supports °F, setting the unit metadata on a Number:Temperature Item will cause that value to be converted to °C and back automatically. What binding is involved here?
You can put all the thermostats into a Group:Number:Temperature and then the logic can become a one liner:
ThermGroup.sendCommand(if(receivedCommand == ON) then '68 °F' else '64 °F'))
This assumes Number:Temperature Items and using °F.
Everything in OH revolves around Items.
Go to Settings → Items → blue + icon
That will create a new Item.
You can use that Item like any other.
You’d use that toggle card with this newly created Item.
@mlobstein is showing Rules DSL in a .rules file that would be placed in /etc/openhab/rules. I recommend managed configuration and if you are not great with programming using Blockly.
Go to Settings → Rules → Blue + icon to create a new rule.
The “when” will be an Item trigger on the Item you created above. The “then” would be a Script Action. choose Blockly and you can build up the code from there.
Definitely review/rereview the Getting Started Tutorial’s rules pages for details.
All rules in OH are event driven. It’s connected to that Item through the Rule trigger.
See the Concepts: rules page for details on the parts of a rule and what they do.
Not unless you set it up that way. The semantic model is not that smart. You’d have to set that up yourself either through a Group or a rule.
Well that’s why I’m back to openHAB it just discovered my radiothermostats automagically and seems to be able to interact with them correctly with very little effort… just a few isms.
I believe my regional settings are correct. I sort of think in C lately this seems to be a quirk of the radiothermostat binding as are the badge behaviours. Indeed the raw json data you send to the thermostats is in F period but the physical display on the thermostat and inputs can be in C. In openHAB out of the box with this binding inputs are in F.
With these settings, when given no other configuration, a Number:Temperature Item will default to degrees C. Plain Number Items don’t have units so those will use whatever the binding publishes.
Well indeed it is. I’ve read through the API dozens of times and never noticed that until now. I was aware of the binding setting but could not relate to what it meant on the physical device since I was only conscious of the hold function which is similar in functionality.
Thanks again guys @mlobstein and @rlkoshak. Homework continues sheesh I never expected to find a switch in “items”. I need to re-read the intro material again… and again. Small dim lights are coming on :-).
That’s often the hardest part. What Channels/Items are available?