feat: add support for Switcher On Wall device

[giladtamam]

• Add ON_WALL device type with hex code 0321
• Add 170-byte datagram length support in bridge
• Add test coverage for new device type
• Update supported devices documentation

Description

Checklist

• I have followed this repository's contributing guidelines.
• I will adhere to the project's code of conduct.

Additional information

Summary by CodeRabbit

Release Notes

• New Features

  • Added support for Switcher On Wall device

• Documentation

  • Updated supported devices list and usage examples with new device information

• Tests

  • Expanded test coverage for device type support

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.05%. Comparing base (f5ade6d) to head (bd10b7d).
⚠️ Report is 6 commits behind head on dev.

Additional details and impacted files

@@            Coverage Diff             @@
##              dev     #847      +/-   ##
==========================================
+ Coverage   98.99%   99.05%   +0.05%     
==========================================
  Files          11       11              
  Lines        1292     1371      +79     
==========================================
+ Hits         1279     1358      +79     
  Misses         13       13              

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[YogevBokobza]

Hey
This PR is a good start but it only very partially.
there is a lot of work to do.
You can see my PR of the heater implementation.

[giladtamam]

@YogevBokobza Thanks for you response, I have updated the PR following your last comment. let me know if something still missing. As far as I understand in your PR you added a new Category but in my PR, I'm using WATER_HEATER category there fore it's not a lot as you mention.

[YogevBokobza]

@giladtamam
Closed by mistake haha
Anyway, I think that this On Wall device is needed a token therefore it changing a lot here..
I was planning to work on this implementaion soon after the other PR is done

[giladtamam]

@YogevBokobza with help from cursor I got the following info:
ON_WALL Device Testing Results:

• Token Required: NO
• Protocol Type: 2 (port 10000, not 9957)
• Login Packet: LOGIN_PACKET_TYPE2 works
• State Packet: GET_STATE_PACKET_TYPE1 returns data but format differs

Changes needed in aioswitcher:

1. DeviceType.ON_WALL: protocol_type should be 2 (not 1)
2. _login(): ON_WALL should use LOGIN_PACKET_TYPE2
3. State parsing: ON_WALL needs custom state response parser
   • The 111-byte response has different field positions
   • Position 150:152 is NOT the device state (value is '04')

Raw state response (111 bytes):
fef06f00040201030000000034000200000000000000000061bf5e6900000000000000000000f0fe53776974636865725f6f6e57616c6c5f393244380000000000000000000000000320000400000000000000000000000000000000000000000000000000004d280000025b83ade0
can you verify?

[ewino]

Hi @giladtamam, I made some research on the OnWall - mind if I push a couple of my changes to this PR?

For reference (ImHex pattern):

u16 signature @ 0x00;
u16 device_type @ 0x4a;
bool device_state @ 0x87; // 2 after v2
le u16 power_consumption @ 0x8f;
u24 time @ 0x18;

u24 device_id @ 0x12;
u16 device_key @ 0x28;
u32 ip @ 0x4d; // 1 after v2
u48 mac @ 0x51; // 1 after v2
char name[32] @ 0x2a;
u32 remaining @ 0x9d; // 9 after v2
// u32 auto_shutdown @ 0x9b;  didn't find mention of auto_shutdown in OnWall packets

[TomerFi]

Thank you @giladtamam @YogevBokobza and @ewino!
#835 is about to be merged, let's wait for it and rebase.

[coderabbitai]

📝 Walkthrough

Walkthrough

This pull request adds support for a new device type, "Switcher On Wall" (ON_WALL), by introducing its enum definition, device mappings, datagram protocol detection, documentation updates, and corresponding test coverage across the codebase.

Changes

Cohort / File(s)	Summary
Device Type Definition src/aioswitcher/device/__init__.py, tests/test_device_enum_helpers.py	Added new DeviceType.ON_WALL enum member with value "Switcher On Wall", hex "0321", protocol_type 1, category WATER_HEATER, and token_needed False. Test coverage added for the new device type properties.
Device Mappings & Bridge Protocol scripts/control_device.py, src/aioswitcher/bridge.py	Added "onwall" to DEVICES mapping pointing to DeviceType.ON_WALL. Extended is_switcher_originator() to recognize 170-byte datagrams for ON_WALL device detection.
Documentation docs/supported.md, docs/usage_api.md	Added "Switcher On Wall" to supported devices table with version 6.1.x and token requirement status. Extended water heater usage example with ON_WALL device type invocation.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Possibly related PRs

• PR #835: Adds support for a different device type (HEATER) through the same device enum/mappings and bridge datagram length detection mechanisms.

Suggested labels

size: l

Suggested reviewers

• TomerFi
• thecode

Poem

🐰 A new device joins the wall,
Switcher On Wall heeds the call,
With mappings, enums, and tests aligned,
Protocol detection refined,
The flock grows, code stays defined! 🌟

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically summarizes the main change: adding support for a new device type (Switcher On Wall). It accurately reflects the core objective of the pull request across all modified files.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[YogevBokobza]

Now that #835 is merged I will take over this PR and continue to implement the rest.
This device is token-based and I have one here I will do all the tests with that.

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@docs/supported.md`:
- Line 7: The supported devices table incorrectly states "Requires token: Yes"
for Switcher On Wall; update the docs/supported.md table row(s) for "Switcher On
Wall" to show "No" under the "Requires token" column to match the code symbol
DeviceType.ON_WALL (token_needed=False) and the tests; search for any other
occurrences of "Switcher On Wall" in docs/supported.md (including the noted
second occurrence) and change their "Yes" to "No" so the documentation aligns
with the implementation.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

# First, let's find where DeviceType.ON_WALL is defined and check the token requirement
find . -type f -name "*.py" | head -20

Repository: TomerFi/aioswitcher

Length of output: 699

---

🏁 Script executed:

# Search for ON_WALL in the codebase
rg "ON_WALL" --type py

Repository: TomerFi/aioswitcher

Length of output: 370

---

🏁 Script executed:

# Also search for the supported.md file to check the current state
cat docs/supported.md

Repository: TomerFi/aioswitcher

Length of output: 3884

---

🏁 Script executed:

# Let's examine the DeviceType definition to understand what that False parameter means
sed -n '1,100p' src/aioswitcher/device/__init__.py | head -50

Repository: TomerFi/aioswitcher

Length of output: 1983

---

🏁 Script executed:

# Search for token_needed in the codebase to understand the parameter meaning
rg "token_needed" --type py -B 2 -A 2

Repository: TomerFi/aioswitcher

Length of output: 12453

---

🏁 Script executed:

# Let's verify if there's any special handling for ON_WALL token requirements
rg "ON_WALL" --type py -B 5 -A 5

Repository: TomerFi/aioswitcher

Length of output: 2952

---

Update documentation to reflect that Switcher On Wall doesn't require a token.

The code defines DeviceType.ON_WALL with token_needed=False, and tests confirm this requirement, but the supported devices table lists "Requires token: Yes". This should be corrected.

Suggested fix

-| Switcher On Wall         |    [product][switcher-on-wall]      |         6.1.x         |         Yes        |
+| Switcher On Wall         |    [product][switcher-on-wall]      |         6.1.x         |         No         |

Also applies to: 28-28

🤖 Prompt for AI Agents

In `@docs/supported.md` at line 7, The supported devices table incorrectly states
"Requires token: Yes" for Switcher On Wall; update the docs/supported.md table
row(s) for "Switcher On Wall" to show "No" under the "Requires token" column to
match the code symbol DeviceType.ON_WALL (token_needed=False) and the tests;
search for any other occurrences of "Switcher On Wall" in docs/supported.md
(including the noted second occurrence) and change their "Yes" to "No" so the
documentation aligns with the implementation.

[giladtamam]

Now that #835 is merged I will take over this PR and continue to implement the rest. This device is token-based and I have one here I will do all the tests with that.

Great, let me know if want me to test it

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[giladtamam]

On Wall TCP control protocol analysis

@YogevBokobza @ewino @TomerFi

I've done extensive protocol analysis on my On Wall device (0321) and found that the device firmware does not support the standard TCP control command (0102).

What works

• Login (both LOGIN_PACKET_TYPE2 and LOGIN_TOKEN_PACKET_TYPE2) ✅
• Get state (GET_STATE_PACKET_TYPE1 with command type 0103) ✅
• Token: convert_token_to_packet() works, token login succeeds

What doesn't work

• Control (SEND_CONTROL_PACKET with command type 0102) ❌ — always returns status=0x10 at byte 15
• GENERAL_TOKEN_COMMAND with CONTROL_DEVICE_PRECOMMAND = "3723" ❌ — same 0x10 error
• Tested every protocol version (0232, 0305, 0402), every precommand (3700-3725), every command type byte (0x00-0x1F) — all rejected with 0x10 or timeout

Key findings

• Only port 10000 is open on the device
• The Switcher mobile app controls the device through the cloud, not via local TCP (confirmed via tcpdump — zero packets to device IP when toggling from app)
• Command type 0103 (get state) is the only command that returns status=0x00 (success)
• Command type 0102 (control) always returns status=0x10 (rejected)
• All other command types get no response (timeout)

Login2 response (132 bytes) contains

• Device name, type (0321), MAC, IP (0a646606 = 10.100.102.6)
• Device key (0f)
• Auto shutdown value

Questions

1. Does your On Wall device accept 0102 control commands?
2. Is there a firmware version that enables local control?
3. Should we focus on cloud API control instead?

Device info: IP 10.100.102.6, ID cc5f6a, key 0f, protocol_type 2 (port 10000)

[TomerFi]

The Switcher mobile app controls the device through the cloud, not via local TCP (confirmed via tcpdump — zero packets to device IP when toggling from app)

Didn't they used to have a Local Only option in thier app?

[YogevBokobza]

On Wall TCP control protocol analysis

@YogevBokobza @ewino @TomerFi

I've done extensive protocol analysis on my On Wall device (0321) and found that the device firmware does not support the standard TCP control command (0102).

What works

• Login (both LOGIN_PACKET_TYPE2 and LOGIN_TOKEN_PACKET_TYPE2) ✅
• Get state (GET_STATE_PACKET_TYPE1 with command type 0103) ✅
• Token: convert_token_to_packet() works, token login succeeds

What doesn't work

• Control (SEND_CONTROL_PACKET with command type 0102) ❌ — always returns status=0x10 at byte 15
• GENERAL_TOKEN_COMMAND with CONTROL_DEVICE_PRECOMMAND = "3723" ❌ — same 0x10 error
• Tested every protocol version (0232, 0305, 0402), every precommand (3700-3725), every command type byte (0x00-0x1F) — all rejected with 0x10 or timeout

Key findings

• Only port 10000 is open on the device
• The Switcher mobile app controls the device through the cloud, not via local TCP (confirmed via tcpdump — zero packets to device IP when toggling from app)
• Command type 0103 (get state) is the only command that returns status=0x00 (success)
• Command type 0102 (control) always returns status=0x10 (rejected)
• All other command types get no response (timeout)

Login2 response (132 bytes) contains

• Device name, type (0321), MAC, IP (0a646606 = 10.100.102.6)
• Device key (0f)
• Auto shutdown value

Questions

1. Does your On Wall device accept 0102 control commands?
2. Is there a firmware version that enables local control?
3. Should we focus on cloud API control instead?

Device info: IP 10.100.102.6, ID cc5f6a, key 0f, protocol_type 2 (port 10000)

Unfortunatly we have an issue..

I spoke with my contact Switcher guy and he said that they put some different hardware in this device and it behaves very differently..
He doesn't have answers right now about what we can do in order to support this device..
He will get back to me with answers soon..
I will update when I have more information..

[TomerFi]

I spoke with my contact Switcher guy and he said that they put some different hardware in this device and it behaves very differently..
He doesn't have answers right now about what we can do in order to support this device..
He will get back to me with answers soon..
I will update when I have more information..

Let's close this PR then. We can open an issue or a discussion for tracking this.

[thecode]

I spoke with my contact Switcher guy and he said that they put some different hardware in this device and it behaves

@YogevBokobza any news from Switcher?

Let's close this PR then. We can open an issue or a discussion for tracking this.

@TomerFi I missed this comment, I agree with you. I think it is better to close this PR, create an issue, collect all the data there and once we know what is needed create a new PR.

[TomerFi]

Closing this PR in favor of issue #889 to better track the investigation and implementation of support for the Switcher On Wall device.