Groups get a value of their own

[flic]

A group has been a write-only concept: a command target with no state. That left
hal2Value, hal2Gate and hal2Bayes unable to use one at all, and hal2Event offering a Group
category that did not work.

Give a group a Value on the Event handler's Groups tab and it gains a state computed from its
members, shaped exactly like a Thing item's — so every reading node can consume it the same way it
consumes an item. "Alla lampor → any true" is one boolean for the whole house; "Temperatur inne →
average" is one number. A group without a Value stays exactly what it was.

The functions

latest, min, max, average, median, sum, range, any true, all true, any false,
all false, count true, count false, percent true.

They live in resources/group-aggregate.js, UMD like bayes-scale, so the list the editor offers
cannot drift from what the engine computes. The module is pure: the engine decides which members
count and hands over only those.

What counts is the load-bearing part

A member contributes only if its item carries state and its Thing is alive. A device that has
dropped off the network must not keep voting with the value it had before it went quiet — so
any true goes false when the last reachable lamp disappears, rather than reporting a light that
may well be dark.

The liveness rule is now lib/common.js:isThingAlive, shared with get_all_states so the group
engine and the MCP catalog cannot disagree about what offline means. The heartbeat item is not a
group member but does trigger a recompute — without that a group would keep counting a device for
as long as it stayed silent, which is the exact failure the rule exists to prevent.

Nothing eligible yields undefined rather than 0 or false, so a silent group can never read as
a real "off" in a Gate. The numeric functions skip non-numbers (a boolean member never counts as 1)
and the boolean functions are strict about true/false, matching lib/rules.js.

Behaving like an item

The group emits on every member update but moves laststate/last_change exactly as
hal2Thing.updateState does, so hal2Event's change filters behave identically whether they watch
a Thing or a group. msg.member says which member moved it. The emit goes straight onto the bus
rather than through publishUpdate: a derived value has no business in the history database, and
hal2Value can only read a group — use hal2Action to command one.

Bugs fixed along the way

• hal2Event wiped its own configuration. Opening a group-configured node resolved the group id
  with RED.nodes.node(); groups are not nodes, so thing, item and typeSel were cleared every
  time. That was the whole of "groups don't work in Events".
• hal2Gate discarded group rules for the same reason, one layer down: the rule loader dropped
  any row whose source did not resolve to a node, so the rule vanished on the next save.
• hal2Gate duplicated dynamic rules, pre-existing: the "set by msg.thing.id" branch called
  addItem twice, once inside its guard and once after it.
• hal2Bayes lost saved time-of-day steps — 'time' was missing from its source whitelist, so
  a time step silently reopened as a thing step.
• hal2Value's dialog would not open when its source select had no matching option.
• The Event handler field was optional even where it is required, so setting it to none on a group
  source passed validation and failed at runtime.

Testing

217 passing, up from 190. The new ones cover every function, the empty and all-offline cases that
must not read as 0/false, vacuous all true/all false, strict booleans, rounding, and the
laststate transition that decides when "on change" fires.

Verified against the running instance: the engine picks the aggregation up at startup, and median
over nine live members computed 25.68 — matching the members' actual readings — with last_change
correctly trailing last_update while the value held steady.

Not yet exercised in production: a member actually going offline, and Gate/Bayes reading a group at
runtime. Only median has run live; the other functions are unit-tested only.