Skip to content

Conversation

@maxwell-01
Copy link

🎯 Overview

Adds software PWM LED dimming for indicator LEDs on Router builds, providing 16 discrete brightness levels (0-15) at 500Hz. Users can now control indicator LED brightness through Zigbee2MQTT and ZHA.

⚠️ Important: Untested on Hardware

I don't have a hardware flasher and cannot test this on actual devices. The implementation compiles successfully and passes all unit tests, but needs community testing on real hardware before merge.

Key Features

  • 16-level brightness control (0-15) for indicator LEDs
  • Router builds only - preserves battery on End Device builds
  • Automatic detection in Z2M/ZHA converters
  • Persistent settings via non-volatile storage
  • Clean fallback to standard LED control when disabled

🐳 Docker Support Added

Added containerized build environment since I'm on Windows and couldn't build natively:

  • Dockerfile + docker-compose.yml for cross-platform builds
  • Cached volumes for faster rebuilds
  • Updated build documentation

📱 Supported Devices

  • Moes ZS-EUB 2-gang Switch (MOES_2_GANG_SWITCH) - Router build only
    • PWM pins: D3, C0
    • Default brightness: 2 (≈12.5%)

🔧 Zigbee Integration

New Attributes:

  • 0xff03 - PWM Enable/Disable (Boolean)
  • 0xff04 - PWM Brightness (0-15)

Home Assistant Entities:

  • switch.device_relay_indicator_pwm_mode
  • number.device_relay_indicator_pwm_brightness

🏗️ Implementation

  • Software PWM engine in src/base_components/led_pwm.{c,h}
  • Device database driven via indicator_pwm: true flag
  • Conditional compilation with INDICATOR_PWM_SUPPORT
  • Comprehensive unit tests (6/6 passing)

📚 Documentation

  • docs/pwm_led_dimming.md - Feature guide
  • docs/zha_pwm_integration.md - ZHA setup
  • docs/building.md - Updated with Docker instructions
  • Updated device database documentation

🔄 Backward Compatibility

  • End Device builds unchanged
  • Existing devices unaffected
  • Z2M/ZHA gracefully handle PWM detection

🙏 Community Testing Needed

Since I can't test on hardware, please help verify:

  • PWM dimming works on actual Moes switches
  • Z2M/ZHA integration functions correctly
  • No regressions on existing functionality

- Resolved conflicts in src/configs/nv_slots_cfg.h by keeping main structure and adding PWM config
- Resolved conflicts in zigbee2mqtt/converters/switch_custom.js by merging PWM features with main changes
- Maintained existing code style and structure
- Added network indicator support and binded mode features from main
- Preserved PWM LED dimming functionality from enhancement branch
@andrei-lazarov
Copy link
Contributor

andrei-lazarov commented Sep 12, 2025

I noticed the PR hasn't had anything happen to it yet, is there a process I should be following to get it reviewed?

Hi, thanks for your interest in the project.

There isn't a process. I just don't know how to react to this.
I did not expect a huge AI-generated PR.

I can point out a couple of things:

  • Docker is inefficient on Windows and doesn't really make sense.
    WSL is the recommended way to run Linux programs on Windows.
  • The converters and quirks are generated, so we need to update the templates instead.
  • Your device does not support hardware PWM so the database fields are not useful right now.
    Software PWM would be supported by every device so we don't need another list in the docs. Also it would not change parsing.
  • I merged router and end_device entries in the database so you have to update that.
  • I think it's easier to write the code from scratch and test it progressively than to review and debug a big AI-gen change. Note that this project is incredibly niche so AI tends to hallucinate.
    The smallest mistake can cause bugs and bricking. The only recovery method is flashing by wire, which most users won't be able to do.
  • The sdk has a built-in timer function which we should probably use.

I kindly suggest you let more experienced contributors tackle this feature.
Also, even if I figure this out, we still need romasku's approval - who can't dedicate much time to the project right now.

You can join the Discord server for quicker updates about the project and seeking what we are currently working on.
Fixing current issues takes priority and we are still a small team contributing in our free time.

I personally focus on welcoming more users, replying to everyone, trying to grow the team and supporting more devices. Thanks for understanding!

…-support

# Conflicts:
#	docs/supported_devices.md
@maxwell-01
Copy link
Author

Hi, thanks for your interest in the project.

Hi, thank you for taking the time to review and share your perspective. I’d like to clarify a couple of things about how I approached this:

  • I’m a software developer, but I don’t have prior experience writing firmware. To get up to speed I used the Augment plugin in Rider mainly to help me understand the existing codebase and steer direction. I tried to follow existing styles and conventions as closely as I could, but I leaned on AI in areas where I lacked familiarity. I also let the AI generate the documentation, since that’s a part I tend to find less enjoyable, though I thought the results were decent.

  • I didn’t expect the PR to grow as large as it did when I first started. Initially it seemed like a manageable task, but it became clear fairly quickly that the scope was larger than I had anticipated. I understand why you’d suggest a more incremental, progressive approach.

  • On Docker: I was assuming use of the WSL engine in Docker. For me that felt faster and easier than using WSL directly, but I’m happy to adjust/remove if that’s not preferred.

  • Your points on converters, quirks, and device database handling all make sense, and I understand why software PWM shouldn’t need separate lists or parsing changes.

I appreciate your note that this project is niche, that AI can hallucinate, and that mistakes here could be costly given the flashing constraints. I completely understand why you’d prefer someone more experienced to take this forward.

That said, I’ll look at addressing some of your comments regardless—even if this PR isn’t merged, it may still serve as a reference for future work.

Thanks again for the feedback, and for all the effort you and the team put into maintaining and growing the project.

@andrei-lazarov
Copy link
Contributor

andrei-lazarov commented Sep 12, 2025

In that case you should order a flashing adapter and a spare switch so you can start testing your changes.

If you want to avoid soldering, I think you can get a development board (I didn't test these yet).

But anyway your switch should have an exposed header where you can easily connect VCC and GND.
And then you can hold SWS and RST connected with your hands. (This is what I do)

@maxwell-01
Copy link
Author

@andrei-lazarov - I have not had a chance to buy or test using a hardware device but I did action the feedback from your comments and pushed the new changes - hopefully it will be of some use!

@maxwell-01
Copy link
Author

Hi @andrei-lazarov - I've not had time to test this with a new job and a baby! Looks like the merge conflicts are building up though 🙈

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants