Formato del profilo

Un profilo add-on è un file JSON. Descrive un dispositivo in modo completo: come il nomos system Controller lo raggiunge, che cosa può inviare, quali valori ritornano e che cosa ne compare nell'app, nelle automazioni e nella Quick Config. Questa pagina descrive il formato; come modificarlo nell'Editor profilo è descritto lì. I profili con connessione propria tramite TCP, UDP, HTTP o seriale sono descritti nel dettaglio in CommandServer; esempi completi per HTTP, TCP (Modbus), UDP, MQTT e KNX si trovano in Profili di esempio.

INFO

Ogni profilo dell'elenco dei profili può essere salvato come .json con il simbolo di download. Un profilo esistente simile al Suo dispositivo è il miglior punto di partenza.

Struttura in sintesi

{
	"version": "1.0",
	"author": "Muster Integration GmbH",
	"description": "Wallbox XY",
	"manufacturer": "XY",
	"model": "Wallbox",
	"platform": "XY",
	"category": "Energy",
	"type": "EV Charger",
	"className": "XY_WALLBOX",
	"engineType": "",
	"structure": { "config": {}, "commands": {}, "mappings": {} },
	"polling": {},
	"properties": {},
	"propertiesMeta": {},
	"mappings": {},
	"mappingsMeta": {},
	"actionTemplates": [],
	"triggerTemplates": [],
	"hooks": {},
	"cameras": [],
	"components": {}
}

Blocco	Contenuto
Dati di base	Nome, produttore, categoria, tipo, tipo di motore
structure	Solo CommandServer: connessione, comandi e pattern di risposta, vedi CommandServer
polling	Solo CommandServer: comandi inviati regolarmente
properties, propertiesMeta	Azioni: che cosa si può inviare al dispositivo, e la loro etichetta
mappings, mappingsMeta	Feedback: quali valori segnala il dispositivo, e la loro etichetta
actionTemplates, triggerTemplates	Modelli per automazioni e Quick Config
hooks	Valori che il dispositivo può inviare da sé tramite HTTP
cameras	Immagini delle telecamere del dispositivo
components	Sottoprofili: più dispositivi su una sola connessione

Importante per capire: structure descrive solo che cosa passa sulla linea. App, automazioni e valori salvati lavorano esclusivamente con properties e mappings. Un profilo CommandServer ha quindi bisogno di entrambi: il comando in structure.commands e l'azione in properties, il pattern di risposta in structure.mappings e il feedback in mappings.

Dati di base

Campo	Obbligatorio	Significato
version	sì	Numero di versione, ad es. 1.0. I dispositivi esistenti adottano le modifiche solo con una versione più alta, vedi Modificare un profilo
description	sì	Nome nell'elenco dei profili e proposta per il nome del dispositivo
author, manufacturer, model	sì	Dati su autore e dispositivo
platform	sì	Origine, di solito il produttore. Con KNX KNX, con MQTT MQTT
category, type	sì	Vedi Categoria e tipo
engineType	sì	Vedi Tipo di motore
className	CommandServer, KNX	Con CommandServer il nome della connessione (solo A–Z, 0–9, _, -, al massimo 28 caratteri), con KNX sempre KNX, con MQTT e BUS vuoto
supportUrl	no	Pagina di aiuto sul dispositivo, compare come pulsante info
compatibility	no	Copertura del dispositivo in percentuale
nomosCertified	no	true solo per i profili verificati da nomos system
minVersion	no	Versione minima del Controller; i Controller più vecchi rifiutano la creazione di un dispositivo
tags	no	Contrassegni, vedi sotto
hideProperties, hideMappings	no	Li imposta l'Editor profilo da sé, vedi Modelli

Tag con effetto: uihidden (dispositivo non nell'app), voicehidden (non agli assistenti vocali e al bridge Matter). Un campo name non va nel profilo principale: sostituirebbe il nome che l'utente assegna alla creazione.

Un punto nel nome del profilo diventa _ all'importazione, perché al caricamento un punto separa profilo e sottoprofilo.

Categoria e tipo

Categoria e tipo decidono il simbolo e l'elemento di comando nell'app, e se e come il dispositivo compare tramite il bridge Matter. Usi i valori che propone l'Editor profilo, ad es.:

Categoria	Tipi
Lighting	Lightbulb
Switches	Switch, Trigger
Thermostats	Thermostat, Thermostat Variation TA
Window Coverings	Window Covering, Window Covering Up/Down
Sunblinds	Sunblind
Sensors	Temperature Sensor, Humidity Sensor, Contact Sensor, Motion Sensor, CO2 Sensor, Smoke Sensor, Light Sensor, Rain Sensor, Wind Sensor, Weather Station, Binary Sensor, …
Energy	Inverter, Smart Meter, EV Charger, Heat Pump, Heating Controller, Pellet Boiler, Power Sensor
Fans, Doors, Garage Door, Valves	Fan, Door, Garage Door Opener, Valve
Security Systems	Lock, Alarm, Camera, Security System

Scelga il tipo in base al valore più importante del dispositivo.

Tipo di motore

engineType	Connessione	Particolarità
"" (CommandServer)	Connessione propria tramite TCP, UDP, HTTP, HTTPS o seriale	structure e polling, vedi CommandServer
MQTT	Tramite il broker della competenza MQTT	Topic per ogni azione e feedback, vedi MQTT
KNX	Tramite l'interfaccia KNX	Profilo senza indirizzi, indirizzi di gruppo alla creazione, vedi KNX
BUS	I valori arrivano solo tramite Webhooks	Per dispositivi che segnalano da sé tramite HTTP
ZWAVE	Tramite la competenza Z-Wave	Viene creato tramite la pagina Z-Wave

Ogni dispositivo creato da un profilo CommandServer, MQTT o BUS conta nel numero di add-on consentito dalla Sua licenza.

Azioni e feedback

properties (azioni) è tutto ciò che si può inviare al dispositivo. mappings (feedback) sono i valori che il dispositivo segnala. Un nome può comparire in entrambi, ad esempio state per commutare e come stato segnalato; solo allora l'app mostra un interruttore che riproduce lo stato effettivo.

"properties": {
	"state":     {"method": "set", "property": "ENA", "datatype": "bool"},
	"switchon":  {"method": "set", "property": "ENA", "value": 1, "datatype": "bool", "uihidden": true},
	"switchoff": {"method": "set", "property": "ENA", "value": 0, "datatype": "bool", "uihidden": true}
},
"mappings": {
	"state":     {"method": "get", "property": "ENABLE_USER", "datatype": "bool", "defaultValue": false},
	"reachable": {"method": "get", "property": "REACHABLE", "datatype": "bool", "defaultValue": false}
}

Campi

Campo	In	Significato
method	entrambi	Azioni: command (inviare un comando), set (impostare una proprietà), alias (deviare su un'altra azione). Feedback: get
command	azioni	Nome del comando con method: "command"
property	entrambi	Con set: nome della proprietà. Nei feedback: nome del valore segnalato, con CommandServer il nome di un pattern di risposta, con KNX sempre value
datatype	entrambi	Vedi Tipi di dati
value	azioni	Valore fisso, vedi Valore fisso
defaultValue	entrambi	Azioni: valore se non ne arriva nessuno. Feedback: valore iniziale fino alla prima segnalazione
valueList	entrambi	Valori di selezione, vedi Elenchi di valori
min, max, internalMin, internalMax	entrambi	Vedi Scalatura
unit	entrambi	Vedi Unità
stepValue	entrambi	Passo dei cursori (non step)
uihidden	entrambi	Non come riga propria nell'app
process	feedback	Vedi Elaborazione
customFormat	feedback	Vedi Visualizzazione
simulateFeedback	azioni	true: il valore inviato vale subito come segnalato. Per dispositivi senza feedback
prefix, suffix	azioni	Vengono posti con una virgola prima o dopo il valore (prefix,valore)
sizeInBit	entrambi	KNX: dimensione del punto dati. Con 1, true/false vengono inviati come 1/0
filterDPT	entrambi	KNX: tipi di punto dati proposti quando si assegna l'indirizzo di gruppo
mqtt, mqttValue, mqttPayload, mqttScale	entrambi	MQTT, vedi MQTT

Con CommandServer {"method": "set", "property": "ENA"} diventa il comando SETENA, {"method": "command", "command": "ON"} il comando ON. Entrambi devono trovarsi in structure.commands.

Tipi di dati

datatype	Significato
bool	Sì/No. Valgono come «spento» 0, false, off, aus, offline, close, closed, error, warning (maiuscole/minuscole indifferenti), tutto il resto come «acceso». Un dispositivo che segnala open è quindi «acceso»
int, float	Numero intero o numero decimale (punto come separatore decimale)
string	Testo
null	Azione senza valore, ad es. un pulsante. Un valore inviato insieme viene scartato
trigger	Azione che viene solo attivata, ad esempio l'arresto di un'ombreggiatura

Nomi standard

L'app riconosce i valori dal loro nome e mostra l'elemento di comando adatto. Per questi valori usi esattamente questi nomi:

Nome	Valore	Tipo di dati
state	Acceso/Spento	bool
level	Luminosità 0–100	int
color-temperature	Temperatura di colore in Mired	int
position	Posizione di un'ombreggiatura 0–100	int
stop	Arrestare l'ombreggiatura	trigger
openclose	Aprire/Chiudere, obbligatorio per le porte garage	bool
opened	Porta o portone aperto	bool
temperature, setpoint	Temperatura attuale e nominale	float
hvacmode	Modalità di funzionamento	int o string
isheating, heatingpower	Sta riscaldando, potenza di riscaldamento in %	bool, int
humidity, co2, pressure, noise	Valori misurati	Numero
battery	Livello della batteria in %	int
reachable	Raggiungibilità	bool
power	Potenza	float
pv_power, grid, battery_power, battery_state, e_day, e_total	Energia: potenza FV, rete, accumulo, produzione di oggi e totale. grid dal punto di vista della casa: immissione positiva, prelievo negativo	Numero

Altri valori possono avere nomi propri (lettere minuscole, cifre, _, -); l'app li mostra come riga di testo. Per il nome, l'Editor profilo propone tutti i nomi noti.

state, switchon e switchoff

Quando l'app commuta un dispositivo, il Controller non invia state, ma switchon o switchoff. Le automazioni usano invece state stesso. Un dispositivo commutabile ha quindi bisogno di tutte e tre le azioni: state con il tipo di dati bool e switchon/switchoff con lo stesso comando e il valore fisso 1 o 0, entrambi con uihidden. In propertiesMeta una voce riunisce le tre:

"propertiesMeta": {
	"state": {"text": "State", "properties": ["state", "switchon", "switchoff"]}
}

Valore fisso

value in un'azione è il valore che essa invia se non ne arriva nessuno. Se arriva un valore, ad esempio dall'app, prevale questo, tranne con "datatype": "null": allora viene sempre inviato value. Nelle automazioni prevale invece sempre il valore fisso del profilo. Per pulsanti con contenuto fisso (richiamare una scena, premere un tasto) usi quindi "datatype": "null" e value.

Elenchi di valori

"valueList": [
	{"text": "Off", "value": "0"},
	{"text": "Low", "value": "1"},
	{"text": "High", "value": "2"}
]

In un'azione l'elenco è anche un elenco dei valori ammessi: un valore che non vi compare viene rifiutato. Le automazioni mostrano la selezione solo se lo stesso elenco si trova anche nel modello; lo ripeta lì.

Scalatura

internalMin/internalMax sono il campo di valori del dispositivo, min/max il campo in nomos (app, automazioni). Il Controller converte in modo lineare, in entrambe le direzioni. Esempio: la wallbox si aspetta la corrente di carica in mA (6000–32000), l'app mostra A (6–32):

"amperelimit": {"method": "set", "property": "CURR", "datatype": "int", "unit": "A",
	"min": 6, "max": 32, "internalMin": 6000, "internalMax": 32000}

WARNING

La scalatura avviene non appena max è impostato. I limiti mancanti valgono come min 0, max 100, internalMin 0, internalMax 100. Un "max": 3000 senza internalMin/internalMax converte quindi un valore del dispositivo 0–100 in 0–3000. Imposti tutti e quattro i limiti oppure nessuno.

• Il risultato viene arrotondato a numeri interi. Una conversione da W a kW con decimali non funziona quindi tramite la scalatura; con CommandServer usi un formato ({%/1000.00}, vedi Filtri di formato) oppure restituisca il valore nell'unità del dispositivo.
• I valori inviati vengono limitati a min/max.
• È possibile un campo invertito, ad es. "internalMin": 100, "internalMax": 0 per un'ombreggiatura che segnala 0 % come chiusa.

Unità

unit è o una categoria che l'app mostra e converte in modo adatto a ogni utente (temperature, percent, luminescence, voltage, current, electric, energy, co2, angle, noise, pressure, currency, bigmetric, smallmetric), oppure un'unità fissa come W, kW, kWh, Hz, m³/h, mostrata così com'è.

Per color-temperature vale: in nomos il valore è sempre in Mired. Se il dispositivo usa Kelvin, indichi "internalUnit": "kelvin", il campo Kelvin con il freddo per primo ("internalMin": 6500, "internalMax": 2700) e come min/max i valori Mired (154/370).

Elaborazione

process in un feedback elabora il valore dopo la ricezione, tra l'altro: invert (invertire il segno), wattHoursToKilowattHours, openCloseToBoolean (parole come open/closed in Sì/No), calculateGridPrice, calculatePhotovoltaicsPrice, calculateWaterPrice (valore × prezzo dalla variabile di sistema GRID_PRICE, PV_PRICE o WATER_PRICE). I trigger nelle automazioni confrontano il valore prima di questa elaborazione.

Visualizzazione

customFormat stabilisce come l'app mostra un valore. La chiave format è un'espressione in JsonLogic che calcola il valore mostrato; ogni altra chiave è un colore che vale quando la sua espressione è vera.

"grid": {"method": "get", "property": "GRID", "datatype": "float", "unit": "W",
	"customFormat": {
		"format": {"Math.abs": {"Math.round": {"var": "value"}}},
		"red-minus": {"<": [{"var": "value"}, 0]},
		"green-plus": {">": [{"var": "value"}, 0]}
	}}

Per format ci sono inoltre Math.round, Math.abs e le altre funzioni Math, toFixed1, toFixed2, toFixed3 e CustomFormatter.toHHMM e CustomFormatter.toHHMMSS (secondi come ora). Colori: green, red, blue, orange, purple, da soli come colore del testo oppure con -plus, -minus, -circle, -square come punto prima del valore.

Etichette e gruppi

propertiesMeta e mappingsMeta danno a ogni azione o feedback la sua etichetta:

"mappingsMeta": {
	"power": {"text": "Power", "group": "Vehicle charging", "properties": ["power"]}
}

• text: etichetta. L'utente può rinominarla per ogni dispositivo.
• group: sezione in cui l'app mostra il valore. Solo per dispositivi con molti valori; altrimenti lo ometta. Le sezioni compaiono nell'ordine del profilo.
• properties: quali voci riunisce questa riga, ad es. state, switchon e switchoff. Con KNX da ogni voce in propertiesMeta e mappingsMeta nasce un campo per un indirizzo di gruppo.

Traduzione

Etichette, gruppi e testi di elenchi di valori e modelli vengono tradotti se corrispondono esattamente a un termine noto a nomos, ad esempio State, Brightness, Power, Temperature, Reachable, Turn On, Is Turned On, Off, Low, Medium, High. Ogni altro testo compare in tutte le lingue così come si trova nel profilo. Scriva quindi questi testi nella lingua dell'impianto, oppure usi i termini standard inglesi proposti dall'Editor profilo.

Modelli

I modelli sono le voci che offrono le automazioni e la Quick Config.

"actionTemplates": [
	{"templateid": "switchon", "mapping": "switchon", "text": "Turn On", "icon": "toggle-on"},
	{"templateid": "level", "mapping": "level", "text": "Brightness", "icon": "sun-o"}
],
"triggerTemplates": [
	{"templateid": "state.on", "mapping": "state", "text": "Is Turned On", "value": "1", "icon": "toggle-on"}
]

Campo	Significato
templateid	Identificativo univoco; viene usato nelle automazioni salvate, quindi non lo modifichi più in seguito
mapping	L'azione (con actionTemplates) o il feedback (con triggerTemplates) a cui si riferisce il modello. Se non esiste, il modello viene tralasciato
text, textsuffix	Etichetta e aggiunta
icon	Nome di un simbolo Font Awesome senza fa-, ad es. toggle-on, bolt, thermometer
value	Valore fisso; l'automazione non mostra allora alcun campo di immissione
valueList	Selezione nell'automazione; copia dell'elenco dell'azione o del feedback
placeholder	Testo di esempio nel campo di immissione vuoto di un'azione con testo
hideInQuickConfig	true: non nella Quick Config, ma nelle automazioni

hideProperties: true o hideMappings: true fanno sì che le automazioni offrano solo i modelli invece di tutte le azioni o di tutti i feedback. L'Editor profilo li imposta entrambi da sé al salvataggio: true non appena esiste almeno un modello.

Interrogazioni

Solo CommandServer. Ogni voce invia un comando di structure.commands a intervalli fissi, all'avvio subito una volta:

"polling": {
	"Status": {"interval": 30, "editableInterval": true, "command": "STATUS"}
}

• interval: intervallo in secondi.
• editableInterval: true: l'intervallo viene richiesto alla creazione del dispositivo (precompilato con interval).
• value e editableValue: valore facoltativo inviato con il comando, e se viene richiesto alla creazione.

I sottoprofili non possono eseguire interrogazioni; le interrogazioni appartengono al profilo principale.

Webhooks

Con i webhook un dispositivo segnala valori da sé invece di essere interrogato, ad es. un pulsante che a ogni pressione richiama un indirizzo. Nel profilo indica quali feedback possono farlo; ogni voce ha bisogno di un feedback con lo stesso nome:

"hooks": {"action": {"enabled": true}, "battery": {"enabled": true}},
"mappings": {
	"action":  {"method": "get", "property": "ACTION", "datatype": "int"},
	"battery": {"method": "get", "property": "BATTERY", "datatype": "int", "unit": "percent"}
}

Alla creazione del dispositivo il Controller indica l'indirizzo che il dispositivo deve richiamare. Ha la forma http://<IP del Controller>/api/v1/hook/<ID dispositivo>; i valori si trovano come parametri nell'indirizzo (GET) o nel corpo (POST, come modulo o JSON):

http://192.168.1.10/api/v1/hook/C12?action=1&battery=98

Il Controller acquisisce solo i parametri abilitati in hooks e risponde con 200 se almeno un valore è stato acquisito, altrimenti con 204.

DANGER

I webhook non hanno autenticazione. Ogni dispositivo nella rete locale che conosce l'indirizzo può impostare i valori abilitati. Tramite l'accesso remoto l'indirizzo è bloccato. Abiliti quindi solo i feedback che un dispositivo deve davvero inviare, e non li usi per attivare automazioni rilevanti per la sicurezza, ad esempio l'apertura di una porta.

Telecamere

"cameras": [
	{"type": "mjpeg", "url": "http://%SERVERIP%/mjpegstream.cgi?usr=%USERNAME%&pwd=%PASSWORD%"}
]

type: snapshot (immagine singola, standard), mjpeg, rtsp o otherhttp. Nell'URL i segnaposto %NAME% vengono sostituiti dai valori della comunicazione. Alla creazione del dispositivo nasce una telecamera per ogni voce. Se con rtsp o otherhttp è stato raggiunto il numero massimo di stream video, la telecamera viene saltata senza messaggio.

Sottoprofili

"components": {
	"out1": {"name": "Ausgang 1", "category": "Switches", "type": "Switch",
		"properties": {}, "propertiesMeta": {}, "mappings": {}, "mappingsMeta": {}}
}

Alla creazione del dispositivo ogni chiave diventa un dispositivo proprio chiamato «Nome dispositivo Ausgang 1». Tutti condividono la connessione del profilo principale; structure, polling e cameras esistono solo nel profilo principale. I dati di base mancanti (versione, produttore, categoria, tipo, tipo di motore) un sottoprofilo li prende dal profilo principale. Non modifichi più la chiave di un sottoprofilo se ci sono dispositivi che lo usano.

MQTT

I profili MQTT usano il broker configurato nella competenza MQTT; un profilo non può scegliere un broker proprio. Alla creazione del dispositivo inserisca un MQTT Topic, che nel profilo compare come %mqttTopic%.

"properties": {
	"switchon": {"method": "command", "command": "power", "value": 1,
		"mqtt": "cmnd/%mqttTopic%/POWER", "datatype": "null", "uihidden": true},
	"level": {"method": "command", "command": "brightness",
		"mqtt": "cmnd/%mqttTopic%/Dimmer", "datatype": "int", "unit": "percent"}
},
"mappings": {
	"level": {"method": "get", "property": "dimmer", "mqtt": "stat/%mqttTopic%/RESULT",
		"mqttValue": "Dimmer", "datatype": "int", "unit": "percent"},
	"reachable": {"method": "get", "property": "reachable", "mqtt": "tele/%mqttTopic%/LWT",
		"mqttValue": "", "datatype": "bool", "defaultValue": true}
}

Campo	Significato
mqtt	Topic. Nei feedback sono ammessi + e # come segnaposto
command	Azioni: nome del comando. Le azioni con lo stesso command devono avere lo stesso topic, come switchon e switchoff
mqttPayload	Azioni: payload con \# come posto per il valore, ad es. {"brightness":\#}. Senza mqttPayload viene inviato solo il valore
mqttValue	Feedback: quale parte di un payload JSON è il valore. Con il punto un percorso (ENERGY.Power), senza punto il primo campo con questo nome, in un array una posizione. Vuoto: l'intero payload
mqttScale	Feedback: viene aggiunto al valore come unità, ma non converte. Utile solo insieme a "unit": "energy" (kW diventa W)

• L'invio avviene con QoS 0 e senza retain.
• %mqttTopic% viene sostituito in mqtt, command e property, non in mqttPayload.
• Senza il feedback reachable il dispositivo vale sempre come raggiungibile. Con il topic LWT del dispositivo (Online/Offline) la raggiungibilità è corretta.

Modelli MQTT pronti e una guida Node-RED per collegare qualsiasi dispositivo sono descritti nella pagina Modelli MQTT (in tedesco) della libreria degli add-on.

KNX

Un profilo KNX non contiene indirizzi. Stabilisce quali valori ha un dispositivo e quanto sono grandi sul bus; gli indirizzi di gruppo li assegna alla creazione del dispositivo. Crea dispositivo apre a questo scopo la finestra della competenza KNX con il profilo.

"className": "KNX", "engineType": "KNX", "platform": "KNX",
"properties": {
	"state":     {"method": "set", "property": "value", "datatype": "bool", "sizeInBit": 1, "filterDPT": ["1.001"]},
	"switchon":  {"method": "set", "property": "value", "value": 1, "datatype": "bool", "sizeInBit": 1, "uihidden": true},
	"switchoff": {"method": "set", "property": "value", "value": 0, "datatype": "bool", "sizeInBit": 1, "uihidden": true}
},
"propertiesMeta": {"state": {"text": "State", "properties": ["state", "switchon", "switchoff"]}},
"mappings": {
	"state": {"method": "get", "property": "value", "datatype": "bool", "sizeInBit": 1, "filterDPT": ["1.001"]}
},
"mappingsMeta": {"state": {"text": "State", "properties": ["state"]}}

• className e platform sono sempre KNX, property è sempre value.
• Ogni voce in propertiesMeta diventa un campo per l'indirizzo di gruppo per commutare, ogni voce in mappingsMeta uno per l'indirizzo di stato. La chiave stessa deve essere il nome di un'azione o di un feedback. L'indirizzo per state vale anche per switchon e switchoff.
• sizeInBit deve corrispondere al tipo di punto dati (1 bit per commutare, 8 bit per percentuali e livelli, 16 bit per temperature); filterDPT limita la selezione durante l'assegnazione. L'unità deriva dal tipo di punto dati dell'indirizzo di gruppo.
• Un valore senza indirizzo di gruppo non fa nulla e non compare nell'app.
• Un feedback reachable non è necessario; la raggiungibilità segue la connessione KNX.

Molti tipi di dispositivo (luce, dimmer, ombreggiatura, termostato, sensori) sono già inclusi nella competenza KNX. Un profilo proprio conviene per i dispositivi che lì mancano. Indicazioni su indirizzi di gruppo e tipi di punto dati si trovano nella pagina Modelli KNX (in tedesco) della libreria degli add-on.

Errori frequenti

• I valori restano vuoti: con CommandServer manca il feedback in mappings, oppure il suo property non corrisponde al nome del pattern di risposta in structure.mappings.
• L'interruttore torna indietro: non c'è un feedback state, oppure il dispositivo non segnala lo stato.
• L'app non commuta: mancano switchon/switchoff; l'app non invia mai state stesso.
• Numeri scalati male: max senza internalMin/internalMax (vedi Scalatura).
• L'automazione non offre un valore: ci sono modelli, ma nessuno per questo valore (vedi Modelli).
• Dispositivo sempre raggiungibile: con CommandServer mancano CONNECTEVENT/DISCONNECTEVENT, con MQTT il feedback reachable (vedi Raggiungibilità).
• Un secondo profilo …_2: nasce solo se, per un profilo modificato nell'Editor profilo, sceglie Come copia. Altrimenti un nuovo caricamento o importazione sostituisce il profilo esistente (vedi Aggiornamenti dalla libreria online).