homebridge-smartsystem 6.8.18 → 7.0.3

package/.vscode/launch.json

@@ -6,8 +6,8 @@
       "request": "launch",
       "smartStep": true,
       "sourceMaps": true,
-      "name": "Test Platform",
-      "program": "${workspaceFolder}/index.spec.js",
+      "name": "Test HB Platform",
+      "program": "${workspaceFolder}/testHB.js",
       "skipFiles": [
         "<node_internals>/**"
       ]
@@ -17,8 +17,19 @@
       "request": "launch",
       "smartStep": true,
       "sourceMaps": true,
-      "name": "Run SmartSocket",
-      "program": "${workspaceFolder}/run.js",
+      "name": "Run SmartSocket Proxy",
+      "program": "${workspaceFolder}/testProxy.js",
+      "skipFiles": [
+        "<node_internals>/**"
+      ]
+    },
+    {
+      "type": "node",
+      "request": "launch",
+      "smartStep": true,
+      "sourceMaps": true,
+      "name": "Run Test Websockets",
+      "program": "${workspaceFolder}/testWS.js",
       "skipFiles": [
         "<node_internals>/**"
       ]

package/MIXINS-GUIDE.md

@@ -0,0 +1,210 @@
+# TypeScript Mixins Pattern for SmartApp
+
+## Overview
+
+Your SmartApp is getting large because it handles multiple concerns:
+- Device management (WebSocket, power measurements)
+- Link management (Homebridge accessories)
+- Switch management (HTTP switches)
+- Power management (Smappee, P1, Shelly)
+- Proxy configuration
+- Settings management
+
+TypeScript doesn't support multiple inheritance, but **mixins** provide a similar capability.
+
+## Solution Options
+
+### **Option 1: Mixin Pattern** (Most Flexible)
+
+Create separate mixin functions that add functionality to your class:
+
+```typescript
+// server/mixins/DeviceMixin.ts
+type Constructor<T = {}> = new (...args: any[]) => T;
+
+export interface DeviceMixinBase {
+  devices: Array<Device>;
+  system: System;
+  power: Power;
+  // ... other required properties
+}
+
+export function DeviceMixin<TBase extends Constructor<DeviceMixinBase>>(Base: TBase) {
+  return class extends Base {
+    setupWebSocketServers() { /* ... */ }
+    sendDeviceList(ws: WebSocket) { /* ... */ }
+    getDeviceList() { /* ... */ }
+    // ... all device-related methods
+  };
+}
+
+// Usage in smartapp.ts
+import { DeviceMixin } from './mixins/DeviceMixin';
+import { LinkMixin } from './mixins/LinkMixin';
+import { SwitchMixin } from './mixins/SwitchMixin';
+
+// Apply mixins
+const SmartAppBase = SwitchMixin(LinkMixin(DeviceMixin(WebApp)));
+
+export class SmartApp extends SmartAppBase {
+  // Only SmartApp-specific logic here
+  constructor(system: System, power: Power, platform: Platform) {
+    super("smartapp");
+    // ...
+  }
+}
+```
+
+**Pros:**
+- True composition - each mixin is independent
+- Can be reused across different classes
+- TypeScript type-safe
+- Easy to test mixins individually
+
+**Cons:**
+- Requires some boilerplate
+- Mixing order matters
+- Can be confusing at first
+
+---
+
+### **Option 2: Delegate Pattern** (Simpler)
+
+Create separate service/manager classes and delegate to them:
+
+```typescript
+// server/services/DeviceManager.ts
+export class DeviceManager {
+  constructor(
+    private devices: Array<Device>,
+    private system: System,
+    private power: Power
+  ) {}
+
+  setupWebSocketServers(servers: http.Server[]) { /* ... */ }
+  getDeviceList() { /* ... */ }
+  // ... all device methods
+}
+
+// server/services/LinkManager.ts
+export class LinkManager {
+  constructor(
+    private links: Array<Link>,
+    private system: System
+  ) {}
+
+  initLinks() { /* ... */ }
+  updateLink(inx: number, link: Link) { /* ... */ }
+  // ... all link methods
+}
+
+// In smartapp.ts
+export class SmartApp extends WebApp {
+  private deviceManager: DeviceManager;
+  private linkManager: LinkManager;
+
+  constructor(system: System, power: Power, platform: Platform) {
+    super("smartapp");
+    
+    this.deviceManager = new DeviceManager(this.devices, this.system, this.power);
+    this.linkManager = new LinkManager(this.links, this.system);
+  }
+
+  // Delegate to managers
+  setupWebSocketServers() {
+    this.deviceManager.setupWebSocketServers(this.servers);
+  }
+
+  initLinks() {
+    this.linkManager.initLinks();
+  }
+}
+```
+
+**Pros:**
+- Simple and intuitive
+- Easy to understand
+- Good separation of concerns
+- Easy to unit test
+
+**Cons:**
+- More delegation boilerplate
+- Not as "clean" as mixins
+- Managers need access to SmartApp state
+
+---
+
+### **Option 3: Module Pattern** (Most Practical)
+
+Split into separate modules but keep in same class:
+
+```typescript
+// server/smartapp/devices.ts
+export class DeviceManagement {
+  static setupWebSocketServers(app: SmartApp) { /* ... */ }
+  static getDeviceList(app: SmartApp) { /* ... */ }
+  // ... all device methods as static functions
+}
+
+// server/smartapp/links.ts
+export class LinkManagement {
+  static initLinks(app: SmartApp) { /* ... */ }
+  static updateLink(app: SmartApp, inx: number, link: Link) { /* ... */ }
+}
+
+// In smartapp.ts
+import { DeviceManagement } from './smartapp/devices';
+import { LinkManagement } from './smartapp/links';
+
+export class SmartApp extends WebApp {
+  setupWebSocketServers() {
+    DeviceManagement.setupWebSocketServers(this);
+  }
+  
+  initLinks() {
+    LinkManagement.initLinks(this);
+  }
+}
+```
+
+**Pros:**
+- Simple to implement
+- Code is organized in separate files
+- No complex patterns needed
+- Easy to refactor incrementally
+
+**Cons:**
+- Still some methods in main class
+- Not true composition
+- Methods take `app` parameter
+
+---
+
+## **Recommended Approach**
+
+For your situation, I'd recommend **Option 2 (Delegate Pattern)** or **Option 3 (Module Pattern)**.
+
+Here's why:
+1. **Easier to understand** - no complex mixin magic
+2. **Incremental refactoring** - move one feature at a time
+3. **Better testability** - each manager/module is isolated
+4. **Clearer dependencies** - you see what each part needs
+
+### Quick Win: Module Pattern
+
+Split your 1680-line smartapp.ts into:
+
+```
+server/
+  smartapp.ts (main class, ~300 lines)
+  smartapp/
+    devices.ts (WebSocket & power, ~300 lines)
+    links.ts (Homebridge links, ~200 lines)
+    switches.ts (HTTP switches, ~200 lines)
+    power.ts (Power bindings, ~150 lines)
+    proxy.ts (Proxy config, ~150 lines)
+    routes.ts (HTTP routing, ~200 lines)
+    units.ts (Unit management, ~150 lines)
+```
+
+Would you like me to help you refactor SmartApp using one of these patterns?

package/README.md

@@ -317,6 +317,9 @@ Homebridge UI version
 - 11: use new DNS entries + exponential backoff for new connections, give up after 16 seconds.
 - 12, 13: small changes for missing value for Target...  
 
+### v7.0.0 - 12/11/2025
+- 0: added mDNS/Bonjour + always port 80 + don't preload EJS files if system.debug == true
+
 ## Hardware 
 A Raspberry Pi that connects to a Duotecno IP Node 
 and (if configured) to a Smappee Infinity (power and plugs) 
@@ -348,6 +351,34 @@ and linked to HB accessories (from v6.7)
   * scenes (a collection of units + a state) that are triggers by a status change (moods, inputs, ...)
   * backup / restore
 
+* Jullix:
+
+  * I would now like to have a websocket server (on the same ports as the SmartApp) that uses JSON as format.
+  * The client that connects can send 2 things: see below, but we should always answer with a number of "switchable items" (relays) together with the power/energy usaged, either measured of estimated (measured: false).
+  * An example we could send:
+    ```
+    [
+      { "id": 1, "name": "Airco", "power": 1.0, "energy": 10.0, "voltage": 230.0, "current": 1.0, "relay": true,  "measured": true},
+      { "id": 2, "name": "Zwembad pomp", "power": 1.0, "energy": 10.0, "voltage": 230.0, "current": 1.0, "relay": true, "measured": false}
+    ]
+    ```
+
+  * What we send / what is in this array needs to be configured though a new section in the web interface.
+
+
+The id's of the relays should be node-numbers * 256 + unit-numbers of Duotecno units (of the first master) and the web/config-page should allow the user to add a "Device" and fill in the details (no id given) + edit a device already in the list. (pass id) (similar as in link-list.ejs and link-details.ejs)
+
+  * Messages we could receive:
+  [] (empty array) keep of keep alice / poll for status
+    ```
+    [
+      { "id": 513 "relay": true },
+      { "id": 258, "relay": false }
+    ]
+    ```
+which would mean: turn unit 1 in node 2 (from 513=2*256+1) "on" and turn unit 2 of node 1 "off" (from 258=1*256+2)
+
+
 
 ## How to set up
 1. Configure IP address of the Raspberry on the SDCard on a PC or Mac (put it in, edit cmdline.txt and you’re done), perhaps DHCP? WiFi?

package/SETTINGS-UPDATE.md

@@ -0,0 +1,195 @@
+# Settings Page Update
+
+## Changes Made
+
+### 1. Cleaned Up Settings Page
+- **Removed** conflicting buttons from header (Reset to DHCP, Install IP Settings, Reboot PI)
+- **Added** proper "Save Settings" button with icon
+- **Added** "Restart Server" button (functional) with icon
+- **Commented out** temporarily disabled network configuration fields
+- **Commented out** temporarily disabled system action buttons
+
+### 2. Added Save Functionality
+- New "Save Settings" button that saves the mDNS configuration
+- Success message displayed after saving
+- Reminder to restart server for changes to take effect
+
+### 3. Temporarily Disabled Features
+The following features are commented out with TODO notes pending proper implementation:
+
+**Network Configuration (commented in EJS):**
+- Primary Fixed IP Address / netmask
+- Gateway
+- Nameservers
+- Secondary IP configuration
+
+**System Actions (commented in EJS):**
+- Reboot System button
+- Reset to DHCP button
+- Install IP Settings button
+
+**Backend Handlers (commented in smartapp.ts):**
+- `install` action - writeDHCP functionality
+- `reset` action - resetDHCP and reboot
+- `reboot` action - system reboot
+
+### 4. Active Features
+Currently working features in Settings:
+
+✅ **mDNS Service Name Configuration**
+- Input field for mDNS name
+- Default value: "duotecno-gateway"
+- Help text showing resulting .local address
+- Save button stores configuration
+
+✅ **Save Settings**
+- Saves mDNS configuration to settings file
+- Shows success message
+- Logs configuration change
+
+✅ **Restart Server**
+- Functional restart button (orange color)
+- Restarts the Node.js process
+- Allows mDNS changes to take effect
+
+### 5. UI Improvements
+
+**Message Display:**
+- Green success message when settings saved
+- Orange info message for disabled features
+- Icon indicators (checkmark for success, info icon for warnings)
+
+**Button Styling:**
+- Save button: Blue with save icon
+- Restart button: Orange with refresh icon
+- Disabled buttons: Commented out (red for reboot, grey for reset, blue for install)
+
+**Layout:**
+- Clear section header: "mDNS Configuration"
+- TODO comment explaining why network settings are disabled
+- Clean, focused interface for current functionality
+
+## Usage
+
+### To Configure mDNS Name:
+
+1. Navigate to `/settings`
+2. Enter desired mDNS name (e.g., "garage-gateway")
+3. Click "Save Settings"
+4. See success message
+5. Click "Restart Server" to apply changes
+6. Access gateway at: `http://{your-name}.local/`
+
+### Current Button Actions:
+
+| Button | Action | Status |
+|--------|--------|--------|
+| Save Settings | Saves mDNS config | ✅ Working |
+| Restart Server | Restarts Node.js process | ✅ Working |
+| Reboot System | System reboot | ⏸️ Disabled (commented) |
+| Reset to DHCP | Reset network config | ⏸️ Disabled (commented) |
+| Install IP Settings | Write DHCP config | ⏸️ Disabled (commented) |
+
+## Technical Details
+
+### Settings File Structure
+```json
+{
+  "network": {
+    "ip1": "",
+    "gateway1": "",
+    "nameservers": "",
+    "ip2": "",
+    "gateway2": ""
+  },
+  "mdnsName": "duotecno-gateway"
+}
+```
+
+### Handler Logic (smartapp.ts)
+
+**Save Action:**
+```typescript
+if (context.action === "save") {
+  config = this.scrapeSettings(context);
+  this.write("settings", config);
+  message = "Settings saved successfully. Restart the server for changes to take effect.";
+  log("smartapp", "Settings saved. mDNS name updated to: " + config.mdnsName);
+}
+```
+
+**Restart Action:**
+```typescript
+else if (context.action === "restart") {
+  context.request = "restart";
+  return this.doRestart(false)
+}
+```
+
+**Disabled Actions:**
+```typescript
+else if (context.action === "install") {
+  message = "Network IP configuration is temporarily disabled. Use 'Save Settings' for mDNS configuration.";
+  // TODO: Re-implement DHCP configuration
+}
+```
+
+## Future Work
+
+### TODO List:
+1. ✅ Test Devices WebSocket functionality (priority)
+2. ⏳ Re-implement DHCP configuration properly
+3. ⏳ Re-enable network IP settings fields
+4. ⏳ Re-enable system reboot functionality
+5. ⏳ Add validation for mDNS name format
+6. ⏳ Test network configuration on actual Raspberry Pi
+7. ⏳ Add confirmation dialog for reboot action
+
+### Implementation Notes:
+
+**DHCP Configuration Issues:**
+- Writing to `/etc/dhcpcd.conf` may require root privileges
+- Need to test on actual Raspberry Pi hardware
+- Consider using `nmcli` or `netplan` for modern systems
+- Add error handling for file write failures
+
+**Reboot Functionality:**
+- Requires appropriate system permissions
+- May need `sudo` or specific user group membership
+- Consider adding confirmation dialog
+- Add timeout before reboot to allow user to see message
+
+## Testing
+
+### Test Save Settings:
+1. Navigate to `/settings`
+2. Change mDNS name to "test-gateway"
+3. Click "Save Settings"
+4. Verify success message appears
+5. Check console log for: "Settings saved. mDNS name updated to: test-gateway"
+6. Verify settings file updated: `cat server/config.json | grep mdnsName`
+
+### Test Restart Server:
+1. Click "Restart Server" button
+2. Server should restart gracefully
+3. mDNS service should re-register with new name
+4. Verify accessible at: `http://test-gateway.local/`
+
+### Verify Disabled Features:
+1. Network IP fields should be commented out (not visible)
+2. System action buttons should be commented out (not visible)
+3. No errors in console when loading `/settings`
+4. Form should only show mDNS configuration and two buttons
+
+## Summary
+
+The Settings page is now **focused and functional** with:
+- ✅ mDNS name configuration working
+- ✅ Save button added
+- ✅ Restart server button working
+- ✅ Success/info messages displayed
+- ✅ Clean UI with proper icons
+- 🔒 Network configuration temporarily disabled pending fixes
+- 📝 Clear TODO notes for future implementation
+
+Priority remains on testing the Devices WebSocket functionality before re-enabling network configuration features.

package/TESTING-GUIDE.md

@@ -0,0 +1,220 @@
+# Testing WebSocket Device Control
+
+## Setup Complete ✅
+
+I've added 2 test devices to your `config.json`:
+
+1. **Test Lamp** (Node 3, Unit 34, ID: 802)
+   - Estimated power: 100W
+   - Maps to your existing "Lamp-Bottom" unit
+
+2. **Blue LED** (Node 3, Unit 30, ID: 798)  
+   - Estimated power: 50W
+   - Maps to your existing "Blue LED" unit
+
+## Testing Steps
+
+### **Step 1: Start the Server (in Debug Mode)**
+
+1. Open VS Code debugger
+2. Set breakpoints if needed:
+   - `server/smartapp.ts` line ~165 (setupWebSocketServers)
+   - `server/smartapp.ts` line ~230 (handleDeviceMessage)
+3. Run the debugger with testHB.ts configuration
+   - Or: `ts-node testHB.ts` in terminal
+
+The server should start on port 5002 (from your config)
+
+### **Step 2: Verify Server Started**
+
+You should see log messages:
+```
+✓ WebSocket server 0 set up on path /devices
+✓ WebApp - Listening on port 5002
+✓ mDNS service registered
+```
+
+### **Step 3: Test WebSocket Connection**
+
+In a **separate terminal**, run the test client:
+
+```bash
+# Using mDNS name (recommended)
+ts-node testWS.ts ws://duotecno-gateway.local/devices
+
+# Or specify IP address if needed
+ts-node testWS.ts ws://192.168.0.99/devices
+```
+
+### **Step 4: Expected Test Client Output**
+
+```
+╔════════════════════════════════════════════════════════════════════╗
+║   WebSocket Device Control Test Client                            ║
+║   Press Ctrl+C to exit                                             ║
+╚════════════════════════════════════════════════════════════════════╝
+
+🔌 Connecting to WebSocket server: ws://duotecno-gateway.local/devices
+✅ Connected to WebSocket server
+
+📊 Received 2 device(s):
+════════════════════════════════════════════════════════════════════════
+ID  | Name                 | Power(W) | Current(A) | Voltage(V) | Relay | Measured
+────────────────────────────────────────────────────────────────────────
+802 | Test Lamp            |      0.0 |       0.00 |      230.0 | 🔴 OFF | 📝
+798 | Blue LED             |      0.0 |       0.00 |      230.0 | 🔴 OFF | 📝
+════════════════════════════════════════════════════════════════════════
+
+⏱️  Sending keep-alive poll...
+
+🎲 Sending random control commands:
+   → Test Lamp (node=3, unit=34, id=802): 🟢 ON
+   → Blue LED (node=3, unit=30, id=798): 🟢 ON
+
+📊 Received 2 device(s):
+════════════════════════════════════════════════════════════════════════
+ID  | Name                 | Power(W) | Current(A) | Voltage(V) | Relay | Measured
+────────────────────────────────────────────────────────────────────────
+802 | Test Lamp            |    100.0 |       0.43 |      230.0 | 🟢 ON  | 📝
+798 | Blue LED             |     50.0 |       0.22 |      230.0 | 🟢 ON  | 📝
+════════════════════════════════════════════════════════════════════════
+```
+
+Notice:
+- Power goes to estimated value (100W, 50W) when relay is ON
+- Power goes to 0 when relay is OFF
+- Current is calculated (Power / 230V)
+- Measured flag shows 📝 (estimated) not 📊 (measured)
+
+### **Step 5: Test Web UI (Optional)**
+
+1. Open browser: `http://duotecno-gateway.local/devices`
+2. You should see the 2 test devices listed
+3. Click a device to edit:
+   - Change name
+   - Change power source (P1, Shelly, Smappee, or Non-measured)
+   - Change estimated power
+   - Save changes
+
+### **Step 6: Test Manual WebSocket Commands**
+
+You can also test manually using a WebSocket client like `wscat`:
+
+```bash
+# Install wscat if needed
+npm install -g wscat
+
+# Connect using mDNS name
+wscat -c ws://duotecno-gateway.local/devices
+
+# You'll receive device list immediately
+
+# Send keep-alive (poll)
+[]
+
+# Turn device ON
+[{"id": 802, "relay": true}]
+
+# Turn device OFF
+[{"id": 802, "relay": false}]
+
+# Control multiple devices
+[{"id": 802, "relay": true}, {"id": 798, "relay": false}]
+```
+
+## What to Look For
+
+### **✅ Success Indicators:**
+
+1. **WebSocket connects** without errors
+2. **Device list received** with correct IDs (802, 798)
+3. **Relay control works** - devices turn on/off
+4. **Power values update** - shows estimated power when ON, 0 when OFF
+5. **Test client runs** for 30+ seconds without errors
+6. **Random commands sent** every 10-15 seconds
+
+### **❌ Common Issues:**
+
+1. **Connection refused**
+   - Server not running
+   - Wrong port (use 5002 from config)
+   - Check firewall
+
+2. **No devices received**
+   - Check config.json saved correctly
+   - Check server logs for device initialization
+   - Verify devices array is not empty
+
+3. **Relay control doesn't work**
+   - Master not connected (192.168.0.97:5001)
+   - Node/Unit don't exist
+   - Check server logs for "Node X not found" errors
+
+4. **Power always 0**
+   - estimatedPower not set in config
+   - powerSource not "none"
+   - Check device configuration
+
+## Debugging
+
+### **VS Code Debugger Breakpoints:**
+
+Set breakpoints at:
+- `setupWebSocketServers()` - Verify WebSocket server created
+- `handleDeviceMessage()` - See incoming commands
+- `setDeviceRelay()` - Check relay control logic
+- `getDeviceList()` - Verify device data calculation
+
+### **Check Server Logs:**
+
+Look for these messages:
+```
+"WebSocket server 0 set up on path /devices"
+"WebSocket client connected on server 0"
+"Setting device 802 (node=3, unit=34) to true"
+"Init 2 Devices -> add units"
+```
+
+### **Common Debug Scenarios:**
+
+1. **Devices not initialized:**
+   ```
+   "** error ** missing device unit: 0x3/0x22 **"
+   ```
+   → Unit doesn't exist in master
+
+2. **WebSocket connection fails:**
+   ```
+   "WebSocket error on server 0: ..."
+   ```
+   → Check port, network, or code issues
+
+3. **Invalid messages:**
+   ```
+   "Invalid WebSocket message: ..."
+   ```
+   → Check message format (must be JSON array)
+
+## Next Steps After Testing
+
+Once everything works:
+1. ✅ Confirm device control works
+2. ✅ Verify power measurements (estimated)
+3. 🔄 Add real power source (Smappee/P1/Shelly)
+4. 🔄 Configure power channels
+5. 🔄 Test with real measurements
+6. 🔄 Then proceed with Module refactoring
+
+## Quick Commands
+
+```bash
+# Terminal 1: Start server
+ts-node testHB.ts
+
+# Terminal 2: Run test client
+ts-node testWS.ts ws://duotecno-gateway.local/devices
+
+# Press Ctrl+C in either terminal to stop
+```
+
+Good luck! 🚀