Repository navigation
Brightness with colour in one packet; MITM switch kept across reconnects - #53
Merged
baudneo merged 2 commits intoNov 1, 2026
Conversation
When one MQTT message carries brightness AND a colour or colour temp
(what Home Assistant sends for light.turn_on with brightness_pct +
color_temp_kelvin or rgb_color), the brightness went out as its own 0xF0
packet, followed by the colour packet with its brightness byte at 0xFF
("keep"). On a type 75 string light at 25 %, {"brightness": 100,
"color_temp": 5000} and {"brightness": 100, "color": white} both left
it at 25 %.
The 0xF0 colour / colour temp payload already has a brightness byte, so
set_temperature() and set_rgb() take an optional bri (0-100) and send
one packet carrying both; the state callbacks then publish the colour
and the brightness. Brightness alone, colour alone and Sol lamps (their
own 5-byte packets) are unchanged. If the colour temp is invalid, the
brightness still goes out on its own.
tests/test_brightness_with_color_one_packet.py: 5 of its 9 tests fail
without the change.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
After devices reconnected, only one of four connected devices still had its "MITM Mode" switch in Home Assistant. Two paths removed it: - Same IP: the server reuses the session object for the new socket. Closing the old socket deleted the switch, and the reused session kept mitm_button_added=True, so its next 0x73 never published it again. Now the reuse path closes without removing the switch, and existing_init() re-arms mitm_button_added. - New IP: the new session published the switch, then the stale session closed and deleted it for the same node. Now only the node's current session (node.tcp_session) may remove the switch. Closing a device's current session still removes its switch. tests/test_mitm_switch_survives_reconnect.py: 3 of its 4 tests fail without the change. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two independent fixes, one commit each. Both have run in our local build since 2026-10-26 (5 WiFi devices: types 75, 127, 171).
1. Brightness + colour / colour temp in one packet (
5791e19)When one MQTT message carries brightness and a colour or colour temp (what Home Assistant sends for
light.turn_onwithbrightness_pct+color_temp_kelvinorrgb_color), the brightness went out as its own 0xF0 packet, then the colour packet followed with its brightness byte at0xFF("keep"). The light kept its old brightness. On a type 75 string light at 25 %,brightness_pct: 100+ 5000 K,brightness_pct: 100+ rgb and rgb +brightness: 128(HA's 0-255 scale) all stayed at 25 %.The 0xF0 colour / colour temp payload already has a brightness byte, so
set_temperature()andset_rgb()take an optionalbri(0-100) and send one packet with both. The ack callback publishes the colour and then the brightness. Brightness alone, colour alone and Sol lamps (their own 5-byte packets) are unchanged. If the colour temp in the message is invalid, the brightness still goes out on its own.Checked on hardware: after the change, all three calls set the new brightness, and the device's own mesh status after a reconnect agreed (100 %, the colour sent).
Test:
tests/test_brightness_with_color_one_packet.py(9 tests, 5 fail without the change).2. A device's MITM switch survives its reconnects (
666a26a)After devices reconnected, only one of four connected devices still had its "MITM Mode" switch. Two paths removed it:
mitm_button_added=True, so its next 0x73 never published it again. Now the reuse path closes withremove_mitm_button=Falseandexisting_init()re-armsmitm_button_added.node.tcp_session) removes the switch.Closing a device's current session still removes its switch.
Checked on hardware: after a restart all 3 connected devices had their switches. Turning MITM off on one forced a same-IP reconnect, and all 3 switches were still there.
Test:
tests/test_mitm_switch_survives_reconnect.py(4 tests, 3 fail without the change).Not addressed here (seen once): an OFF sent about 1 s after ON, while the device is still reconnecting, was dropped. The switch read off but the relay to the cloud stayed up until a second OFF.
Full suite: 284 passed (commit 1 alone: 280), ruff clean.
🤖 Generated with Claude Code