Documentation
¶
Index ¶
Constants ¶
const ( Power DeviceType = "power" Lighting DeviceType = "lighting" Meter DeviceGroup = "meter" DaliEL DeviceGroup = "daliEL" )
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type Category ¶
type Category struct {
DeviceType
DeviceGroup
}
type Device ¶
type Device struct {
DeviceUID string `firestore:"uid" json:"uid"`
*DeviceMeta `datastore:",omitempty" firestore:",omitempty" json:",omitempty"`
}
Device minimally identifies an IoT resource a devices message typically identifies itself with a UID the Meta information can then be accessed and added to the struct as well as Groups, an open array of structural helpers
type DeviceGroup ¶
type DeviceGroup string
type DeviceMeta ¶
type DeviceMeta struct {
DeviceName string `datastore:",omitempty" firestore:"name,omitempty" json:"deviceName,omitempty"`
DeviceTag string `datastore:",omitempty" firestore:"tag,omitempty" json:"deviceTag,omitempty"`
DeviceType DeviceType `datastore:",omitempty" firestore:"type,omitempty" json:"type,omitempty"`
CompanyUID string `datastore:",omitempty" firestore:"companyUID,omitempty" json:"companyUID,omitempty"`
LocationUID string `datastore:",omitempty" firestore:"locationUID,omitempty" json:"locationUID,omitempty"`
Firmware *Firmware `datastore:",omitempty" firestore:"firmware,omitempty" json:"firmware,omitempty"`
//Datastore can't handle map[string]interface so a datastore implementation will need to serialize the specific processors it needs
Processors *Processor `datastore:"-" firestore:"processors,omitempty" json:"processors,omitempty"`
}
DeviceMeta helps further identify a Device. Deployed devices *must* have an UID that identifies the physical unit.
The metadata can be added to passed messages so a cache is not needed to query the structure needed for microservice ¶
DeviceName is a human-readable identifier for the device which may or may not be unique DeviceTag identifies the function of the device in its environment and should remain constant if the device is switched out due to failure or replacement but the function of the device remains constant
so for example:
the cooler in room 4B is still the cooler in 4B even if it is upgraded from PhilipsKA4500 to PhilipsKA4501
CompanyUID and LocationUID remain as basic organizational elements
type DeviceSkeleton ¶
DeviceSkeleton is used by microservices before they have full admin details for a device - this allows a device's data to be stored and traced even if it is not currently identified in admin.
type DeviceType ¶
type DeviceType string
type JWTParser ¶
type JWTParser struct {
// contains filtered or unexported fields
}
JWTParser: We use JWT primarily in conjunction with external Webhooks