Skip to content

v2.0.19 — macOS support + Home Assistant auto-discovery fix

Choose a tag to compare

View all tags
@K0rb3nD4ll4S K0rb3nD4ll4S released this 11 May 15:39
· 31 commits to main since this release
v2.0.19
e326cd5

What's New in v2.0.19

Two major themes: macOS is now a first-class platform, and the Home Assistant integration uses HA's own SSDP/DHCP discovery framework so it works in Docker bridge networking (the most common HA install).

All monorepo packages bumped to 2.0.19 in unified versioning.

🍎 macOS support (new — universal x64 + Apple Silicon)

Dibby Wemo Manager now runs on macOS with full feature parity to the Windows build:

  • Cross-platform path refactor — new core/paths.js module is the single source of truth. Resolves to /Library/Application Support/Dibby Wemo Manager/ on macOS, C:\ProgramData\DibbyWemoManager\ on Windows, /var/lib/dibby-wemo-manager/ on Linux
  • macOS headless service via LaunchDaemon — installed to /Library/LaunchDaemons/com.srsit.dibbywemoscheduler.plist via the native macOS authentication dialog (osascript privileged-shell helper, no extra dependencies). Runs at boot under root via launchd, hosts the HomeKit bridge + scheduler 24/7
  • Universal Node binary shipped via extraResources (lipo'd x64 + arm64) so the LaunchDaemon has a Node interpreter with chacha20-poly1305 cipher support (Electron's BoringSSL doesn't expose it in a hap-nodejs-compatible form)
  • Hardened-runtime + entitlements (resources/entitlements.mac.plist) so the app can JIT, spawn the bundled node, and bind HAP listener ports
  • Platform-aware UI labels — "DibbyWemoScheduler service" on Windows, "Dibby Wemo LaunchDaemon" on macOS, etc.

On first launch the .dmg is ad-hoc signed (not Apple-notarised). macOS shows "Dibby Wemo Manager can't be opened because Apple cannot check it for malicious software." To open:

  1. Right-click the app in Applications → Open → confirm in the dialog
  2. After the first launch, future launches open normally
  3. Service install (Settings → 🏠 HomeKit Bridge) prompts for your macOS admin password via the standard system dialog

🏠 Home Assistant integration — proper auto-discovery

The HA integration previously used raw socket multicast in its config flow, which fails silently in Home Assistant Container with default Docker bridge networking (the most common install). This release switches to Home Assistant's own discovery framework via manifest.json declarations:

  • SSDP deviceType patterns for every Wemo product line (controllee, lightswitch:1/:2, sensor, Lighting, bridge, insight, Maker, dimmer, Crockpot, Coffee, HeaterB, HumidifierB, AirPurifier, NetCamSensor) plus catch-all manufacturer Belkin International Inc.
  • DHCP macaddress patterns for 18 known Belkin OUIs
  • async_step_ssdp + async_step_dhcp handlers in config_flow.py
  • Single-instance unique ID — one Dibby Wemo entry covers all devices on LAN
  • Legacy user step kept as fallback with comma-separated manual IP list
  • Options flow exposes manual-device editing post-install

⚠ Important if you already use HA's built-in wemo integration: disable it first. Both declare the same SSDP/DHCP patterns and will create duplicate entities + race each other on toggles. See README for steps.

Linux

Cross-platform paths work; systemd service install is scaffolded but not implemented in this release — returns a clear error. Planned for v2.0.20. The desktop app still works fine for device control + DWM rule editing while open.

Install

Platform Action
Windows desktop Download Dibby Wemo Manager Setup 2.0.19.exe below
Windows portable Download Dibby Wemo Manager 2.0.19.exe
macOS Download Dibby Wemo Manager-2.0.19.dmg → right-click → Open first launch
Homebridge npm install -g homebridge-dibby-wemo
HOOBS Plugins tab → search homebridge-dibby-wemo → Install
Home Assistant HACS → Custom repositories → add this repo as Integration. Disable HA's built-in wemo first.
Node-RED npm install node-red-contrib-dibby-wemo (from ~/.node-red)
Assets 6
Loading