OH 4.2.2 refuses to communicate with Heatit thermostats

[apella12 (Bob Eckhoff)]

@satman

The following quote says it works with just a Number, right?

@apella12

MainThermostat14_SetpointHeating.sendCommand(65)

I have that item configured as Number:Temperature, so it knows commands are of that type. The main issues (IMO and at least in DSL) in working with Number:Temperature is to ensure var are defined with the quantity or else they get referenced to absolute zero (Kelvin or Rankin).

[rlkoshak (Rich Koshak)]

@satman

Does this mean that the freedom to define an Item Type basically disappeared completely with OH4? I’m not sure I fully understand the consequences her

Again, quite the opposite.

What you define the Item to be in OH 4 is now and forever will be what that item is. If you define it as a Number, it will never suddenly become a Number: Temperature because some binding sent it a value with units.

You now have full control over your Items. That’s what changed in OH 4. In OH 3 you’re Item type could change out from under you. No longer is that possible.

@satman

added |°C in the if-part, but how can I make tempBa2 a QuantityType in the Command-part?

Adding a unit that way only works for constants. When getting the state of the Item you need to use

(MyItem.state as QuantityType<Temperature>)

That tells Rules DSL the role of the state.

@satman

addition I would have to redefine my items to Number:Temperature.

This is true.

@apella12

The main issues (IMO and at least in DSL) in working with Number:Temperature is to ensure var are defined with the quantity or else they get referenced to absolute zero (Kelvin or Rankin).

Most of that you’re if stuff has been fixed IIRC. if you do nothing to change it, the values and units you get from the state of the Item will be in the unit of the Item. If you’ve not set the unit metadata you should get the system default with is C or F based on whether you are using SI or Imperial units in the regional settings.

Some calculations will convert the operands to K before the operation and then convert back to the unit, but that should be transparent to the user.

Temperature is weird because unlike all the other units, 0 isn’t 0 in all the different units so some calculations are more complicated.

A great deal of work had been done on this since OH 4.0 release.

[satman (Bjorn Narheim)]

Thanks for a very interesting an enlightening discussion.
I feel, however, that the bottom line question is still open:
How do I now modify the Setpoint Command to send tempBa2 as a QuantityType?
Nothing will work until I can properly execute a command.

[rlkoshak (Rich Koshak)]

All your hard coded temperatures (i.e. everything in arrayBa2) needs to be defined as a temperature.

val arrayBa2 = newArrayList(20.1|°C, 31.1|°C, 30.1|°C, 29.1|°C, 28.1|°C, 25.1|°C)

Then tempBa2 we’ll have units for the comparison as well as sending the command.

Or you can send the command as a String with the unit.

MyItem.sendCommand("66 °C")

Or, if your item has the unit metadata, any command sent to it without units will have that unit appended. So if you’ve set the unit metadata to “°C” and if you command with a plane number, that number will automatically have |°C appended to it.

[satman (Bjorn Narheim)]

Thanks !!! Now we’re talking.
I know I’ve stretched your patience a fair bit already, but could you please check if my updated code looks good.

var temp = MS6_Ga_temperature.state as QuantyType<Temperature>
var newCase = 0

// Temp windows             Vaca     <-10     -10-0    0-10     10-20    >+20
// newCase                  0        1        2        3        4        5
val arrayBa2 = newArrayList(20.1|°C, 31.1|°C, 30.1|°C, 29.1|°C, 28.1|°C, 25.1|°C)

  if( vacation ) { ... }

  else {
    if((temp <= -10.0|°C) && (newCase != 1)) { newCase = 1 }
    else if((temp > -10.0|°C) && (temp <= 0.0|°C) && (newCase != 2)) { newCase = 2 }
    else if((temp > 0.0|°C) && (temp <= 10.0|°C) && (newCase != 3)) { newCase = 3 }
    else if((temp > 10.0|°C) && (temp <= 20.0|°C) && (newCase != 4)) { newCase = 4 }
    else if(temp > 20.0|°C && (newCase != 5))  { newCase = 5 }
  }

  var tempBa2 = arrayBa2.get(newCase)

  if(SF_Bath_Setpoint.state as QuantityType<Temperature> != tempBa2)      { SF_Bath_Setpoint.sendCommand(tempBa2) }

Again, thanks a million for your patience. I’ve learned a lot.

[rlkoshak (Rich Koshak)]

If it works it’s good code. I don’t see anything out of place.

[apella12 (Bob Eckhoff)]

@satman

var temp = MS6_Ga_temperature.state as QuantyType<Temperature>

I’m surprised this isn’t causing a problem as it should be Quantity, not Quanty, but whatever. I agree working is good.

[satman (Bjorn Narheim)]

Hi,
Good thing: You are absolutely right.
Sad thing:

  if(SF_Bath_Setpoint.state as QuantityType<Temperature> != tempBa2)      { SF_Bath_Setpoint.sendCommand(tempBa2) }
   Ambiguous feature call.
The extension methods
	sendCommand(Item, Number) in BusEvent and
	sendCommand(Item, Command) in BusEvent
both match.; line 50, column 1497, length 11

and I have no clue what this means.

[rlkoshak (Rich Koshak)]

You’ve encountered one of the main reasons I recommend against the use of Rules DSL for new rules development. Rules DSL has a half broken typeing system. It punishes you if you try to overspecify the types and then it breaks when you fail to specify the type in other places. Rules DSL no longer has any advantages over the other rules languages and has a lot of significant limitations.

In this case, QuantityType is both a Number and a Command. The Number Item has two sendCommand methods, one that takes a Number and one that takes a Command. Because QuantityType is both, Rules DSL can’t figure out which sendCommand method to use. So you have to tell it. You have three options:

SF_Bath_Setpoint.sendCommand(tempBa2 as Number)
SF_Bath_Setpoint.sendCommand(tempBa2 as Command)
SF_Bath_Setpoint.sendCommand(tempBa2.toString)

[satman (Bjorn Narheim)]

Hi,
I’ve spent an insane number of hours trying to just send a value to a thermostat in OH4. Right now it feels impossible, so I give up.

@rlkoshak

Given all of this, the Zwave binding is in error here and should have an issue filled. When it receives a DecimalType, it should convert it to a QuantityType assuming the system default unit.

Yes yes yes, I think you should absolutely file an issue. PLEASE.DO SO.

[satman (Bjorn Narheim)]

Hi all,
I finally have my OH4.2.3 thermostats going. Thanks.

But, with OH4 I’ve now lost the ability to “Add Items from Textual Definition” by hitting the + sign.

So how can I now define Items not related to Things?
I’m using quite a few as replacement for OH2 Global Variables and Values.
Thanks.

[hmerk (Hans-Jörg Merk)]

@satman

But, with OH4 I’ve now lost the ability to “Add Items from Textual Definition” by hitting the + sign.

No, it has moved to the developer tools section…

[satman (Bjorn Narheim)]

Thanks. I found it.

[rlkoshak (Rich Koshak)]

@satman

I’m using quite a few as replacement for OH2 Global Variables and Values.

You don’t have to use Items for this. You can use the sharedCache if that makes more sense.

[satman (Bjorn Narheim)]

Thanks Rich,
I’ll look into that.
I have just started OH4.3 64bit on an RPi5B using openhabian 1.9.3 + latest OH4.2.3 Backup. It loaded OK (I guess), but how do I gain access to the new log viewer. Port 9001 is dead.
The release notes just says “openHAB 4.3 introduces a new log viewer that is integrated into the Main UI:” but how and where?
Thanks.

[rlkoshak (Rich Koshak)]

@satman

but how do I gain access to the new log viewer.

In MainUI go to Developer Tools → Log Viewer.