Commandes shell pour le délestage

Il est prévu que tous les produits “organes de chauffe” et chargeurs des véhicules (CEVMAX) puissent être pilotés en délestage, par le même format de commandes shell/Mesh depuis le controleur GEMAX.

Ainsi tous ces produits implémentent le model Mesh Vendor Heater model qui est adapté aux différents cas de figures :

possibilité d’envoyer une consigne par un contrôleur Mesh, par l’app mobile ou le backend (via le PASSMAX),
possibilité d’ecraser la dernière consigne de l’utilisateur par une consigne de délestage, permanente ou temporaire (sur timer) depuis un contrôleur Mesh ou le backend (pas d’accès via l’App mobile),
Le protocole Mesh se charge de publier les changements de status contenant le mode de consigne en cours ainsi que les indications de délestage en cours. Ces status sont ainsi disponibles pour mettre à jour les pages produits de l’app mobile et remontent via le PASSMAX au backend.
possibilité de contrôle par un thermostat avec des modes de programmation et de dérogation, qui sort du cadre de cette documentation.

Commande shell sur le model Heater

Supposons que l’on veuille piloter la feature feature_idx du produit ayant l’adresse unicast unicast_addr. Le contrôleur Mesh (GEMAX) envoie une commande de type :

Commande sans acquittement (surtout utilisé dans le cas de messages de groupe) :

==> mesh models msg send-vnd <elem id> <model id> <company id> <addr> <opcode> [payload]

Avec

elem id : the element index of the model instance (source) = feature_idx

model id : the model id sender (source) = Heater Client = 0x0019

company id: the Company ID of the vendor model = 0x04AA

addr : the destination address = unicast_addr

opcode : the opcode message to send = Vendor Heater Set Unacknowledged = 0xDA

payload : the Heater Set message payload

Soit

==> mesh models msg send-vnd <feature_idx> 0x0019 0x04AA <unicast_addr> 0xDA <payload>

Commande avec acquittement attendu (sur une Unicast Address précise) :

==> mesh models msg send-vnd-rsp <elem id> <model id> <company id> <addr> <opcode> <opcode_rsp> [payload]

Avec

elem id : the element index of the model instance (source) = feature_idx

model id : the model id sender (source) = Heater Client = 0x0019

company id: the Company ID of the vendor model = 0x04AA

addr : the destination address = unicast_addr

opcode : the opcode message to send = Vendor Heater Set = 0xD9

opcode_rsp: the opcode waited for response = Vendor Heater Status = 0xDC

payload : the Heater Set message payload

Soit

==> mesh models msg send-vnd-rsp <feature_idx> 0x0019 0x04AA <unicast_addr> 0xDA 0xDC <payload>

Valeur du payload

La valeur de payload est décrite ici Heater Set message, ce qui donne :

<payload> = <Mode><TID>[Duration][Reg_Type][Reg_value]

Mode est un octet (à écrire en hexadécimal) composé des champs de bits suivants :

Setting (bits [0..3]) : Current setting

Load shedding (bit[4]) : Load shedding running flag

Derogation (bit[5]) : Derogation running flag

Program (bit[6]) : Program running flag

NC (bit[7]) : Reserved

Les paramètres optionels Duration, Reg_type et Reg_value sont décrits dans Heater parameters Values.

Attention

Rappel : la valeur de TID doit être différente entre 2 messages consécutifs de la même source, sinon le message est ignoré.

Le principe du délestage

Supposons que la fonction soit dans un état donné, défini par l’utilisateur via l’App mobile :

Setting        = <any>
Load shedding  = 0
Derogation     = 0
Program        = 0
Duration       = <any>
Reg_type       = <any>
Reg_value      = <any>

Le GEMAX souhaite appliquer un délestage à cette fonction en indiquant une nouvelle valeur de consigne ( définie par Setting, eventuellement adjointe de Reg_type et Reg_value), alors la nouvelle commande contiendra :

Setting        = <Load shedding setting>
Load shedding  = 1
Derogation     = 0
Program        = 0
Duration       = <Load shedding duration>
Reg_type       = <Load shedding Reg_type>
Reg_value      = <Load shedding Reg_value>

Les nouvelles valeurs seront appliquées jusqu’à :

ce qu’une commande de fin de délestage soit reçue
l’expiration du timer interne si Load shedding duration > 0

Alors la fonction retournera dans son état précédent (qui aura été sauvegardé).

Si une nouvelle commande de délestage est reçue, elle remplace la précédente.

La commande de fin de délestage a le format suivant :

Setting        = RESTORE (0xF)
Load shedding  = 0
Derogation     = 0
Program        = 0
Duration       = <ignored>
Reg_type       = <ignored>
Reg_value      = <ignored>

Soit Mode = 0x0F :

==> mesh models msg send-vnd <feature_idx> 0x0019 0x04AA <unicast_addr> 0xDA 0F<TID>

Pilotage d’un module Fil Pilote

Les fonctions Fil Pilote 4 et 6 ordres sont pilotables avec les Setting suivants :

Value	Description
0	COMFORT
1	ECO
2	NO_FROST
3	STOP
4	COMFORT_1
5	COMFORT_2

Exemples

Mise en mode COMFORT (TID=0x23) :

==> mesh models msg send-vnd <feature_idx> 0x0019 0x04AA <unicast_addr> 0xDA 0023

Mise en mode STOP (TID=0x23) :

==> mesh models msg send-vnd <feature_idx> 0x0019 0x04AA <unicast_addr> 0xDA 0323

Délestage en mode ECO pour 1 heure (60min=0x003C) (TID=0x23) :

==> mesh models msg send-vnd <feature_idx> 0x0019 0x04AA <unicast_addr> 0xDA 11233C00

Pilotage d’un module chauffe-eau

Les controleurs de chauffe par relais (Dry contact) sont pilotables avec les Setting suivants :

Value	Description
0	ON
1	ON
2	ON
3	OFF
4	ON
5	ON

Exemples

Mise en mode ON (TID=0x23) :

==> mesh models msg send-vnd <feature_idx> 0x0019 0x04AA <unicast_addr> 0xDA 0023

Mise en mode OFF (TID=0x23) :

==> mesh models msg send-vnd <feature_idx> 0x0019 0x04AA <unicast_addr> 0xDA 0323

Délestage en mode OFF pour 1 heure (60min=0x003C) (TID=0x23) :

==> mesh models msg send-vnd <feature_idx> 0x0019 0x04AA <unicast_addr> 0xDA 10233C00

Pilotage du chargeur de vehicule CEVMAX

Les controleurs de chauffe par relais (Dry contact) sont pilotables avec les Setting suivants :

Value	Description
0	0W
1	1150W
2	1380W
3	3680W
4	4830W
5	7360W

Pilotage de l’interface IR Climax

A détailler