Remove obsolete INFORMATION_NEEDED.md and streamline README.md for clarity

- Deleted the INFORMATION_NEEDED.md file as it was no longer necessary for documentation.
- Revised README.md to enhance the overview of the home automation system, focusing on how services and CODESYS connectivity work.
- Updated project structure in README.md for better organization and clarity, including links to relevant documentation.

This update simplifies the documentation and improves the overall user experience for developers and users of the home automation system.
This commit is contained in:
2026-02-08 17:09:30 +02:00
parent 6ef31cd12a
commit f0d883b8c2
24 changed files with 15006 additions and 3673 deletions

View File

@@ -1,189 +0,0 @@
# CODESYS Project Analysis
## Overview
This document contains information extracted from the CODESYS project export file (`Home_Automation.export`).
## Device Information
- **Device Name**: `codesys-home`
- **CODESYS Version**: 4.15.0.0
- **Platform**: CODESYS Control for Raspberry Pi MC SL
- **SDK Version**: 3.5.21.0
- **Order Number**: 2302000009
## Hardware Configuration
### EtherCAT Network
- **EtherCAT Master**: Version 4.9.0.0
- **EtherCAT Task**: `EtherCAT_Task`
### EtherCAT Devices
1. **EK1100** - EtherCAT Coupler (2A E-Bus)
- Vendor: Beckhoff Automation GmbH & Co. KG
- Order Number: EK1100
- Function: EtherCAT coupler connecting to E-Bus modules
2. **EL1809** - 16Ch. Digital Input 24V, 3ms
- Vendor: Beckhoff Automation GmbH & Co. KG
- Order Number: EL1809
- Function: 16-channel digital input module
- Channels: 16 digital inputs (Channels 1-16)
3. **Output Module** (Likely EL2004 or similar)
- 16 output channels configured
- Channel addresses: 16#1A00 through 16#1A0F (Channels 1-16)
## Network Variables
CODESYS communicates with Node-RED using UDP-based network variables.
### Variables Sent to Node-RED (NVL_Sender)
**List Identifier**: 1
**Protocol**: UDP
**Task**: EtherCAT_Task
**Transmission**: Cyclic
**Interval**: T#50ms
**Minimum Gap**: T#20ms
**Structure**: `struct_lights` containing light states for each room:
| Variable Name | Type | Description |
|--------------|------|-------------|
| `l_masterBedroom` | struct_lights | Master bedroom lights |
| `l_masterBathroom` | struct_lights | Master bathroom lights |
| `l_bedroom_1` | struct_lights | Bedroom 1 lights |
| `l_bedroom_2` | struct_lights | Bedroom 2 lights |
| `l_bathroom` | struct_lights | Bathroom lights |
| `l_hallway` | struct_lights | Hallway lights |
| `l_pantry` | struct_lights | Pantry lights |
| `l_kitchen` | struct_lights | Kitchen lights |
| `l_livingRoom` | struct_lights | Living room lights |
| `l_dinningRoom` | struct_lights | Dining room lights |
| `l_entrance` | struct_lights | Entrance lights |
| `l_guestWc` | struct_lights | Guest WC lights |
| `l_outVeranda` | struct_lights | Outdoor veranda lights |
| `l_outFront` | struct_lights | Outdoor front lights |
| `l_outSide` | struct_lights | Outdoor side lights |
| `l_outBack` | struct_lights | Outdoor back lights |
### Variables Received from Node-RED (NVL_Receiver)
**List Identifier**: 3
**Protocol**: UDP
**Task**: EtherCAT_Task
**Transmission**: Cyclic
**Interval**: T#50ms
**Minimum Gap**: T#20ms
**Import File**: `C:\Users\NearchosParaskeva\OneDrive - individual\Codesys_Home_Automation\NVL_Receiver.gvl`
**Structure**: `struct_switches` containing switch states for each room:
| Variable Name | Type | Description |
|--------------|------|-------------|
| `masterBedroom` | struct_switches | Master bedroom switches |
| `masterBathroom` | struct_switches | Master bathroom switches |
| `bedroom_1` | struct_switches | Bedroom 1 switches |
| `bedroom_2` | struct_switches | Bedroom 2 switches |
| `bathroom` | struct_switches | Bathroom switches |
| `hallway` | struct_switches | Hallway switches |
| `pantry` | struct_switches | Pantry switches |
| `kitchen` | struct_switches | Kitchen switches |
| `livingRoom` | struct_switches | Living room switches |
| `dinningRoom` | struct_switches | Dining room switches |
| `entrance` | struct_switches | Entrance switches |
| `guestWc` | struct_switches | Guest WC switches |
| `outVeranda` | struct_switches | Outdoor veranda switches |
| `outFront` | struct_switches | Outdoor front switches |
| `outSide` | struct_switches | Outdoor side switches |
| `outBack` | struct_switches | Outdoor back switches |
## Program Structure
### Main Program (PLC_PRG)
- **Type**: Program
- **Language**: Structured Text (ST)
- **Function Blocks Used**: `fb_switch`
- **Instances**:
- `masterBedroom: fb_switch`
### Function Blocks
- **fb_toogleButton**: Toggle button function block
- **fb_switch**: Switch control function block
### Variables Used in Logic
From the program code, the following variables are referenced:
- `lights.l_1`, `lights.l_2`, `lights.l_3`, `lights.l_4`, `lights.l_5`, `lights.l_6`
- `switches.sw_1`, `switches.sw_2`, `switches.sw_3`, `switches.sw_4`, `switches.sw_5`, `switches.sw_6`
- `switches.all_off`
- `switches.all_on`
## Room Configuration
The system controls lighting for 15 rooms/areas:
1. Master Bedroom
2. Master Bathroom
3. Bedroom 1
4. Bedroom 2
5. Bathroom
6. Hallway
7. Pantry
8. Kitchen
9. Living Room
10. Dining Room
11. Entrance
12. Guest WC
13. Outdoor Veranda
14. Outdoor Front
15. Outdoor Side
16. Outdoor Back
## I/O Mapping
### Inputs (EL1809)
- 16 digital input channels
- Likely used for local switch inputs or status feedback
### Outputs (16 channels, likely EL2004)
- 16 digital output channels (16#1A00 - 16#1A0F)
- Used to control relay outputs for lighting
**Note**: The exact mapping between relay outputs and rooms needs to be determined from the program logic or wiring documentation.
## Libraries Used
- **IoStandard** (System)
- **SM3_Basic** (3S - Smart Software Solutions GmbH)
- **SM3_CNC** (3S - Smart Software Solutions GmbH)
- **3SLicense** (CODESYS)
- **SM3_CamBuilder** (CODESYS)
- **SM3_Robotics** (CODESYS)
- **SM3_Robotics_Visu** (CODESYS)
- **SM3_Transformation** (CODESYS)
- **Standard** (System)
- **CmpLog** (System)
## Task Configuration
- **EtherCAT Task**: Used for EtherCAT communication and network variable updates
- **Update Rate**: 50ms (cyclic transmission)
## Notes
- The project uses structured data types (`struct_lights`, `struct_switches`) for organizing room data
- Network variables are packed and transmitted via UDP
- The system appears to support both indoor and outdoor lighting control
- Water boiler control mentioned in documentation was not found in the export - may be in a separate module or not yet implemented
---
**Analysis Date**: January 27, 2026
**Source File**: `Home_Automation.export`
**Export Format**: CODESYS XML

View File

@@ -1,147 +0,0 @@
# CODESYS Project Export Guide
## Overview
CODESYS projects can be exported to readable XML formats that allow for better analysis, documentation, and version control. The binary `.project` file format is proprietary and not human-readable, but CODESYS provides export options that create XML files.
## Export Formats
### 1. CODESYS XML Format (*.export)
**Best for:** Full project export, version control, complete documentation
- **Format:** Fully compatible CODESYS XML format
- **Content:** Complete project structure in machine-parsable XML
- **Compatibility:** 100% compatible with CODESYS
- **Use Cases:**
- Full project backup
- Version control systems
- Automated analysis and documentation
- Project migration
**How to Export:**
1. Open your project in CODESYS IDE
2. Go to **Project → Export**
3. Select the objects you want to export (or select all)
4. Choose **CODESYS XML Format (*.export)** as the file type
5. Save the file (e.g., `Home_Automation.export`)
### 2. PLCopen XML Format (*.xml)
**Best for:** Interoperability, documentation tools, program structure
- **Format:** PLCopen XML standard
- **Content:** Subset of CODESYS elements (programs, function blocks, variables)
- **Compatibility:** May not include all CODESYS-specific features
- **Use Cases:**
- Documentation generation
- Integration with other tools
- Program structure analysis
- Cross-platform compatibility
**How to Export:**
1. Open your project in CODESYS IDE
2. Go to **Project → Export PLCopenXML**
3. Select the objects to export
4. Save the file (e.g., `Home_Automation.xml`)
## What Information Can Be Extracted
From exported XML files, we can extract:
### Project Structure
- Program Organization Units (POUs)
- Function blocks and functions
- Libraries and dependencies
- Project hierarchy
### Network Variables
- Variable names
- Data types
- Initial values
- Network variable declarations
- Direction (input/output)
### I/O Configuration
- EtherCAT device configuration
- I/O channel mappings
- Device parameters
- Scan rates
### Control Logic
- Program code structure
- Variable declarations
- Function block instances
- Logic flow
### Hardware Configuration
- Device configurations
- Network settings
- Communication parameters
## Recommended Export Process
For comprehensive documentation, export both formats:
1. **Full Export (CODESYS XML):**
```
File: Home_Automation.export
- Complete project structure
- All configurations
- Network variables
- I/O mappings
```
2. **Program Export (PLCopen XML):**
```
File: Home_Automation.xml
- Program structure
- Variable declarations
- Logic organization
```
## After Export
Once you have the exported XML files:
1. **Share the files** - The XML files can be analyzed and documented
2. **Version control** - XML files are text-based and work well with Git
3. **Documentation** - Information can be extracted and added to the docs
4. **Analysis** - Scripts can parse the XML to extract specific information
## Next Steps
After exporting:
1. Place exported files in the project directory
2. Update `.gitignore` if needed (or commit the exports)
3. Use the exported files to:
- Document network variables
- Map I/O configurations
- Understand control logic
- Complete the documentation templates
## Example Export Workflow
```bash
# In CODESYS IDE:
1. File → Open → "Home_Automation (1).project"
2. Project → Export
- Select: All objects
- Format: CODESYS XML (*.export)
- Save as: "Home_Automation.export"
3. Project → Export PLCopenXML
- Select: Programs, POUs
- Save as: "Home_Automation.xml"
```
## Notes
- Export files are typically much larger than binary project files
- XML exports are human-readable and can be opened in any text editor
- Some CODESYS-specific features may not be fully represented in PLCopen XML
- Exported files can be re-imported into CODESYS if needed
---
**Status:** Ready for export - follow the steps above to create readable project files

View File

@@ -1,260 +0,0 @@
# CODESYS PLCopen XML Analysis
## Overview
This document contains detailed information extracted from the PLCopen XML export (`Home_Automation.xml`), which provides a more structured view of the project compared to the CODESYS export format.
## Project Information
- **Format**: PLCopen XML (TC6 0200)
- **CODESYS Version**: V3.5 SP21
- **Export Date**: 2026-01-27T14:48:52
- **Project Name**: Home_Automation.project
## Task Configuration
### MainTask
- **Type**: Cyclic
- **Interval**: t#4ms (4 milliseconds)
- **Priority**: 1
- **Watchdog**: Disabled
- **Program**: PLC_PRG
### EtherCAT_Task
- **Type**: Cyclic
- **Interval**: t#4ms (4 milliseconds)
- **Priority**: 1
- **Watchdog**: Disabled
- **Purpose**: EtherCAT communication and network variable updates
## Data Structures
### struct_switches
```iec
TYPE struct_switches :
STRUCT
all_off: BOOL; // Command to turn all lights off
all_on: BOOL; // Command to turn all lights on
sw_1: BOOL; // Switch 1 state
sw_2: BOOL; // Switch 2 state
sw_3: BOOL; // Switch 3 state
sw_4: BOOL; // Switch 4 state
sw_5: BOOL; // Switch 5 state
sw_6: BOOL; // Switch 6 state
END_STRUCT
END_TYPE
```
### struct_lights
```iec
TYPE struct_lights:
STRUCT
l_1: BOOL; // Light 1 control output
l_2: BOOL; // Light 2 control output
l_3: BOOL; // Light 3 control output
l_4: BOOL; // Light 4 control output
l_5: BOOL; // Light 5 control output
l_6: BOOL; // Light 6 control output
END_STRUCT
END_TYPE
```
## Function Block: fb_toogleButton
### Interface
**Inputs**:
- `Input: BOOL` - Input signal (switch state from network)
**Outputs**:
- `Output: BOOL` - Output signal (light control)
**Internal Variables**:
- `Switch: BOOL` - Internal switch state
- `Light: BOOL` - Internal light state
- `Flag1: BOOL` - Internal flag 1
- `Flag2: BOOL` - Internal flag 2
- `RT: R_TRIG` - Rising edge trigger
- `Pulse: TP` - Pulse timer
- `CTU_0: CTU` - Counter up 0
- `CTD_0: CTD` - Counter down 0
- `CTU_1: CTU` - Counter up 1
- `CTU_2: CTU` - Counter up 2
- `TOF_0: TOF` - Timer off delay 0
### Implementation (Ladder Diagram)
**Network 1: Input Debouncing**
- Input signal → TP (Pulse Timer) with PT = t#100ms
- TP output → TOF (Timer Off Delay) with PT = t#100ms
- TOF output → Switch (internal state)
- **Purpose**: Debounces input signal with 100ms pulse and 100ms off delay
**Network 2: Flag1 Logic**
- Switch AND (NOT Light) AND (NOT Flag2) → Flag1
- **Purpose**: Sets Flag1 when switch is on, light is off, and Flag2 is off
**Network 3: Flag2 Logic**
- Switch AND Light AND (NOT Flag1) → Flag2
- **Purpose**: Sets Flag2 when switch is on, light is on, and Flag1 is off
**Network 4: Light Toggle Logic**
- Flag1 AND (NOT Flag2) → Light (toggle)
- **Purpose**: Toggles light state based on flag conditions
**Network 5: Output Assignment**
- Light → Output
- **Purpose**: Direct output assignment
### Timing Characteristics
- **Input Debounce**: 100ms pulse timer (TP)
- **Output Delay**: 100ms off delay (TOF)
- **Total Response Time**: ~200ms (debounce + delay)
## Function Block: fb_switch
### Interface
**Inputs**:
- `switches: struct_switches` - Switch states from Node-RED
**Outputs**:
- `lights: struct_lights` - Light control outputs to Node-RED
**Internal Variables**:
- `all_off: fb_toogleButton` - Toggle button for "all off"
- `all_on: fb_toogleButton` - Toggle button for "all on"
- `sw_1: fb_toogleButton` - Toggle button for switch 1
- `sw_2: fb_toogleButton` - Toggle button for switch 2
- `sw_3: fb_toogleButton` - Toggle button for switch 3
- `sw_4: fb_toogleButton` - Toggle button for switch 4
- `sw_5: fb_toogleButton` - Toggle button for switch 5
- `sw_6: fb_toogleButton` - Toggle button for switch 6
### Implementation (Continuous Function Chart - CFC)
**Logic Flow for Each Light (l_1 through l_6)**:
1. **All Off Logic**:
```
all_off.Output AND lights.l_X → AND gate → (forces light off)
```
2. **All On Logic**:
```
all_on.Output AND (NOT lights.l_X) → AND gate → (forces light on)
```
3. **Individual Switch Logic**:
```
switches.sw_X → sw_X.Input → sw_X.Output → lights.l_X
```
4. **Combined Logic (OR)**:
```
(all_on logic) OR (sw_X.Output) OR (other sources) → lights.l_X
```
**Execution Order** (example for l_1):
1. Execution Order 1: AND gate for all_on logic
2. Execution Order 2: sw_2 toggle button
3. Execution Order 3: OR gate combining sources
4. Execution Order 4: AND gate for all_off logic
5. Execution Order 5: Output assignment to lights.l_1
6. Execution Order 30: sw_1 toggle button (individual control)
**Key Logic Patterns**:
- **All Off**: Uses AND gate with `all_off.Output` and current light state
- **All On**: Uses AND gate with `all_on.Output` and inverted light state
- **Individual Control**: Each switch has its own toggle button instance
- **Priority**: All_off can override individual controls, all_on combines with individual
## Program: Lights
The "Lights" program contains instances of `fb_switch` for all 15 rooms:
1. `masterBedroom: fb_switch`
2. `masterBathroom: fb_switch`
3. `bedroom_1: fb_switch`
4. `bedroom_2: fb_switch`
5. `bathroom: fb_switch`
6. `guest_wc: fb_switch`
7. `kitchen: fb_switch`
8. `pantry: fb_switch`
9. `livingRoom: fb_switch`
10. `diningRoom: fb_switch`
11. `veranda: fb_switch`
12. `entrance: fb_switch`
13. `front: fb_switch`
14. `back: fb_switch`
15. `side: fb_switch`
16. `hallway: fb_switch`
## Network Variables
### NVL_Sender (Sent to Node-RED)
All 15 room light structures:
- `l_masterBedroom` through `l_outBack` (struct_lights)
### NVL_Receiver (Received from Node-RED)
All 15 room switch structures:
- `masterBedroom` through `outBack` (struct_switches)
## Control Logic Summary
### Individual Light Control
1. **Switch Input** → `switches.sw_X` (from Node-RED)
2. **Toggle Processing** → `fb_toogleButton` instance
- 100ms debounce (TP)
- 100ms delay (TOF)
- Toggle logic with flags
3. **Output** → `lights.l_X` (to Node-RED)
### Global Commands
**All Off**:
- `switches.all_off` → `all_off` toggle button
- Output ANDed with current light state
- Forces all lights off
**All On**:
- `switches.all_on` → `all_on` toggle button
- Output ANDed with inverted light state
- Forces all lights on
- Combined with individual switches via OR logic
### Timing Characteristics
- **Task Cycle**: 4ms (MainTask and EtherCAT_Task)
- **Input Debounce**: 100ms
- **Output Delay**: 100ms
- **Network Variable Update**: 50ms (from .export analysis)
- **Total Response**: ~200ms (debounce + delay)
## Implementation Language
- **fb_toogleButton**: Ladder Diagram (LD)
- **fb_switch**: Continuous Function Chart (CFC)
- **Lights Program**: Continuous Function Chart (CFC)
## Key Insights
1. **Debouncing**: All switch inputs are debounced with 100ms pulse timer
2. **Toggle Logic**: Uses flag-based state machine for reliable toggling
3. **Priority System**: All_off has priority over individual controls
4. **Combined Control**: All_on works in conjunction with individual switches
5. **Fast Response**: 4ms task cycle ensures responsive control
6. **Structured Design**: Each room is independent with its own fb_switch instance
---
**Analysis Date**: January 27, 2026
**Source File**: `Home_Automation.xml`
**Format**: PLCopen XML (TC6 0200)