Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • eclipse/oniro-blueprints/oniro-blueprints-docs/docs
  • gwozdzcfs/docsbps
  • kristis/blueprints-docs
  • stefanschmidt/docs
  • pcoval/oniro-blueprints-docs
  • mrfrank/docs
6 results
Show changes
Commits on Source (29)
Expand all Hide whitespace changes
Inline Side-by-side
Showing
with 689 additions and 780 deletions
assets/cats-hardware-setup.jpg 0 → 100644
View file @ 48056d5a
assets/cats-hardware-setup.jpg

3.12 MiB

cats.rst 0 → 100644
View file @ 48056d5a
.. SPDX-FileCopyrightText: Huawei Inc.
..
.. SPDX-License-Identifier: CC-BY-4.0
Context-Aware Touch-Screen Blueprint
####################################
.. contents::
:depth: 4
Overview
********
The Context-Aware Touch-Screen (CATS) blueprint demonstrates a smart
touch-screen that is able to control multiple devices over a network.
Wired communication over ethernet as well as wireless communication over Wi-Fi
and low-power Thread mesh network.
A device manufacturer using Oniro can utilise a CATS panel in a one-to-many
or one-to-one design to allow a standardised touch panel using a defined API
to be easily integrated into their products, yet control others.
With extensibility as a core principle of Oniro, CATS code is written in a such
a way that extending CATS is easy with modular virtual screens created using
the `Light and Versatile Embedded Graphics Library (LVGL) <https://lvgl.io/>`_.
This blueprint demonstrates the use-case in which the user controls a doorlock
which is connected in the Thread network.
The CATS panel displays the doorlock's keypad and sends the keys that are being
pressed to the doorlock which ultimately locks/unlocks the doorlock when the
inserted PIN is correct.
Doorlock Blueprint Setup
------------------------
If you would like to try out the doorlock blueprint controlled by CATS, in
addition to the current guide, follow the :doc:`doorlock blueprint
documentation <doorlock>` to build the doorlock.
Hardware Setup
**************
Bill of Materials
-----------------
- 1x `Raspberry Pi 4B board
<https://www.raspberrypi.com/products/raspberry-pi-4-model-b/>`_ (>=2GB RAM)
- 1x `Raspberry Pi USB-C Power supply
<https://www.raspberrypi.com/products/type-c-power-supply/>`_
- 1x microSD card (>=8GB size)
- 1x Arduino Nano 33 BLE
- 1x `USB serial cable <https://www.adafruit.com/product/954>`_ (optional)
- 1x `7inch HDMI LCD Display, Waveshare, Rev3.1 or Rev2.1
<https://www.waveshare.com/wiki/7inch_HDMI_LCD_(C)>`_ (comes with USB and
HDMI cable)
- 1x HDMI to micro-HDMI adapter
The setup of the hardware components is illustrated in the hardware setup image:
.. image:: assets/cats-hardware-setup.jpg
:alt: CATS Hardware setup
Connect the touch-screen display to the Raspberry Pi board:
- Connect the display's HDMI input through a micro-HDMI adapter to the
connector labeled HDMI0 on the Raspberry Pi 4B board (see the image above).
- Connect the display's power + touchscreen port to one of the Raspberry Pi 4B
board USB ports.
For the Raspberry Pi 4 you need to perform a few more steps for completing the
setup:
- Insert the Arduino Nano 33 BLE in one of the USB ports this will act as
OpenThread Radio Co-Processor.
- Insert the micro SD card, and the USB-C power supply can wait until the
software is build and flashed.
Optionally, a USB to TTL serial cable can be connected as a serial console for
debugging. A detailed description of connecting the cable can be found `on the
connect the lead page
<https://learn.adafruit.com/adafruits-raspberry-pi-lesson-5-using-a-console-cable/connect-the-lead>`_.
An alternative to the serial console is to SSH over the local network
connection.
Fetch Blueprint Sources and Build
*********************************
Fetch the Build Metadata
------------------------
For fetching or updating the build metadata, follow the :ref:`blueprints
workspace documentation <Workspace>`. Doing so, brings everything you need on
your host to start building an image for this blueprint. For this specific
build, you need to clone `meta-oniro-blueprints-cats
<https://gitlab.eclipse.org/eclipse/oniro-blueprints/context-aware-touch-screen/meta-oniro-blueprints-cats>`_.
.. code-block:: console
$ git clone --recurse-submodules https://gitlab.eclipse.org/eclipse/oniro-blueprints/context-aware-touch-screen/meta-oniro-blueprints-cats.git
.. note::
Make sure you define or replace `CHECKOUT_DIR` as described in
:ref:`blueprints workspace documentation <Workspace>`.
Build the Oniro Image for CATS
-------------------------------------
Once you have a workspace initialized as per the instructions in the preceding
section, you are ready to build the OS. Firstly, you initialize a build
directory:
.. code-block:: console
$ cd $CHECKOUT_DIR
$ TEMPLATECONF=../oniro/flavours/linux . ./oe-core/oe-init-build-env build-oniro-linux
Executing the command sets up a new build environment in the
`build-oniro-linux` directory (or reuse it, if it already exists).
Next we add the blueprint layers, this is only needed once after initializing
a new build:
.. code-block:: console
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-oniro-blueprints-cats/meta-oniro-blueprints-core
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-oniro-blueprints-cats/meta-oniro-blueprints-cats
Once the build environment is set, start building the image.
.. code-block:: console
$ DISTRO="oniro-linux-blueprint-cats" MACHINE=raspberrypi4-64 bitbake blueprint-cats-gateway-image
Once the build finishes, the image is ready to be flashed on a microSD card.
Flash
-----
Ensure that you have plugged in an microSD card via an microSD card reader
attached to your host. Once that is done, note its associated device node.
You can find that using `udev`, `dmesg` or various other tools. Once the device
node associated to the microSD card is known, proceed to flash the built image.
.. warning::
The following commands assume that the device node associated with the
microSD card is provided via the `DEVICE` environment variable. Make sure
you have the correct one set before running the commands to avoid
risking the loss of data.
The image to flash is a full disk image, so the `DEVICE` variable needs to
point to the entire block device node, and not to a specific partition.
.. code-block:: console
$ sudo bmaptool copy ./tmp/deploy/images/raspberrypi4-64/blueprint-cats-gateway-image-raspberrypi4-64.wic.gz "$DEVICE"
.. note::
If the device that needs to be flashed had existing partitions, you may
need to unmount the existing partitions using the `umount` command.
Prepare OpenThread Radio Co-Processor (RCP)
------------------------------------------------------
Build a OpenThread radio co-processor firmware for the Arduino Nano 33 BLE, this
will act as a Thread radio for the Raspberry Pi board.
To build the RCP image initialize a new build environment using the Zephyr
build flavour:
.. code-block:: console
$ TEMPLATECONF=../oniro/flavours/zephyr . ./oe-core/oe-init-build-env build-oniro-zephyr
Run the following command from the newly created build environment:
.. code-block:: console
$ MACHINE=arduino-nano-33-ble DISTRO=oniro-zephyr bitbake zephyr-openthread-rcp
After building the image, we can now flash the Arduino board. Prepare the board
by connecting the board's USB port to your computer and putting the board into
flashing mode by double-pressing the reset button.
Next, use the following command to flash the board:
.. code-block:: console
$ MACHINE=arduino-nano-33-ble DISTRO=oniro-zephyr bitbake zephyr-openthread-rcp -c flash_usb
Once flashed the Arduino board you can connect it into one of the USB ports on
the Raspberry Pi board.
.. note::
The *nRF52840 DK* and *nRF52840 Dongle* are alternative boards that can also
be used as RCP. In order to build and flash one of these boards, please
replace the `MACHINE` variable to ``nrf52840dk-nrf52840`` or
``nrf52840-mdk-usb-dongle`` accordingly.
Use CATS
********
At this point, we have the hardware ready and we can run the blueprint.
Plug in the microSD card on which you flashed the OS into the board's microSD
card slot. That brings us to the last step: booting the board by attaching the
power source. On a Raspberry Pi 4B, that would be a USB-C power supply.
When the CATS app loads, it presents the main screen with Oniro logo. The user
can swipe left and right to traverse a set of screens.
You will be able to switch between the following screens:
* main: simple screen with Oniro logo.
* keypad: numeric keypad screen which can be used to control the doorlock.
* demo: includes the demo screen that showcases animations and widgets.
* settings: screen with setting options for example to change the light/dark
theme.
* Developer settings: screen containing developer options.
Doorlock Zephyr Node Onboarding
-------------------------------
If you completed the :doc:`doorlock blueprint setup <doorlock>`, before we can
control the doorlock with CATS we have to onboard the doorlock Zephyr node in
the OpenThread network.
Follow the instructions in the `transparent gateway documentation
<transparent-gateway.html#run-the-gateway-blueprint>`_ to onboard the
mesh node.
Once you completed the onboarding process you will be able to control the
doorlock using CATS. First of all, using the keypad screen in CATS, the first
four digits you enter will be used as the new PIN and then using the same PIN
you can lock/unlock the doorlock.
See the doorlock blueprint documentation for more information.
Resources
*********
.. _ResourcesTG:
- `Demo video of CATS blueprint used to operate a safe box
<https://www.youtube.com/watch?v=1SxcqvR_QUI>`_
conf.py
View file @ 48056d5a
......@@ -46,6 +46,9 @@ copyright = '2021'
author = 'Oniro Project'
version = 'dunfell'
#probably has to be changed to kirkstone
release = version
# -- General configuration ---------------------------------------------------
......
doorlock.rst
View file @ 48056d5a
This diff is collapsed.
index.rst
View file @ 48056d5a
......@@ -67,11 +67,10 @@ This section details the available blueprints provided as part of the |main_proj
.. toctree::
:maxdepth: 1
smart-panel
doorlock
keypad
transparent-gateway
vending-machine
cats
Blueprint Hardware
******************
......
keypad.rst deleted 100644 → 0
View file @ fdace385
.. SPDX-FileCopyrightText: Huawei Inc.
..
.. SPDX-License-Identifier: CC-BY-4.0
.. include:: ./definitions.rst
KeyPad Blueprint
#####################
.. contents::
:depth: 4
.. attention::
The `TouchPannel` blueprint is still a work in progress (WIP). For more
information, see the :ref:`resources <Resources>` section.
Overview
********
The KeyPad Blueprint provides support for building a PoC smart touch panel that can be used in other smart devices to accept input and display status. Some features to demonstrate include:
#. Accepting input from a keypad
#. Accepting input from UI icons on a touch panel
#. Ability to send input data securely over the network
.. image:: assets/keypad-nRF52840.jpg
:alt: Keypad on nRF52840-DK
Hardware Setup - Bill of Materials
**********************************
The current version of keypad can be deployed to Nordic's nRF52840-DK
- 1 x `nRF52840-DK
<https://www.nordicsemi.com/Products/Development-hardware/nRF52840-DK>`_
- 1 x `2.8" TFT Touch Shield for Arduino w/Capacitive Touch
<https://www.adafruit.com/product/1947>`_
- 1 x Micro USB cable
Get sources
***********
Get or update the |main_project_name| sources as described in the
:ref:`blueprints workspace documentation <Workspace>`.
The quick steps are detailed as follows:
.. code-block:: bash
$ export CHECKOUT_DIR=~/oniroproject
$ mkdir -p "${CHECKOUT_DIR}" ; cd "$CHECKOUT_DIR"
$ # Download sources
$ repo init -u https://booting.oniroproject.org/distro/oniro -b dunfell
$ git clone https://booting.oniroproject.org/distro/meta-oniro-blueprints --branch dunfell --depth 1
$ git clone https://github.com/meta-homeassistant/meta-homeassistant --branch dunfell --depth 1
$ repo sync
$ # Configure environement and build directory for supported hardware
$ TEMPLATECONF=../oniro/flavours/zephyr . ./oe-core/oe-init-build-env build-oniro-zephyr
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-homeassistant
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-oniro-blueprints
$ export MACHINE=nrf52840dk-nrf52840
$ # Build firmware image
$ bitbake zephyr-blueprint-keypad
$ du -hs ./tmp-newlib/deploy/images/nrf52840dk-nrf52840/zephyr-blueprint-keypad.bin # 148K
Then plug the board to USB connector (the one near the battery), then it should be detected by Linux system:
.. code-block:: bash
$ sudo dmesg
[...] usb 2-1.7: Product: J-Link
[...] usb 2-1.7: Manufacturer: SEGGER
(...)
$ ls /dev/disk/by-id/usb-SEGGER_MSD_Volume_*
$ sudo mkdir /tmp/usb
$ sudo mount /dev/disk/by-id/usb-SEGGER_MSD_Volume_*-0\:0 /mnt/usb
$ sudo cp -v /tmp-newlib/deploy/images/nrf52840dk-nrf52840/zephyr-blueprint-keypad.bin /mnt/usb
Display should show the keypad on reset.
Resources
=========
.. _Resources:
- See `KeyPad's requirement <https://git.ostc-eu.org/OSTC/planning/blueprints/-/issues/1>`_
smart-panel.rst deleted 100644 → 0
View file @ fdace385
.. SPDX-FileCopyrightText: Huawei Inc.
..
.. SPDX-License-Identifier: CC-BY-4.0
.. include:: ./definitions.rst
Smart Panel Blueprint
#####################
.. contents::
:depth: 4
Overview
********
The Smart Panel Blueprint provides support for building a PoC for a home
automation system with components showing the capabilities of the build
infrastructure in leveraging different kernels for building an end to end
solution.
The setup is composed of an Avenger96 board acting as a gateway and running
HomeAssistant. The gateway also provides UI as a browser connected to the
localhost HomeAssistant server. The gateway is connected over Bluetooth to two
Nitrogen boards exposing sensors and/or actuator (e.g. controlled light source).
.. image:: assets/smart-home-blueprint-arch.png
.. uml::
title
<b>High level connection diagram
end title
node "Avenger96" #11AAFF {
[Linux]
}
node "Nitrogen #1" #116699 {
[Zephyr#1]
}
node "Nitrogen #2" #116699 {
[Zephyr#2]
}
[LED] #3BB300
[LCD] #3BB300
[MotionSensor] #3BB300
[HumidityTemperature] #3BB300
[Display]
[Linux] --> [Display] : HDMI
[Zephyr#1] --> Linux : BLE
[Zephyr#1] --> LCD : I2C
[Zephyr#1] <-- MotionSensor : I2C
[Zephyr#1] <-- HumidityTemperature : GPIO
[Zephyr#2] <-- Linux : BLE
[Zephyr#2] --> LED : GPIO
legend
|= Legend: |
|<back:#11AAFF>Avenger96:96Boards</back>|
|<back:#116699>Nitrogen:96Boards</back>|
|<back:#3BB300>Grove sensors</back>|
endlegend
[Human] --> [Display]
Bill of materials
*****************
IoT controller (Avenger96)
--------------------------
Equipment
^^^^^^^^^
* 1x 96Boards Avenger96
* 1x Power supply 12 V minimum 2 A,
* 1x microSD card at least 8 GB,
* 1x HDMI touch screen,
Cables and connectors
^^^^^^^^^^^^^^^^^^^^^
* 1x HDMI-HDMI.
* 1x microUSB-USB type A cable.
* 1x Ethernet cable.
IoT devices (Nitrogens)
-----------------------
Equipment
^^^^^^^^^
* 2x 96Boards Nitrogen,
* 2x Grove Mezzanine board,
* 1x Grove LED module,
* 1x Grove DHT11 temperature and humidity sensor,
* 1x Grove AK9753 human presence sensor,
* 1x Grove LCD RGB Backlight screen,
Cables and connectors
^^^^^^^^^^^^^^^^^^^^^
* 4x Grove connector cables,
* 2x microUSB cable.
Assembly
********
IoT controller
--------------
#. Connect the screen's display output with the board using HDMI cable.
#. Connect the screen's touch controller with the board using USB cable.
#. The board to a network with DHCP server configured using the Ethernet cable.
#. Do not insert the microSD card into the board's slot. It will be needed for
flashing.
#. Connect power supply to the power jack.
.. image:: assets/smarthome-blueprint-assembled.jpg
:alt: The whole assembled setup with labels
IoT devices
-----------
#. Connect Grove Mezzanine boards to both Nitrogen boards. One of them will act
as a light switching device, the other as sensors device.
#. Assemble the light switching device:
* Connect Grove LED module to GPIO IJ port on the Mezzanine board.
#. Assemble the sensors device:
* Connect Grove DHT11 module to GPIO GH port on the Mezzanine board,
* Connect Grove AK9753 module to GPIO KL port on the Mezzanine board,
* Connect Grove LCD module to I2C0 port on the Mezzanine board,
#. Connect Nitrogens to your computer with microUSB cables.
Get sources
***********
Get or update |main_project_name| sources as described in the :ref:`blueprints
workspace documentation <Workspace>`.
.. note::
Mind the `CHECKOUT_DIR` variable in the workspace documentation as you will
need them below.
Prepare IoT devices (Nitrogen/Zephyr flavour)
*********************************************
Build
-----
#.
Create build directory
.. code-block:: bash
$ TEMPLATECONF=../oniro/flavours/zephyr . ./oe-core/oe-init-build-env build-oniro-zephyr-96b-nitrogen
#.
Edit ``conf/local.conf``, and uncomment the following line:
.. code-block:: bash
#MACHINE ?= "96b-nitrogen"
#.
Add the `meta-oniro-blueprints` layer to the build. This is only needed once
after initializing a new build:
.. code-block:: bash
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-homeassistant
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-oniro-blueprints
#.
Build ``zephyr-blueprint-smarthome-sensors`` image using ``bitbake``,
with the following override:
.. code-block:: bash
$ DISTRO=oniro-zephyr-blueprint-dashboard bitbake zephyr-blueprint-smarthome-sensors
.. note::
* The build will configure the MAC address with sane defaults. If you
want a custom MAC address, you can prepend to the command above the
following:
BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE SMART_HOME_SENSORS_MAC" SMART_HOME_SENSORS_MAC="<custom_mac_address>"
* The MAC address can have any value provided it starts with ``C0`` and
is unique in your environment.
#.
Make sure you have at least 3 GB of free space on the partition
where the build directory is located.
#.
Build ``zephyr-blueprint-smarthome-switch`` image using ``bitbake``,
with the following override:
* ``SMART_HOME_SWITCH_MAC`` set to MAC address of the IoT device.
**It must be different than the MAC address used in the previous step**.
.. code-block:: bash
$ DISTRO=oniro-zephyr-blueprint-dashboard bitbake zephyr-blueprint-smarthome-switch
.. note::
* The build will configure the MAC address with sane defaults. If you
want a custom MAC address, you can prepend to the command above the
following:
BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE SMART_HOME_SWITCH_MAC" SMART_HOME_SWITCH_MAC="<custom_mac_address>"
* The MAC address can have any value provided it starts with ``C0`` and
is unique in your environment.
Flash
-----
#.
Connect 96Boards Nitrogen boards to your computer.
#.
Assuming both boards are connected simultaneously, retrieve their IDs
.. code-block:: bash
$ pyocd list
# Probe Unique ID
---------------------------------------------------
0 Arch BLE [nrf51] 9009022103BB2A02FE6545F3
1 Arch BLE [nrf51] 9009022103BB3A2DFE6555DC
If you do not have PyOCD in your system, follow the guide in the PyOCD section of the
`Nitrogen documentation <https://docs.oniroproject.org/en/latest/oniro/hardware-support/boards/96b-nitrogen.html#supportedboardnitrogenpyocd>`_.
#.
Flash the first board with ``zephyr-blueprint-smarthome-sensors`` image. Use the same
command you used for build, with the following changes:
* add ``-c flash_usb`` suffix,
* remove the MAC address override (it is only effective at build time),
* add board ID override in the form of:
``BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE PYOCD_FLASH_IDS" PYOCD_FLASH_IDS="<id>"``
.. code-block:: bash
$ BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE PYOCD_FLASH_IDS" \
PYOCD_FLASH_IDS="9009022103BB2A02FE6545F3" bitbake zephyr-blueprint-smarthome-sensors -c flash_usb
#.
Flash the other board with ``zephyr-blueprint-smarthome-switch`` image
.. code-block:: bash
$ BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE PYOCD_FLASH_IDS" \
PYOCD_FLASH_IDS="9009022103BB3A2DFE6555DC" bitbake zephyr-blueprint-smarthome-switch -c flash_usb
Prepare IoT controller (Avenger96/Linux flavour)
************************************************
Build
-----
#.
Create build directory
.. code-block:: bash
$ TEMPLATECONF=../oniro/flavours/linux . ./oe-core/oe-init-build-env build-oniro-linux-stm32mp1-av96
#.
Edit ``conf/local.conf``, and uncomment the following line:
.. code-block:: bash
#MACHINE ?= "stm32mp1-av96"
#.
Add the `meta-oniro-blueprints` layer to the build. This is only needed once
after initializing a new build:
.. code-block:: bash
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-homeassistant
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-oniro-blueprints
#.
Make sure you have at least 25 GB of free space on the partition
where the build directory is located.
#. Build ``blueprint-dashboard-gateway-image`` image using ``bitbake``,
with the following overrides:
* ``DISTRO`` set to ``oniro-linux-blueprint-dashboard`` --
this distribution configuration enhances the regular distribution
with dependencies necessary for this demonstration scenario,
* ``SMART_HOME_SENSORS_MAC`` and ``SMART_HOME_SWITCH_MAC`` set to MAC
addresses of IoT devices, as set in the previous section.
.. code-block:: bash
$ DISTRO=oniro-linux-blueprint-dashboard \
BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE SMART_HOME_SENSORS_MAC SMART_HOME_SWITCH_MAC" \
SMART_HOME_SENSORS_MAC="C0:BA:DD:06:F0:0D" \
SMART_HOME_SWITCH_MAC="C0:BA:DD:06:F0:0E" \
bitbake blueprint-dashboard-gateway-image
Flash
-----
#.
Build artifacts are located in ``./tmp/deploy/images/stm32mp1-av96/`` relative
to the build directory. Flashing script is located in
``./scripts/create_sdcard_from_flashlayout.sh`` relative to the build artifacts
directory. FSD card flash layout used to convert build artifacts to the image is
located in ``flashlayout_<image name>/extensible/FlashLayout_sdcard_stm32mp157a-av96-extensible.tsv``
relative to the build artifacts directory.
#.
Go to the build artifacts directory and convert flash layout into a build image
.. code-block:: bash
$ cd tmp/deploy/images/stm32mp1-av96
$ ./scripts/create_sdcard_from_flashlayout.sh \
flashlayout_blueprint-dashboard-gateway-image/extensible/FlashLayout_sdcard_stm32mp157a-av96-extensible.tsv
#.
Lots of text will appear, but the most important part are the two commands
.. code-block:: bash
WARNING: before to use the command dd, please umount all the partitions
associated to SDCARD.
sudo umount `lsblk --list | grep <sd card name> | grep part | gawk '{ print $7 }' | tr '\n' ' '`
To put this raw image on sdcard
sudo dd if=<image>.raw of=<sd card node> bs=8M conv=fdatasync status=progress
#. Put a microSD card in your card reader. Copy the commands above and paste them
into your terminal. Do not remove the microSD card from the reader just yet.
Add Bluetooth firmware
----------------------
Due to licensing details, |main_project_name| cannot provide the firmware file for
the on-board Bluetooth controller. However, user may download and install it
manually.
#. Download the `Bluetooth firmware file from GitHub <https://github.com/dh-electronics/meta-av96/raw/9d2a3fdacf49aebc9298a7c444f5a021d3e99e13/recipes-bsp/firmware-files/files/lib/firmware/brcm/BCM4345C0.hcd>`_.
#. Create directory ``lib/firmware/brcm`` on the ``rootfs`` partition of the
microSD card and copy the downloaded file into that directory. Assuming your
card's mount point is ``/mnt/rootfs``, you may use the example commands to
accomplish that:
.. code-block:: bash
$ sudo mkdir /mnt/rootfs/lib/firmware/brcm
$ sudo cp ~/Downloads/BCM4345C0.hcd /mnt/rootfs/lib/firmware/brcm
$ sudo chmod 755 /mnt/rootfs/lib/firmware/brcm
#. Unmount all microSD card partitions, remove them from the reader and put
it in Avenger96 card slot. Power up the board.
Home Assistant
**************
Set up
------
#. Put ths SD card into Avenger96 and press power on button.
#. On start up, Avenger96 will try to contact a DHCP server. Be sure to
have one in your network, where you can see the IP address assigned to
the board. Alternatively, you can use UART-USB adapter, log in to the
system and set IP address manually.
#. Using a web browser, go to the IP address of Avenger96, port ``8123``.
E.g. if you find out the Avenger's IP address is ``192.0.2.137`` , go to
``http://192.0.2.137:8123``.
#. Create a user account and click your way through the basic settings.
#. You should find yourself in Home Assistant dashboard. Three circular
icons on top show temperature, humidity and human presence.
.. image:: assets/smarthome-blueprint-dashboard.png
:alt: Home Assistant dashboard
Customizing the Dashboard
-------------------------
#. Click three vertical dots in the top-right corner of the dashboard
and select ``Configure UI``.
#. Agree to take control over the UI, remove the default widgets and
click the yellow ``+`` button in the bottom-right corner of the dashboard.
#. Choose widgets according to your taste. They are already pre-configured,
connected to the existing sensors (temperature, humidity, human presence)
and light controls.
#. Adjust widgets configuration according to your taste. Most notable
possibility is that you can combine multiple entities in one widget,
e.g. creating a single widget with all the sensors and a light control
switch.
.. image:: assets/smarthome-blueprint-dashboard-config.png
:alt: Home Assistant dashboard configuration
.. image:: assets/smarthome-blueprint-dashboard-config-done.png
:alt: Home Assistant dashboard finished configuration
Set up automations
------------------
Home Assistant can do things for you based on state sensors. This is how
Home Assistant can be configured to turn the light on/off based on
user presence nearby the human presence sensor. Imagine it is a kitchen
light turning on every time it detects you are about to prepare a meal!
#. Go to Configuration menu using the cog button located on the left-hand
sidebar, then to Automations.
#. Click the yellow ``+`` button in the bottom-right corner of the screen, then
skip the smart automations generator.
#. Name your automation accordingly, e.g. *Lights on when somebody in the room*.
#. Set the trigger as follows:
* Trigger type: ``State``,
* Entity: ``sensor.all_scenarios_os_smarthome_device_presence``,
* From: ``False`` (*person not detected*).
* To: ``True`` (*person detected*)/
.. image:: assets/smarthome-blueprint-dashboard-automations-trigger.png
:alt: Home Assistant dashboard automations trigger
#.
Set the action as follows:
* Action type: ``Call service``,
* Service: ``switch.turn_on``,
* Name(s) of entities to turn on: ``switch.all_scenarios_os_smarthome_device_light``.
.. image:: assets/smarthome-blueprint-dashboard-automations-action.png
:alt: Home Assistant dashboard automations action
#.
Click the yellow save button in the bottom-right corner of the screen.
#. Repeat steps 2-6 for the opposite automation, i.e. turning the light off,
when human presence state switches from ``True`` to ``False``.
Verify operations
*****************
#. Temperature and humidity readings should show temperature and humidity
in the room where the Nitrogen with sensors is located. Try to blow
hot/cold air on the sensor to see values changing
#. Human presence state should change when you move your hand close to
the sensor.
#. The light switch should control the LED.
#. The LED should turn on/off automatically when human presence is detected.
#. The LCD screen should display the current temperature, humidity
and the connection state marked with a ``<B>`` symbol.
transparent-gateway-details.rst
View file @ 48056d5a
......@@ -5,86 +5,69 @@
Transparent Gateway Blueprint Details
#####################################
The following section details about various specifics of the Transparent Gateway Blueprint. The details include the basic networking subnet, configuration, Wi-Fi, and OpenThread connectivity details.
The following section details about various specifics of the Transparent Gateway
Blueprint. The details include the basic networking subnet, configuration,
Wi-Fi, and OpenThread connectivity details.
.. _MDK-rcp-flash:
.. _rcp-flash:
Build and Flash the Radio Co-Processor Firmware
***********************************************
Build a OpenThread radio co-processor firmware for the Arduino Nano 33 BLE, this
will act as a Thread radio for the Raspberry Pi board.
To allow the Raspberry Pi 4 to participate in an OpenThread wireless network, add a radio interface, as the Raspberry Pi 4 lacks on-board radio hardware to support it.
To build the RCP image initialize a new build environment using the Zephyr
build flavour:
In this blueprint, the Makerdiary nrf52840 MDK USB dongle is used to provide the radio functionality. To enable our use case of an OpenThread border router, you need to compile and flash a fitting firmware image to the device.
.. code-block:: console
The current manual process is quite intricated, but expect vast improvements in future iterations of the blueprint.
$ cd $CHECKOUT_DIR
$ TEMPLATECONF=../oniro/flavours/zephyr . ./oe-core/oe-init-build-env build-oniro-zephyr
- Setup the OpenThread environment as follows:
Run the following command from the newly created build environment:
.. code-block:: bash
$ docker pull openthread/environment:latest
$ docker run -it --rm openthread/environment bash
- Inside the docker container prepare the build as follows:
.. code-block:: bash
$ rm -rf openthread/
$ git clone --recursive https://github.com/openthread/openthread.git
$ cd openthread
$ git checkout thread-reference-20191113-1633-g4d50cbadb -b mdk-rcp
$ ./bootstrap
- Build the radio co-processor (RCP) firmware image as follows:
.. code-block:: console
.. code-block:: bash
$ make -f examples/Makefile-nrf52840 USB=1 BOOTLOADER=USB JOINER=1
$ MACHINE=arduino-nano-33-ble DISTRO=oniro-zephyr bitbake zephyr-openthread-rcp
- Convert the firmware into the correct format for flashing as follows:
After building the image, we can now flash the Arduino board. Prepare the board
by connecting the board's USB port to your computer and putting the board into
flashing mode by double-pressing the reset button.
.. code-block:: bash
Next, use the following command to flash the board:
$ arm-none-eabi-objcopy -O ihex output/nrf52840/bin/ot-rcp output/nrf52840/bin/ot-rcp.hex
$ wget https://raw.githubusercontent.com/makerdiary/nrf52840-mdk-usb-dongle/master/tools/uf2conv.py
$ python3 ./uf2conv.py output/nrf52840/bin/ot-rcp.hex -c -f 0xADA52840
.. code-block:: console
The process creates a new file `flash.uf2`, which is the final firmware file needed.
$ MACHINE=arduino-nano-33-ble DISTRO=oniro-zephyr bitbake zephyr-openthread-rcp -c flash_usb
The following two commands need to be executed in a new shell while the docker instance is still running.
Once you flashed the Arduino board, it can be connected to one of the USB ports
on the Raspberry Pi board.
- Get container ID for the running instance as follows:
.. note::
.. code-block:: bash
$ docker container list
- Insert the container ID from above into the command below to copy the firmware file out of the container into your current directory:
.. code-block:: bash
$ docker cp $CONTAINER_ID:/openthread/flash.uf2 .
- Flash firmware onto the device as follows:
#. Switch the device into flash mode by holding down the button, while inserting the device into the USB port (a steady green LED next to the button indicates the device is in flash mode).
#. A new USB storage device appears (with name MDK-DONGLE).
#. Copy the `flash.uf2` file into the root folder of the USB storage.
#. Once copied, the bootloader writes the new firmware, and resets the device.
#. After the reset, only the main LED next to the USB plug remains steady green, which signifies that, it is now ready to be placed into the Raspberry Pi 4.
The *nRF52840 DK* and *nRF52840 Dongle* are alternative boards that can also
be used as RCP. In order to build and flash one of these boards, please
replace the `MACHINE` variable to ``nrf52840dk-nrf52840`` or
``nrf52840-mdk-usb-dongle`` accordingly.
.. _QR-gen:
Generate Onboarding QR Code
***************************
During the OpenThread onboarding process of the mesh node onto the OpenThread network, a QR code is used. The QR code holds the joiner credential, and the unique EUI64 address of the device to join.
During the OpenThread onboarding process of the mesh node onto the OpenThread
network, a QR code is used. The QR code holds the joiner credential, and the
unique EUI64 address of the device to join.
The joiner credential can be chosen freely, but ensure that it is identical in the firmware of the node to join, as well as in the QR code.
The joiner credential can be chosen freely, but ensure that it is identical in
the firmware of the node to join, as well as in the QR code.
In this blueprint the joiner credential is: J01NU5
The EUI64, basically the MAC address of the device, is hardware dependent and needs to be fetched from the device after flashing the generated firmware image. After accessing the serial console of the Arduino Nano 33 BLE, issue the *ot eui64* command to receive the address as follows:
The EUI64, basically the MAC address of the device, is hardware dependent and
needs to be fetched from the device after flashing the generated firmware image.
After accessing the serial console of the Arduino Nano 33 BLE, issue the
*ot eui64* command to receive the address as follows:
.. code-block:: bash
......@@ -96,43 +79,77 @@ The full string needed to be encoded in the QR code looks as follows:
`v=1&&eui=00124b001ca77adf&&cc=J01NU5`
The value for the EUI parameter needs to be replaced with the one received from
the device. The QR code needs to be generated in text format (not as an URL). A simple online QR generator can be found here: https://qrd.by/#text
the device. The QR code needs to be generated in text format (not as an URL).
A simple online QR generator can be found here: https://qrd.by/#text
Network Subnets and Configuration
*********************************
On the basis of the board you use, and its hardware configuration, the available network interfaces and their names may vary. In order to avoid confusion, the following interfaces are assumed to be available:
On the basis of the board you use, and its hardware configuration, the available
network interfaces and their names may vary. In order to avoid confusion, the
following interfaces are assumed to be available:
- **Ethernet interface eth0:** assumed to be uplink with DHCP enabled.
- **Wi-Fi interface wlan0:** Wi-Fi access point interface serving the Wi-Fi subnet.
- **OpenThread interface wpan0:** OpenThread border router interface serving the mesh network.
- **OpenThread interface wpan0:** OpenThread border router interface serving the
mesh network.
In terms of IP subnets, use the private 172.16.47.0/24 range on the Wi-Fi subnet. The Access point(AP) has 172.16.47.1/24 assigned to it. Clients are served DHCP leases in the range of 172.16.47.100 - 172.16.47.150. The default DNS servers are 9.9.9.9 (primary) and 8.8.8.8 (secondary) respectively. For IPv6, you can rely on address auto-configuration for the time being.
In terms of IP subnets, use the private 172.16.47.0/24 range on the Wi-Fi
subnet. The Access point(AP) has 172.16.47.1/24 assigned to it. Clients are
served DHCP leases in the range of 172.16.47.100 - 172.16.47.150. The default
DNS servers are 9.9.9.9 (primary) and 8.8.8.8 (secondary) respectively.
For IPv6, you can rely on address auto-configuration for the time being.
On the OpenThread mesh network subnet, no IPv4 is available, and again you can rely on address auto-configuration for the time being.
On the OpenThread mesh network subnet, no IPv4 is available, and again you can
rely on address auto-configuration for the time being.
Forwarding for IPv4 and IPv6 is enabled on all interfaces with `sysctl`.
Wi-Fi Access Point Configuration
********************************
Using the default Wi-Fi access point configuration, create an AP on channel 6 in the 2.4 GHz band with WPA2 pre-shared key configuration as:
Using the default Wi-Fi access point configuration, create an AP on channel 6 in
the 2.4 GHz band with WPA2 pre-shared key configuration as:
.. code-block:: bash
`SSID: "Oniro Project WiFi"`
`Passphrase: "12345678"`
For more details, refer to the `NetworkManager configuration file <https://booting.oniroproject.org/distro/oniro/-/blob/dunfell/meta-oniro-blueprints/recipes-connectivity/networkmanager/networkmanager-softap-config/SoftAP.nmconnection>`_ to get more clarity.
For more details, refer to the `NetworkManager configuration file <https://gitlab.eclipse.org/eclipse/oniro-blueprints/core/meta-oniro-blueprints-core/-/blob/master/recipes-connectivity/networkmanager/networkmanager-softap-config/SoftAP.nmconnection>`_ to get more clarity.
OpenThread Border Router Configuration
**************************************
In our default OpenThread border router configuration, we create an OpenThread mesh network on channel 26 in the 2.4 GHz band with panid 0x1357:
In our default OpenThread border router configuration, we create an OpenThread
mesh network on channel 26 in the 2.4 GHz band with panid 0x1357:
.. code-block:: bash
`Networkname "OniroThread"`
`OpenThread masterkey: 00112233445566778899aabbccddeeff`
For more details, refer to the `OpenThread configuration script <https://booting.oniroproject.org/distro/oniro/-/blob/dunfell/meta-oniro-blueprints/recipes-connectivity/openthread/ot-br-posix/otbr-configuration>`_ for getting more clarity.
For more details, refer to the `OpenThread configuration script <https://gitlab.eclipse.org/eclipse/oniro-blueprints/core/meta-oniro-blueprints-core/-/blob/master/recipes-connectivity/openthread/ot-br-posix/otbr-configuration>`_ for getting more clarity.
.. _mesh-troubleshooting:
Troubleshooting
***************
In case you run into trouble while onboarding the mesh node to the OpenThread
network this section has instructions how to factory reset the different
components.
To factory reset the mesh node you need to connect to its serial console and
issue the following command, the device will reboot after the command:
.. code-block:: bash
$ screen /dev/ttyACM0 115200
uart:~$ ot factoryreset
To reset the Android Thread Commissioner App you need to clear data as well as
cache in the storage menu of the App info settings. Depending on the phone and
Android version there might be different ways to reach the App info settings. A
long press on the icon on the launcher could work or an application menu inside
the main Android settings dialog.
transparent-gateway.rst
View file @ 48056d5a
......@@ -13,8 +13,10 @@ Transparent Gateway Blueprint
Overview
********
The Transparent Gateway Blueprint provides support for building a Proof of Concept(PoC) IoT
gateway that can be ideally used as the communication hub in a smart home. In addition to the gateway, it also provides a PoC of a mesh node based on Zephyr.
The Transparent Gateway Blueprint provides support for building a Proof of
Concept(PoC) IoT gateway that can be ideally used as the communication hub in a
smart home. In addition to the gateway, it also provides a PoC of a mesh node
based on Zephyr.
A few of the features demonstrated are as follows:
......@@ -34,7 +36,7 @@ Gateway:
- 1x `Raspberry Pi 4B board <https://www.raspberrypi.com/products/raspberry-pi-4-model-b/>`_ (>=2GB RAM)
- 1x `Raspberry Pi USB-C Power supply <https://www.raspberrypi.com/products/type-c-power-supply/>`_
- 1x microSD card (>=8GB size)
- 1x `Makerdiary nrf52840 MDK USB dongle <https://wiki.makerdiary.com/nrf52840-mdk-usb-dongle/>`_
- 1x `Arduino Nano 33 BLE`_ (alternatively a *nRF52840 DK* or *nRF52840 Dongle*)
- 1x `USB serial cable <https://www.adafruit.com/product/954>`_ (optional)
- 1x Ethernet cable
......@@ -48,14 +50,22 @@ The setup of the hardware components is illustrated in the hardware setup image:
.. image:: assets/gateway-hw-setup.png
:alt: Transparent Gateway - Hardware setup
On the Arduino Nano 33 BLE the only connection needed is the micro USB cable which is used for power, flashing, and serial console.
On the Arduino Nano 33 BLE the only connection needed is the micro USB cable
which is used for power, flashing, and serial console.
For the Raspberry Pi 4 you need to perform a few more bits for completing the setup.
For the Raspberry Pi 4 you need to perform a few more bits for completing the
setup.
- Connect the ethernet cable and insert the Makerdiary MDK USB dongle in one of the USB ports.
- Insert the micro SD card, and the USB-C power supply can wait until the software is build and flashed.
- Connect the ethernet cable and insert the Arduino Nano 33 BLE in one of the
USB ports.
- Insert the micro SD card, and the USB-C power supply can wait until the
software is build and flashed.
Optionally, a USB to TTL serial cable can be connected as a serial console for debugging. A detailed description on connecting the cable can be found `on the conect the lead page <https://learn.adafruit.com/adafruits-raspberry-pi-lesson-5-using-a-console-cable/connect-the-lead>`_. An alternative to the serial console is to SSH over the local network connection.
Optionally, a USB to TTL serial cable can be connected as a serial console for
debugging. A detailed description of connecting the cable can be found `on the
connect the lead page
<https://learn.adafruit.com/adafruits-raspberry-pi-lesson-5-using-a-console-cable/connect-the-lead>`_.
An alternative to the serial console is to SSH over the local network connection.
Fetch Blueprint Sources and Build
*********************************
......@@ -67,31 +77,45 @@ The final piece remaining after building the hardware setup is fetching the
software sources and building the OS.
For fetching or updating the build metadata, follow the :ref:`blueprints
workspace documentation <Workspace>`. Doing so, brings everything you need on your host to start building an image for this blueprint.
workspace documentation <Workspace>`. Doing so, brings everything you need on
your host to start building an image for this blueprint. For this specific
build, you need to clone `meta-oniro-blueprints-gateway
<https://gitlab.eclipse.org/eclipse/oniro-blueprints/transparent-gateway/meta-oniro-blueprints-gateway>`_.
.. code-block:: bash
$ cd $CHECKOUT_DIR
$ git clone --recursive https://gitlab.eclipse.org/eclipse/oniro-blueprints/transparent-gateway/meta-oniro-blueprints-gateway.git
$ cd meta-oniro-blueprints-gateway
$ git checkout origin/main
.. note::
Ensure to `CHECKOUT_DIR` variable in the workspace documentation as you need the variable during the process
Make sure you define or replace
`CHECKOUT_DIR` as described in :ref:`blueprints workspace documentation
<Workspace>`.
Build the Oniro Image for the Gateway
-------------------------------------
Once you have a workspace initialized as per the instructions in the preceding section, you are ready to build the OS. Firstly, you initialize a build:
Once you have a workspace initialized as per the instructions in the preceding
section, you are ready to build the OS. Firstly, you initialize a build:
.. code-block:: bash
$ cd $CHECKOUT_DIR
$ TEMPLATECONF=../oniro/flavours/linux . ./oe-core/oe-init-build-env build-oniro-gateway
Executing the command sets up a new build environment in the `build-oniro-gateway` directory (or reuse it, if it already exists).
Executing the command sets up a new build environment in the
`build-oniro-gateway` directory (or reuse it, if it already exists).
Add the `meta-oniro-blueprints` layer to the build. This is only needed once
after initializing a new build:
Add `meta-oniro-blueprints-gateway` layer to the build.
This is only needed once after initializing a new build:
.. code-block:: bash
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-homeassistant
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-oniro-blueprints
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-oniro-blueprints-gateway/meta-oniro-blueprints-core
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-oniro-blueprints-gateway/meta-oniro-blueprints-gateway
Once the build environment is set, start building the image.
......@@ -128,20 +152,21 @@ Build the Oniro Image for the Mesh Node
---------------------------------------
Once you have a workspace initialised as per the instructions above, you are
ready to build the OS. The following command sets up a new build environment in the `build-oniro-mesh-node` directory (or reuse it, if it already exists):
ready to build the OS. The following command sets up a new build environment in
the `build-oniro-mesh-node` directory (or reuse it, if it already exists):
.. code-block:: bash
$ cd $CHECKOUT_DIR
$ TEMPLATECONF=../oniro/flavours/zephyr . ./oe-core/oe-init-build-env build-oniro-mesh-node
Add the `meta-oniro-blueprints` layer to the build. This is only needed once
after initializing a new build:
Add layer `meta-oniro-blueprints-gateway` to the build.
This is only needed once after initializing a new build:
.. code-block:: bash
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-homeassistant
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-oniro-blueprints
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-oniro-blueprints-gateway/meta-oniro-blueprints-core
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-oniro-blueprints-gateway/meta-oniro-blueprints-gateway
Once the build environment is set, start building the image.
......@@ -158,8 +183,6 @@ To flash the Arduino Nano 33 BLE device it first needs to enter the bootloader
to allow flashing. Connect the USB cable and double press the button. An orange
LED fading in and out indicates the device is ready to be flashed.
You might need to install the `python3-serial` package installed on your host
OS for the flashing task below..
To access the USB device for flashing your user needs to be part of the dialout
group. You need to logout and back in again for this change to take effect. If
you want to avoid this, temporarily change the ownership for the device
......@@ -171,10 +194,13 @@ to allow flashing from a normal user account.
$ sudo chown `whoami` /dev/ttyACM0
$ DISTRO=oniro-zephyr-blueprint-gateway MACHINE=arduino-nano-33-ble bitbake zephyr-blueprint-gateway-node -c flash_usb
Prepare Makerdiary nRF52840 MDK USB dongle
Prepare the OpenThread Radio Co-Processor
------------------------------------------
As the last preparation step, you need to build and flash the firmware for the Makerdiary nRF52840 MDK USB dongle to allow it to act as an OpenThread radio for the border router. More details on this can be found in the following :ref:`section <MDK-rcp-flash>`.
As the last preparation step, you need to build and flash the firmware for the
Arduino Nano 33 BLE to allow it to act as an OpenThread Radio Co-Processor (RCP)
for the border router. More details on this can be found in the following
:ref:`section <rcp-flash>`.
Run the Gateway Blueprint
*************************
......@@ -187,43 +213,66 @@ power source. On a Raspberry Pi 4B, that would be a USB-C power supply.
The Arduino Nano 33 BLE board does not need a dedicated power supply, it
runs off the USB connection that you have for serial access.
With both devices up and running, now switch to demonstrate the mesh node onboarding process onto the OpenThread network. A full video tutorial on the Gateway blueprint, with details on the onboarding process, can be found :ref:`here <ResourcesTG>`.
With both devices up and running, now switch to demonstrate the mesh node
onboarding process onto the OpenThread network. A full video tutorial on the
Gateway blueprint, with details on the onboarding process, can be found
:ref:`here <ResourcesTG>`.
Install Thread Commissioner App on Android Phone
------------------------------------------------
The Thread specification allows an external commissioner, in our case an Android based phone, to onboard headless devices which have no means to enter the needed credentials by themselves.
The Thread specification allows an external commissioner, in our case an Android
based phone, to onboard headless devices which have no means to enter the needed
credentials by themselves.
For this purpose, the Thread group released an Android app, which is used in the blueprint too, and can be found in Android Playstore at: https://play.google.com/store/apps/details?id=org.threadgroup.commissioner.
For this purpose, the Thread group released an Android app, which is used in the
blueprint too, and can be found in Android Playstore at:
https://play.google.com/store/apps/details?id=org.threadgroup.commissioner.
Generate QR Code for Commissioner Onboarding
--------------------------------------------
The credential and unique hardware identifiers used for the onboarding process are passed to the commissioner app in form of an QR code (in a final product, this is expected to be printed on the packaging or quick setup guide). Details on how to gather the information and generate the QR code is documented here :ref:`section <QR-gen>`.
The credential and unique hardware identifiers used for the onboarding process
are passed to the commissioner app in form of an QR code (in a final product,
this is expected to be printed on the packaging or quick setup guide). Details
on how to gather the information and generate the QR code is documented here
:ref:`section <QR-gen>`.
Onboarding Process
------------------
The onboarding process is divided in the following steps:
#. Open the Android settings and connect the mobile phone to the Oniro Project WiFi. The Wi-Fi password is: **12345678**
#. Open the Android settings and connect the mobile phone to the Oniro Project
WiFi. The Wi-Fi password is: **12345678**
.. image:: assets/gateway-commissioner-1.jpg
:alt: Transparent Gateway - Connecting to WiFi
.. image:: assets/gateway-commissioner-1.jpg
:alt: Transparent Gateway - Connecting to WiFi
#. Start the Thread application on your phone. It shows two available OpenThread border routers. Select the one with the IP address 172.16.47.1. When accessing the border router, enter the Thread admin password as: J01NME.
#. Start the Thread application on your phone. It shows two available OpenThread
border routers. Select the one with the IP address 172.16.47.1. When
accessing the border router, enter the Thread admin password as: J01NME.
.. image:: assets/gateway-commissioner-2.jpg
:alt: Transparent Gateway - Thread Commissioner App
.. image:: assets/gateway-commissioner-2.jpg
:alt: Transparent Gateway - Thread Commissioner App
#. The camera view gets enabled and allows to scan the generated QR code for the mesh node.
#. Once the screen changes to **Adding My Thread Product to OniroThread**, press the button of the Arduino Nano 33 BLE to reset the device and finish the onboarding process.
#. The camera view gets enabled and allows to scan the generated QR code for the
mesh node.
#. The screen changes to **Adding My Thread Product to OniroThread**.
#. The Thread app screen changes to **Added My Thread Product to OniroThread**.
.. note::
If the process gets stuck on the screen showing *Adding My Thread
Product to OniroThread*, try to factory reset the mesh node,
following the instructions in the :ref:`mesh-troubleshooting` section.
.. image:: assets/gateway-commissioner-3.jpg
:alt: Transparent Gateway - Thread device onboarded
Congratulations! you have successfully implemented the Transparent gateway blueprint. Now is a good time to explore the system further, and start extending it for your own needs.
Congratulations! you have successfully implemented the Transparent gateway
blueprint. Now is a good time to explore the system further, and start extending
it for your own needs.
Gateway Configuration Details
*****************************
......
vending-machine.rst
View file @ 48056d5a
......@@ -140,13 +140,20 @@ The final piece remaining after building the hardware setup is fetching the
software sources and building the OS.
For fetching or updating the build metadata, follow the :ref:`blueprints
workspace documentation <Workspace>`. This will bring everything you need on
your host to start building an image for this blueprint.
workspace documentation <Workspace>`.
For this specific build, you need to
clone `meta-oniro-blueprints-vending-machine <https://gitlab.eclipse.org/eclipse/oniro-blueprints/vending-machine/meta-oniro-blueprints-vending-machine>`_.
.. code-block:: bash
$ cd $CHECKOUT_DIR
$ git clone --recursive https://gitlab.eclipse.org/eclipse/oniro-blueprints/vending-machine/meta-oniro-blueprints-vending-machine.git
.. note::
Mind the `CHECKOUT_DIR` variable in the workspace documentation as you will
need them below.
Make sure you define or replace
`CHECKOUT_DIR` as described in :ref:`blueprints workspace documentation <Workspace>`.
Build the Oniro Image for the Vending Machine Blueprint
-------------------------------------------------------
......@@ -161,13 +168,13 @@ ready to build the OS. Firstly, you will be initialising a build:
This will setup a new build environment in the `build-oniro-vending-machine`
directory (or reuse it if it already exists).
Add the `meta-oniro-blueprints` layer to the build. This is only needed once
after initializing a new build:
Add layers which are inside `meta-oniro-blueprints-vending-machine` to the build.
This is only needed once after initializing a new build:
.. code-block:: bash
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-homeassistant
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-oniro-blueprints
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-oniro-blueprints-vending-machine/meta-oniro-blueprints-core
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-oniro-blueprints-vending-machine/meta-oniro-blueprints-vending-machine
Once the build environment is set we can start building the image. The building
command will be slightly different depending on the target board.
......@@ -211,13 +218,13 @@ For the Raspberry Pi 4B-based setup:
.. code-block:: bash
$ sudo bmaptool copy ./tmp/deploy/images/raspberrypi4-64/blueprint-vending-machine-image-raspberrypi4-64.wic.bz2 "$DEVICE"
$ sudo bmaptool copy ./tmp/deploy/images/raspberrypi4-64/blueprint-vending-machine-image-raspberrypi4-64.wic.gz "$DEVICE"
For the SECO b68-based setup:
.. code-block:: bash
$ sudo bmaptool copy ./tmp/deploy/images/seco-intel-b68/blueprint-vending-machine-image-seco-intel-b68.wic "$DEVICE"
$ sudo bmaptool copy ./tmp/deploy/images/seco-intel-b68/blueprint-vending-machine-image-seco-intel-b68.wic.gz "$DEVICE"
Running the Vending Machine Blueprint Image
*******************************************
......@@ -249,4 +256,4 @@ Resources
.. _ResourcesVM:
- See `Vending machine's requirement <https://git.ostc-eu.org/OSTC/requirements/-/issues/80>`_
- See `Vending machine's requirements <https://git.ostc-eu.org/OSTC/requirements/-/issues/80>`_
workspace.rst
View file @ 48056d5a
......@@ -36,50 +36,68 @@ layers set up in the build. The general steps are:
$ export CHECKOUT_DIR=~/oniroproject
$ mkdir -p $CHECKOUT_DIR
#. Clone `meta-oniro-blueprints
<https://booting.oniroproject.org/distro/meta-oniro-blueprints>`_:
#. Clone the layer for the blueprint which you want to add:
.. code-block:: bash
$ cd $CHECKOUT_DIR
$ git clone https://booting.oniroproject.org/distro/meta-oniro-blueprints
$ cd meta-oniro-blueprints
$ git checkout origin/dunfell
If you want to add the `doorlock` blueprint, type:
.. code-block:: bash
#. Clone the dependencies of the `meta-oniro-blueprints` layer that are not
brought in by `oniro` by default:
$ git clone --recursive https://gitlab.eclipse.org/eclipse/oniro-blueprints/doorlock/meta-oniro-blueprints-doorlock.git
If you want to add the `transparent-gateway` blueprint, type:
.. code-block:: bash
* `meta-homeassistant <https://github.com/meta-homeassistant/meta-homeassistant>`_
$ git clone --recursive https://gitlab.eclipse.org/eclipse/oniro-blueprints/transparent-gateway/meta-oniro-blueprints-gateway.git
If you want to add the `vending-machine` blueprint, type:
.. code-block:: bash
.. code-block:: bash
$ git clone --recursive https://gitlab.eclipse.org/eclipse/oniro-blueprints/vending-machine/meta-oniro-blueprints-vending-machine.git
$ cd $CHECKOUT_DIR
$ git clone https://github.com/meta-homeassistant/meta-homeassistant.git
$ cd meta-homeassistant
$ git checkout origin/dunfell
#. The first time a build is initialized, after running the `oe-init-build-env`
script, add all layers present in the directory that you have cloned
to the build's `bblayers.conf` either manually or by
running (for each layer separately):
.. note::
.. code-block:: bash
If you already have any of these layers cloned and you want to reuse
them, just update the revision of the branch above.
$ bitbake-layers add-layer <path-to-a-layer>
.. note::
If 'oniro-blueprints-core' layer exists in blueprint directory, you may need to add it first.
#. The first time a build is initialized, after running the `oe-init-build-env`
script, add that layers to the build's `bblayers.conf` either manually or by
running:
If you want to add the `doorlock` blueprint, type:
.. code-block:: bash
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-oniro-blueprints-doorlock/meta-oniro-blueprints-core
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-oniro-blueprints-doorlock/meta-oniro-blueprints-doorlock
If you want to add the `transparent-gateway` blueprint, type:
.. code-block:: bash
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-oniro-blueprints-gateway/meta-oniro-blueprints-core
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-oniro-blueprints-gateway/meta-oniro-blueprints-gateway
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-homeassistant
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-oniro-blueprints
If you want to add the `vending-machine` blueprint, type:
.. code-block:: bash
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-oniro-blueprints-vending-machine/meta-oniro-blueprints-core
$ bitbake-layers add-layer $CHECKOUT_DIR/meta-oniro-blueprints-vending-machine/meta-oniro-blueprints-vending-machine
.. attention::
Make sure you define (as per the instructions above) or replace
`CHECKOUT_DIR` accordingly.
Als, the order above is important as `meta-homeassistant` is a dependency
of `meta-oniro-blueprints`.
#. Once that is done. Follow the specific blueprint's build instructions.

Copyright © Eclipse Foundation, Inc. All Rights Reserved.     Privacy Policy | Terms of Use | Copyright Agent