Unable to set thermostat setpoint above 10

[Lurch]

@rlkoshak

I recommend working these off in order shown but this is your show.

I agree, now I know what my issues are. I’m learning more about openHAB as we go here too, I fully appreciate my initial posts were a bit haphazard and confusing but I didn’t understand what wasn’t actually working at the time.

@rlkoshak

Please show the profile config (this is one of those cases where there really isn’t a code tab unfortunately so a screen shot from the Link page is sufficient. But also show any other configs associated with the profile, e.g. a .js file, .map files, etc.

The profile/rules are from Math Transformation.

@rlkoshak

Understanding the direction of these is important. Sets the target temp from where, OH or the thermostat?

From OH. Setting the temperature from the thermostat seems to send the setpoint through the rules and displays the value as double but because OH hasn’t set the setpoint it doesn’t get sent back and we don’t get into the loop.

[rlkoshak (Rich Koshak)]

OK, that’s a third party transformation. There might be a bug there. I’m not sure how where (binding or profile).

Here’s a bit of a deep dive into the different between a command and an update in OH.

A command is something sent to an Item asking an actuator to activate (e.g. turn on the light). Commands do not, by themselves, change the state of an Item. When a command is sent to an Item, that command gets picked up by the binding and sent out to the actual device.

So how does the Item change as a result of a command? There are two ways. First, there’s autoupdate. This is a service in OH that sees the command and predicts what state the Item will become as a result of doing what the command asked. When ever you see “predicted to become”, that’s autoupdate. Autoupdate can be turned off on an Item by Item basis in Item metadata. Autoupdate is turned on by default.

The second way is that the binding waits for the device to report it’s new state and then issues an update to the Item. This should not generate an infinite loop because, unlike commands, updates to Items are ignored by the bindings.

Based on your logs, something is issuing a command to the Item when an update is required. I’d be inclined to blame the multiply profile for no other reason than it’s not used as much by the community and I’ve not seen an error like this reported before. But that’s not definitive.

What if you did a transform profile with ECMAScript profile. This profile lets you set a different transformation based on the direction of the data flow and it is possible to set an inline script so it’s just about as easy to set up.

For the “Thing to Item” transform use

JS(| (parseFLoat(input) / 2) + ' °C')

and for the “Item to Thing” transform use

JS(| parseFloat(input) * 2)

Eliminate all rules that may command this Item for now. You can just disable them by clicking the pause icon at the top right.

The way it’s supposed to work:

1. a command is sent to the Item from somewhere in OH

2. command is processed in parallel
   a. autoupdate predicts then updates the Item to that newly predicted state
   b. link picks up the command, transforms it through the profile, sends transformed value to binding which in turn sends it to the device, device reports back it’s new state to the binding which updates the Item, transforming the value through the profile first.

I know for a fact that autoupdate isn’t sending a command. It seems a pretty basic error for the profile to be sending a command here. The developer of smarthome/j knows better. So now I’m wondering if you might have a rule you’ve not mentioned or something.

[Lurch]

@rlkoshak

Based on your logs, something is issuing a command to the Item when an update is required. I’d be inclined to blame the multiply profile for no other reason than it’s not used as much by the community and I’ve not seen an error like this reported before. But that’s not definitive.
[…]
Eliminate all rules that may command this Item for now. You can just disable them by clicking the pause icon at the top right.
[…]
So now I’m wondering if you might have a rule you’ve not mentioned or something.

I have no rules/schedules/scripts or anything else like that. Couple of basic items on the overview page but that’s it. Really not doing anything much with OH yet.

I changed the script on the channel as suggested and now these errors are given. Firstly I adjusted the set point in the Tuya app then from openHAB.

Aug 28 18:10:39 openhab karaf[1511]: 18:10:39.414 [ERROR] [.module.script.profile.ScriptProfile] - Failed to process script 'JS(| (parseFLoat(input) / 2) + ' °C')': Could not get script for UID 'JS(| (parseFLoat(input) / 2) + ' °C')'.
Aug 28 18:11:06 openhab karaf[1511]: 18:11:06.298 [ERROR] [.module.script.profile.ScriptProfile] - Failed to process script 'JS(| (parseFLoat(input) / 2) + ' °C')': Could not get script for UID 'JS(| (parseFLoat(input) / 2) + ' °C')'.
Aug 28 18:12:10 openhab karaf[1511]: 18:12:10.738 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Thermostat_TempSet' received command 13
Aug 28 18:12:10 openhab karaf[1511]: 18:12:10.742 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 13
Aug 28 18:12:10 openhab karaf[1511]: 18:12:10.755 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 12 °C to 13 °C
Aug 28 18:12:10 openhab karaf[1511]: 18:12:10.764 [ERROR] [.module.script.profile.ScriptProfile] - Failed to process script 'JS(| parseFloat(input) * 2)': Could not get script for UID 'JS(| parseFloat(input) * 2)'.
Aug 28 18:12:11 openhab karaf[1511]: 18:12:11.399 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Thermostat_TempSet' received command 14
Aug 28 18:12:11 openhab karaf[1511]: 18:12:11.402 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 14
Aug 28 18:12:11 openhab karaf[1511]: 18:12:11.402 [ERROR] [.module.script.profile.ScriptProfile] - Failed to process script 'JS(| parseFloat(input) * 2)': Could not get script for UID 'JS(| parseFloat(input) * 2)'.
Aug 28 18:12:11 openhab karaf[1511]: 18:12:11.407 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 13 °C to 14 °C
Aug 28 18:13:42 openhab karaf[1511]: 18:13:42.467 [ERROR] [.module.script.profile.ScriptProfile] - Failed to process script '(parseFLoat(input) / 2) + ' °C'': Could not get script for UID '(parseFLoat(input) / 2) + ' °C''.

[rlkoshak (Rich Koshak)]

That one’s easy. You need to install the JS Scripting add-on.

[Lurch]

Appears I already have it

There isn’t one specifically called ‘JS Scripting’ so I assume that is the one to which you refer.

[rlkoshak (Rich Koshak)]

Hmmm.

Oh, this is a profile and you’ve already selected ECMAScript so you don’t need the JS part. I think this should work:

| (parseFLoat(input) / 2) + ' °C'

[Lurch]

Ah yes, that works, I tried that but didn’t realise the pipe was the start. Makes sense I guess now I think about it.

So that seems to be for the most part working. It does struggle with half degree points, e.g. I set it to 12.5 in Alexa (using the openHAB thermostat) and it rounds it to 13 which I can live with, main thing I wanted to do was drop the Tuya skill in Alexa and have Alexa send commands to openHAB so Alexa won’t really be setting this directly, I was thinking of adding dummy push buttons in openHAB and having Alexa routines trigger them so I can then just use the button inputs in OH scripts/rules (use them like interrupts). I’m going to expand this using geofencing and weather compensation (DHT22 & ESP01) so it should be pretty smart in itself, the physical stat is for visitors really and Alexa is just a convenient command interface.

[rlkoshak (Rich Koshak)]

@Lurch

I tried that but didn’t realise the pipe was the start

The pipe is the difference between an inline script or a script referenced to a file or managed transform. Without the pipe it’s going to look for a transformation with that ID and of course there won’t be one.

For something simple like this that doesn’t need to be reused elsewhere, I prefer inline to creating the script separately.

@Lurch

I set it to 12.5 in Alexa (using the openHAB thermostat) and it rounds it to 13 which I can live with

Hmmm, that’s unexpected. I’m not a JS developer professionally. Maybe JS works like other languages and defaults to a rounded integer value if one of the operands are an integer. What happens if you change the 2s to 2.0?

@Lurch

I was thinking of adding dummy push buttons in openHAB and having Alexa routines trigger them so I can then just use the button inputs in OH scripts/rules (use them like interrupts).

If that’s the path you want to head down, you don’t need to represent the thermostat as a thermostat in Alexa in the first place. So maybe that whole problem is moot.

[Lurch]

@rlkoshak

Hmmm, that’s unexpected. I’m not a JS developer professionally. Maybe JS works like other languages and defaults to a rounded integer value if one of the operands are an integer. What happens if you change the 2s to 2.0?

Same behaviour.

@rlkoshak

If that’s the path you want to head down, you don’t need to represent the thermostat as a thermostat in Alexa in the first place. So maybe that whole problem is moot.

Currently there are some devices in Alexa that won’t work in openHAB (or aren’t worth the hassle, few Sonoff basic R3’s for instance) so I am still using Alexa to control all the routines and tie everything together. Until I have all the rules and extra bits working in openHAB then Alexa needs to continue working. It will be a while before I get all the Zigbee switches and sensors etc up and running and fully working but I wanted to try and remove all the multiple skills in Alexa and just have it talking to openHAB and have openHAB control the existing devices. The added bonus of getting this working is I can ask Alexa what the current temperature/setpoint is.
So yes, it is somewhat moot but if it works then it will get used from time to time, but the main control will be via openHAB.

[rlkoshak (Rich Koshak)]

@Lurch

Same behaviour.

Hmmm. How are you verifying the state of the Item? Are you looking at the UI or in the logs? If the UI, you might have the state description set to round the value for display.

I can think of no other reason why it would round up. Most of the time people complain of there being too many decimal places.

@Lurch

Until I have all the rules and extra bits working in openHAB then Alexa needs to continue working.

Right, but then you can use the Tuya interface in Alexa instead of messing with openHAB’s integration, for that one device at least.

@Lurch

I wanted to try and remove all the multiple skills in Alexa and just have it talking to openHAB and have openHAB control the existing devices.

My wife has a saying. “You gotta choose which ditch you want to die in.” You can continue to fight getting this thermostat represented in Alexa through openHAB, but if you are going to rip that out in the end anyway, maybe your time is better spent elsewhere.

[Lurch]

@rlkoshak

Hmmm. How are you verifying the state of the Item?

I set it in Alexa, setting it to 12.5 then waiting it jumped to 13. The steps are 0.5 in the Tuya app/on the thermostat itself and the Alexa integration is set to 0.5 steps. I also changed the default list item widget to oh-stepper with 0.5 steps (since doing all the other things above) and while I can set it shows the 0.5 set point but still jumps in the Tuya app/on Alexa to the full integer point.
I think if I persevered with this I could get it to work but it’s a minor issue on a feature that as you say, could be moot at some point.

@rlkoshak

My wife has a saying. “You gotta choose which ditch you want to die in.” You can continue to fight getting this thermostat represented in Alexa through openHAB, but if you are going to rip that out in the end anyway, maybe your time is better spent elsewhere.

I’m not married but I know that I should just agree with the wife (anyone’s wife) regardless! These ideas are not set in stone, tbh I’ve learnt a few things, sometimes reading tutorials and things don’t go in, actually doing something things click/fall into place.

The only reason I was persevering with the thermostat was because there was more info in the openHAB binding/skill and I could only use Alexa to set the temperature when the thermostat was in manual mode. Using openHAB Alexa could set the mode too, but this may be moot again anyway though if I just schedule everything through openHAB.

[rlkoshak (Rich Koshak)]

@Lurch

I think if I persevered with this I could get it to work but it’s a minor issue on a feature that as you say, could be moot at some point.

I’m not entirely certain this part is moot. I’m more talking about getting that nice unified thermostat widget in Alexa is moot.

Based on the most recent events you’ve published I only see whole numbers. Did you post half a degree for those? Something is rounding the value and once we find where it will be trivial to fix. I’m not convinced it’s the transforms any more. It might be a widget config, Item config, or maybe even a Channel config. There’s not enough data to pinpoint it.

[Lurch]

Using the stepper selector on the thermostat card I can set it to 12.5 and in the Tuya app it is 12.5. Setting it in Alexa and it is set to 12.5 but then Alexa shows 13. If I set it to 8.5 in the Tuya app then openHAB shows 8.5 but then Alexa shows 9. I guess this means the Alexa integration is doing the rounding.

[rlkoshak (Rich Koshak)]

@Lurch

Setting it in Alexa and it is set to 12.5 but then Alexa shows 13

Show all the events in events.log (or where ever they show up) for this latter case. Does 12.5 ever reach the Item or does the Item update straight to 13?

@Lurch

I guess this means the Alexa integration is doing the rounding.

I suspect so. I don’t use Alexa for this but I could see them wanting to round in their display.

What the Item’s state in OH reflects is the source of truth.

[Lurch]

@rlkoshak

Show all the events in events.log (or where ever they show up) for this latter case. Does 12.5 ever reach the Item or does the Item update straight to 13?

Setting it in Alexa to 15.5 and it switches to 16 (after a short delay). Did this twice and the only thing in the log is;

Aug 28 23:24:33 openhab karaf[1511]: 23:24:33.038 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 15 °C to 16 °C

@rlkoshak

I suspect so. I don’t use Alexa for this but I could see them wanting to round in their display.

Their display in the Alexa app has the temperature at 0.5 steps. I used to be able to set it at half degree steps when it was just Tuya so I suspect there’s more to it than just an Amazon constraint.

@rlkoshak

What the Item’s state in OH reflects is the source of truth.

Yes, and that is all seemingly fine now. I might revisit this once I get more things in OH working. For now I will spend my time actually using the bits that do work and preparing for the various Zigbee bits that are on their way to me!

[jeshab (Jeremy)]

@Lurch

Setting it in Alexa to 15.5 and it switches to 16 (after a short delay). Did this twice and the only thing in the log is;

You should see an ItemCommandEvent related to your Alexa request prior to the ItemStateChangedEvent. This will indicate what value the skill is sending to your OH server.

@Lurch

Their display in the Alexa app has the temperature at 0.5 steps. I used to be able to set it at half degree steps when it was just Tuya so I suspect there’s more to it than just an Amazon constraint.

Alexa supports half degree for temperatures in Celsius. Keep in mind that the skill uses the item state presentation if defined, to format the number sent back to Alexa. So if you have an integer formatting %d, then the number sent to Alexa will be rounded.