I have a MoesGo WiFi Smart Thermostat which I have added to openHAB 4.0.2 via the Tuya binding. The setpoint values are constrained to 5-10. I can still set the setpoint in the Tuya app and OH reads the value correctly. I have tried setting limits/steps in various places and OH seems to take note of this but if I set anything over 10 then the setpoint jumps back to 10. Not sure what to do next or how to check if the issue is with OH or the binding, or the thermostat or something else!
I’ve read various posts no the forum about similar issues (but nothing exactly the same) and it feels like I’m missing something fundamental, and/or the help files are outdated/missing some info. For example, I read say Items | openHAB or openHAB Skill For Amazon Alexa | openHAB but it never really tells me where to add any of this data. I can add metadata to an item/group/thing but the code tab is not in this format, and it allows me to enter code formatted as per the above link and says it is updated when I hit save but going back to it the old value: "" config: {} is still there.
There are a lot of vague details here. We need some more concrete information.
What’s the Item config? (click the code tab and paste the YAML with code fences)
```
code goes here
```
Which UI?
What’s the UI element’s configuration?
The Item’s page is mostly geared towards text file writers. But most of it should be apparent in the screen you are looking at and the menu options presented. The big source of confusion is Profiles, which don’t actually exist separately in the text file configs like they do in MainUI. Profiles get configured on the Link between the Item and Channel so you navigate to the Link either from the Item or the Channel side and configure it there.
You shouldn’t need to use the code tab. This is among the “well known” metadatas so just select “Amazon Alexa” and fill out the form.
But if you ever do need to translate metadata from a text file config to UI it’s pretty straight forward.
The text file config format is: namespace=value[prop1name=prop1value,prop2name=prop2value] where value is optional, and the config ([]) are optional. Mostly “value” is used.
In MainUI, the namespace is entered for you by selecting a well known metadata option from the list, or you enter your own when choosing “Enter custom namespace…”. What’s entered after “value” becomes the value of the metadata. Stuff entered under “config” becomes the configuration.
Apologies, this is part of the issue, getting my head around what is pertinent info, like the UI I installed openHAB and got a UI, wasn’t aware there were options/alternatives.
I was running openHAB on DietPi under ESXi but then migrated to a local instance once I got it up and running. Now running under Armbian on a Libre Le Potato (AML-S905X-CC).
Versions:
Linux openhab 6.1.30-meson64 #8 SMP PREEMPT Wed May 24 16:32:53 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux
openHAB Distribution Version Information
----------------------------------------
build-no : Release Build
online-repo : https://openhab.jfrog.io/openhab/libs-release
Repository Version
----------------------------------------
openhab-distro : 4.0.2
openhab-core : 4.0.2
openhab-addons : 4.0.2
karaf : 4.4.3
openjdk version "17.0.8" 2023-07-18
OpenJDK Runtime Environment (build 17.0.8+7-Ubuntu-122.04)
OpenJDK 64-Bit Server VM (build 17.0.8+7-Ubuntu-122.04, mixed mode, sharing)
The specific item is:
label: TempSet
type: Number:Temperature
category: temperature
groupNames:
- thermostat
groupType: None
function: null
tags:
- Control
- Temperature
- Point
The thermostat itself:
label: Thermostat
type: Group
category: HVAC
groupNames:
- House
groupType: None
function: null
tags:
- Equipment
- Heating
- RadiatorControl
That’s kind of what I thought but I couldn’t see anything that confirmed this or a simple way to (as a newbie to OH) convert from on to the other.
That’s what I was hoping, maybe the fact this thermostat issue has arisen has meant I’ve gone off looking at things I probably don’t need to which has maybe added to the confusion.
In the context of this topic for instance, I have the following:
config:
setpointRange: 5:30
Where would I enter that and where/how would I find it on the UI? I am guessing then that it is actually metadata for thermostat.TempSet, not for the actual code of the device/item/channel itself?
I think my confusion was coming from not knowing where to enter it and not getting anywhere with it.
If I enter incorrect code in the code tab of the item e.g.
config:
setpointRange: 5:30
and click save then I get Item Updated show in the lower left which suggests it saved and then going back to the code tab the config: lines have disappeared. Obviously the issue was I was using them in the wrong place but the UI throwing no errors was confusing the issue.
I had been adding the metadata for the Thermostat using this method but adding metadata to 5 of the channels showed up in Alexa as 3 thermostats, each with either a single or multiple bits of the data, i.e. one thermostat with power only, one with eco mode and set point (no numbers set/displayed though) and one for current temperature and mode, but with no temperature shown. Seemed that 2 thermstats came in as uncapitalised “thermostat” and one came in as capitalised “Thermostat” but checking all channels, items etc I couldn’t see anywhere it was set differently between configs. All very strange!
When in doubt, give us more information rather than less. It’s very easy to skip over or ignore irrelevant stuff but it’s a pain playing 20 questions to ask for info that’s missing.
That’s part of what isn’t clear. Context of what? What has told you you need to have that YAML? There are lots of parts of OH, as you well know, and that little snippet could be for a widget, Item metadata, Thing Channel config or more. It might be incorrect (if copied from a forum post or guessed at by you).
That’s not what’s clear. Let’s assume you are talking about Item metadata.
A more complex endpoint may be a thermostat which has many capabilities to control and report temperature, setpoints, modes, etc…
…
In openHAB a thermostat is modeled as many different items, typically there are items for setpoints (target, heat, cool), modes, and the current temperature. To map these items to a single endpoint in Alexa, we will add them to a group which also uses “Alexa” metadata. When items are Alexa-enabled, but are also a member of a group Alexa-enabled, they will be added to the group endpoint and not exposed as their own endpoints.
Group Thermostat "Bedroom" {alexa="Thermostat"}
Number Temperature "Temperature [%.1f °F]" (Thermostat) {alexa="CurrentTemperature"}
Number CoolSetpoint "Cool Setpoint [%.1f °F]" (Thermostat) {alexa="CoolingSetpoint"}
Number HeatSetpoint "Heat Setpoint [%.1f °F]" (Thermostat) {alexa="HeatingSetpoint"}
Number Mode "Mode [%s]" (Thermostat) {alexa="HeatingCoolingMode"}
The group metadata also describes the category for the endpoint, in this case a “Thermostat”. In this example an endpoint is created called “Bedroom”, its various capabilities are mapped to different openHAB items. You can ask Alexa, set the Bedroom thermostat to 72 and the “HeatSetpoint” will receive the command, if currently in heating mode, likewise you can ask Alexa, what’s the temperature of the Bedroom? and the current state of “Temperature” will be returned.
The bold is mine. Complex entities like thermostats need to be Grouped together to tell Alexa that they are part of the same equipment. So create a Group and add “Thermostat” as the Amazon Alexa metadata (you’ll find it in the list) and add all your individual thermostat Items to that Group. Then Alexa will see all those Items as part of one thermostat.
That is likely, it was just an example, this is what I’m struggling with, some of the forum posts and configs etc don’t seem to tally up with anything I can see in openHAB, it’s almost like I’m on completely the wrong forum. I have a look at a post where someone has the same issue but the fix that is confirmed as working doesn’t seem to fit anywhere in my config.
So it looks like I am having 2 issues, 1 is that openHAB won’t set the temperature correctly (won’t go over 10) and it doesn’t send all channels/info to Alexa.
But Alexa doesn’t see the temperature channels in the thermostat;
ETA: As I reread this again it seems like I need to just add the metadata to the thermostat group and not every individual channel/link. I have done this and nothing shows up in Alexa. It only seems to work if I add Alexa metadata to the individual channels, and then only some seem to show up. I have had the temperature channels show up once when shared from openHAB but neither displayed any values. Since then I have removed and re-added the device to openHAB and added metadata to the group and to the channels but I haven’t managed to get them to show up in Alexa again. Only the power and modes seem to show when added as individual items, although Amazon groups them under the same device still.
Further ETA:
Adding Amazon Alexa metadata for the group and for the current temperature and setpoint temperature channels I can get this to show up in Alexa;
I cannot set or change anything here though, although I can adjust the setpoint in openHAB so it would seem openHAB isn’t passing the right info to Alexa. Also at some point the actual original issue of the setpoint being constrained within openHAB is currently fixed and the setpoint can be adjusted freely. I’m wondering if the metadata for the Alexa has some bearing on the channels?
As I test this further it gets more random. If I delete the item and re-add it it seems to have a different issue or behave differently every time. I think I might just put this down to the Tuya binding and/or the thermostat itself being an issue.
My hope was to move all my existing things over to openHAB and have Alexa as a secondary control surface but I’ve now also discovered that the Zigbee gateway I have won’t work directly with openHAB (seems I need to buy a new USB one as OH doesn’t support IP gateways) and adding Zigbee devices via Tuya doesn’t work as OH expects an IP address, although it can read all the channels of the RGB lamps, just can’t control them which seems like it should work if it is happily talking to the gateway to receive data. Another nail in the coffin for the Tuya binding I guess.
Just to sort of draw a line under this a bit, I’m going to blame the Tuya binding in some form as it seems this thermostat works fine under Alexa and in the Tuya app but it does all sorts of weird things in openHAB. Slightly disappointed with the fact I can’t use my existing WiFi/BLE/Zigbee hub/gateway but I have ordered a USB Zigbee gateway and a Zigbee thermostat (and a few other Zigbee bits). Hopefully I’ll have a bit more success here using a more direct connection. Should be able to remove a few of the workarounds I’m having to do with Alexa and the Tuya app regarding scenes and modes too.
Note that screen shots are next to useless to us. Where possible instead of or in addition to screen shots post the contents of the “Code” tab. For Items you can find the code tab after clicking on “edit”.
Without there isn’t nearly enough information to determine where a problem might lie. But to reiterate what the docs say.
You need a group with alexa metadata set to “Thermostat”.
Make all the Items that make up this thermostat be members of this Group
Each Item must have the appropriate alexa metadata for what that Item represents.
Not all possible channels exposed in OH are likely to work with Alexa. Alexa has a concept of what cn be a part of a Thermostat and if it’s not in Alexa’s model (e.g. child lock) Alexa isn’t going to show that or let you control that.
Furthermore, the types if the Items must match. For example, the docs for the Alexa integration expects the mode to be a Number Item. You have a String Item. That’s not likely to work.
And I can’t tell if you’ve configured it right. Does the thermostat Item have the correct alexa metadata? You don’t show that.
Note, often you need to tell Alexa to synchronize the devices after making changes to the configs on OH or else it won’t see the changes. At least that’s how Google Assistant works.
No, you need to add metadata to the individual Items too so Alexa can tell the difference between the current temp and the heating setpoint, for example.
Note, Alex works strictly with Items, not Channels nor Links. Only Items. What and whether those Items are linked to anything is completely transparent to Alexa. She just sees Items and the alexa metadata on those Items.
It doesn’t. The Channels and Links are completely oblivious to the alexa metadata. The only think I could think of is if the Item had a State Description metadata with a min/max property set, but you’ve not shown anything to indicate that (nor anything to eliminate that as a possibility either).
Without knowing if you’ve set up and configured the Item exactly the same way each time I don’t think we can draw any conclusions. It is possible for bindings to push State Description metadata to the Item when it’s Linked. So it is possible there could be something in the binding that changes the behavior of the Item. But there is nothing in the binding that will impact the Alexa integration. That happens at the Item level and the binding has no influence on that.
I don’t know anything about Tuya so cannot comment on the gateway stuff.
That’s because Tuya wrote an integration with Alexa specifically to support it’s thermostats. OH has a generic integration with Alexa using Alexa’s generic models for various types of devices. Any odd behaviors there have to do with configuration of the Items, or if there is a problem, the problem lies in the Amazon Control binding. The Tuya binding knows nothing and has no influence over the Amazon integration.
That bit does work though. As per the first screenshot from Alexa the mode is selectable and the mode on the thermostat is set according to this setting in Alexa. Also this type definition was what was set as default when the item was added and adding Alexa metadata there were no errors when it was added/saved.
Yep, done that every time. Even deleted and re-added it to make sure everything is using new data.
I’m just following what is in the guide and the bit you quoted above.
The way I read that is that if you add the items to an Alexa enabled group then the items are all exposed as part of the group so there is no need to expose them individually. You quoted this section but also say that all items need their own metadata which seems to be in direct contradiction of this sentence.
As it currently stands this is what is configured. The Thermostat group item and 2 items which are channels of the thermostat. I have copied the code tab here for each item and also the relevant Alexa metadata tab.
Thermostat Item
label: Thermostat
type: Group
category: heating
groupNames:
- House
groupType: None
function: null
tags:
- Equipment
- RadiatorControl
Alexa Metadata
value: Thermostat
config: {}
TempSet Item
label: TempSet
type: Number
category: Number
groupNames:
- Thermostat
groupType: None
function: null
tags:
- Point
- RadiatorControl
There won’t be. Metadata is pretty free form. MainUI doesn’t know enough to know if what you’ve entered is reasonable or not. You’ll have to try to use it and watch for errors.
Maybe the confusion is the term “endpoint”. An “endpoint” is a single device in Alexa which may consist of one or more sensor or actuator. So the Group with the metadata takes N Items and makes them appear as one device (i.e. endpoint) in Alexa.
The Alexa skill API uses the concept of “endpoints”. Endpoints are addressable entities that expose one or more capabilities. An example endpoint may be a light switch, which has a single capability to control power and report its state (ON/OFF). A more complex endpoint may be a thermostat which has many capabilities to control and report temperature, setpoints, modes, etc…
But none of that eliminates the requirement that all Items that get exposed to Alexa require alexa metadata. All that does is change whether each Item appears as a single device, or they get grouped together into a single device.
When items are Alexa-enabled (i.e. have alexa metadata) and also a member of an Alexa-enabled group, they will be added to the group endpoint (i.e. appear as one device) and not exposed as their own endpoints (i.e. each Item is it’s own device).
In your screen shot above you show the setpoint range being set on the setpoint Item. Did you leave it out or is there a discrepancy here?
What are these Item’s states?
The docs do not say anything about this as far as I can see, but for Google Assistant, it used to be the case that a Thermostat had a minimum number of Items required to make a thermostat. Maybe the same goes for Alexa and you need a Mode Item at least, maybe both a cooling and heating setpoint, not just one.
What happens when you click + or - on the setpoint? See anything in the logs or get any sort of error as feedback?
OK, I think I get what it all means now. I was obviously initially just going off of documents/guides I have read but some of them aren’t the clearest, which is to be expected as there is a lot of technical detail to everything here!
Nope, screenshot and code both from the same metadata item. Maybe screenshots aren’t so bad after all?
In Alexa? Nothing/non-functioning.
In Alexa I have a thermostat (the same thermostat) added via Tuya and it only has setpoint and current temp. These both work fine.
I have added all items to the thermostat before and had mixed results, in that I can add the mode for instance and add mappings so 0 and 1 display as schedule and manual. These work fine. I have added all items, child lock and eco mode too so there has been upwards of 5 items added, and child lick and eco mode seem to display too.
But I don’t think this is the issue as ther current thermostat has just these 2 items that are controllable/displayed. The openHAB thermostat the setpoint isn’t controllable and the current temperature is not displayed.
Clicking +/- does absolutely nothing. /var/log/openhab/*.log all empty (and so is Readme.txt oddly). No errors or logs anywhere I can see.
Except the code is what is actually set on the Item regardless of what the UI says.
But in general, screen shots don’t show everything, cannot be searched, copied from, edited, and are all but impossible to read on smaller screens like phones.
In openHAB
It is irrelevant what the Tuya app has put into Alexa. They implemented their own interface and customized if for their own device. It has no bearing on OH and Alexa integration.
empty as in literally empty, or just nothing relevant to these Items?
First make sure that you can interact with your thermostat from OH and are seeing the proper state as expected.
The Alexa thermostat modes are pre-defined. You can’t use free-form as it seems to be. You need to map your modes to the closest one matching the Alexa side if they aren’t exactly the same. As per the documentation, thermostat modes are supported by Number, String or even Switch items for on/off control. Keep in mind that the Alexa app will always show a mode even if that capability isn’t configured on the endpoint. In that case, the app will show a dummy read only custom mode property.
As far as setpoint, if your thermostat only controls one setpoint either cooling or heating, use TargetTemperature instead. The documentation indicates that CoolingSetpoint and HeatingSetpoint needs to be paired to each other. So if only one is defined, the skill will ignore them. Similar to thermostat mode, the Alexa App will show a dummy target setpoint even if it’s not configured. Also, if neither a mode or a setpoint is defined on the endpoint, the current temperature will not be displayed in the Alexa app as well.
I would strongly recommend that you use MainUI to configure your Alexa metadata. Also use the Config and not the Code tab. There is a specific view at the group endpoint level that lists all the capabilities and which one will be ignored.
I don’t disagree but I think both have their place, clearly been useful here as a discrepancy seems to have been identified?
I’m not sure how to show/find the info here. All I can see is what is in the UI. Setpoint is 15 (which it is on the thermostat) and current temp is whatever the current temp is. All items on the thermostat seem to function correctly, setting them in openHAB and they change according to what is expected in the app and at the thermostat and vice-versa, setting anything on the Tuya app or at the thermostat and the changes are seen in openHAB.
I was just meaning that Alexa doesn’t have a minimum amount of things to be a thermostat as far as I can see as the same device connected via Tuya has only the 2 items, the setpoint and current temperatures. Unless you were meaning maybe the Alexa/OH integration specifically needs to have a minimum number of items (which I covered I think anyway)?
Empty as in empty files, nothing there at all. cat /var/log/openhab/openhab.log etc produces absolutely nothing.
Well, this is a bit hit and miss. Sometimes it seems to work but then sometimes it works for a while then starts misbehaving. like for some reason the setpoint has started misbehaving (which I had fixed once and it seemed to work from OH). Currently trying to set the setpoint from OH and it won’t go over 10. Also seems to be showing the wrong readings. The thermostat expects the value in half a degree steps, so 10 degrees is 20 etc. IF I use a transfrom profile on the actual channel then it seemed to work but now if I use openHAB to set the temperature then it is back to not going over 10, and at 10 it sets the setpoint on the thermostat to 5. Setting it to say 20 in Alexa (using the OH thermostat) then I can set it to 20, but then it is set to 20, the transform reads the setpoint and then divides by 2 and then sets the setpoint display to 10, which then sets the setpoint to 10 which then gets divided by 2 which then sets the actual setpoint to 5. I guess at this point we stop for some reason?
When I started this thread I thought it was working but it may have been superficially “working” on the face of it. I don’t think it actually does work, which is a shame but I’m not too broke up about it, there’s too many steps/things between the thermostat and me to make it reliable enough to use how I want, hence why I just ordered the Zigbee one to allow a bit more of a direct channel between it and openHAB.
This makes sense, I guess reading all the docs I’ve misread/misunderstood a few subtle bits here and there. I’d not read that quite as mandatorily as it actually is.
That’s what I was doing but seems most of the posts/guides favour the files/text method of config. I would be quite happy to use the UI exclusively and not delve into the code tab.
Not seen that until now. Usually I add that metadata first so it is all empty. Going back after adding the other points and I see it is ignoring the Heating.Setpoint. Whilst that has helped slightly in that I now have a display there are other issues still.
I don’t know if I have the willpower to see this working! It’s detracting from getting the rest of openHAB working which would for the most part make this a unnecessary integration. Essentially all I want Alexa for is voice commands, so I can just add dummy buttons which are triggered by voice/routines. All the routines/logic will be in openHAB. Also means I can tie in all the other inputs into the logic that Alexa can’t do, home/away status, some basic if/then blocks and free use of all devices as sources for decisions etc.
That was the reason for my first point. It seems that you are trying to solve issues at different levels by adding complexity to the mix. You should focus on getting what you expect at the OH level and then you can expend to the rest. It makes it very hard for us to pinpoint a given issue when there are different parts at play.
I think this summarize well the issue that needs to be resolved which is ultimately what you started in your other thread.
Maybe if you provide event logs for the relevant items you are trying to interact with could shed more light on what is going on between OH and your thermostat.
Yes, I thought that was working, or at least it did seem to work once. Going over it again now it seems the main issue is with the thermostat item/thing somewhere but I haven’t seen the same issues exactly in both OH and Alexa. I’ve put 2+2 together in this thread when looking at it from the Alexa angle.
Perhaps. I don’t know if you just entered the data and haven’t saved yet.
MainUI or, if you are looking for confirmation that an Item is being commanded or updated look in events.log.
This
This indicates you have bigger problems, perhaps, than just alexa integration. openhab.log always has a few dozen lines just starting up, often even more depending on rules and bindings installed. event.log has at least one line for every Item change, could be several lines for every Item command. Your logging config is broken. Compare $OH_USERDATA/etc/log4j2.xml with the default one here. You’ll never be able to debug any problem without logs.
They seem to match. Permissions for /var/log/openhab are
drwxr-xr-x 2 openhab openhab 4096 Aug 27 19:40 openhab
and all the files within are as per openhab.log
-rw-r--r-- 1 openhab openhab 0 Aug 28 00:00 openhab.log
I tried setting the logging folder in /etc/default/openhab but that seemed to make no difference, tailing openhab.log still gave me nothing.
Be interesting to see if anything else doesn’t work, but seems odd that only a thermostat in a binding would be the only thing that didn’t work. I do have some lights and plugs added that work fine, and also a TV.
Well some progress here, seems /var/log/syslog is full of openHAB events. As above I set the log file path to /var/log/openhab in /etc/default/openhab but that seemed to be ignored. Somewhere there is another setting in openHAB using /var/log/syslog or there is a symlink in Armbian itself. I checked in /etc/rsyslog.d/50-default.conf and I guess the default *.*;auth,authpriv.none -/var/log/syslog is directing all karaf entries to the default path.
So, that aside for a moment, I have removed the transformation on the item that I was doing. Now if I set the target temp in openHAB to 20°C the logs show;
Aug 28 11:13:04 openhab karaf[1511]: 11:13:04.946 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_TempSet' received command 20
Aug 28 11:13:04 openhab karaf[1511]: 11:13:04.950 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 20
Aug 28 11:13:04 openhab karaf[1511]: 11:13:04.971 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 19 °C to 20 °C
But in the Tuya app the temperature is 10°C.
If I set the temperature in the Tuya app to 20°C then the logs are;
Aug 28 11:15:02 openhab karaf[1511]: 11:15:02.347 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 20 °C to 40°C
So the original issue here seems to be that it is showing half steps/0.5°C values. I was doing a multiply by 0.5 transformation on the setpoint channel profile but that seems to send it into some sort of endless loop.
Just writing out what I think it is doing to get it clear in my head;
I set target temp to 22.
The profile multiplies by 0.5, gets 11.
Sends 11.
Receives the new setpoint of 11 from the thermostat, multiplies by 0.5 and gets 5.5. Then it sets this as the new target temp and sends this to the thermostat and here the loop starts.
Aug 28 11:25:56 openhab karaf[1511]: 11:25:56.595 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_TempSet' received command 39
Aug 28 11:25:56 openhab karaf[1511]: 11:25:56.605 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 39
Aug 28 11:25:56 openhab karaf[1511]: 11:25:56.622 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 40 °C to 39 °C
Aug 28 11:25:56 openhab karaf[1511]: 11:25:56.718 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_TempSet' received command 38
Aug 28 11:25:56 openhab karaf[1511]: 11:25:56.720 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 38
Aug 28 11:25:56 openhab karaf[1511]: 11:25:56.725 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 39 °C to 38 °C
Aug 28 11:25:56 openhab karaf[1511]: 11:25:56.796 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 38 °C to 19.5 °C
Aug 28 11:25:56 openhab karaf[1511]: 11:25:56.874 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_TempSet' received command 37
Aug 28 11:25:56 openhab karaf[1511]: 11:25:56.877 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 37
Aug 28 11:25:56 openhab karaf[1511]: 11:25:56.888 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 19.5 °C to 37 °C
Aug 28 11:25:56 openhab karaf[1511]: 11:25:56.890 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 37 °C to 19 °C
Aug 28 11:25:57 openhab karaf[1511]: 11:25:57.050 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 19 °C to 18.5 °C
Aug 28 11:25:57 openhab karaf[1511]: 11:25:57.204 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_TempSet' received command 37
Aug 28 11:25:57 openhab karaf[1511]: 11:25:57.206 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 37
Aug 28 11:25:57 openhab karaf[1511]: 11:25:57.214 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 18.5 °C to 37 °C
Aug 28 11:25:57 openhab karaf[1511]: 11:25:57.312 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 37 °C to 18.5 °C
Aug 28 11:25:57 openhab karaf[1511]: 11:25:57.992 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_TempSet' received command 36
Aug 28 11:25:57 openhab karaf[1511]: 11:25:57.995 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 36
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.000 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 18.5 °C to 36 °C
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.043 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_TempSet' received command 18
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.047 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 18
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.064 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 36 °C to 18 °C
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.108 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_TempSet' received command 17
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.109 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 17
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.115 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 18 °C to 17 °C
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.133 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_TempSet' received command 20
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.134 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 20
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.140 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 17 °C to 20 °C
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.222 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 20 °C to 9 °C
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.263 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_TempSet' received command 36
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.266 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_TempSet' received command 16
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.268 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 36
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.271 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 16
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.276 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 9 °C to 36 °C
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.279 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 36 °C to 8.5 °C
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.286 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 8.5 °C to 16 °C
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.374 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 16 °C to 10 °C
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.447 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 10 °C to 18 °C
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.455 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 18 °C to 8 °C
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.670 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_TempSet' received command 19
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.673 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 19
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.686 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 8 °C to 19 °C
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.690 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_TempSet' received command 18
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.694 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 18
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.704 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 19 °C to 18 °C
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.779 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 18 °C to 9.5 °C
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.825 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_TempSet' received command 17
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.829 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 17
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.833 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 9.5 °C to 17 °C
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.892 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 17 °C to 9 °C
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.932 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_TempSet' received command 16
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.934 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 16
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.951 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 9 °C to 16 °C
Aug 28 11:25:58 openhab karaf[1511]: 11:25:58.957 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 16 °C to 8.5 °C
Aug 28 11:25:59 openhab karaf[1511]: 11:25:59.039 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 8.5 °C to 8 °C
Aug 28 11:25:59 openhab karaf[1511]: 11:25:59.213 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_TempSet' received command 9
Aug 28 11:25:59 openhab karaf[1511]: 11:25:59.216 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 9
Aug 28 11:25:59 openhab karaf[1511]: 11:25:59.220 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 8 °C to 9 °C
Aug 28 11:25:59 openhab karaf[1511]: 11:25:59.404 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_TempSet' received command 8
Aug 28 11:25:59 openhab karaf[1511]: 11:25:59.406 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 8
Aug 28 11:25:59 openhab karaf[1511]: 11:25:59.411 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 9 °C to 8 °C
Aug 28 11:25:59 openhab karaf[1511]: 11:25:59.658 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_TempSet' received command 7
Aug 28 11:25:59 openhab karaf[1511]: 11:25:59.660 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 7
Aug 28 11:25:59 openhab karaf[1511]: 11:25:59.668 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 8 °C to 7 °C
Aug 28 11:25:59 openhab karaf[1511]: 11:25:59.671 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_TempSet' received command 6
Aug 28 11:25:59 openhab karaf[1511]: 11:25:59.674 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 6
Aug 28 11:25:59 openhab karaf[1511]: 11:25:59.681 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 7 °C to 6 °C
Aug 28 11:25:59 openhab karaf[1511]: 11:25:59.851 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_TempSet' received command 10
Aug 28 11:25:59 openhab karaf[1511]: 11:25:59.853 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 10
Aug 28 11:25:59 openhab karaf[1511]: 11:25:59.858 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 6 °C to 10 °C
Aug 28 11:25:59 openhab karaf[1511]: 11:25:59.998 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 10 °C to 5 °C
Aug 28 11:26:00 openhab karaf[1511]: 11:26:00.054 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_TempSet' received command 9
Aug 28 11:26:00 openhab karaf[1511]: 11:26:00.056 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 9
Aug 28 11:26:00 openhab karaf[1511]: 11:26:00.063 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 5 °C to 9 °C
Aug 28 11:26:01 openhab karaf[1511]: 11:26:01.402 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_TempSet' received command 10
Aug 28 11:26:01 openhab karaf[1511]: 11:26:01.417 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 10
Aug 28 11:26:01 openhab karaf[1511]: 11:26:01.489 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 9 °C to 10 °C
Aug 28 11:26:01 openhab karaf[1511]: 11:26:01.586 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 10 °C to 5 °C
Aug 28 11:26:01 openhab karaf[1511]: 11:26:01.640 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_TempSet' received command 11
Aug 28 11:26:01 openhab karaf[1511]: 11:26:01.641 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 11
Aug 28 11:26:01 openhab karaf[1511]: 11:26:01.648 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 5 °C to 11 °C
Aug 28 11:26:01 openhab karaf[1511]: 11:26:01.812 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 11 °C to 5.5 °C
Aug 28 11:26:01 openhab karaf[1511]: 11:26:01.853 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_TempSet' received command 6
Aug 28 11:26:01 openhab karaf[1511]: 11:26:01.855 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 6
Aug 28 11:26:01 openhab karaf[1511]: 11:26:01.861 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_TempSet' changed from 5.5 °C to 6 °C
Aug 28 11:26:02 openhab karaf[1511]: 11:26:02.052 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_TempSet' received command 6
Aug 28 11:26:02 openhab karaf[1511]: 11:26:02.054 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_TempSet' predicted to become 6
This should be doable but I think you need to prioritize these issues so we can work them off in order. You’ll go mad pursuing them all at the same time. So far I think we have:
Tuya sends/expects the temp in number of half degree increments instead of the actual temp and the profile to multiply/divide by .5 goes into an infinite loop
logging isn’t going to openhab.log (maybe that’s an Armbian thing?)
Alexa isn’t showing the thermostat as expected.
I recommend working these off in order shown but this is your show.
The Profile is supposed to prevent that. Something fishy is going on. 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.
Understanding the direction of these is important. Sets the target temp from where, OH or the thermostat?
You don’t show that.