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?
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.
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.
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:
a command is sent to the Item from somewhere in OH
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.
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''.
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.
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.
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?
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.
