1. Le programme client envoie une "Connection

Cedocumentdécritbrièvementcommentutiliserl’APIKNX
LeprotocoleKNX/IP
Lafigure1montrelesmessageséchangésentreunclient(enbleu)etlapasserelleKNX/IP(envert)
danslecasd’uneécriture(figureàgauche:a)etd’unelecture(figureàdroite:b)
Figure1-UtilisationduprotocoleKNXnet/IPpourl'envoid'unecommande(a)d'écriture,(b)delecture
1. Le programme client envoie une "Connection Request" pour demander une
connexion.CetterequêtecontientdeuxHPAI(HostProtocoladdressinformation)qui
sontdeuxpaires(adresseIP,numérodePort).L'adresseIPestlamêmepourlesdeux
HPAI mais les numéros de port peuvent changer. Le premier port est utilisé pour
envoyer les télégrammes "Connection_Request", "Connection_State_Request",
"Disconnect_Request", "Connection_Response", "Connection_State_Response" et
"Disconnect_Response". En résumé, ce port est utilisé gérer la connexion avec la
passerelle KNXnet/IP. Le second post est utilisé pour envoyer et recevoir les
télégrammes "Tunnelling Request" et "Tunnelling Ack" qui contiennent les données
(lescommandes)quelapasserelleKNXnet/IPdoittransformerentélégrammesKNX
etlespasserverslebusKNX.Ilestpossibled'utiliserlemêmeportdanslesdeuxHPAI
pourfairesimple.
2. Lapasserellerenvoieune"ConnectionResponse"avecun"ChannelID"quiestunidentifiant
unique de la connexion. Ce channel ID sera utilisé par les connexions : Connection State
Requests,TunnellingRequests,TunnellingAcksetDisconnectRequests
3. Une"ConnectionStateRequest"estenvoyéeavecle"ChannelID"récupéréaupoint2qu'on
vientderécupérerpourtesterlaconnexionavecce"ChannelID".
4. Réceptiond’une"ConnectionStateResponse"avecuncoded'erreur(appelé"status")"00".
5. Arrivéàcestade,laconnexionestétablie.Envoiedesdonnéesnécessairespourlaconstruction
d’un télégramme "Tunnelling Request" (envoyé à partir du deuxième port spécifié dans la
"ConnectionRequest")avecunchamps"DataService"misà0x11("Data.request").
6. Dés la réception du "Tunnelling Request", la passerelle KNXnet/IP renvoie un acquittement
("TunnellingAck")avecuncoded'erreur(appelé"status")"00"s'ilnyapaseud'erreur.
7. L'interfaceKNXnet/IPvérifienotre"TunnellingRequest"etlerenvoieaveclechamps"Data
Service"misà0x2e("Data.confirmation").
8. Leprogrammeclientcomparele"TunnellingRequest"déjàenvoyéetle"TunnellingRequest"
renvoyéeparlapasserelleKNXnet/IP.S'iln'yapasd’erreursdetransmission,leprogramme
clientenvoieunacquittement("TunnellingAck")avecuncoded'erreur(appelé"status")"00"
(zéro).
9. S’ils’agitd’unedemandedelecturedel'étatd'unactionneur,leprogrammeclientreçoitun
«télégramme»detype"TunnellingRequest"contenantladonnée
L’APIknxnet
Onseproposed’utiliserl’APIknxnet,développéeparAdrienLescourtdanslecadreduprojetEMG4B
pourgérerlacommunicationentreunprogrammeclientécritenpythonetunepasserelleKNXnet/IP.
Lesprincipauxobjetsetméthodesdelalibrairie"knxnet"sontlessuivants:
"ServiceTypeDescriptor":objeténumératifquicontientlesdifférentstypesdetélégrammespossibles
:
Typedutélégramme
ConnectionRequest
ConnectionResponse
ConnectionStateRequest
ConnectionStateResponse
DisconnectRequest
DisconnectResponse
TunnellingRequest
TunnellingAck
Nomdel'attributcorrespondant
CONNECTION_REQUEST
CONNECTION_RESPONSE
CONNECTION_STATE_REQUEST
CONNECTION_STATE_RESPONSE
DISCONNECT_REQUEST
DISCONNECT_RESPONSE
TUNNELLING_REQUEST
TUNNELLING_ACK
Lacréationd’unobjetreprésentantunfuturtélégrammeKNX,sefaitvialaméthode'create_frame'de
laclasseknxnet.Letypedutélégrammeestlepremierargumentdececonstructeur.Ilestsuivide
paramètresquidépendentdutypedetélégrammesàcréer:
a)
CONNECTION_REQUEST
attribut
description
control_endpoint
Delaforme(adresseIP,Port):utilisépourenvoyerourecevoirles
objets qui représentant des télégrammes de type Connection
Request/Response, Connection_State Request/Response et
DisconnectRequest/Response.
data_endpoint
Delaforme(adresseIP,Port):utilisépourenvoyeret/ourecevoir
les des objets représentant des télégrammes de type Tunnelling
Request/Ack
b)
CONNECTION_RESPONSE
attribut
description
channel_id
Identifiant du canal alloué par la passerelle KNX/IP pour
communiquer avec le programme client. La passerelle peut
communiquer avec plusieurs clients en même temps grâce à la
notiondecanal.
status
Statutdelaconnexion:0(zéro):OK.Sinon:messaged'erreur(voir
doc).
data_endpoint
Voir(a)
c)
CONNECTION_STATE_REQUEST
attribut
d)
description
channel_id
Voir(b)
control_endpoint
Voir(a)
CONNECTION_STATE_RESPONSE
attribut
e)
description
channel_id
Voir(b)
status
Statut de la connexion demandée par la "Connection State
Request" : 0 "Connection State Request" acceptée, message
d’erreursinon(voirdoc).
TUNNELLING_REQUEST
attribut
f)
description
dest_addr_group
L'adressedegroupedel’équipement(device)àcommander(lecture
ouécriture).
Pour créer un address group à partir d'une chaîne de caractères
utilisezcetteméthode:
dest_addr_group = knxnet.GroupAddress.from_str("x/y/z")
channel_id
Voir(b)
data
La valeur à envoyer vers la passerelle KNX/IP (commande d’un
device)ouàrecevoiràpartirdelapasserelleKNX/IP(danslecasoù
Tunnellingrequestestgénéréeparlapasserelle).Cettevaleurest
compriseentre0et255.Danslecasd’unelecture,cettevaleurn’a
pasdesignification.
data_size
Tailleduchamp"data"envoyé.
apci
Cechampspécifielanaturedelarequête:
0x0==demandedelecture(envoyéeparleclient);
0x1 == réponse à une requête précédente (cas d’un Tunnelling
request envoyée par la passerelle suite à un Tunnelling request
envoyéparleclient;
0x2==demanded'écriture(envoyéeparleclient).
data_service
Champoptionnel.Ilpeutavoirtroisvaleurspossibles:
1. Data.request (0x11) : correspond aux Tunnelling requests
envoyéesparleclientàlapasserelle
2. Data.confirmation(0x2e):correspondàunTunnellingrequest
envoyéeparlapasserelleenréponseàunTunnellingrequestde
type«Datarequest».
3. Data.response : correspond au second un Tunnelling request
envoyée par la passerelle pour répondre à une demande de
lecture(TunnellingrequestdetypeData.request)
Champoptionnel.
sequence_counter
TUNNELLING_ACK
attribut
description
channel_id
Voir(b)
status
Statutdelarequêteenvoyéedansle"TunnellingRequest".0sic’est
OK.Valeurdifférentede0,sierreur(voirdoc).
sequence_counter
Lemême"sequence_counter"dutélégramme"TunnellingRequest"
àacquitter.
g)
DISCONNECT_REQUEST
attribut
h)
description
channel_id
Voir(b)
control_endpoint
Voir(a)
DISCONNECT_RESPONSE
attribut
description
channel_id
Voir(c)
status
C'est le status de votre demande de déconnexion envoyé dans le
"DisconnectRequest".Sic'est0(zéro)c'estquetoutestbonetvotre
"DisconnectRequest"aétéaccepté.Silavaleurestdifférentede0,
alorsc'estunmessaged'erreur(voirdoc).
Exemple:pourdemanderàlapasserelledecréeruntélégrammedetype"ConnectionRequest",ilfaut
appelerlaméthodecreate_frameaveclesparamètressuivants:
conn_req_obj = knxnet.create_frame
(knxnet.ServiceTypeDescriptor.CONNECTION_REQUEST, ('0.0.0.0',0),
('0.0.0.0',0))
Lecodesuivant(incomplet)permetdedémarrerl’initialisationdelaconnexionavecunepasserelle
KNX/IP:
gateway_ip = "adresse IP da la passerelle KNXnet/IP"
gateway_port = Port sur lequel la passerelle KNXnet/IP écoute"
# -> in this example, for sake of simplicity, the two ports are the same.
data_endpoint = ('0.0.0.0', 3672)
control_enpoint = ('0.0.0.0', 3672)
# -> Socket creation
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind(('',3672))
# -> Sending Connection request
conn_req_object =
knxnet.create_frame(knxnet.ServiceTypeDescriptor.CONNECTION_REQUEST,
control_enpoint,
data_endpoint)
conn_req_dtgrm = conn_req_object.frame # -> Serializing
sock.sendto (conn_req_dtgrm, (gateway_ip, gateway_port))
# <- Receiving Connection response
data_recv, addr = sock.recvfrom(1024)
conn_resp_object = knxnet.decode_frame(data_recv)
# <- Retrieving channel_id from Connection response
conn_channel_id = conn_resp_object.channel_id
A vous de finir le reste!