thingsboard-cli 4.4.0.1__tar.gz → 4.4.0.1.post1__tar.gz

{thingsboard_cli-4.4.0.1 → thingsboard_cli-4.4.0.1.post1}/CHANGELOG.md

@@ -2,7 +2,18 @@
 
 All notable changes to ThingsBoard CLI are documented in this file.
 
-## [4.4.0.1] — Unreleased
+## [Unreleased]
+
+### Fixed
+
+- **HTML pages only on servers that can show them.** The HTML page dashboard
+  layout ships in ThingsBoard 4.4.1, not 4.4.0.1. `tb system info` reported
+  `htmlPageLayout: true` for 4.4.0.1, so the agent built HTML page states
+  that this version shows as blank. It now reports `false`, and the agent
+  uses stock-widget grids there. ThingsBoard Cloud and 4.4 development
+  builds are not affected.
+
+## [4.4.0.1] — 2026-10-23
 
 First-run usability release.
 

{thingsboard_cli-4.4.0.1 → thingsboard_cli-4.4.0.1.post1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: thingsboard-cli
-Version: 4.4.0.1
+Version: 4.4.0.1.post1
 Summary: CLI tool for managing ThingsBoard resources
 Project-URL: Homepage, https://github.com/thingsboard/thingsboard-cli
 Project-URL: Source, https://github.com/thingsboard/thingsboard-cli

{thingsboard_cli-4.4.0.1 → thingsboard_cli-4.4.0.1.post1}/extension-starter/extension/target/thingsboard-extension-1.0.0-SNAPSHOT.jar

@@ -1,4 +1,4 @@
 [diffend] Oversized file quarantined before diffing.
-name: thingsboard_cli-4.4.0.1/extension-starter/extension/target/thingsboard-extension-1.0.0-SNAPSHOT.jar
+name: thingsboard_cli-4.4.0.1.post1/extension-starter/extension/target/thingsboard-extension-1.0.0-SNAPSHOT.jar
 size: 39342529 bytes
 sha256: b2a093f7037d1d4fcc9b196d9bd5412a02920a181b39e2d02cf54939630a6d7d

{thingsboard_cli-4.4.0.1 → thingsboard_cli-4.4.0.1.post1}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "thingsboard-cli"
-version = "4.4.0.1"
+version = "4.4.0.1.post1"
 description = "CLI tool for managing ThingsBoard resources"
 readme = "README.md"
 requires-python = ">=3.11,<3.15"

{thingsboard_cli-4.4.0.1 → thingsboard_cli-4.4.0.1.post1}/scaffold/agent-kit/agents/dashboard-generator.md

@@ -113,7 +113,7 @@ The available names are listed in dashboard-foundations. Pull each needed templa
 ### C1 — Build structure and the validated plan
 
 1. Using dashboard-foundations, decide the states/navigation and build the global `entityAliases` map (allocate UUIDs per the UUID conventions).
-2. Produce a COMPACT render-plan. **First apply the server version gate** from the dashboard-foundations core ("Layout policy" — `tb system info --format json`, once per run) and plan in the mode it selects. **HTML page mode (ThingsBoard 4.4.0.1+, or version unknown — the default):** plan every state a user navigates to as an HTML page — `{stateId, host: "page", contentSpec}`, no widgets — with `contentSpec` per the shape in `references/custom-html-path.md`. Plan a grid state only as an **embedded helper** that a page hosts via `<tb-dashboard-state>`: stock maps (`outdoor-map`, `indoor-map`, `trip-map`) and the stock alarm table when users acknowledge or clear alarms — `{stateId, host: "helper", widgets: [...]}`, never a navigation target. Stock entity dialogs (create/edit/delete) are page actions, not helper states: list them in the page's `contentSpec` as JavaScript-source actions in `htmlPageConfig.actions`, opened from page buttons. **Grid mode (`htmlPageLayout: false`, server older than 4.4.0.1):** plan per state each widget as `{widgetType, title, aliasRef, dataKeys, layout {x,y,w,h}, actions}`; stock widgets are the default; when a grid-mode trigger fires (explicit custom-HTML/composite ask, visual-upgrade ask, a use case no stock widget expresses, a grid-bound limitation), use an htmlContainer region `{widgetType: "htmlContainer", title, contentSpec, layout}`, and for a whole-state custom view the full-state htmlContainer fallback. No widget JSON yet.
+2. Produce a COMPACT render-plan. **First apply the server version gate** from the dashboard-foundations core ("Layout policy" — `tb system info --format json`, once per run) and plan in the mode it selects. **HTML page mode (ThingsBoard 4.4.1+, or version unknown — the default):** plan every state a user navigates to as an HTML page — `{stateId, host: "page", contentSpec}`, no widgets — with `contentSpec` per the shape in `references/custom-html-path.md`. Plan a grid state only as an **embedded helper** that a page hosts via `<tb-dashboard-state>`: stock maps (`outdoor-map`, `indoor-map`, `trip-map`) and the stock alarm table when users acknowledge or clear alarms — `{stateId, host: "helper", widgets: [...]}`, never a navigation target. Stock entity dialogs (create/edit/delete) are page actions, not helper states: list them in the page's `contentSpec` as JavaScript-source actions in `htmlPageConfig.actions`, opened from page buttons. **Grid mode (`htmlPageLayout: false`, server older than 4.4.1):** plan per state each widget as `{widgetType, title, aliasRef, dataKeys, layout {x,y,w,h}, actions}`; stock widgets are the default; when a grid-mode trigger fires (explicit custom-HTML/composite ask, visual-upgrade ask, a use case no stock widget expresses, a grid-bound limitation), use an htmlContainer region `{widgetType: "htmlContainer", title, contentSpec, layout}`, and for a whole-state custom view the full-state htmlContainer fallback. No widget JSON yet.
 3. VALIDATE the plan before pulling any template or emitting any JSON (this is where correctness is won):
    - Every widget's `aliasRef` resolves to an alias in the map that OWNS the keys in `dataKeys` (Rule: alias-owns-keys).
    - Every drill-down/navigation action's source kind matches the target state's primary alias kind (Rule: drill-down kind-match).
@@ -216,7 +216,7 @@ These invariants apply per-state and can be verified from the assembled state ou
 6. **typeFullFqn** — must match the `typeFullFqn` value in the matching `widget-*` catalog skill exactly; never invent values.
 7. **alarmTable datasource** — alarm data goes into `alarmSource`, not `datasources`. `datasources` must be `[]`.
 8. **alarmCount datasource** — uses `"type": "alarmCount"` (not `"entity"`) with `dataKeys: [{name:"count", type:"count"}]`.
-9. **No empty content shipped — the #1 failure.** Every `htmlContainer` (`config.settings`) and every HTML page (`htmlPageConfig.settings`) must have **non-empty** `html` AND `js` (and `css` unless trivially styled); empty `html`/`js` renders a blank widget or a blank state. No grid state may consist of a single htmlContainer covering the whole state — that state must be an HTML page — except on a server older than ThingsBoard 4.4.0.1 (`tb system info` → `htmlPageLayout: false`), where it is the required fallback. Every `system.map`/outdoor-map widget must have at least one configured `markers` layer (with `xKey`/`yKey` bound to position keys on a real alias) or `polygons` layer (with `polygonKey`) — an empty `markers: []` + `polygons: []` shows a blank map. If a widget you assembled has empty content/datasources, STOP and fill it before saving — never save a structural skeleton.
+9. **No empty content shipped — the #1 failure.** Every `htmlContainer` (`config.settings`) and every HTML page (`htmlPageConfig.settings`) must have **non-empty** `html` AND `js` (and `css` unless trivially styled); empty `html`/`js` renders a blank widget or a blank state. No grid state may consist of a single htmlContainer covering the whole state — that state must be an HTML page — except on a server older than ThingsBoard 4.4.1 (`tb system info` → `htmlPageLayout: false`), where it is the required fallback. Every `system.map`/outdoor-map widget must have at least one configured `markers` layer (with `xKey`/`yKey` bound to position keys on a real alias) or `polygons` layer (with `polygonKey`) — an empty `markers: []` + `polygons: []` shows a blank map. If a widget you assembled has empty content/datasources, STOP and fill it before saving — never save a structural skeleton.
 10. **Landing state is not empty.** The root state must render the primary view on load. If the root is a composite HTML page (or htmlContainer) that embeds states, its own `html` is non-empty AND every `embeddedStateIds` state it shows exists and is populated — a root that resolves to an empty container or an empty embedded state means "nothing visible on landing."
 11. **Map position keys are resolvable.** For every map marker layer, the `xKey`/`yKey` (lat/lng) and any polygon `polygonKey` must be keys that actually exist on the bound alias's profile (in the `entityProfiles` input, projected from the overview). Flag in the save report when those keys are TIMESERIES (markers only render once telemetry/emulator data populates them) so the caller knows demo data must be pushed.
 

{thingsboard_cli-4.4.0.1 → thingsboard_cli-4.4.0.1.post1}/scaffold/agent-kit/skills/dashboard-dark-mode/SKILL.md

@@ -21,7 +21,7 @@ Skip the background fix → "the page went dark but the widgets are still white.
 
 - `userRequirements` asks for a "dark dashboard", "dark mode", "dark theme", "night mode", or names a dark palette for the whole view.
 
-Apply this **independently of the widget mix**. The layout policy (HTML pages on 4.4.0.1+, stock-widget grids on older servers) is unchanged — the design may still include an htmlContainer (for custom layout, a composite view, a branded header, etc.) and that's fine. The bug this skill fixes is the *inconsistent* result: a dark htmlContainer sitting next to stock widgets that stayed white. `settings.dashboardCss` is the page-wide layer that turns the **stock** widgets dark too, so the whole dashboard — stock widgets and htmlContainers alike — comes out dark together. Set it whenever dark mode is requested, whether or not the dashboard also has an htmlContainer.
+Apply this **independently of the widget mix**. The layout policy (HTML pages on 4.4.1+, stock-widget grids on older servers) is unchanged — the design may still include an htmlContainer (for custom layout, a composite view, a branded header, etc.) and that's fine. The bug this skill fixes is the *inconsistent* result: a dark htmlContainer sitting next to stock widgets that stayed white. `settings.dashboardCss` is the page-wide layer that turns the **stock** widgets dark too, so the whole dashboard — stock widgets and htmlContainers alike — comes out dark together. Set it whenever dark mode is requested, whether or not the dashboard also has an htmlContainer.
 
 ## Two modes
 

{thingsboard_cli-4.4.0.1 → thingsboard_cli-4.4.0.1.post1}/scaffold/agent-kit/skills/dashboard-foundations/SKILL.md

@@ -26,7 +26,7 @@ Actions: drill-down, change-state, create-entity-dialog, edit-entity-dialog, del
 
 | File (`references/…`) | Read when |
 |---|---|
-| `custom-html-path.md` | HTML page mode (every create on 4.4.0.1+), a grid-mode trigger fires, or the dashboard already has an HTML page or htmlContainer you are changing — host rules, `contentSpec`, composite-page structure. |
+| `custom-html-path.md` | HTML page mode (every create on 4.4.1+), a grid-mode trigger fires, or the dashboard already has an HTML page or htmlContainer you are changing — host rules, `contentSpec`, composite-page structure. |
 | `aliasing.md` | You create or change aliases or datasources: display-name fields, `resolveMultiple`, alias-owns-keys, drill-down entity passing, multi-hop navigation, `currentCustomer` scoping, entity alias JSON structure. **Create mode: always.** |
 | `navigation.md` | The dashboard has `switcherDetail` states (state switching) or any "Back" control. |
 | `validation-checklists.md` | **Always — every mode — but read it last:** once every state is built and assembled, right before writing the JSON. Then run the per-state checklist on every state you built or touched and the pre-write checklist on the whole dashboard. Never read it at the start. |
@@ -39,11 +39,11 @@ In **Update mode**, read only the files for what the change touches (plus `valid
 
 ## Layout policy — HTML pages first (full rules: `references/custom-html-path.md`)
 
-**Server version gate — first, once per run, before planning any state.** Run `tb system info --format json` (it always queries the profile's server, also in local mode) and read `htmlPageLayout`: `true` → **HTML page mode**; `false` → the server is older than ThingsBoard 4.4.0.1 → **grid mode**; `null`, or the command fails (no profile, server unreachable) → version unknown, use HTML pages (**HTML page mode**). Record the mode in the save report.
+**Server version gate — first, once per run, before planning any state.** Run `tb system info --format json` (it always queries the profile's server, also in local mode) and read `htmlPageLayout`: `true` → **HTML page mode**; `false` → the server is older than ThingsBoard 4.4.1 → **grid mode**; `null`, or the command fails (no profile, server unreachable) → version unknown, use HTML pages (**HTML page mode**). Record the mode in the save report.
 
 **HTML page mode (default).** Build **every state a user navigates to** as an HTML page: `layouts.main.gridSettings.layoutType: "html"`, `widgets: {}`, all content in `htmlPageConfig` — custom HTML/CSS/JS on the `widget-html-container` content model. Grid states with stock widgets remain only as **embedded helper states** inside a page (`<tb-dashboard-state>`), never as navigation targets: stock maps — `outdoor-map` (`system.map`), `indoor-map`, `trip-map` (`system.trip_map`, with timeline scrolling) (a page never draws its own map or loads Leaflet from a CDN; ThingsBoard ships its own, and a second copy breaks every stock map) — and the stock alarm table when users acknowledge or clear alarms. Stock entity dialogs (create/edit/delete) need no helper state: put the action in `htmlPageConfig.actions` as a JavaScript-source action and open it from a page button with `ctx.actionsApi.invokeAction` (`widget-html-container` → `references/platform-calls.md`).
 
-**Grid mode (servers before 4.4.0.1).** Stock catalog widgets are the default. Plan custom content only when a trigger fires: (1) explicit ask — custom HTML, free-form or composite layout, a third-party library; (2) visual-upgrade ask beyond stock styling fields (dark mode alone does not count); (3) gap-filler — no stock widget expresses the use case (**Maps are never a gap**); (4) grid-bound limitation — end-user resize/move/drag, overlays, drawers, splitters. A trigger is **mandatory** (never approximate with the nearest stock widget). **Pick the host:** one region of a grid → htmlContainer widget; the whole state → the **full-state htmlContainer fallback** (SKILL.md → "Full-state htmlContainer fallback").
+**Grid mode (servers before 4.4.1).** Stock catalog widgets are the default. Plan custom content only when a trigger fires: (1) explicit ask — custom HTML, free-form or composite layout, a third-party library; (2) visual-upgrade ask beyond stock styling fields (dark mode alone does not count); (3) gap-filler — no stock widget expresses the use case (**Maps are never a gap**); (4) grid-bound limitation — end-user resize/move/drag, overlays, drawers, splitters. A trigger is **mandatory** (never approximate with the nearest stock widget). **Pick the host:** one region of a grid → htmlContainer widget; the whole state → the **full-state htmlContainer fallback** (SKILL.md → "Full-state htmlContainer fallback").
 
 Then `Read` `references/custom-html-path.md` before planning any `contentSpec`.
 
@@ -250,9 +250,9 @@ A state built as an HTML page (see "Layout policy") replaces the grid with one c
 - `htmlPageConfig.settings` is exactly an htmlContainer's `config.settings` and `htmlPageConfig.actions` is exactly its `config.actions` — author both per `widget-html-container`.
 - `widgets` is always `{}`; nothing for this state goes into the top-level `widgets` map. `gridSettings` holds only `layoutType` and `htmlPageConfig` — no columns, margins, row height, or background (the page paints its own), and no `right` layout or `breakpoints`.
 - The page renders without a widget frame: no title bar, transparent background, zero padding, full state height on desktop and mobile. Design the page's own header, padding, and surfaces in its CSS.
-- Requires ThingsBoard 4.4.0.1+; an older UI cannot render this layout type. Use it only when `tb system info` reports `htmlPageLayout: true` or the version is unknown — otherwise use the fallback below.
+- Requires ThingsBoard 4.4.1+; an older UI cannot render this layout type. Use it only when `tb system info` reports `htmlPageLayout: true` or the version is unknown — otherwise use the fallback below.
 
-### Full-state htmlContainer fallback (server older than 4.4.0.1)
+### Full-state htmlContainer fallback (server older than 4.4.1)
 
 When `tb system info --format json` reports `htmlPageLayout: false`, a state planned as an HTML page is built as a **grid state holding one htmlContainer that covers the whole state** instead — the only shape that renders on those servers. The content is identical: the page's `htmlPageConfig.settings` / `htmlPageConfig.actions` become the widget's `config.settings` / `config.actions` unchanged.
 

{thingsboard_cli-4.4.0.1 → thingsboard_cli-4.4.0.1.post1}/scaffold/agent-kit/skills/dashboard-foundations/references/custom-html-path.md

@@ -6,7 +6,7 @@
 
 Custom HTML/CSS/JS content has two hosts that share one content model (`widget-html-container` catalog skill — same `settings.type/html/css/js/resources`, same `ctx` APIs, subscriptions, embedded states, and actions):
 
-- **HTML page** — a dashboard state whose layout type is `html` (`layouts.main.gridSettings.layoutType: "html"`, content in `gridSettings.htmlPageConfig`). The state has **no widget grid**: the page fills the whole state area by itself. ThingsBoard 4.4.0.1+.
+- **HTML page** — a dashboard state whose layout type is `html` (`layouts.main.gridSettings.layoutType: "html"`, content in `gridSettings.htmlPageConfig`). The state has **no widget grid**: the page fills the whole state area by itself. ThingsBoard 4.4.1+.
 - **htmlContainer widget** — a widget placed in a state's grid, sharing the grid with other widgets.
 
 Below, "the container" means the custom content in either host; "Pick the host" decides which one. It is the dashboard's open canvas — it fills its area with whatever HTML/CSS/JS you write, so it stretches to fit almost any idea. Its range:
@@ -23,7 +23,7 @@ These are starting points, not boundaries — anything expressible in HTML/CSS/J
 
 **Generation is craft, not slot-filling.** Treat building a dashboard as design work where the full palette is yours to use as the result demands: stock widgets, from-scratch htmlContainer widgets, embedded states, composition, and custom code — mixed however serves the best dashboard. Nothing here limits you to one tool or one shape; reach for whatever expresses the idea most faithfully. The rules that follow are technique for wielding that palette well — don't rebuild what stock widgets already give you, validate data keys, states, and permissions — not a cage on what you may create.
 
-**Which mode applies** — decided by the server version gate (SKILL.md → "Layout policy"). In **HTML page mode** (ThingsBoard 4.4.0.1+, the default) every state a user navigates to is an HTML page, without any trigger; the triggers below are not consulted for that choice, and stock widgets appear only in embedded helper states (maps; the alarm table when users acknowledge or clear alarms). Stock entity dialogs are page actions opened from page buttons, not helper states. In **grid mode** (older servers) custom content is the pipeline's escape hatch from the widget grid. In grid mode, reach for it when the user wants **custom logic or interaction** a stock widget doesn't offer (bespoke controls, RPC panels, drag-and-drop, custom forms, client-side computation); when a **design or layout can't be reached with the default implementation** — free-form / overlaid / composite arrangements, a structure the dashboard grid system can't express, or **runtime interaction the locked grid can't give** (end-user resizing, moving, dragging, or freely positioning content; overlays or drawers floating over the dashboard; resizable splitters); when the user asks for a **special, branded, or modern custom-designed view**; or when **no stock widget fits the need** — the container is fully configurable, so it can be built to spec rather than forcing an ill-fitting stock widget. Outside those, grid mode keeps stock catalog widgets as the default. Concretely, in grid mode the plan includes custom content when one of these triggers fires:
+**Which mode applies** — decided by the server version gate (SKILL.md → "Layout policy"). In **HTML page mode** (ThingsBoard 4.4.1+, the default) every state a user navigates to is an HTML page, without any trigger; the triggers below are not consulted for that choice, and stock widgets appear only in embedded helper states (maps; the alarm table when users acknowledge or clear alarms). Stock entity dialogs are page actions opened from page buttons, not helper states. In **grid mode** (older servers) custom content is the pipeline's escape hatch from the widget grid. In grid mode, reach for it when the user wants **custom logic or interaction** a stock widget doesn't offer (bespoke controls, RPC panels, drag-and-drop, custom forms, client-side computation); when a **design or layout can't be reached with the default implementation** — free-form / overlaid / composite arrangements, a structure the dashboard grid system can't express, or **runtime interaction the locked grid can't give** (end-user resizing, moving, dragging, or freely positioning content; overlays or drawers floating over the dashboard; resizable splitters); when the user asks for a **special, branded, or modern custom-designed view**; or when **no stock widget fits the need** — the container is fully configurable, so it can be built to spec rather than forcing an ill-fitting stock widget. Outside those, grid mode keeps stock catalog widgets as the default. Concretely, in grid mode the plan includes custom content when one of these triggers fires:
 
 1. **Explicit ask** — `userRequirements` (or the use-case text itself) requests custom HTML, free-form layout, a specific composite experience (tabs-in-one-widget, slide-over drawer, master-detail split, kanban), or a third-party visualization library. An explicit ask wins even when a stock widget could cover the use case.
 2. **Visual upgrade ask** — `userRequirements` asks for a noticeably prettier / branded / custom-designed view beyond what stock widget styling fields can express (custom typography, hero headers, card compositions, bespoke color systems). A preference the stock styling fields already cover — a single color, a theme, a chart palette — stays on stock widgets. **A dark theme / dark mode is handled separately and additively** — whatever widget mix the dashboard ends up with (stock widgets, htmlContainers, or both), a dark request also adds dashboard-wide dark CSS (`settings.dashboardCss`) so the stock widgets go dark alongside any htmlContainer. See "Dark mode" in `theme-and-dark-mode.md`; it is not an either/or with the Custom HTML path.
@@ -40,7 +40,7 @@ These are starting points, not boundaries — anything expressible in HTML/CSS/J
 
 - **The custom content is the whole state → HTML page.** A complete custom screen (landing page, branded overview, bespoke analytics view), a composite shell (custom tabs / sidebar / drawer / master–detail embedding other states), or any state that would otherwise be a single full-width htmlContainer. The page has no grid to size, no widget frame, and fills the state on desktop and mobile alike.
 - **The custom content is one region of a state that also shows stock widgets in the same grid → htmlContainer widget.** A bespoke KPI strip, RPC control panel, or custom visual sitting next to stock charts/tables/maps on one state, and the mid-generation swap of a single slot (below). This is the rarer case.
-- **Never** emit a state whose grid holds a single htmlContainer covering the whole state (e.g. one `sizeX: 24` container and nothing else) — that is an HTML page. **The one exception is a server older than ThingsBoard 4.4.0.1** (gate below), where the full-state htmlContainer is the required fallback for a whole-state custom view. Do not mix the two in one state either: an HTML page state has no grid, so it cannot also hold widgets; when custom content and stock widgets must share one view, either build the state as a grid with an htmlContainer region, or make it an HTML page that **embeds** a state holding the stock widgets (`<tb-dashboard-state>`).
+- **Never** emit a state whose grid holds a single htmlContainer covering the whole state (e.g. one `sizeX: 24` container and nothing else) — that is an HTML page. **The one exception is a server older than ThingsBoard 4.4.1** (gate below), where the full-state htmlContainer is the required fallback for a whole-state custom view. Do not mix the two in one state either: an HTML page state has no grid, so it cannot also hold widgets; when custom content and stock widgets must share one view, either build the state as a grid with an htmlContainer region, or make it an HTML page that **embeds** a state holding the stock widgets (`<tb-dashboard-state>`).
 
 **Server version gate.** Apply it as the SKILL.md core states it ("Layout policy" → "Server version gate") — that paragraph is the one definition; this file does not repeat it. The fallback shape is in SKILL.md → "Full-state htmlContainer fallback"; the rest of this file applies to it as written for HTML pages.
 

{thingsboard_cli-4.4.0.1 → thingsboard_cli-4.4.0.1.post1}/scaffold/agent-kit/skills/dashboard-foundations/references/validation-checklists.md

@@ -83,7 +83,7 @@ For every state you built or touched, verify:
 | Header zone only | `headerCard`, `navigationWidget`, `actionButton`, `connectRealDevices` appear only at `row: 0`. |
 | Color ranges | Every `"type": "range"` color with `rangeList.advancedMode: true` has BOTH `from` and `to` on every `rangeAdvanced` entry (open side = `{"type": "constant"}`) — a missing side crashes the widget on every update (`color-ranges.md`). `latestKey` bounds name keys that exist on the widget's datasource profile. |
 | Layout mode | HTML page mode (`tb system info` → `htmlPageLayout` `true`/`null`/failed): every state reachable by navigation is an HTML page; grid states exist only as embedded helper states (maps; the alarm table for acknowledge/clear) and are never navigation targets; stock entity dialogs are `htmlPageConfig.actions` opened from page buttons. Grid mode (`false`): stock widgets by default. The save report states the mode. |
-| HTML page state | A state built as an HTML page has `layouts.main.widgets: {}` and `gridSettings` = `{layoutType: "html", htmlPageConfig: {settings, actions}}` only, no `right` layout or `breakpoints`; the grid rows below (row budget, row coverage, overlaps, header zone, widget↔layout sync) do not apply to it. A grid state is never a single htmlContainer covering the whole state — that is an HTML page — except on a server older than ThingsBoard 4.4.0.1 (`tb system info` → `htmlPageLayout: false`), where it is the required fallback (SKILL.md → "Full-state htmlContainer fallback"). |
+| HTML page state | A state built as an HTML page has `layouts.main.widgets: {}` and `gridSettings` = `{layoutType: "html", htmlPageConfig: {settings, actions}}` only, no `right` layout or `breakpoints`; the grid rows below (row budget, row coverage, overlaps, header zone, widget↔layout sync) do not apply to it. A grid state is never a single htmlContainer covering the whole state — that is an HTML page — except on a server older than ThingsBoard 4.4.1 (`tb system info` → `htmlPageLayout: false`), where it is the required fallback (SKILL.md → "Full-state htmlContainer fallback"). |
 | htmlContainer checklist | Every HTML page and every `htmlContainer` passes the pre-save checklist in `widget-html-container` (keys exist on profile, stateIds exist, mode matches template, bindings exposed, cleanup registered, permission gating). State-content rows below exempt `htmlContainer` per the Custom HTML path. |
 | switcherDetail body | Exactly one `stateSwitcher` is present at `{ row: 1, col: 0, sizeX: 24, sizeY: 14 }` (REQUIRED whenever the state has navigationWidget tabs — without it the tabs do nothing), and no other body widgets. |
 | typeFullFqn | Must match the typeFullFqn in the matching `widget-*` catalog skill exactly. |

{thingsboard_cli-4.4.0.1 → thingsboard_cli-4.4.0.1.post1}/scaffold/agent-kit/skills/widget-html-container/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: widget-html-container
-description: "Custom HTML/CSS/JS content for a dashboard — the HTML page state layout (preferred when the content fills a whole state; TB 4.4.0.1+) and the htmlContainer widget (a custom region inside a grid). Pulled on-demand by dashboard-generator when the Custom HTML path is active."
+description: "Custom HTML/CSS/JS content for a dashboard — the HTML page state layout (preferred when the content fills a whole state; TB 4.4.1+) and the htmlContainer widget (a custom region inside a grid). Pulled on-demand by dashboard-generator when the Custom HTML path is active."
 user-invocable: false
 ---
 
@@ -19,7 +19,7 @@ The same content (`settings.type/html/css/js/resources` + `actions`) runs in two
 | **HTML page** (preferred) | A state whose layout type is HTML page: `states.<stateId>.layouts.main.gridSettings` = `{layoutType: "html", htmlPageConfig: {settings, actions}}`, `widgets: {}` | The custom content **is the whole state** — a full custom screen, a branded landing/overview page, a composite shell (tabs / sidebar / drawer / master–detail) embedding other states. |
 | **htmlContainer widget** | A `system.html_container` widget in a grid state: `config.settings` + `config.actions` | The custom content is **one region of a grid** that also holds stock widgets (a custom KPI strip, RPC panel, or visual next to stock charts/tables), or a single slot swapped mid-generation. |
 
-ThingsBoard renders an HTML page as a virtual htmlContainer (id `html-page-<stateId>`, never stored in `configuration.widgets`), so **everything in this skill applies to both hosts** — modes, the JS contract, `ctx`, subscriptions, embedded states, actions, the pre-save checklist. Where a rule says "the container" or "the widget", read "the page" too. A state whose grid would hold one htmlContainer covering the whole state is an HTML page instead (`dashboard-foundations` → `references/custom-html-path.md` → "Pick the host"). HTML page requires ThingsBoard 4.4.0.1+: when the server version gate (`dashboard-foundations` core, "Server version gate") selects the **full-state htmlContainer fallback**, build that state as the fallback — same content in `config.settings`/`config.actions`.
+ThingsBoard renders an HTML page as a virtual htmlContainer (id `html-page-<stateId>`, never stored in `configuration.widgets`), so **everything in this skill applies to both hosts** — modes, the JS contract, `ctx`, subscriptions, embedded states, actions, the pre-save checklist. Where a rule says "the container" or "the widget", read "the page" too. A state whose grid would hold one htmlContainer covering the whole state is an HTML page instead (`dashboard-foundations` → `references/custom-html-path.md` → "Pick the host"). HTML page requires ThingsBoard 4.4.1+: when the server version gate (`dashboard-foundations` core, "Server version gate") selects the **full-state htmlContainer fallback**, build that state as the fallback — same content in `config.settings`/`config.actions`.
 
 **Data path — custom subscription only.** ThingsBoard offers two ways to feed data into a widget: the widget's configured **datasources**, or a **custom subscription** created in code. **Static widgets do not support datasources** — and the htmlContainer is a static widget (`type: "static"`); an HTML page is rendered by the same static widget and has no datasources at all. So the only way to get data into the container's own content is a custom subscription created in `settings.js` (`ctx.subscriptionApi`, see `references/live-data.md`); `config.datasources` stays `[]` and is ignored. (This applies to the container's own DOM. Stock widgets placed in **embedded states** are ordinary, non-static widgets — they keep their normal datasources and resolve data the usual way; the custom-subscription rule is only about the container itself.)
 
@@ -172,7 +172,7 @@ The widget editor (and the HTML page editor) exposes a **Plain HTML / Angular**
 
 | Check | Rule |
 |---|---|
-| Host chosen | Content that fills a whole state is an HTML page (`layoutType: "html"`, `widgets: {}`, content in `htmlPageConfig`); an htmlContainer is used only for a region of a grid that also holds other widgets — never a single container covering a whole grid state, except as the full-state fallback when `tb system info` reports `htmlPageLayout: false` (server older than 4.4.0.1). |
+| Host chosen | Content that fills a whole state is an HTML page (`layoutType: "html"`, `widgets: {}`, content in `htmlPageConfig`); an htmlContainer is used only for a region of a grid that also holds other widgets — never a single container covering a whole grid state, except as the full-state fallback when `tb system info` reports `htmlPageLayout: false` (server older than 4.4.1). |
 | Keys exist | Every `dataKeys.name` in the JS exists on the targeted profile (in the `entityProfiles` input, projected from the overview — a CF output is a key annotated `(derived: …)`). A pure-composition container whose JS creates no subscription passes this vacuously — the embedded states' widgets carry their own keys. |
 | States exist | Every `stateId` in `<tb-dashboard-state>` / JS exists in the dashboard `states` map. |
 | Mode matches template | Angular syntax (`{{ }}`, `@if`/`@for`, `mat-*`, `<tb-dashboard-state>`) ⇒ `settings.type: "ANGULAR"`. |

thingsboard_cli-4.4.0.1.post1/scaffold/manifest.json

@@ -0,0 +1,4 @@
+{
+  "version": 122,
+  "content_hash": "sha256:7bbf252bae8b0a993644786e079ce516be9c68c13632b76b6ad325483e6771a2"
+}

{thingsboard_cli-4.4.0.1 → thingsboard_cli-4.4.0.1.post1}/src/thingsboard_cli/core/server_version.py

@@ -12,10 +12,12 @@ import re
 from typing import NamedTuple
 
 # The HTML page dashboard state layout (``gridSettings.layoutType: "html"``) ships
-# in ThingsBoard 4.4.0.1. Development builds of the 4.4 line (``4.4.0-SNAPSHOT``)
-# and ThingsBoard Cloud builds of it (``4.4.0PAAS.<build>``) already carry it, so
-# those count from the 4.4.0 base.
-HTML_PAGE_LAYOUT_MIN_RELEASE = (4, 4, 0, 1)
+# in ThingsBoard 4.4.1; the 4.4.0.1 hotfix was cut from 4.4.0 and does not carry it.
+# Development builds of the 4.4 line (``4.4.0-SNAPSHOT``) and ThingsBoard Cloud builds
+# of it (``4.4.0PAAS.<build>``) are treated as carrying it, so those count from the
+# 4.4.0 base. Cloud can report an older patch than it runs (4.4.0PAAS while serving
+# 4.4.0.2PAAS code), so only its 4.4 base is a reliable check.
+HTML_PAGE_LAYOUT_MIN_RELEASE = (4, 4, 1)
 HTML_PAGE_LAYOUT_MIN_PRERELEASE_BASE = (4, 4, 0)
 
 # "<numbers>[edition[.build]][-qualifier]", e.g. "4.4.0.1", "4.3.1.5PE", "4.4.0-SNAPSHOT",
@@ -59,7 +61,7 @@ def _at_least(numbers: tuple[int, ...], minimum: tuple[int, ...]) -> bool:
 def supports_html_page_layout(version: str | None) -> bool | None:
     """Whether a server of *version* can render HTML page dashboard states.
 
-    ``True`` for releases from 4.4.0.1 and for pre-release builds (``-SNAPSHOT``,
+    ``True`` for releases from 4.4.1 and for pre-release builds (``-SNAPSHOT``,
     ``-RC1``, …) or ThingsBoard Cloud versions (``4.4.0PAAS[.<build>]``) of 4.4.0 or later;
     ``False`` below that; ``None`` when the version is unknown or unparseable —
     callers decide the default for that case.

{thingsboard_cli-4.4.0.1 → thingsboard_cli-4.4.0.1.post1}/tests/e2e/test_system.py

@@ -1,7 +1,7 @@
 """E2E: `tb system info` against a real ThingsBoard server.
 
 The agent kit runs this command once per dashboard run to decide between an
-HTML page state (ThingsBoard 4.4.0.1+) and the full-state htmlContainer
+HTML page state (ThingsBoard 4.4.1+) and the full-state htmlContainer
 fallback, so the reported gate must match the server's actual version.
 """
 

{thingsboard_cli-4.4.0.1 → thingsboard_cli-4.4.0.1.post1}/tests/e2e/test_system_offline.py

@@ -71,19 +71,25 @@ def system_info_server() -> Iterator[tuple[str, dict[str, str]]]:
 
 
 @pytest.mark.parametrize(
-    ("version", "expected"),
+    ("version", "server_type", "expected"),
     [
-        ("4.4.0PAAS.07b21e82967", True),  # ThingsBoard Cloud build of the 4.4 line
-        ("4.4.0PAAS", True),  # same Cloud base without a build suffix
-        ("4.3.1.4.3PAASmailnonfree", False),  # ThingsBoard Cloud release of the 4.3 line
-        ("4.4.0.", None),  # malformed: unknown, never a confident True
+        ("4.4.0PAAS.07b21e82967", "PAAS", True),  # ThingsBoard Cloud build of the 4.4 line
+        ("4.4.0PAAS", "PAAS", True),  # same Cloud base without a build suffix
+        ("4.3.1.4.3PAASmailnonfree", "PAAS", False),  # ThingsBoard Cloud release of the 4.3 line
+        ("4.4.0.1", "PE", False),  # hotfix cut from 4.4.0: no HTML page layout
+        ("4.4.1", "PE", True),  # first release with HTML page layout
+        ("4.4.0.", "PAAS", None),  # malformed: unknown, never a confident True
     ],
 )
 def test_html_page_gate_for_reported_version(
-    tmp_path: Path, system_info_server: tuple[str, dict[str, str]], version: str, expected: bool | None
+    tmp_path: Path,
+    system_info_server: tuple[str, dict[str, str]],
+    version: str,
+    server_type: str,
+    expected: bool | None,
 ) -> None:
     url, reply = system_info_server
-    reply.update({"version": version, "type": "PAAS", "name": "ThingsBoard"})
+    reply.update({"version": version, "type": server_type, "name": "ThingsBoard"})
     env = _write_profile(tmp_path / "tb-config", "stub", url)
 
     result = tb("system", "--profile", "stub", "info", "--format", "json", cwd=tmp_path, env=env)

{thingsboard_cli-4.4.0.1 → thingsboard_cli-4.4.0.1.post1}/tests/test_scaffold_content.py

@@ -10,7 +10,7 @@ Guards two classes of generator bugs that shipped in the past:
   crashes the dashboard at load (``reading 'valueOf'`` in createSubscriptionTimewindow).
   Every timewindow the kit ships must carry the companion field its type needs.
 
-It also pins the HTML page state layout (ThingsBoard 4.4.0.1+): example states
+It also pins the HTML page state layout (ThingsBoard 4.4.1+): example states
 built as HTML pages must have the exact shape the UI stores, and no example may
 fall back to a grid state holding a single htmlContainer that covers the whole
 state — the generator copies the examples, so that shape would come back.
@@ -591,7 +591,7 @@ def test_generator_explains_file_path_save() -> None:
 
 
 # ---------------------------------------------------------------------------
-# HTML page version gate: fallback to a full-state htmlContainer below 4.4.0.1
+# HTML page version gate: fallback to a full-state htmlContainer below 4.4.1
 # ---------------------------------------------------------------------------
 
 NEVER_FULL_STATE_CONTAINER = re.compile(
@@ -602,7 +602,7 @@ NEVER_FULL_STATE_CONTAINER = re.compile(
 
 
 def test_never_full_state_container_rules_name_the_version_exception() -> None:
-    """Every 'never a single full-state htmlContainer' rule must carve out the pre-4.4.0.1 fallback."""
+    """Every 'never a single full-state htmlContainer' rule must carve out the pre-4.4.1 fallback."""
     rules = [
         (str(path.relative_to(AGENT_KIT)), line)
         for path in _markdown_files()
@@ -610,7 +610,7 @@ def test_never_full_state_container_rules_name_the_version_exception() -> None:
         if NEVER_FULL_STATE_CONTAINER.search(line)
     ]
     assert len(rules) >= 4, [f for f, _ in rules]
-    missing = [(f, line.strip()[:160]) for f, line in rules if "4.4.0.1" not in line]
+    missing = [(f, line.strip()[:160]) for f, line in rules if "4.4.1" not in line]
     assert not missing, missing
 
 
@@ -1210,12 +1210,12 @@ def test_generator_always_reads_the_map_prerequisite_rule() -> None:
 
 
 def test_html_page_mode_is_the_default_layout() -> None:
-    """Policy: on ThingsBoard 4.4.0.1+ every navigable state is an HTML page; stock-widget
+    """Policy: on ThingsBoard 4.4.1+ every navigable state is an HTML page; stock-widget
     grids only as embedded helpers. Older servers (htmlPageLayout false) keep grid mode."""
     core = (AGENT_KIT / "skills" / "dashboard-foundations" / "SKILL.md").read_text(encoding="utf-8")
     assert "**HTML page mode (default).** Build **every state a user navigates to** as an HTML page" in core
     assert "**embedded helper states**" in core
-    assert "**Grid mode (servers before 4.4.0.1).** Stock catalog widgets are the default." in core
+    assert "**Grid mode (servers before 4.4.1).** Stock catalog widgets are the default." in core
     generator = (AGENT_KIT / "agents" / "dashboard-generator.md").read_text(encoding="utf-8")
     assert "plan every state a user navigates to as an HTML page" in generator
     assert 'host: "helper"' in generator

{thingsboard_cli-4.4.0.1 → thingsboard_cli-4.4.0.1.post1}/tests/test_system_commands.py

@@ -49,12 +49,14 @@ def test_parse_server_version(version: str | None, expected: object) -> None:
 @pytest.mark.parametrize(
     ("version", "supported"),
     [
-        ("4.4.0.1", True),  # first release with HTML page layout
-        ("4.4.0.2", True),
-        ("4.4.1", True),
+        ("4.4.1", True),  # first release with HTML page layout
+        ("4.4.1.1", True),
         ("4.5", True),
         ("5.0.0", True),
-        ("4.4.0.1PE", True),
+        ("4.4.1PE", True),
+        ("4.4.0.1", False),  # hotfix cut from 4.4.0 does not carry the feature
+        ("4.4.0.1PE", False),
+        ("4.4.0.2", False),
         ("4.4.0", False),  # released 4.4.0 predates the feature
         ("4.4", False),
         ("4.3.1.5", False),
@@ -164,8 +166,9 @@ def test_info_json_unrecognized_version_is_null(client: MagicMock) -> None:
 @pytest.mark.parametrize(
     ("version", "label"),
     [
-        ("4.4.0.1", "supported"),
-        ("4.3.1.5", "not supported (requires ThingsBoard 4.4.0.1+)"),
+        ("4.4.1", "supported"),
+        ("4.4.0.1", "not supported (requires ThingsBoard 4.4.1+)"),
+        ("4.3.1.5", "not supported (requires ThingsBoard 4.4.1+)"),
         ("4.4.0PAAS.07b21e82967", "supported"),
         ("weird", "unknown (version not recognized)"),
     ],

{thingsboard_cli-4.4.0.1 → thingsboard_cli-4.4.0.1.post1}/uv.lock

@@ -787,7 +787,7 @@ wheels = [
 
 [[package]]
 name = "thingsboard-cli"
-version = "4.4.0.1"
+version = "4.4.0.1.post1"
 source = { editable = "." }
 dependencies = [
     { name = "click" },

thingsboard_cli-4.4.0.1/scaffold/manifest.json

@@ -1,4 +0,0 @@
-{
-  "version": 121,
-  "content_hash": "sha256:4657fcd138c146377c5b4e61b754d5dd421f4222cce788fedc6e36c78e4d1768"
-}