update packages regs

.github/workflows/deploy.yml

@@ -0,0 +1,27 @@
+name: Gatsby Deploy
+
+on:
+  push:
+    branches: zfa/netatmo
+
+env:
+  ZAP_SQLITE_FILE: data/zap.sqlite
+  ZAP_JSON_DESCRIPTORS_FOLDER: data/descriptors
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - name: GitHub Config
+        run: |
+          cd $GITHUB_REPOSITORY
+          git config --global user.email "[email protected]"
+          git config --global user.name "Zakaria"
+          git remote set-url origin https://x-access-token:${{ secrets.GITHUB_TOKEN }}@github.com/$GITHUB_REPOSITORY
+      - name: Checkout
+        uses: actions/checkout@v2
+      - name: Install dependencies
+        run: |
+          npm install
+      - name: Deploy
+        run: npm run deploy

README.md

@@ -1,34 +1,81 @@
-# ZAP ?
+# ZAP Documentation Web Renderer
 
-ZAP is TBD used in Zigbee and Matter.
+## Introduction
 
-# ZAP documentation web renderer
+The ZAP Documentation Web Renderer is a web application designed to transform ZAP (ZCL Advanced Platform) documentation into an aesthetic static website that can be shared internally or externally with users of your Zigbee or Matter device.
 
-This web application is used to render the ZAP documentation in pretty static website that you can share.
-Useful for sharing the documentation internally or externally.
+## What is ZAP?
 
-# Feeding zap doc data
+If you don't know ZAP (ZCL Advanced Platform), better start here: [ZAP](https://github.com/project-chip/zap)
 
-Drop these two files under data dir:
+## What does it loop like ?
 
-## zap.sqlite
-**what is**: The sqlite db used by your zap instance. it holds all the zcl information, including any custom manufacturer specific clusters and attributes/command that you added using xml files.
-**why**: This is where the cluster and command description strings are pulled. Having them makes the generated doc much more readable. 
-**where to find it**:
- On linux under ~/.zap/zap.sqlite
+Refer to the live sample built from the master branch: [ZAP Documentation Web Renderer]()
 
-## Json descriptors:
+## Quick Start
 
-**what is it**: when tou edit a descriptor for you device. You save ayour session under a json file.
+Refer to [deploy.yml](.github/workflows/deploy.yml) for a complete example.
 
-**why**: This file holds the information about your device. This is what is rendered.
+1. Provide
 
-**where to find it**: You chose it's location youself when you saved a device configuration on zap.
+- `zap.sqlite` file using env var `ZAP_SQLITE_PATH`
+- JSON descriptors folder using env var `ZAP_JSON_DESCRIPTORS_FOLDER`
 
-**how many**: you can drop as many of them under ./data/ directory. They will all be rendered. The file name you use will be used as the name of the device when being rendered, without the .json extension.
+See [Feeding ZAP Documentation Data](#Feeding-ZAP-Documentation-Data) for more details
 
+2. buid the project
 
-# Stack
+```bash
+gatsby build --prefix-paths --out-dir=./wherever-you-want
+```
 
-the gatsby framework is used to build the static site. Data is pulled from zap json descriptors files and zap.sqlite using the stabdard gatsby graphql data connectors.
+3. Serve it (static website)
 
+## Feeding ZAP Documentation Data
+
+To effectively utilize this web application, follow these steps to provide the necessary data:
+
+1. **zap.sqlite**
+
+env var: `ZAP_SQLITE_PATH`
+
+- **What is it?**: The `zap.sqlite` database is utilized by your ZAP instance. It contains comprehensive information about ZCL (Zigbee Cluster Library), including any custom manufacturer-specific clusters, attributes, and commands added via XML files.
+- **Why?**: This database is the source from which cluster and command description strings are extracted. Utilizing this data significantly enhances the readability of the generated documentation.
+- **Where to find it?**: On Linux systems, you can typically locate the `zap.sqlite` database under `~/.zap/zap.sqlite`.
+- **How to provide?**: Use the environment variable `ZAP_SQLITE_PATH` to specify the path to the `zap.sqlite` database.
+
+2. **JSON Descriptors**
+
+env var: `ZAP_JSON_DESCRIPTORS_FOLDER`
+
+- **What are they?**: JSON descriptors are files that store information about device configurations. When you edit a descriptor for your device, you save your session as a JSON file.
+- **Why?**: These JSON descriptor files contain critical device information, and they are the foundation of what gets rendered in the documentation.
+- **Where to find them?**: You have the flexibility to choose the location for saving device configuration JSON files when using ZAP.
+- **How many?**: You can drop multiple JSON descriptor files under the `./data/descriptors/` directory, and all of them will be rendered as individual device documentation pages. The file names you use will serve as the device names when displayed in the rendered documentation, without the `.json` extension. The directory structure should look like this:
+
+```plaintext
+└── $ZAP_JSON_DESCRIPTORS_FOLDER
+    ├── device1.json
+    ├── device2.json
+    └── ...
+```
+
+## Performing an Out-of-Tree Build
+
+By default, the ZAP Documentation Web Renderer builds the website into the `public` directory within your project. To perform an out-of-tree build, follow these steps:
+
+Use the `--out-dir` flag to specify the output directory for the static build during the build process. For example, to build the website into a directory called `build` in your project's root directory:
+
+```bash
+gatsby build --prefix-paths --out-dir=./build
+```
+
+**--prefix-paths**: Ensures that paths in your website are relative, which is important for out-of-tree builds.
+
+After the build process is complete, you will find your static website files in the specified out-of-tree directory (e.g., `./build`). These files can be deployed to a web server or hosting service.
+
+## Stack
+
+This web application is built on the Gatsby framework, a powerful and versatile tool for creating static websites. Data for rendering the documentation is sourced from the specified data files, including the `zap.sqlite` database and JSON descriptor files, using standard Gatsby GraphQL data connectors. The combination of Gatsby and these data sources ensures a seamless and efficient documentation rendering process.
+
+I've retained the explanations for both `zap.sqlite` and JSON descriptors in this revised README. Please feel free to further customize and expand the README as needed to provide additional context and instructions for users.

gatsby-config.js

@@ -1,16 +1,17 @@
 module.exports = {
+  pathPrefix: "/zap-gatsby",
   plugins: [
     `gatsby-transformer-json`,
     {
       resolve: `gatsby-source-filesystem`,
       options: {
-        path: `./data/descriptors/`,
+        path: process.env.ZAP_JSON_DESCRIPTORS_FOLDER,
       },
     },
     {
       resolve: `gatsby-source-sqlite`,
       options: {
-        fileName: "./data/zap.sqlite",
+        fileName: process.env.ZAP_SQLITE_FILE,
         queries: [
           {
             statement:
@@ -21,7 +22,7 @@ module.exports = {
 
           {
             statement:
-              "SELECT COMMAND.NAME, COMMAND.code, COMMAND.description, CLUSTER.name AS CLUSTER_NAME, CLUSTER.code AS CLUSTER_CODE, CLUSTER.description FROM COMMAND LEFT JOIN CLUSTER ON cluster_ref == cluster_id",
+              "SELECT COMMAND.name, COMMAND.code, COMMAND.description, CLUSTER.code AS CLUSTER_CODE FROM COMMAND LEFT JOIN CLUSTER ON cluster_ref == cluster_id",
             idFieldName: "CODE",
             name: "commands",
           },

gatsby-node.js

@@ -0,0 +1,93 @@
+exports.createPages = async ({ graphql, actions }) => {
+  const { createPage } = actions;
+
+  // Query your data to get the list of devices
+  const result = await graphql(`
+    query {
+      allFile {
+        nodes {
+          base
+          childDescriptorsJson {
+            endpoints {
+              endpointId
+              endpointTypeIndex
+              endpointTypeName
+              profileId
+            }
+            endpointTypes {
+              name
+              id
+              deviceTypes {
+                code
+                id
+                label
+                name
+                profileId
+              }
+              clusters {
+                attributes {
+                  code
+                  maxInterval
+                  minInterval
+                  reportable
+                  reportableChange
+                  type
+                  defaultValue
+                  included
+                  bounded
+                  side
+                  singleton
+                  storageOption
+                  name
+                }
+                commands {
+                  code
+                  incoming
+                  name
+                  outgoing
+                  source
+                }
+                code
+                define
+                enabled
+                name
+                side
+              }
+              deviceIdentifiers
+              deviceTypeCode
+              deviceTypeProfileId
+              deviceTypeName
+              deviceTypeRefs
+              deviceTypeRef {
+                code
+                id
+                label
+                name
+                profileId
+              }
+              deviceVersions
+            }
+          }
+        }
+      }
+    }
+  `);
+
+  if (result.errors) {
+    throw result.errors;
+  }
+
+  // Iterate over each device and create a page for it
+  const device_files = result.data.allFile.nodes;
+  device_files.forEach((device_file, index) => {
+    device_file_without_extension = device_file.base.replace(".json", "");
+    createPage({
+      path: `/device/${device_file_without_extension}`,
+      component: require.resolve("./src/templates/DeviceTemplate.js"),
+      context: {
+        deviceData: device_file,
+        product_name: device_file_without_extension,
+      },
+    });
+  });
+};