Generate XML using Alchemy tool for closure cluster and device type #37371
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,261 @@ | ||
| <?xml version="1.0"?> | ||
| <!-- | ||
| Copyright (c) 2025 Project CHIP Authors | ||
|
|
||
| Licensed under the Apache License, Version 2.0 (the "License"); | ||
| you may not use this file except in compliance with the License. | ||
| You may obtain a copy of the License at | ||
|
|
||
| http://www.apache.org/licenses/LICENSE-2.0 | ||
|
|
||
| Unless required by applicable law or agreed to in writing, software | ||
| distributed under the License is distributed on an "AS IS" BASIS, | ||
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
| See the License for the specific language governing permissions and | ||
| limitations under the License. | ||
| --> | ||
| <!-- | ||
| XML generated by Alchemy; DO NOT EDIT. | ||
| Source: src/app_clusters/ClosureControl.adoc | ||
| Parameters: in-progress | ||
| Git: 0.7-summer-2025-dirty | ||
| --> | ||
| <configurator xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../../zcl.xsd"> | ||
| <domain name="Closures"/> | ||
| <enum name="ClosureErrorEnum" type="enum8"> | ||
| <cluster code="0x0104"/> | ||
| <item name="Blocked" value="0x00"/> | ||
| <item name="TemperatureLimited" value="0x01"/> | ||
| <item name="MaintenanceRequired" value="0x02"/> | ||
| <item name="InternalInterference" value="0x03"/> | ||
| </enum> | ||
|
|
||
| <enum name="LatchingEnum" type="enum8"> | ||
| <cluster code="0x0104"/> | ||
| <cluster code="0x0106"/> | ||
|
Comment on lines
+34
to
+35
There was a problem hiding this comment. Why does this not apply to all the cluster IDs for Closure Dimension? There was a problem hiding this comment. Bug in alchemy; this is the first time we've had a set of cluster aliases reference a type from a different cluster. Fixed in 1.5.4. |
||
| <item name="LatchedAndSecured" value="0x00"/> | ||
| <item name="LatchedButNotSecured" value="0x01"/> | ||
| <item name="NotLatched" value="0x02"/> | ||
| </enum> | ||
|
|
||
| <enum name="MainStateEnum" type="enum8"> | ||
| <cluster code="0x0104"/> | ||
| <item name="Stopped" value="0x00"/> | ||
| <item name="Moving" value="0x01"/> | ||
| <item name="WaitingForMotion" value="0x02"/> | ||
| <item name="Error" value="0x03"/> | ||
| <item name="Calibrating" value="0x04"/> | ||
| <item name="Protected" value="0x05"/> | ||
| <item name="Disengaged" value="0x06"/> | ||
| <item name="SetupRequired" value="0x07"/> | ||
| <item name="PendingFallback" value="0x08"/> | ||
| </enum> | ||
|
|
||
| <enum name="PositioningEnum" type="enum8"> | ||
| <cluster code="0x0104"/> | ||
| <item name="FullyClosed" value="0x00"/> | ||
| <item name="FullyOpened" value="0x01"/> | ||
| <item name="PartiallyOpened" value="0x02"/> | ||
| <item name="OpenedForPedestrian" value="0x03"/> | ||
| <item name="OpenedForVentilation" value="0x04"/> | ||
| <item name="OpenedAtSignature" value="0x05"/> | ||
| </enum> | ||
|
|
||
| <enum name="RestingProcedureEnum" type="enum8"> | ||
| <cluster code="0x0104"/> | ||
| <item name="DoNothing" value="0x00"/> | ||
| <item name="ReturnToFullyOpened" value="0x01"/> | ||
| <item name="ReturnToFullyClosed" value="0x02"/> | ||
| </enum> | ||
|
|
||
| <enum name="TagLatchEnum" type="enum8"> | ||
| <cluster code="0x0104"/> | ||
| <cluster code="0x0105"/> | ||
| <cluster code="0x0106"/> | ||
| <cluster code="0x0107"/> | ||
| <cluster code="0x0108"/> | ||
| <cluster code="0x0109"/> | ||
| <item name="Latch" value="0x00"/> | ||
| <item name="Unlatch" value="0x01"/> | ||
| </enum> | ||
|
|
||
| <enum name="TagPositionEnum" type="enum8"> | ||
| <cluster code="0x0104"/> | ||
| <item name="CloseInFull" value="0x00"/> | ||
| <item name="OpenInFull" value="0x01"/> | ||
| <item name="Pedestrian" value="0x02"/> | ||
| <item name="Ventilation" value="0x03"/> | ||
| <item name="Signature" value="0x04"/> | ||
| <item name="SequenceNextStep" value="0x05"/> | ||
| <item name="PedestrianNextStep" value="0x06"/> | ||
| </enum> | ||
|
|
||
| <enum name="TriggerConditionEnum" type="enum8"> | ||
| <cluster code="0x0104"/> | ||
| <item name="AfterDelay" value="0x00"/> | ||
| <item name="AfterApplicativeTrigger" value="0x01"/> | ||
| <item name="AfterDelayOrApplicativeTrigger" value="0x02"/> | ||
| </enum> | ||
|
|
||
| <enum name="TriggerPositionEnum" type="enum8"> | ||
| <cluster code="0x0104"/> | ||
| <item name="AtFullyClosed" value="0x00"/> | ||
| <item name="AtFullyOpened" value="0x01"/> | ||
| <item name="InBetween" value="0x02"/> | ||
| <item name="AtVentilation" value="0x03"/> | ||
| <item name="AtPedestrian" value="0x04"/> | ||
| </enum> | ||
|
|
||
| <struct name="OverallStateStruct" apiMaturity="provisional"> | ||
|
There was a problem hiding this comment. Shouldn't the enums also be tagged with There was a problem hiding this comment. The XSD for ZCL only allows apiMaturity on clusters and structs, so alchemy doesn't generate that attribute. We could update the XSD, of course. Is there anything downstream that's expecting this? I only see it on clusters, structs and attributes in the existing XML. There was a problem hiding this comment. Everything can be marked provisional in the spec, so anything should be able to be marked provisional in the XML. If the XSD does not support that, the XSD is broken. If the tooling we have on PRs does not support that (e.g. does not look at it), that tooling is broken.... @andy31415 |
||
| <cluster code="0x0104"/> | ||
| <item fieldId="0" name="Positioning" type="PositioningEnum" optional="true" default="0x02" min="0x00" max="0x05"/> | ||
| <item fieldId="1" name="Latching" type="LatchingEnum" optional="true" default="0x02" min="0x00" max="0x02"/> | ||
| <item fieldId="2" name="Speed" type="ThreeLevelAutoEnum" optional="true" default="0x00" min="0x00" max="0x03"/> | ||
| <item fieldId="3" name="ExtraInfo" type="bitmap32" optional="true"/> | ||
| </struct> | ||
|
|
||
| <struct name="OverallTargetStruct" apiMaturity="provisional"> | ||
| <cluster code="0x0104"/> | ||
| <item fieldId="0" name="TagPosition" type="TagPositionEnum" optional="true" min="0x00" max="0x06"/> | ||
| <item fieldId="1" name="TagLatch" type="TagLatchEnum" optional="true" min="0x00" max="0x01"/> | ||
| <item fieldId="2" name="Speed" type="ThreeLevelAutoEnum" optional="true" min="0x00" max="0x03"/> | ||
| </struct> | ||
|
|
||
| <cluster> | ||
|
There was a problem hiding this comment. Shouldn't this have There was a problem hiding this comment. Alchemy used to do this if a cluster was new to the file, but it's been changed to only generate apiMaturity when the cluster is marked provisional in the spec. It's not marked provisional, so no apiMaturity. There was a problem hiding this comment. Shouldn't anything that's in ifdefs in the spec be provisional automatically @hasty ? |
||
| <domain>Closures</domain> | ||
| <name>Closure Control</name> | ||
| <code>0x0104</code> | ||
| <define>CLOSURE_CONTROL_CLUSTER</define> | ||
| <description/> | ||
| <client init="false" tick="false">true</client> | ||
| <server init="false" tick="false">true</server> | ||
| <globalAttribute code="0xFFFD" side="either" value="1"/> | ||
| <attribute code="0x0000" side="server" define="COUNTDOWN_TIME" type="elapsed_s" isNullable="true" max="259200" optional="true"> | ||
| <description>CountdownTime</description> | ||
| <optionalConform/> | ||
|
Comment on lines
+133
to
+135
There was a problem hiding this comment. Maybe this is an alchemy question, but why do we have both There was a problem hiding this comment. Because the optional attribute predated the embedding of DM-style conformance. The "optional" attribute essentially just means "not mandatory" There was a problem hiding this comment. Well, do we plan to keep the "optional" XML attribute in the long term? If not, we should make sure ZAP handles that and just stop emitting it. If we plan to keep it, we should not output the conformance bit when it's pure-optional. No matter what, we should not have two sources of truth here... |
||
| </attribute> | ||
| <attribute code="0x0001" side="server" define="MAIN_STATE" type="MainStateEnum" min="0x00" max="0x08">MainState</attribute> | ||
| <attribute code="0x0002" side="server" define="CURRENT_ERROR_LIST" type="array" entryType="ClosureErrorEnum">CurrentErrorList</attribute> | ||
| <attribute code="0x0003" side="server" define="OVERALL_STATE" type="OverallStateStruct" isNullable="true">OverallState</attribute> | ||
| <attribute code="0x0004" side="server" define="OVERALL_TARGET" type="OverallTargetStruct" isNullable="true">OverallTarget</attribute> | ||
| <attribute code="0x0005" side="server" define="RESTING_PROCEDURE" type="RestingProcedureEnum" min="0x00" max="0x02" optional="true"> | ||
| <description>RestingProcedure</description> | ||
| <mandatoryConform> | ||
| <feature name="FB"/> | ||
| </mandatoryConform> | ||
| </attribute> | ||
| <attribute code="0x0006" side="server" define="TRIGGER_CONDITION" type="TriggerConditionEnum" min="0x00" max="0x02" optional="true"> | ||
| <description>TriggerCondition</description> | ||
| <mandatoryConform> | ||
| <feature name="FB"/> | ||
| </mandatoryConform> | ||
| </attribute> | ||
| <attribute code="0x0007" side="server" define="TRIGGER_POSITION" type="TriggerPositionEnum" min="0x00" max="0x04" optional="true"> | ||
| <description>TriggerPosition</description> | ||
| <mandatoryConform> | ||
| <feature name="FB"/> | ||
| </mandatoryConform> | ||
| </attribute> | ||
| <attribute code="0x0008" side="server" define="WAITING_DELAY" type="elapsed_s" max="86400" default="60" optional="true"> | ||
| <description>WaitingDelay</description> | ||
| <mandatoryConform> | ||
| <feature name="FB"/> | ||
| </mandatoryConform> | ||
| </attribute> | ||
| <attribute code="0x0009" side="server" define="KICKOFF_TIMER" type="elapsed_s" max="86400" default="0" optional="true"> | ||
| <description>KickoffTimer</description> | ||
| <mandatoryConform> | ||
| <feature name="FB"/> | ||
| </mandatoryConform> | ||
| </attribute> | ||
| <command code="0x00" source="client" name="Stop" optional="true"> | ||
| <description>On receipt of this command, the device SHALL stop its operation if it is at a position where it is safe to do so and/or permitted.</description> | ||
| <mandatoryConform> | ||
| <notTerm> | ||
| <feature name="IS"/> | ||
| </notTerm> | ||
| </mandatoryConform> | ||
| </command> | ||
|
|
||
| <command code="0x01" source="client" name="MoveTo" optional="false"> | ||
| <description>Upon receipt, this SHALL move the product in the most fitting state following the data as follows: </description> | ||
| <arg id="0" name="Tag" type="TagPositionEnum" optional="true" min="0x00" max="0x06"/> | ||
| <arg id="1" name="Latch" type="TagLatchEnum" optional="true" min="0x00" max="0x01"/> | ||
| <arg id="2" name="Speed" type="ThreeLevelAutoEnum" optional="true" min="0x00" max="0x03"/> | ||
| </command> | ||
|
|
||
| <command code="0x02" source="client" name="Calibrate" optional="true"> | ||
| <description>Upon receipt, this SHALL initiate a calibration.</description> | ||
| <access op="invoke" privilege="manage"/> | ||
| <mandatoryConform> | ||
| <feature name="CL"/> | ||
| </mandatoryConform> | ||
| </command> | ||
|
|
||
| <command code="0x03" source="client" name="ConfigureFallback" optional="true"> | ||
| <description>Upon receipt, this SHALL configure the Fallback feature behavior using the data as follows: </description> | ||
| <arg id="0" name="RestingProcedure" type="RestingProcedureEnum" optional="true" min="0x00" max="0x02"/> | ||
| <arg id="1" name="TriggerCondition" type="TriggerConditionEnum" optional="true" min="0x00" max="0x02"/> | ||
| <arg id="2" name="TriggerPosition" type="TriggerPositionEnum" optional="true" min="0x00" max="0x04"/> | ||
| <arg id="3" name="WaitingDelay" type="elapsed_s" optional="true" max="86400"/> | ||
| <mandatoryConform> | ||
| <feature name="FB"/> | ||
| </mandatoryConform> | ||
| </command> | ||
|
|
||
| <command code="0x04" source="client" name="CancelFallback" optional="true"> | ||
| <description>Upon receipt, this SHALL cancel the current PendingFallback.</description> | ||
| <mandatoryConform> | ||
| <feature name="FB"/> | ||
| </mandatoryConform> | ||
| </command> | ||
|
|
||
| <features> | ||
| <feature bit="0" code="PS" name="Positioning" summary="Supports positioning with at least Fully Opened (0%) and Fully Closed (100%) discrete position"> | ||
| <optionalConform choice="a" more="true" min="1"/> | ||
| </feature> | ||
| <feature bit="1" code="LT" name="MotionLatching" summary="Supports a latch (securing a position, a state ...)"> | ||
| <optionalConform choice="a" more="true" min="1"/> | ||
| </feature> | ||
| <feature bit="2" code="IS" name="Instantaneous" summary="Supports the Instantaneous feature"> | ||
| <optionalConform/> | ||
| </feature> | ||
| <feature bit="3" code="SP" name="Speed" summary="Supports speed motion throttling"> | ||
| <optionalConform> | ||
| <andTerm> | ||
| <feature name="PS"/> | ||
| <notTerm> | ||
| <feature name="IS"/> | ||
| </notTerm> | ||
| </andTerm> | ||
| </optionalConform> | ||
| </feature> | ||
| <feature bit="4" code="VT" name="Ventilation" summary="Supports Ventilation discrete state"> | ||
| <optionalConform> | ||
| <feature name="PS"/> | ||
| </optionalConform> | ||
| </feature> | ||
| <feature bit="5" code="PD" name="Pedestrian" summary="Supports Pedestrian discrete state"> | ||
| <optionalConform> | ||
| <feature name="PS"/> | ||
| </optionalConform> | ||
| </feature> | ||
| <feature bit="6" code="CL" name="Calibration" summary="Supports the Calibration feature"> | ||
| <optionalConform> | ||
| <feature name="PS"/> | ||
| </optionalConform> | ||
| </feature> | ||
| <feature bit="7" code="PT" name="Protection" summary="Supports the Protection feature"> | ||
| <optionalConform/> | ||
| </feature> | ||
| <feature bit="8" code="MO" name="ManuallyOperable" summary="Supports the manual operation feature"> | ||
| <optionalConform/> | ||
| </feature> | ||
| <feature bit="9" code="FB" name="Fallback" summary="Supports the fallback feature"> | ||
| <optionalConform> | ||
| <feature name="PS"/> | ||
| </optionalConform> | ||
| </feature> | ||
| </features> | ||
| </cluster> | ||
| </configurator> | ||
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the spec.... you can't just randomly reference a data type from cluster X in cluster Y. I mean, you can write that, and Alchemy seems to "do something" with it as here, but it's broken, because data type names are not unique; so they are always scoped to the cluster they are defined in, except for global data types, which do have unique names.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For backwards compatibility purposes, alchemy allows this because existing clusters use each other's structs, but now that we have proper global struct support, we should use that instead.
You could do this most easily by moving the shared struct definitions to closures.adoc, and making sure you have references to them everywhere they're used.