merged version

merged version

2022.33.115: brightness settings updates

########################################
SHORT CHANGELOG (since 2022.33.113)
########################################

• 2022.33.115 Default Brightness is now a real plugin-wide value (default 80%). Each dimmable light/group
  picks its Default Brightness "source": use plugin default, or a manual value. New device
  state lastBrightness (last ON %). ON-command-brightness applies to all dimmable devices
  (lamps AND dimmers); on/off-only plugs have no brightness and are unaffected.
• 2022.33.114 Added the plugin-config ON-command brightness policy field and fixed its default attribute.
  (Superseded/extended by .115 — see below.)
• 2022.33.113 Daily min/max/average + change/trend tracking for numeric sensor states (motion temperature
  and light-level sensors); time-weighted averages, persisted and rolled over at midnight.

various upgrades

========================================
2022.32.112 @ 2026-07-09
The "shortBridgeInfo" print (bridge/lights/groups/... summary header + per-bridge lines) is now built into
one string (leading \n, each line \n-separated) and written with a single log call, instead of one log
entry per line. The rare not-setup/not-paired lines are included in the same block (now level 20).

The full bridge re-read now runs ONLY on a real outage (gap > kEventReplayWindowSecs). Previously it also
fired for short gaps where 0 events were replayed (nothing had happened) — unnecessary. Now: gap > window
-> level 20 + re-read; replay recovered events (short gap) -> level 10, no re-read; short gap with no events
-> level 10, no re-read. So no re-read for the routine hourly recycle.

Shortened the reconnect-table header line: "eventstream reconnects (last N of 100) — M replayed, avg gap Xs".
Dropped the long column-explanation parenthetical (the column names are self-explanatory).

Level 20 now fires only when events may actually have been MISSED (not merely recovered). Reasoning:
recovered events are counted reliably and are NOT missed; a true miss only happens if the reconnect gap
outlasts the bridge's Last-Event-ID replay buffer (then the oldest events age out). So: gap <= the assumed
replay window (kEventReplayWindowSecs, default 300s) -> fully recoverable -> level 10; gap > the window ->
possible data loss -> level 20 ("gap of Ns EXCEEDED the ~Ws replay window ... MAY HAVE BEEN MISSED").
Honest limitation: from the stream alone a quiet gap and a buffer-overflow gap are indistinguishable, so
this is a gap-duration proxy, not a perfect miss detector. For the ~40s hourly recycles it stays at level 10.
Also: the re-read is now forced whenever there was no full replay OR the gap exceeded the window.

The "real gap ... recovered N events" line is now level 10 too. The hourly bridge-recycle reconnect is
routine and self-healing, so it produces no level-20 output at all now (details remain in the print-stats
reconnect table). Still level 20: the first-connect "Successful Connected" (startup) and the generic
"Error: ... Reconnecting" for unexpected exceptions.

Reconnect table "last event" column now shows the full YYYY-MM-DD HH:MM:SS timestamp (column widened).

Reconnect table: replaced the raw epoch ev-ids (useless to read) with human-readable columns —
"last event" = the bridge time of the last ev-id before the gap (epoch converted to local, dd HH:MM:SS),
and "next event" = "+Ns" seconds to the first ev-id after. Dropped the separate ev-gap column (now the
"next event" delta).

Reconnect table: dropped the misleading "spurious?" label. recovered==0 only means "no events occurred
during the gap", NOT that the restart was unneeded — the connection gap was still real (confirmed by
the ev-id epochs jumping tens of seconds). Added an "ev-gap" column = the time hole between the last
ev-id before and the first ev-id after (seconds), which shows the real gap even when 0 events were
recovered. Summary line now reports total events replayed + average gap, no spurious count.

Quieter reconnect logging. Routine reconnect notices are now level 10 (debug): "Bridge connection
closed/unreachable / read timeout ... Reconnecting", "Successful Connected" (on reconnects only — still
level 20 on the first connect), "reconnect after Ns gap ... checking replay", and the "no events missed
/ likely unneeded restart" resolution. Only a REAL gap (events actually recovered) logs at level 20,
now as one self-contained line including the gap duration: "bridge X: real gap of Ns — last ev-id ...
-> first ev-id ...; N events replayed by bridge". So a spurious reconnect is silent at normal level;
a genuine data-gap shows exactly one line.

Single source of truth for config defaults: all plugin-config parameter reads now use
kDefaultPluginPrefs["key"] as their fallback instead of hardcoded literals — timeScaleFactor,
sendDeviceUpdatesTo, timeScaleFactorAPIV2, showLoginTest (startup + getDebugLevels), the debug* flags,
autoCreatedNewDevices, folderNameForNewDevices, and logAnyChanges (now a safe .get). The event
thresholds already used kDefaultPluginPrefs + minMaxEventRecovery ranges. (Consistent with removing the
default= attributes from PluginConfig.xml — defaults now live only in kDefaultPluginPrefs.) Action /
device dialog fields are unchanged; those aren't plugin-config parameters.

Faster reconnect. The eventstream reconnect used a fixed 5-10s sleep, adding ~10s to every gap. Now a
drop of a working connection (the common case: the bridge gracefully recycles/close-notifies the SSE
connection) reconnects IMMEDIATELY (0s); the delay only escalates (2 -> 5 -> 10s) if the reconnect
itself keeps failing (bridge genuinely down). reconnectFailures resets as soon as data flows again.
This covers the TLS close-notify case without parsing the alert (requests abstracts it away).
Also fixed two bugs introduced in the parameter-driven readEventTimerPrefs edit: a missing ')' on the
NumberOfSecondsEventRestart read, and the fallback clamp using 'restart' instead of 'woMsg'.
Note: the remaining gap (~25s in the captured case) is the bridge holding the connection open/idle
before it closes it — that part is bridge-side and not reducible from here.

Track the last ev-id before a reconnect and the first ev-id received after, to tell a real gap from a
spurious restart. Each reconnect log line and the print-stats reconnect table now show both ids, and
the table adds a summary ("N real gap, M with NO events missed"). A reconnect that recovers 0 events
(recovered==0) means nothing was actually missed — flagged "0 no-gap"; a run of these at a low
NumberOfSecondsEventRestart indicates the threshold is too aggressive (spurious restarts, no data lost).

Fix: the v.99 "apply NumberOfSecondsEventRestart immediately" didn't work — validatePrefsConfigUi
applies the new value before closedPrefsConfigUi captured the old one, so the change was never detected
(it only took effect on a full plugin reload). Now each listener session is stamped with the threshold
it was built with ('restartSecs'), and checkIfListenerIsRunning (main loop, every ~10s) restarts the
listener when that differs from the current config value. Works regardless of the dialog callback order.

Changing the (main) NumberOfSecondsEventRestart threshold now takes effect immediately. The keepalive
is baked into the socket at session creation, so a changed value previously needed a plugin reload
(in-thread reconnects reuse the same session). closedPrefsConfigUi now detects a change to that value
and restarts the V2 event listeners, so checkIfListenerIsRunning respawns them with a fresh session
(new keepalive) within ~10s. The (fallback) NumberOfSecondsEventWoMessage watchdog already applied live.

Cosmetic: getDebugLevels() collapsed its two duplicate branches (loop + showLoginTest read) into one
path — "if useMe is None or empty: useMe = self.pluginPrefs", then a single loop. No behaviour change.

Refactor (continued): the general prefs that were applied in startup + validatePrefsConfigUi +
closedPrefsConfigUi (timeScaleFactor, sendDeviceUpdatesTo, searchForStringinFindHueBridge, and the
fixed timeScaleFactorAPIV2) are now read/applied by one method applyGeneralPrefs(prefs), called from
all three. Removes the duplicated apply blocks and the dead if False: timeScaleFactorAPIV2 reads
(the value was already forced to 119). All three sites now apply the same set consistently. No
behaviour change for real values.

Refactor: the read+range-clamp of the two eventstream restart thresholds was duplicated in three
places (startup, validatePrefsConfigUi, closedPrefsConfigUi). Consolidated into one method
readEventTimerPrefs(prefs) that all three call. No behaviour change.

Split the eventstream restart control into two separate expert-section config dropdowns:

• (main) NumberOfSecondsEventRestart: 10..130s, default 90 — drives the TCP keepalive (fast restart,
  fires "Bridge unreachable. Reconnecting"). This is the primary threshold.
• (fallback) NumberOfSecondsEventWoMessage: 60..200s, default 180 — drives the no-message watchdog,
  the backstop for the rare case where TCP stays alive but the bridge stops sending events.
  Both defaults are in kDefaultPluginPrefs; both are range-clamped on load (legacy values → default).
  The stream read timeout now sits above whichever of the two is larger (+60s).

1. Full bridge re-read after a gap is now conditional: if the bridge replays the missed events
   (Last-Event-ID), processing them already makes device states current, so the re-read is skipped.
   The re-read is only forced when the bridge sends no backlog. Removes the redundant per-hour re-read
   on bridges that support replay.

2. Restart threshold is now a config dropdown (expert section, bottom of plugin config):
   "Restart api-V2 event listener after no events for:" with fixed values 10..130s, default 90.
   Reuses the existing NumberOfSecondsEventWoMessage pref and now drives BOTH the TCP keepalive
   (idle = threshold-20, +2x10s probes) and the no-message watchdog, so the whole range is effective.
   Legacy/out-of-range saved values (e.g. 180/240) are clamped to the new default 90 on load.

3. Restart threshold raised to ~90s: eventstream TCP keepalive is now 60s idle + 3x10s probes (was
   30s + 3x10s = ~60s). A >=90s silence has <0.01% chance of being normal (observed max gap ~40s), so
   this never false-triggers and avoids reconnecting into a still-stalled bridge.

4. Reconnect table in print-stats clarified: the count column is now labelled "recovered" (= gap events
   the bridge replayed), right-aligned; values are a number or "pending" (events not yet resumed).
   Columns realigned.
   Note: the separate watchdog backstop (config: NumberOfSecondsEventWoMessage, ~180s) ...

did not recognize "xxx outdoor XXX "

did not recognize "xxx outdoor XXX "
fixed in counting number of device types attached.

various updates for hue pro bridge

see version history

added event connection loss recovery

1. add check if connection to hue bridge is lost through eg reboot. The event listener in api v2 (pro bridge) does not realize if the connection is broken.
   Now added a timeout you can set to re-establish the connection if no events where send from the bridge to the plugin.

2022.29.81: fixed bugs

lots of little format issues, misspelled variables, but used only in rare circumstances
used "pycharm" and "claude" to do syntax error checking
pycharm is much better though.

fixed bug

fixed bug
1048, in autocreateNewDevicesV1 name = "Hue_{}{}{}_{}".format(self.pluginPrefs.get(prefix,kDefaultPluginPrefs[prefix]), hubNumber, theID, nameOnBridge)

2022.29.78

2022.29.78 @ 2026-03-13

1. fixed bug for hue contact sensor update
2. fixed bug not creating api v2 devices for groups - there was a debug statement not commented

2022.29.77: various updates

========================================
2022.29.77 @ 2026-03-12

1. added option to use default for brightness and ramp rate for recall action
2. fixed several rgb / dimmer functions
3. added enable disable for devices for pro bridge
4. added scenes support for pro bridge
5. added config option to set prefixes for devices names types switch/sensor/light/group eg Hue_light_br#_id#_nameOnBridge (replace light with lampa)
6. added different prefix for switches and sensors (was all sensor)
7. combined many sql updates for a device into a single call
8. reduced CPU usage, with > 80 lights, 15+ sensors 40+ switches on pro bridge: 0.1% .. 2% cpu on MAC-M1 (state updates depending on sensor, switch, light event frequency, no update: 0.1% CPU)
   on my previous setup with 4 old bridges it was 5%-15% and response time to sensor events was 2-3 secs, now < 0.5 secs.
9. added option in config to enabled / disable a bridge. this will only disable communication with the bridge.
   Useful if you have disconnected a bridge and would like to stop error messages
10. added a device for each bridge. it will contain bridge values in the device states (30+) This device is not editable, the states are just for info.
11. The pro bridge does not supply rgb (xy) color update events for groups (zones, rooms), only brightness level.
    the issue is likely that a mix of different lamp types makes it difficult to actually calculate the proper color values (rgb + dimm only + color temp lamp types )
    work around: Added a http api v1 "get" for all data for the hue group, WHEN a brightness level change event is received. That should cover most situations.
12. fixed indigo device icon. if a device is turned off, but brightness level is not 0 the icon stayed "ON". Now it reflecting state is off/on

========================================
2022.28.76 @ 2026-02-25

1. added option to use default for brightness and ramp rate for recall action

========================================
2022.28.75 @ 2026-02-24

1. added support for pro bridge for scene recall (active a scene on the bridge)
2. several smaller performance improvements
3. cleaned up code.
4. reconfigured RGB to XY color schema for pro bridges.