Sorry - I’m not sure why. This was certainly tested and working with this device early this year as you can also see from the forum posts.
It seems I have to try zigbee2mqtt to the the devices working.
OK - thank you for your support anyway.
I had another look at the log, and at least for one of the setpoints, and therefore I suspect all of them, the device doesn’t support sending reports from the device to the binding -:
You see here that when setting attribute 17 for reporting, it is reporting that the attribute is unreportable so based on this the device cannot be configured to send these reports to the binding.
The latest documentation of the device does not contain an attribute with ID 17.
In fact there is a gap for this ID and there are no cooling configurations at all.
Or have I missed something?
I guess that’s why it’s unsupported 
In theory the binding should try to detect this, but it depends on what the device returns as to how successful this is. The binding tries to get a list of supported attributes, but some devices don’t support this function.
I do see though that unoccupied heating is correctly set and the device returns SUCCESS in this log so at least that should report
@chris, @ibimms
I guess this is the wrong chat. I propose to shift further discussions to Eurotronic Spirit Zigbee Thermostat again
Why is it wrong? All of the discussion has been here - swapping around makes this a mess to try and work out. I suggest we keep this in one place.
I’ve had a look at the debug logs when I configured the setpoint at the physical device.
touch device.log (1.7 KB)
2020-04-12 11:59:08.305 [DEBUG] [transaction.ZigBeeTransactionManager] - notifyTransactionCommand: ReportAttributesCommand [Thermostat: 605B/1 → 0000/1, cluster=0201, TID=C3, reports=[AttributeReport [attributeDataType=SIGNED_16_BIT_INTEGER, attributeIdentifier=16387, attributeValue=1650 ]]]
attributeIdentifier=16387 meets the documentation and attributeValue=1650 is my configured value of 16.5°C
It seems the device reports the change to OH, but nothing happens.
Ok, that makes more sense. I did ask earlier if you were sure that there was nothing being received -:
The problem here is that the device is reporting using a non-standard attribute rather than the ones that the binding has configured reporting for (ie the standard ZigBee attributes).
That’s bad. This means the device is not really compatible with ZigBee - right?
Is there a chance to implement a connector anyway?
I am looking for some Spirit device specific source code or configuration at org.openhab.binding.zigbee , but I can’t find something. Is this the wrong location or is the ZigBee binding so generic that there is no device specific part needed?
Well, it’s still ZigBee I guess - devices are allowed to implement manufacturer specific features, but they are also required by ZigBee to implement certain standard features. One such feature is the setpoint - this is marked as mandatory in the standard. Now - they are implementing it - we can write to that attribute and it sets the setpoint, but when reporting changes, they use their non-standard setpoint attribute.
This can be seen below. Attribute 12 (Heating setpoint) is supported - but it’s not reporting. The only attributes that are reporting are the non standard ones (and the standard current temperature).
Ultimately, this would need a static definition to solve this. This should be mostly possible in the binding, but it’s not something I’ve looked at for a long time as most of my customers are using standard devices - unfortunately OH users tend to be the ones that buy the non-standard devices…
The issue that is currently outstanding to resolve this is -:
OK - I understand what’s the problem to receive manual changes to of the setpoint. Let’s hope Henning is still working on that. But this is still the framework, so until it is working for my devices this might take a while. So I have to live with it for now.
Coming back to my initial question
What’s about the System Mode that can’t be changed? It’s given as attribute with ID 0x001C, at the ZigBee specification as well as Spirits manual.
Why is System Mode read only in Paper UI? And why doesn’t it change when I modify the value of an item with the same channel?
As requested earlier, please can you provide a log showing you changing this. From the earlier log you provided, it is working, so I need to see it changing.
Here the logs. I changed from off (code 0) to mode sleep (code 9).
system mode - events.log (567 Bytes)
system mode - openhab.log (5.6 KB)
There seems to be no way to set the system mode directly at the physical device.
Again, this appears to be fine -:
The binding is correctly sending attribute 28 to value 9 - as per the incoming command. The device has acknowledged that with the state SUCCESS.
What the binding does is to read out an attribute called “sequence of operation” which has the following definition.
Depending on the response, the binding will make only certain options available to the user, although this is not checked in the binding when the user sends a command, so you can set any mode you like between 0 and 9.
Modes are defined as follows -:
Again, the binding should provide these as options in theory and it should only provide the ones allowed as per the sequence attribute discussed above.
From the logs you’ve provided, you’ve set 0 and 9 and these have both correctly been sent to the device, and the device has responded with SUCCESS. I’d suggest trying other values - maybe it only implements one or two of them.
Now I’ve tried all modes from 0 to 9 and waited for some seconds in between. None changed the value in PaperUI.
I can imagine that the thermostat does not support all modes. But al least OFF (0) should be there. Further one to switch between occupied and unoccupied heating, I guess this is Sleep - right?
all system modes - openhab.log (50.2 KB)
Looking at the logs, the response always seems to use attributeidentifier=0.
Is this correct?
Yes (or No) - I also just noticed this. This is incorrect. The device should respond with the same attribute ID as the write command.
Can you please enable logging with -:
log:set debug com.zsmartsystems.zigbee.dongle.ember.internal.ash
And send a mode command again.