Group management overview

A group is the unit of ownership and access in ESP RainMaker Neo: nodes belong to groups, users are granted access to groups, and ESPRMNeoGroup is how an app reads and changes both. A group may contain nested groups (subgroups) which is how apps model a home containing rooms.

Everything starts from the signed-in user:

const groups = await user.getGroups();

getGroups() returns Promise<ESPRMNeoGroup[]>, the user's root groups, each with its subgroups already populated as ESPRMNeoGroup instances.

What a group carries

Property	Contents
groupId	Identifier used in every group call
groupName	Display name
accessType	primary, secondary or subgroup
parentId	Set only on a subgroup
nodeIds	Node IDs directly in this group
subgroups	Nested ESPRMNeoGroup instances
nodeDetails	Per-node capability information

Root groups and subgroups

Node A shows the case worth remembering: a node can belong to the root group and to one or more of its subgroups.

The same class represents both levels. parentId is the discriminator: present on a subgroup, absent on a root group. The exported isChildGroup(group) helper reads it for you.

This distinction changes what several methods do, because the cloud addresses subgroups through their parent:

Method	On a root group	On a subgroup
removeNode	Removes from the account	Removes from the subgroup only
addNode	Throws	Adds to the subgroup
delete	Deletes the group	Deletes the subgroup
setParams	Broadcasts group-wide	Targets that subgroup

addNode only works on a subgroup

group.addNode() is the subgroup membership API and throws ESPAPICallValidationError when called on a root group. Nodes enter a root group by being provisioned into it. See Provisioning, not by being added afterwards.

A node can be in several subgroups

A node in a root group may also belong to more than one of its subgroups. That matters when reading a node, because its MQTT shadow name is derived from the full set of memberships:

const node = await rootGroup.getNode("<node-id>");

Call getNode() on the root group rather than a subgroup, so all memberships are discovered and live updates reach the right shadow. Fetching through a single subgroup sees only that membership.

Access types

accessType tells you what the signed-in user may do:

• primary: owner; can share, transfer ownership, remove members and delete the group
• secondary: member; can see and control, and can leave
• subgroup: access granted through one subgroup rather than the whole group

The value comes from the cloud per request, so treat it as the authority on what to enable in your UI rather than inferring permissions from who created the group.

Where to go next

You want to	Read
Create, rename, delete, move nodes	Manage groups
Control every node at once	Group control
Give another user access	Sharing
React to a trigger automatically	Automations

Related

• Manage groups — lifecycle and membership
• Sharing — access for other users
• Node configuration — reading nodes out of a group
• Groups — the platform feature behind this class
• User–node association — how ownership is established