hour_effect_v2: fix UTC/localTime mismatch, notify ordering, and input-pin self-heal - #27
Open
KrX3D wants to merge 1 commit into
Open
hour_effect_v2: fix UTC/localTime mismatch, notify ordering, and input-pin self-heal#27KrX3D wants to merge 1 commit into
KrX3D wants to merge 1 commit into
Conversation
…t-pin self-heal
- parseNotificationEffectPayload's stale-message check compared msgTimestamp
(a real UTC epoch, e.g. HA's as_timestamp(now())) against localTime, which
is timezone/DST-adjusted. On any non-UTC device this made every fresh
notification effect look stale and get dropped. Use toki.second() (raw NTP
UTC seconds) instead.
- applyEffectSettings() called stateUpdated() before _SetLedsOn() despite a
comment claiming the order was already fixed, so MQTT/UDP listeners were
notified of the new effect colors while bri was still 0. Reordered to turn
the LEDs on first, restoring the internalStateChange guard around the
stateUpdated() call so it doesn't misinterpret its own notification as an
external brightness change.
- checkInputPin() never called reconcilePresenceLed() on an unchanged read,
unlike every MQTT presence path, so pin-based presence had no way to
self-heal if the LEDs were turned off externally while the pin stayed
active. Added the same steady-state reconcile call.
- Fixed mojibake ("Küche" corrupted to replacement/`?` characters) in the
in-file JSON config documentation examples.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J6bJtispewBKR2dXBcNWpw
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
2 participants
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.
Summary
Follow-up review pass on the
hour_effect_v2usermod (after the earlier #23/#26 fixes), looking specifically for remaining bugs. Found and fixed four issues:onMqttMessage's/NotificationEffecthandler rejects a retained/replayed message once its owndurationMshas elapsed since it was sent, by comparing the payload'smsgTimestamp(a real UTC Unix timestamp, e.g. Home Assistant'sas_timestamp(now())) against WLED's globallocalTime.localTimeis timezone/DST-adjusted (updateLocalTime()inntp.cpp), so on any device configured for a non-zero UTC offset the computed age was off by roughly the timezone offset — enough to exceedmaxAge(capped at 600s) and make every fresh notification effect look "stale" and get silently dropped. Now compares againsttoki.second(), the raw NTP UTC seconds, instead.applyEffectSettings()had a comment claiming it notifies after turning the LEDs on sostateUpdated()sees the correctbri, but the actual statement order still calledstateUpdated()before_SetLedsOn(). Any MQTT/UDP listener (e.g. Home Assistant) receiving the notification while the LEDs were off would see the new effect colors reported againstbri=0. Reordered so_SetLedsOn()runs first; also restored theinternalStateChangeguard around the subsequentstateUpdated()call, since_SetLedsOn()clears that flag at its own end andstateUpdated()synchronously re-enters this usermod's ownonStateChange().reconcilePresenceLed()when a message reports "no change" but presence is still true and the LEDs are off (e.g. someone turned them off manually via the app/HA), so it can safely turn them back on later.checkInputPin()had no equivalent for the steady-state (unchanged) poll, so a user relying on the physical input pin had no way to recover once the LEDs were switched off externally while the pin stayed active."Küche"corrupted to a replacement character /?in two places from a prior lossy save.Test plan
🤖 Generated with Claude Code
https://claude.ai/code/session_01J6bJtispewBKR2dXBcNWpw
Generated by Claude Code