Support for other sensors

[lucaci32u4]

Hi,
I find your project really useful for building custom home automation on zigbee.

I'd like to contribute by implementing more sensor/actuator support. I'm especially interested in rotary encoders as sensors and light outputs. I suppose interrupt support for encoders would be useful, but will this break any other parts of the application?

Any pointers where I should start to look to implement these?

[Hedda]

Could sensor components be ported from ESPHome?

https://esphome.io/

https://github.com/esphome/esphome

Also check out the code for the projects linked in this discussion:

#15

These DIY device projects use other custom Zigbee firmware with different sensors:

https://github.com/rbaron/b-parasite

https://github.com/diyruz

https://www.tindie.com/stores/diyberk/

https://github.com/mattlokes/zwallremote

https://github.com/MattWestb/DIY-ZigBee-smoke-dektor

https://databyte.ch/project/

https://github.com/pvvx/ZigbeeTLc

https://www.zigbee2mqtt.io/supported-devices/#v=Custom%20devices%20(DiY)

[ffenix113]

Hello,
Thank you for the question and interest in this project!

For now adding new sensors could fall into one of two categories based on the fact if the sensor is supported(or otherwise has drivers) for Zephyr:

• If it is supported - it could be as simple as adding a sensor definition and its configuration. For example as in Bosch BME280 sensor. It needs to define available clusters, KConfig options(if any), and devicetree definition.
• If it is NOT supported - it can be a quite a bit more complex:
• • If some open-source drivers are available - they can be added to this repo as a Zephyr module and then used as in point one. Example of commit adding a module can be found here.
• • If drivers are not available - probably the simpler option would be to write implementation in the template definition for sensor, like in this file, for example. It uses Zephyr sensor API, but it is not limited to only use it.

In both cases the sensor should also have Zigbee cluster(s) defined, and that could also be something that should be implemented, if necessary cluster is not yet available.

I will add a section on support for new sensors and will update this issue to add a link to it.

Could sensor components be ported from ESPHome?

Not directly, at least. ESPHome uses C++, while currently this project is C. I also have plans to switch to C++ for zigbee_home, but have higher priorities for now.
I think that with some compatibility layer from ESPHome it should be doable otherwise.

[ffenix113]

For near future this will be the doc on supporting new sensors: https://ffenix113.github.io/zigbee_home/sensors/supporting_new_sensors/

It is not complete, as I want to try and describe as much as possible related to supporting sensors, so keep an eye on updates.