Summary
Push Active is documented in the README as "on while OBSERVE is firing". It goes online for ten minutes after every session start even when the appliance has no route to Samsung's cloud and is therefore emitting no notifications at all.
Why
_on_cache_change records the timestamp for any cache change whose source is observe (bridge.py:184-186), and publish_health treats a timestamp inside push_active_window_s (600 s) as push being active (bridge.py:596-598).
The OBSERVE registration response takes that same path. subscribe() registers the token and creates no pending waiter, so the piggybacked 2.05 answering the registration GET is dispatched through the observe branch and reaches _on_notification exactly as a spontaneous notification would. At session start the cache is empty, so every one of those responses is a change, which sets the timestamp.
The result is that a registration response, which the device sends because we asked for it, is indistinguishable from a push the device chose to send.
Reproduction
Block the appliance from the internet, restart the bridge, and watch the diagnostic. Seen on all three session starts during the #39 hardware validation, one of them being:
12:35:16 push_active → offline (session start)
12:36:16 push_active → online (60 s later, appliance has no internet)
Both appliances flipped online each time, and neither had pushed anything.
Impact
Small, and confined to the diagnostic. State freshness is unaffected: the poll tiers carry it, and the entity does not gate any behaviour.
It does mislead in the configuration this project explicitly supports. An air-gapped install is where an operator would most reasonably consult this entity to answer "is push doing anything here", and it answers yes for ten minutes out of every session. The README's air-gapped section tells people to look at exactly this entity to see which path is doing the work.
Possible fix
Distinguish the registration response from a later notification. The session knows the difference even though the callback does not: the initial 2.05 arrives while subscribe() is registering, and everything after it is unsolicited. Options include passing the OBSERVE sequence number through to the callback, since registration responses carry 0 or the server's current counter value and later notifications increment from there, or having the bridge ignore observe-sourced changes for the first few seconds of a session.
The sequence number looks like the better signal, but it changes a public callback signature, so it needs a decision rather than a patch.
Summary
Push Activeis documented in the README as "on while OBSERVE is firing". It goes online for ten minutes after every session start even when the appliance has no route to Samsung's cloud and is therefore emitting no notifications at all.Why
_on_cache_changerecords the timestamp for any cache change whose source isobserve(bridge.py:184-186), andpublish_healthtreats a timestamp insidepush_active_window_s(600 s) as push being active (bridge.py:596-598).The OBSERVE registration response takes that same path.
subscribe()registers the token and creates no pending waiter, so the piggybacked 2.05 answering the registration GET is dispatched through the observe branch and reaches_on_notificationexactly as a spontaneous notification would. At session start the cache is empty, so every one of those responses is a change, which sets the timestamp.The result is that a registration response, which the device sends because we asked for it, is indistinguishable from a push the device chose to send.
Reproduction
Block the appliance from the internet, restart the bridge, and watch the diagnostic. Seen on all three session starts during the #39 hardware validation, one of them being:
Both appliances flipped online each time, and neither had pushed anything.
Impact
Small, and confined to the diagnostic. State freshness is unaffected: the poll tiers carry it, and the entity does not gate any behaviour.
It does mislead in the configuration this project explicitly supports. An air-gapped install is where an operator would most reasonably consult this entity to answer "is push doing anything here", and it answers yes for ten minutes out of every session. The README's air-gapped section tells people to look at exactly this entity to see which path is doing the work.
Possible fix
Distinguish the registration response from a later notification. The session knows the difference even though the callback does not: the initial 2.05 arrives while
subscribe()is registering, and everything after it is unsolicited. Options include passing the OBSERVE sequence number through to the callback, since registration responses carry 0 or the server's current counter value and later notifications increment from there, or having the bridge ignore observe-sourced changes for the first few seconds of a session.The sequence number looks like the better signal, but it changes a public callback signature, so it needs a decision rather than a patch.