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.
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.
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)
I think this is ok. The device is actually sending the short version of the report - so it doesn’t include the attribute IDs in the list. This is (IFRC) allowed in the standard if all requests return SUCCESS, but the ZSS ZigBee framework is just logging this incorrectly.
So, we’re back to the position where the binding correctly sends the data, and the device responds with SUCCESS, but nothing changes.
If OH is sending the correct command to the device but this does not behave accordingly, this seems to be a problem with the hardware, we can’t solve by software.
I think I need to get in touch with Eurotronic to get it solved. Or do you see any other option?
I’m pretty confident that the binding will be sending the right thing - the logs show what is being sent to the NCP and it looks ok. We also support this for a number of large companies, and it was recently ZigBee certified for a Smart Energy product. So, from what I’ve seen, this looks fine. I also just checked the data type is correct in the device manual, and it seems to agree with the ZigBee definition which is what the ZSS library uses.
There is one thing that makes me wonder:
If OH behaves correctly, why doesn’t the value in Paper UI change?
Is it because the actual value needs to be send by the device after it has changed this?
Probably it’s related to how the item is configured, but what matters is what gets sent to the device and we can clearly see that in the logs. I solely focus on the device communication - what the binding receives from the user (be it from the UI, a rule, or the REST interface, or anywhere else) and what gets sent to the device.
