Reinitialisation did not change anything.
Still unidirectional.
openhab.log (759.3 KB)
The configuration looks fine to me. The binding and reporting are set by the binding, and acknowledged by the device.
If I change the setpoint in OH this takes effect at the device. But not in the other direction.
From what I can tell from the log, the binding is correctly setting the reporting - or at least some of the setpoints based on this log and the temperature. The device has acknowledged that, so it should work
Is there something more I can do to debug this?
Not that I can think of - if there’s absolutely nothing being received in the debug logs when configured as per the binding documentation, then I’m out of ideas.
I will setup a vanilla system tomorrow and see if that helps.
I don’t expect it will make much difference from the OH side - from what you’ve shown it looks like everything is working fine on the binding side.
I’m not sure - I don’t have it set up as I don’t use it personally.
This is standard ZigBee stuff though - binding and reporting is used everywhere. We use this with thousands of thermostats with one of our customers.
I have 8 identical devices - all bought in second half of 2019 and all behave the same way.
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).