first of all, thank you for this project. Looks really promising.
I wanted to generate a firmware using on_off sensor. If I try to build the generated project it fails with the following errors:
/home/lescho/Devel/zigbee_home/cli/firmware/src/main.c:197:17: warning: implicit declaration of function 'sensor_sample_fetch' [-Wimplicit-function-declaration]
197 | sensor_sample_fetch(base_onoff_1_2);
| ^~~~~~~~~~~~~~~~~~~
/home/lescho/Devel/zigbee_home/cli/firmware/src/main.c:197:37: error: 'base_onoff_1_2' undeclared (first use in this function)
197 | sensor_sample_fetch(base_onoff_1_2);
| ^~~~~~~~~~~~~~
/home/lescho/Devel/zigbee_home/cli/firmware/src/main.c:197:37: note: each undeclared identifier is reported only once for each function it appears in
/home/lescho/Devel/zigbee_home/cli/firmware/src/main.c:198:17: warning: implicit declaration of function 'zbhome_sensor_fetch_and_update_on_off' [-Wimplicit-function-declaration]
198 | zbhome_sensor_fetch_and_update_on_off(base_onoff_1_2, 2);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: /usr/bin/cmake --build /home/lescho/ncs/v2.5.2/build
Using a configuration that is only using bme680/i2c sensor produces a project that can be built without issues.
It seems that the files for the on_off sensor are not generated. Maybe I missed something?
# Format for this file is not stable, and can change at any time.
general:
# Defines how much time a loop will sleep after each iteration.
runevery: 1m
board: nrf52840dongle_nrf52840
# This paths are necessary to build the generated firmware.
# If nRF Connect setup was done with VS Code extension -
# most probably this can be left empty, but if version changes -
# new path would need to be set here.
# Paths specified here can start with `~/`, and contain
# environmental variables, which will be resolved.
# This values have sane defaults and point to ~/ncs/...
# Env variables NCS_TOOLCHAIN_BASE & ZEPHYR_BASE have
# priority over this fields.
#ncs_toolchain_base: ~/toolchains/7795df4459/
#zephyr_base: ~/ncs/zephyr
# zigbee_channels will provide optional list of channels to use.
# Note: if not defined device will use all available channels,
# so it is not needed to define this if not specifically necessary.
zigbee_channels: [11,13,15,16,17]
# Flasher tells which flashing method to use.
# Currently `nrfutil`, `mcuboot` and `west`
# are defined(but not equally tested). Nrfutil works though.
flasher: nrfutil
# Flasheroptions are flasher-specific options
flasheroptions:
port: /dev/ttyACM1
# This section is for defining peripherals
# on the board. I.e. uart, spi, i2c, etc.
# NOTE: Only changes should be defined here.
# See https://github.com/zephyrproject-rtos/zephyr/tree/main/boards/<arch>/<board_name>/<board_name>.dts
# for existing definitions for the board.
# For example nRF52840 Dongle would have board devicetree at
# https://github.com/zephyrproject-rtos/zephyr/tree/main/boards/arm/nrf52840dongle_nrf52840/nrf52840dongle_nrf52840.dts
board:
# Specifically define bootloader for the board.
# This field is optional, and in most cases this might not be needed.
# But it is possible that board can be flashed
# with some non-default bootloader, or that the generated firmware is not
# placed correctly in memory. This setting can help in above situations.
# Also this option can be used to try and support boards that
# are not labeled as officialy supported.
#bootloader: nrf52_legacy
# This option will add UART loging functionality.
# User can choose which console to use(usb or uart).
# UART has to be defined either in default device tree,
# or in `board.uart` section.
# Quite limited for now, but can be easily extended
debug:
enabled: false
console: uart0
leds:
enabled: true
# Define led which will be used to show that the board is powered.
power: led_green
# Change device type from sleepy end device to router.
# This allows for device to always be available from coordinator
# and other devices.
# By default device will be configured as sleepy end device.
# Note: Enabling router will increase the size of the firmware.
is_router: false
# I2C is optional, only to provide different pins for i2c instance(s)
i2c:
# ID of instance is the same as defined in the SoC definition.
# Generally they are in form of `i2c[0-9]`.
# Number of i2c instances is also limited, and this allows only to
# re-define pins for specified i2c instance.
- id: i2c0
sda: 0.29
scl:
port: 0
pin: 31
uart:
- id: uart0
tx: 1.03
rx: 1.10
leds:
- id: led_green
pin:
port: 0
pin: 6
inverted: true
sensors:
# - type: bme680
# i2c:
# id: i2c0
# addr: '0x76'
# - type: scd4x
# i2c:
# id: i2c0
# - type: device_temperature
# on_off is a sensor that will respond to on/off state of the pin.
# For now verifyied to be controlled by the client only,
# so not by actually changing the state of the pin manually.
- type: on_off
pin:
# This is Green LED(LD1) on nrf52840 Dongle
port: 0
pin: 6
inverted: true