1. Le programme client envoie une "Connection
Transcription
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!