A number of small changes

Docs
====
- Add Standards and Guidelines

Back end
========
- Move Char out of Utilities to separate file
- Artnet in: use channelsPerLight

Author: ewowi

docs/develop/development.md

@@ -7,7 +7,8 @@
 * Make changes
 * Document your change
 * Submit a pull request
-* Develop principles: Checklist before submitting a request.
+
+[Standards and Guidelines](https://moonmodules.org/MoonLight/develop/standardsguidelines/). Check before submitting a request!
 
 ## Create a branch
 
@@ -123,14 +124,3 @@ There are 3 files to consider when making a ESP32-device definition.
 	boards/BOARD_NAME.csv
 	boards/BOARD_NAME.JSON
 	firmware/BOARD_TYPE_NAME.ini (e.g. esp32dev, esp32-s3), contains different boards
-
-## Develop principles
-
-* One firmware per board containing everything, to keep management of firmware simple - for everybody. 3MB flash space to allow for this.
-* Clang-format and Prettier for unified layout of code (right click format document in VSCode)
-* Part of submitting a change via a pull request is updated documentation. Functionality and documentation should be in one Pull Request 
-* Make minimal changes in upstream (Sveltekit) code, as we need to stay in sync as easy as possible. Add // 🌙 to show a change has been made.
-* The main branch is the source to branch and merge to, no direct code commits to the main branch. As the main branch docs folder is the source for the website, doc changes can be made directly to main. 
-* The dev branch is used for latest updates between releases. Optionally branch from dev if latest updates are needed for a change.
-* The src folder is for all MoonBase and MoonLight Nodes and Modules development. No need for UI changes as that is generated for Nodes and Modules. The lib folder is for upstream (Sveltekit). The interface folder is for UI, mainly Sveltekit and Modules and Nodes generic functions.
-* A pull request should contain compilable code and tested to not crash the system at minimal and support also boards without PSRAM, e.g. ESP32-D0. Code may be work in progress.

docs/develop/standardsguidelines.md

@@ -0,0 +1,93 @@
+
+# Standards and Guidelines
+
+## Develop principles
+
+* One firmware per board containing everything, to keep management of firmware simple - for everybody. 3MB flash space to allow for this.
+* Part of submitting a change via a pull request is updated documentation. Functionality and documentation should be in one Pull Request 
+* Make minimal changes in upstream (Sveltekit) code, as we need to stay in sync as easy as possible. Add // 🌙 to show a change has been made.
+* The main branch is the source to branch and merge to, no direct code commits to the main branch. As the main branch docs folder is the source for the website, doc changes can be made directly to main. 
+* The dev branch is used for latest updates between releases. Optionally branch from dev if latest updates are needed for a change.
+* The src folder is for all MoonBase and MoonLight Nodes and Modules development. No need for UI changes as that is generated for Nodes and Modules. The lib folder is for upstream (Sveltekit). The interface folder is for UI, mainly Sveltekit and Modules and Nodes generic functions.
+* A pull request should contain compilable code and tested to not crash the system at minimal and support also boards without PSRAM, e.g. ESP32-D0. Code may be work in progress.
+
+## Describe your PR
+
+Please add a description of your proposed code changes. It does not need to be an exhaustive essay, however a PR with no description or just a few words might not get accepted, simply because very basic information is missing.
+
+A good description helps us to review and understand your proposed changes. For example, you could say a few words about
+* what you try to achieve (new feature, fixing a bug, refactoring, security enhancements, etc.)
+* how your code works (short technical summary - focus on important aspects that might not be obvious when reading the code)
+* testing you performed, known limitations, open ends you possibly could not solve.
+* any areas where you like to get help from an experienced maintainer
+
+## Your Pull Request (PR)
+
+### Target branch for pull requests
+
+Please make all PRs against the `main` branch.
+
+### Updating your code
+
+While the PR is open - and under review by maintainers - you may be asked to modify your PR source code.
+You can simply update your own branch, and push changes in response to reviewer recommendations. 
+Github will pick up the changes so your PR stays up-to-date.
+
+> [!CAUTION]
+> Do not use "force-push" while your PR is open!
+> It has many subtle and unexpected consequences on our github reposistory.
+> For example, we regularly lost review comments when the PR author force-pushes code changes. So, pretty please, do not force-push.
+
+You can find a collection of very useful tips and tricks here: https://github.com/wled-dev/WLED/wiki/How-to-properly-submit-a-PR
+
+
+## Source Code from an AI agent or bot
+> [!IMPORTANT]
+> Its OK if you took help from an AI for writing your source code. 
+>
+> However, we expect a few things from you as the person making a contribution to MoonLight:
+* Make sure you really understand the code suggested by the AI, and don't just accept it because it "seems to work".
+* Don't let the AI change existing code without double-checking by you as the contributor. Often, the result will not be complete. For example, previous source code comments may be lost.
+* Remember that AI are still "Often-Wrong" ;-)
+* If you don't feel very confident using English, you can use AI for translating code comments and descriptions into English. AI bots are very good at understanding language. However, always check if the results is correct. The translation might still have wrong technical terms, or errors in some details.
+
+### best practice with AI:
+  * As the person who contributes source code to MoonLight, make sure you understand exactly what the AI generated code does
+  * best practice: add a comment like ``'// below section of my code was generated by an AI``, when larger parts of your source code were not written by you personally.
+  * always review translations and code comments for correctness
+  * always review AI generated source code
+  * If the AI has rewritten existing code, check that the change is necessary and that nothing has been lost or broken. Also check that previous code comments are still intact.
+
+## Code style
+
+### Code
+
+We use Clang-format for c-files (see .clang-format in the repo for the definition) and Prettier for front end files.
+
+Right click Format Document on each file you edit before committing.
+
+### Comments
+
+Comments are used for technical documentation, always document your changes, each function must have a comment describing what it does, including its arguments. Comments are also formatted using Clang-format and Prettier.
+(Functional documentation must be done on the MoonLight website, see above)
+
+Examples:  
+```
+// This is a comment.
+
+/* This is a CSS inline comment */
+
+/* 
+ * This is a comment
+ * wrapping over multiple lines,
+ * used in MoonLight for file headers and function explanations
+ */
+
+<!-- This is an HTML comment -->
+```
+
+There is no set character limit for a comment within a line, though as a rule of thumb you should wrap your comment if it exceeds the width of your editor window.  
+
+Inline comments are OK if they describe that line only and are not exceedingly wide.
+
+(modified version from WLED-MM, 🙏 to @softhack007)

interface/src/routes/moonbase/monitor/Monitor.svelte

@@ -57,7 +57,6 @@
 	// let offsetRed:number;
 	// let offsetGreen:number;
 	// let offsetBlue:number;
-	// let offsetWhite:number;
 
 	const handleHeader = (header: Uint8Array) => {
 		console.log('Monitor.handleHeader', header);