When working with a Sedona app, the Sedona palette becomes available in the left-side nav bar pane. The palette provides “drag and drop” access to components in the kits available to the app.
If the Sedona Palette is not in the nav bar, from the Workbench menu select -> -> . Note that the contents of the palette will be “Unavailable” if your Workbench view is not within the “App” itself—for example,
when viewing the Sox Manager.
Click the drop-down control to see the kits available for selection, as shown in Figure 16. Some of the kits may contain as few as one (or even no) component, while others will have multiple components.
In brackets beside every component listed in a palette is the number of bytes of memory [n]
consumed by each instance of it, say when copied (dragged into) an app.
Relative to other Sedona platforms, the Sedona (Jennic) Module platform has a small amount of available memory space for apps, including kits and scode. Keep this in mind when developing for this platform.
Note the JennicPlatform component (from jennic kit) provides a read-only “memAvailable” slot that lists the currently available amount of memory, in bytes. In the standard demo app, see this value by expanding the app’s service folder and double-clicking on the plat named node, to display its property sheet view. The “Mem Available” value shows available bytes.
Also, when working with a Sedona (Jennic) Module platform such as the Dev Board, note that memory freed by deleting components is not available until after you restart the node.
Related to memory constraints, Sedona components have a 7-character maximum name limit, using only alphanumeric (A-Z, a-z, 0-9) and underscore (_) characters. Spaces and other punctuation are not permitted. When adding a new component, the popup Name dialog enforces this limit.
The first character in a name must be a letter.
Name must be unique for every component within the same parent container. Workbench automatically enforces this rule, say when duplicating copies of the same component, by imposing unique numeral(s) at the end of each component name.
Naming is case-sensitive—for example, Door_1 and door_1 are unique names.
A few of the more interesting palettes for early exploration among Sedona kits include the following:
As shown in Figure 17, this contains several component types, briefly described below the figure.
App — Top level container for the entire app, holds the app name and scan period.
Component — Base class for all Sedona components, it has no practical application as-is.
Folder — Container to organize groups of child components, has a default “wire sheet” view.
PlatformService — (JennicPlatform) Holds the node’s wireless network configuration (Panid, channel map, router operation) and other read-only status properties, including available memory.
Service — Base class for all Sedona services, it has no practical application as-is.
User — Represents an individual app user, implemented as child of the UserService. Properties define component and provisioning permissions, along with user login credentials (password).
UserService— Container for all User components, provides a Sedona User Manager view to adminster (add, change, delete) individual Users.
Typically, only the Folder component is useful from the sys palette when working in a demo app. This is so because each demo
app already includes the one-only App and “services” components (PlatformService, UserService, found in the service folder), along with a default User “admin” under the UserService.
As shown in Figure 18, this contains several component types, briefly described below.
Adc — Each provides an interface to one of the four analog inputs (ADC) of the SED-M0x
module.
AdcScanService — Must be copied into an app’s
folder to provide continuous updates of analog inputs (ADC points). If an app does not use Adc components, it is not required.Dac — Each provides an interface to one of the two analog outputs (DAC) of the SED-M0x
module.
DioIn — Each provides an interface to one of the digital inputs of the SED-M0x
module. On the dev board, these correspond to pushbutton switches SW1 and SW2.
DioOut — Each provides an interface to one of the digital outputs of the SED-M0x
module. On the dev board, these correspond to the four relay outputs (1 - 4) as well as LEDs D1 - D4.
Each basicio component has one or more properties that define which IO point (address) and often items that affect the component’s value.
As shown in Figure 19, this contains various component types, briefly described below.
And2 — A logic AND gate for boolean states (True, False) at two boolean type inputs.
B2P — Boolean “to pulse” conversion of single boolean input, upon False-to-True transition.
ConstBool — Provides a boolean out value, with right-click “Set” action to select either state.
ConstFloat — Provides a floating point out value, with right-click “Set” action to specify the value.
ConstInt — Provides an integer out value, with right-click “Set” action to specify the value.
Eeprom — Provides an example interface to the serial EEPROM on the dev board with actions to “write to” and “read from” the EEPROM, using a configurable memory start address.
F2I — Provides conversion for a floating point input to an integer output.
I2F — Provides conversion for an integer input to a floating point output.
IncDec — Provides a float value from transitions on two boolean “Inc” and “Dec” inputs, used in a specific demo app (jenDbDemo2).
LSeq4 — A linear sequencer for 4 boolean outputs based on received floating point input.
Not — A logic NOT gate to “flip” the boolean input state at the component’s out slot.
TickTock — Provides a boolean multivibrator with a configurable cycle period (ticks per second).
The “Const” named components provide a convenient way to link and test control logic to various other components, including output I/O types such as Dac and DioOut (found on the basicio palette).
Copyright © 2000-2014 Tridium Inc. All rights reserved.