DIVUS VISION API პროგრამული უზრუნველყოფა

სპეციფიკაციები

• პროდუქტი: DIVUS VISION API
• მწარმოებელი: DIVUS GmbH
• ვერსია: 1.00 REV0 1 – 20240528
• მდებარეობა: Pillhof 51, Eppan (BZ), იტალია

პროდუქტის ინფორმაცია

DIVUS VISION API არის პროგრამული უზრუნველყოფის ინსტრუმენტი, რომელიც შექმნილია DIVUS VISION სისტემებთან ინტერფეისისთვის. ის საშუალებას აძლევს მომხმარებლებს წვდომა და აკონტროლონ სისტემის სხვადასხვა ელემენტი MQTT პროტოკოლების გამოყენებით.

FAQ

კითხვა: შემიძლია გამოვიყენო DIVUS VISION API კომპიუტერის ან ავტომატიზაციის ტექნოლოგიის წინასწარი ცოდნის გარეშე?

პასუხი: სახელმძღვანელო მორგებულია მომხმარებლებისთვის, რომლებსაც აქვთ წინა ცოდნა ამ სფეროებში, რათა უზრუნველყონ API-ს ეფექტური გამოყენება.

ზოგადი ინფორმაცია

• DIVUS GmbH Pillhof 51 I-39057 Eppan (BZ) – იტალია

ოპერაციული ინსტრუქციები, სახელმძღვანელოები და პროგრამული უზრუნველყოფა დაცულია საავტორო უფლებებით. Ყველა უფლება დაცულია. კოპირება, დუბლირება, თარგმნა, თარგმნა მთლიანად ან ნაწილობრივ დაუშვებელია. გამონაკლისი ეხება პროგრამული უზრუნველყოფის სარეზერვო ასლის შექმნას პირადი სარგებლობისთვის.
სახელმძღვანელო შეიძლება შეიცვალოს გაფრთხილების გარეშე. ჩვენ ვერ მოგცემთ გარანტიას, რომ ამ დოკუმენტში და მიწოდებულ საცავის მედიაზე არსებული მონაცემები შეცდომებისა და სწორია. ყოველთვის მისასალმებელია წინადადებები გაუმჯობესებისთვის, ასევე მინიშნებები შეცდომებზე. ხელშეკრულებები ასევე ვრცელდება ამ სახელმძღვანელოს კონკრეტულ დანართებზე. აღნიშვნები ამ დოკუმენტში შეიძლება იყოს სასაქონლო ნიშნები, რომელთა გამოყენება მესამე მხარის მიერ საკუთარი მიზნებისთვის შეიძლება დაარღვიოს მათი მფლობელების უფლებები. მომხმარებლის ინსტრუქციები: გთხოვთ, წაიკითხოთ ეს სახელმძღვანელო პირველად გამოყენებამდე და შეინახეთ ის უსაფრთხო ადგილას მომავალი მითითებისთვის. სამიზნე ჯგუფი: სახელმძღვანელო დაწერილია კომპიუტერის და ავტომატიზაციის ტექნოლოგიების წინა ცოდნის მქონე მომხმარებლებისთვის.

პრეზენტაციის კონვენციები

შესავალი

ზოგადი შესავალი

ეს სახელმძღვანელო აღწერს VISION API-ს (აპლიკაციის პროგრამირების ინტერფეისი) – ინტერფეისი, რომლის საშუალებითაც შესაძლებელია VISION-ის მიმართვა და კონტროლი გარე სისტემებიდან.
პრაქტიკული თვალსაზრისით, ეს ნიშნავს, რომ თქვენ შეგიძლიათ გამოიყენოთ ისეთი სისტემები, როგორიცაა

• MQTT Explorer (https://www.microsoft.com/store/… – ტესტირებისთვის),
• სახლის ასისტენტი (https://www.home-assistant.io/) ან
• კვანძი-წითელი (https://nodered.org/)

VISION-ის მიერ მართული ელემენტების გასაკონტროლებლად ან მათი სტატუსის წაკითხვისთვის. წვდომა და კომუნიკაცია ხდება MQTT პროტოკოლის მეშვეობით, რომელიც იყენებს ეგრეთ წოდებულ თემებს ცალკეული ფუნქციების ან ფუნქციების ნაკრების განსახილველად ან მათში ცვლილებების შესახებ ინფორმირებისთვის. ამ მიზნით გამოიყენება MQTT სერვერი (ბროკერი), რომელიც ახორციელებს უსაფრთხოებას და მონაწილეთათვის შეტყობინებების მართვას/გავრცელებას. ამ შემთხვევაში, MQTT სერვერი მდებარეობს პირდაპირ DIVUS KNX IQ-ზე და სპეციალურად არის კონფიგურირებული ამ მიზნით. მიუხედავად იმისა, რომ VISION API ასევე შეიძლება გამოყენებულ იქნას პროგრამირების ცოდნის გარეშე, ეს ფუნქცია შესაფერისია მოწინავე მომხმარებლებისთვის.

წინაპირობები

როგორც VISION სახელმძღვანელოშია ახსნილი, API მომხმარებელი ნაგულისხმევად ჯერ უნდა იყოს გააქტიურებული, რათა შეძლოს მისი გამოყენება, API წვდომა მუშაობს მხოლოდ Api მომხმარებლების ავტორიზაციის მონაცემების გამოყენებით. რაც შეეხება მომხმარებლის უფლებებს, ამ ფუნქციის აქტივაციის კონფიგურაცია შესაძლებელია ყველა ან ცალკეულ ელემენტზე. იხილეთ თავ.0. რა თქმა უნდა, თქვენ ასევე გჭირდებათ VISION პროექტი, რომელშიც ის ელემენტები, რომელთა კონტროლიც გსურთ გარედან, სრულად არის კონფიგურირებული და მათთან კავშირი წარმატებით არის გამოცდილი. იმისათვის, რომ შეძლოთ ცალკეული ელემენტების API-ს მეშვეობით მიმართვა, მათი ელემენტის ID უნდა იყოს ცნობილი: ეს ნაჩვენებია ელემენტის პარამეტრების ფორმის ბოლოში.

უსაფრთხოება

უსაფრთხოების მიზეზების გამო, API წვდომა შესაძლებელია მხოლოდ ადგილობრივად (ანუ არა ღრუბლის საშუალებით). ამიტომ უსაფრთხოების რისკი API წვდომის გააქტიურებისას დაბალია. მიუხედავად ამისა, უსაფრთხოებასთან დაკავშირებული ელემენტები არ უნდა იყოს ჩართული ან აშკარად უარყოფილი API წვდომისთვის.

MQTT და მისი პირობები - მოკლე ახსნა

• MQTT-ში, ყველა შეტყობინების ცენტრალიზებული მართვისა და განაწილების როლი არის ბროკერის როლი. მიუხედავად იმისა, რომ MQTT სერვერი და MQTT ბროკერი არ არის სინონიმები (სერვერი არის უფრო ფართო ტერმინი იმ როლისთვის, რომელიც MQTT კლიენტებსაც შეუძლიათ), ამ სახელმძღვანელოში ბროკერი ყოველთვის იგულისხმება, როდესაც MQTT სერვერი არის ნახსენები. თავად DIVUS KNX IQ ასრულებს MQTT ბროკერის / MQTT სერვერის როლს ამ სახელმძღვანელოს კონტექსტში.
• MQTT სერვერი იყენებს ეგრეთ წოდებულ თემებს: იერარქიულ სტრუქტურას, რომლითაც ხდება მონაცემების კატეგორიზაცია, მართვა და გამოქვეყნება.
• გამოცემას უპირველეს მიზნად ისახავს, ​​რომ მონაცემები ხელმისაწვდომი გახდეს სხვა მონაწილეებისთვის თემების საშუალებით. თუ გსურთ შეცვალოთ მნიშვნელობა, წერთ სასურველ თემას სასურველ მნიშვნელობის ცვლილებასთან ერთად, ასევე გამოქვეყნების მოქმედების გამოყენებით. სამიზნე მოწყობილობა ან MQTT სერვერი კითხულობს სასურველ ცვლილებას, რომელიც გავლენას ახდენს მასზე და შესაბამისად იღებს მას. იმის შესამოწმებლად, რომ ცვლილება იქნა გამოყენებული, შეგიძლიათ გადახედოთ რეალურ დროში გამოწერილ თემას, რათა ნახოთ, აისახება თუ არა ცვლილება იქ – თუ ყველაფერი კარგად გამოვიდა.
• კლიენტები ირჩევენ მათთვის საინტერესო თემებს: ამას ჰქვია გამოწერა. ყოველ ჯერზე, როცა მნიშვნელობა იცვლება თემის ქვემოთ/ქვემოთ, ყველა გამოწერილი კლიენტი ეცნობება - ე.ი. მკაფიოდ კითხვის გარეშე, შეიცვალა თუ არა რაიმე ან რა არის მიმდინარე მნიშვნელობა.
• თქვენ შეგიძლიათ გახსნათ (ან მიმართოთ) ცალკე საკომუნიკაციო არხს MQTT სერვერთან, თემაში ნებისმიერი უნიკალური სტრიქონის შეყვანით, სახელწოდებით client_id. მნიშვნელობების დასამუშავებლად თემაში უნდა იყოს გამოყენებული client_id. ეს ემსახურება თითოეული ცვლილების წარმოშობის იდენტიფიცირებას, ეხმარება შეცდომებს და არ მოქმედებს სხვა კლიენტებზე, რადგან სერვერის შესაბამისი პასუხები, შეცდომის კოდებისა და შეტყობინებების ჩათვლით, ასევე აღწევს თემას მხოლოდ იმავე client_id-ით (და ამდენად მხოლოდ ეს კლიენტი). client_id არის სიმბოლოების უნიკალური სტრიქონი, რომელიც შედგება სიმბოლოების 0-9, az, AZ, „-“, „_“ ნებისმიერი კომბინაციისგან.
• ზოგადად, DIVUS KNX IQ MQTT სერვერის გამოწერის თემები შეიცავს საკვანძო სიტყვის სტატუსს, ხოლო გამოქვეყნების თემები შეიცავს საკვანძო სიტყვის მოთხოვნას. სტატუსის მქონე პირები ავტომატურად განახლდებიან, როგორც კი გარე მნიშვნელობის ცვლილება მოხდება, ან როგორც კი ღირებულების ცვლილება მოითხოვება თავად კლიენტმა გამოქვეყნების საშუალებით და წარმატებით იქნა გამოყენებული. გამოქვეყნებისთვის განკუთვნილი პირობა იყოფა ტიპის (მოთხოვნა/)get და ტიპის (მოთხოვნა/) ნაკრები.
• ღირებულების ცვლილებები და სხვა არჩევითი პარამეტრები ემატება თემას ე.წ. ცალკეული ელემენტების პარამეტრები (ელემენტის ID, სახელი, ტიპი, ფუნქციები)

მთავარი განსხვავება MQTT და კლასიკურ კლიენტ-სერვერის მოდელს შორის, სადაც კლიენტი ითხოვს და შემდეგ ცვლის მონაცემებს, ორიენტირებულია გამოწერისა და გამოქვეყნების ცნებებზე. მონაწილეებს შეუძლიათ გამოაქვეყნონ მონაცემები, გახადონ ისინი ხელმისაწვდომი სხვებისთვის, ვისაც დაინტერესების შემთხვევაში შეუძლია გამოიწეროს იგი. ეს არქიტექტურა შესაძლებელს ხდის მონაცემთა გაცვლის მინიმუმამდე შემცირებას და ყველა დაინტერესებული მხარის განახლებას. მეტი დეტალების შესახებ აქ: და სპეციალური პარამეტრები (uuid, ფილტრები) გამოიყენება აქ. მიუხედავად იმისა, რომ არსებობს რამდენიმე ვარიანტი, ამ სახელმძღვანელოში დატვირთვა ნაჩვენებია ფორმატირებული, როგორც JSON. JSON იყენებს ფრჩხილებსა და მძიმეებს ნებისმიერი სტრუქტურის მონაცემების წარმოსადგენად და ამით ამცირებს გადასაცემი მონაცემთა პაკეტების ზომას. დამატებითი დეტალები დატვირთვის შესახებ შეგიძლიათ იხილოთ მოგვიანებით სახელმძღვანელოში.

• სპეციალური მიზნებისათვის შესაძლებელია გაფილტვრა ფუნქციის ტიპის მიხედვით, მაგ. მიმართოს მხოლოდ ჩართვა/გამორთვის ანუ 1-ბიტიანი გადამრთველები. ამ მიზნით გამოიყენება დატვირთვის ფილტრების პარამეტრი. ფილტრაცია ამჟამად შესაძლებელია მხოლოდ ფუნქციის ტიპის მიხედვით.
• ცალკეული ელემენტების დასაკავშირებლად საჭიროა მათი ელემენტის ID. ეს შეგიძლიათ იხილოთ VISION-ში ელემენტის თვისებების მენიუში, ან ასევე შეიძლება წაიკითხოთ უშუალოდ მონაცემებიდან, რომლებიც ნაჩვენებია MQTT Explorer-ის ზოგადი გამოწერის ყველა ხელმისაწვდომი ელემენტის წინ (აქ ელემენტები ჩამოთვლილია ანბანურად ელემენტის ID-ით).

კონფიგურაცია API წვდომისთვის

API მომხმარებლის წვდომისთვის ხედვის კონფიგურაცია

VISION-ში, როგორც ადმინისტრატორი, გადადით კონფიგურაციაზე - მომხმარებლის/API წვდომის მენეჯმენტი, დააწკაპუნეთ Users/API წვდომაზე და მარჯვენა ღილაკით დააწკაპუნეთ API User-ზე (ან დააჭირეთ ხანგრძლივად) რედაქტირების ფანჯრის გასახსნელად. აქ ნახავთ ამ პარამეტრებს და მონაცემებს

• ჩართვა (მონიშვნის ველი)
  • მომხმარებელი პირველად აქ არის ჩართული. ნაგულისხმევი გამორთულია
• მომხმარებლის სახელი
  • ეს სტრიქონი საჭიროა API-ით წვდომისთვის – დააკოპირეთ იგი აქედან
• პაროლი
  • ეს სტრიქონი საჭიროა API-ით წვდომისთვის – დააკოპირეთ იგი აქედან
• ნებართვები
  • აქ შეიძლება განისაზღვროს VISION ელემენტების მნიშვნელობების წაკითხვისა და ჩაწერის ნაგულისხმევი უფლებები, ანუ ის, რაც აქ არის განსაზღვრული, ვრცელდება ყველა არსებულ და მომავალ ელემენტზე. თუ გსურთ მხოლოდ ცალკეულ ელემენტებზე წვდომის დაშვება, არ უნდა შეცვალოთ ეს ნაგულისხმევი უფლებები

ნებართვები ინდივიდუალურ ელემენტებზე

რეკომენდირებულია არ მიანიჭოთ API წვდომა მთელ პროექტზე, არამედ მხოლოდ სასურველ ელემენტებზე. გააგრძელეთ შემდეგნაირად

1. შედით VISION-ში, როგორც ადმინისტრატორი
2. აირჩიეთ სასურველი ელემენტი და გახსენით მისი პარამეტრების მენიუ (დააწკაპუნეთ მაუსის მარჯვენა ღილაკით ან დააჭირეთ ღილაკს, შემდეგ პარამეტრები)
3. მენიუს ჩანაწერში General – Permissions, გააქტიურეთ „Override default permissions“ და შემდეგ გადადით ქვეპუნქტზე Permissions, რომელიც აჩვენებს ნებართვების მატრიცას.
4. გაააქტიურეთ კონტროლის ნებართვა აქ, რაც ასევე საშუალებას აძლევს view ნებართვა პირდაპირ. თუ გსურთ მხოლოდ მონაცემების წაკითხვა API წვდომის საშუალებით, საკმარისია ჩართოთ view ნებართვა.
5. გაიმეორეთ იგივე პროცედურა ყველა ელემენტისთვის, რომელზეც გსურთ წვდომა

კავშირი MQTT-ის საშუალებით

შესავალი

როგორც ყოფილიampჩვენ ვაჩვენებთ წვდომას DIVUS KNX IQ-ის MQTT API-ით შედარებით მარტივი, უფასო პროგრამული უზრუნველყოფით, სახელწოდებით MQTT Explorer (იხ. თავ. 1.1), რომელიც ხელმისაწვდომია Windows-ისთვის, Mac-ისთვის და Linux-ისთვის. იგულისხმება ძირითადი ცოდნა და გამოცდილება MQTT-თან დაკავშირებით.

კავშირისთვის საჭირო მონაცემები

როგორც უკვე აღვნიშნეთ (იხ. სექცია 2.1), საჭიროა API მომხმარებლის მომხმარებლის სახელი და პაროლი. აქ არის დასრულდაview ყველა მონაცემიდან, რომელიც უნდა შეგროვდეს კავშირის დამყარებამდე:

• მომხმარებლის სახელი წაიკითხეთ API მომხმარებლის დეტალების გვერდზე
• პაროლი წაიკითხეთ API მომხმარებლის დეტალების გვერდზე
• IP მისამართი წაიკითხეთ გამშვების პარამეტრებში ზოგადი - ქსელი - Ethernet (ან სინქრონიზატორის საშუალებით)
• პორტი 8884 (ეს პორტი დაცულია ამ მიზნით)

პირველი კავშირი MQTT EXPLORER-თან და GENERAL SUBSCRIBE-თან

ჩვეულებრივ, MQTT განასხვავებს გამოწერის და გამოქვეყნების აქტივობებს. MQTT Explorer ამარტივებს ამას ყველა ხელმისაწვდომი თემის ავტომატურად გამოწერით (თემა #) პირველი კავშირის დამყარებისას. შედეგად, ხე, რომელიც მივყავართ ყველა ხელმისაწვდომ ელემენტამდე (ანუ API მომხმარებლის წვდომა მინიჭებული) შეიძლება ნახოთ პირდაპირ MQTT Explorer ფანჯრის მარცხენა მხარეს წარმატებული კავშირის შემდეგ. შემდგომი გამოწერის თემების შესაყვანად ან # უფრო კონკრეტული თემით ჩასანაცვლებლად, გადადით გაფართოებულზე კავშირის ფანჯარაში. ზედა მარჯვენა კუთხეში ნაჩვენები თემა ასე გამოიყურება:

სადაც 7f4x0607849x444xxx256573x3x9x983 არის API მომხმარებლის სახელი და objects_list შეიცავს ყველა ხელმისაწვდომ ელემენტს. ეს თემა ყოველთვის განახლებულია, ანუ მნიშვნელობის ნებისმიერი ცვლილება აისახება იქ რეალურ დროში. თუ გსურთ მხოლოდ ცალკეული ელემენტების გამოწერა, შეიყვანეთ სასურველი ელემენტის ელემენტის ID-ს შემდეგ objects_list/.

შენიშვნა: ამ ტიპის გამოწერა დაახლოებით შეესაბამება KNX გამოხმაურების მისამართების ლოგიკას; ის აჩვენებს ელემენტების მიმდინარე სტატუსს და შეიძლება გამოყენებულ იქნას იმის შესამოწმებლად, წარმატებით იქნა თუ არა გამოყენებული სასურველი ცვლილებები. თუ გსურთ მხოლოდ მონაცემების წაკითხვა, მაგრამ არა შეცვლა, ამ ტიპის გამოწერა საკმარისია.

ერთი მარტივი ელემენტი ასე გამოიყურება JSON ნოტაციაში

შენიშვნა: ყველა მნიშვნელობას აქვს ზემოთ ნაჩვენები სინტაქსი, მაგ. { „მნიშვნელობა“: „1“ }, როგორც გამოწერის თემების გამოსავალი, ხოლო მნიშვნელობა იწერება პირდაპირ დატვირთვაში მნიშვნელობის შესაცვლელად (ანუ თემების გამოქვეყნებისთვის) – ფრჩხილები და "მნიშვნელობა" გამოტოვებულია მაგ. "onoff": "1".

გაფართოებული ბრძანებები

შესავალი

ზოგადად არის 3 სახის თემა:

1. გამოიწერეთ თემ(ები) ხელმისაწვდომი ელემენტების სანახავად და რეალურ დროში ღირებულების ცვლილებების მისაღებად
2. გამოიწერეთ თემები, რომ მიიღოთ პასუხები (კლიენტები ) გამოაქვეყნეთ მოთხოვნები
3. გამოაქვეყნეთ თემ(ებ)ი, რომ მიიღოთ ან დააყენოთ ელემენტები მათი მნიშვნელობებით

ჩვენ მოგვიანებით მივმართავთ ამ სახეობებს აქ ნაჩვენები ნუმერაციის გამოყენებით (მაგ. 1, 2, 3 ტიპის თემები). დამატებითი დეტალები შემდეგ განყოფილებებში და თავში. 4.2.

გამოიწერეთ თემები, რომ ნახოთ ხელმისაწვდომი ელემენტები და მიიღოთ რეალურ დროში ღირებულების ცვლილებები

ესენი უკვე აღწერილია

გამოიწერეთ თემები, რომ მიიღოთ პასუხი კლიენტის გამოქვეყნების მოთხოვნებზე

ამ ტიპის თემები არჩევითია. ის იძლევა საშუალებას

• გახსენით უნიკალური საკომუნიკაციო არხი MQTT სერვერთან თვითნებური client_id-ის გამოყენებით. მეტი ამის შესახებ თავში. 4.2.2
• მიიღეთ გამოქვეყნების მოთხოვნების შედეგი შესაბამის გამოწერის თემაზე: წარმატება ან წარუმატებლობა შეცდომის კოდით და შეტყობინებებით.

არსებობს სხვადასხვა თემები პასუხების მისაღებად ან გამოქვეყნების ბრძანებების დასაყენებლად. შესაბამისი განსხვავება როგორც კი გაასწორებთ სისტემისთვის საჭირო თემებს, შეგიძლიათ გადაწყვიტოთ ამ ნაბიჯის ამოღება და პირდაპირ გამოიყენოთ თემების გამოქვეყნება.

 გამოაქვეყნეთ თემები, რათა მიიღოთ ან დააყენოთ ელემენტები მათი ღირებულებებით

ეს თემები იყენებენ გამოწერის მსგავს გზას – ერთადერთი ცვლილება არის სიტყვა „მოთხოვნა“ გამოწერისთვის გამოყენებული „სტატუსის“ ნაცვლად. სრული თემის ბილიკები ნაჩვენებია შემდეგ თავში. 4.2.2\ მიიღეთ თემა ითხოვს MQTT სერვერის ელემენტების და მნიშვნელობების წაკითხვას. ტვირთამწეობა შეიძლება გამოყენებულ იქნას ელემენტების ფუნქციის ტიპის მიხედვით გასაფილტრად. დაყენებული თემა მოითხოვს ელემენტის ზოგიერთი ნაწილის შეცვლას, როგორც ეს დეტალურადაა აღწერილი მის დატვირთვაში.

პრეფიქსი ბრძანებებისა და შესაბამისი პასუხებისთვის

 მოკლე ახსნა

ყველა ბრძანებას, რომელიც იგზავნება MQTT სერვერზე, აქვს საერთო საწყისი ნაწილი, კერძოდ:

დეტალური განმარტება

რეალურ დროში თემებს (ტიპი 1) ექნება ზოგადი პრეფიქსი (იხ. ზემოთ), შემდეგ კი

or

კომპლექტის ბრძანებებისთვის, payload აშკარად თამაშობს მთავარ როლს, რადგან ის შეიცავს სასურველ ცვლილებებს (ანუ ელემენტის ფუნქციების შეცვლილ მნიშვნელობებს). გაფრთხილება: არასოდეს გამოიყენოთ შენარჩუნების ვარიანტი თქვენი ტიპის 3 ბრძანებებში, რადგან ამან შეიძლება გამოიწვიოს პრობლემები KNX მხარეს.

EXAMPLE: გამოქვეყნება ერთი ელემენტის ღირებულებ(ებ)ის შესაცვლელად

უმარტივესი შემთხვევაა გსურდეთ შეცვალოთ ერთი ელემენტის მნიშვნელობა, რომელიც ნაჩვენებია ზოგადი გამოწერით.
ზოგადად რომ ვთქვათ, VISION-ის ფუნქციის შეცვლა/გადართვა MQTT-ის საშუალებით შედგება 3 საფეხურისაგან, რომელთაგან ყველა არ არის აბსოლუტურად აუცილებელი, მაგრამ მაინც გირჩევთ მათ შესრულებას, როგორც აღწერილია.

1. თემა, რომელიც შეიცავს ფუნქციას, რომლის რედაქტირებაც გვინდა, გამოწერილია მორგებული client_id-ის გამოყენებით
2. რედაქტირების თემა გამოქვეყნებულია დატვირთვასთან ერთად სასურველი ცვლილებებით 1-ში არჩეული client_id-ის გამოყენებით.
3. ამის შესამოწმებლად შეგიძლიათ იხილოთ პასუხი თემაში (1.) – ე.ი. მუშაობდა თუ არა (2.).
4. ზოგად გამოწერაში, სადაც ყველა მნიშვნელობა განახლდება ცვლილებების განხორციელებისას, შეგიძლიათ იხილოთ სასურველი მნიშვნელობის ცვლილება(ებ), თუ ყველაფერი კარგად გამოვიდა.

ამის გასაკეთებელი ნაბიჯებია:

1. აირჩიეთ client_id მაგ. „Divus“ და ჩასვით API მომხმარებლის სახელის შემდეგ გზაზე
   ეს არის სრული თემა MQTT სერვერთან საკუთარი საკომუნიკაციო არხის გამოსაწერად. ეს ეუბნება სერვერს, თუ სად ელით პასუხებს ცვლილებებზე, რომელთა გაგზავნას აპირებთ. ყურადღება მიაქციეთ სტატუსის/კომპლექტის ნაწილს, რომელიც განსაზღვრავს a. რომ ეს არის გამოწერის თემა და ბ. რომ მიიღებს პასუხებს ტიპის ბრძანებების დაყენებაზე.
2. გამოქვეყნების თემა იგივე იქნება, გარდა სტატუსის მოთხოვნის საკვანძო სიტყვების გადართვისა
3. რისგანაც უნდა შედგებოდეს ცვლილება, წერია payload-ში. აქ არის რამდენიმე ყოფილიamples.
   • ელემენტის გამორთვა, რომელსაც აქვს ჩართვა/გამორთვის ფუნქცია (1 ბიტი):
   • ელემენტის ჩართვა, რომელსაც აქვს ჩართვა/გამორთვის ფუნქცია (1 ბიტი). გარდა ამისა, თუ რამდენიმე ასეთი ბრძანება იწყება ერთი და იმავე კლიენტიდან, uuid პარამეტრი („უნიკალური ID“, ჩვეულებრივ არის 128-ბიტიანი სტრიქონი, ფორმატირებული 8-4-4-4-12 ციფრული თექვსმეტობით) შეიძლება გამოყენებულ იქნას მინიჭებისთვის. პასუხი შესაბამის შეკითხვაზე, რადგან ეს პარამეტრი - თუ ეს არის შეკითხვაში - ასევე შეგიძლიათ იპოვოთ პასუხში.
   • დიმერის სიკაშკაშის ჩართვა და დაყენება 50%-მდე
   • ზემოთ ნაჩვენები და გამოწერილი თემის პასუხი (ზუსტად მისი დატვირთვა) არის შემდეგ, მაგampლე.
     ზემოთ მოყვანილი პასუხი არის ყოფილიample სწორი დატვირთვის შემთხვევაში, თუმცა ელემენტს არ აქვს დაბინდვის ფუნქცია. თუ არსებობს უფრო სერიოზული პრობლემები, რაც იწვევს დატვირთვის არასწორ ინტერპრეტაციას, პასუხი ასე გამოიყურება (მაგ.):
     შეცდომის კოდებისა და შეტყობინებების ახსნისთვის, მაგრამ ზოგადად, როგორც http-ისთვის, 200 კოდი დადებითი პასუხია, ხოლო 400 უარყოფითი.

EXAMPLE: PUBLISH მრავალი ელემენტის ღირებულებების შესაცვლელად

პროცედურა მსგავსია ადრე ნაჩვენები ერთი ელემენტის შესაცვლელად. განსხვავება ისაა, რომ თემებიდან გამოტოვებთ element_id-ს და შემდეგ მიუთითებთ element_id-ების კომპლექტს payload-ის შიგნით არსებული მონაცემების წინ. იხილეთ სინტაქსი და სტრუქტურა ქვემოთ.

გაფილტვრა ფუნქციის მიხედვით კითხვებში

ფილტრების პარამეტრი ტვირთის დატვირთვაში იძლევა მხოლოდ ელემენტის სასურველი ფუნქციის (ფუნქციების) მიმართვის საშუალებას. ჩამრთველის ან დიმერის ჩართვა/გამორთვის ფუნქციას ეწოდება "ჩართვა", მაგample, და შესაბამისი ფილტრი განისაზღვრება ამ გზით:

პასუხი მაშინ ასე გამოიყურება, მაგალითადample

კვადრატული ფრჩხილი მიუთითებს, რომ თქვენ ასევე შეგიძლიათ გაფილტროთ რამდენიმე ფუნქციით, მაგ

იწვევს ასეთ პასუხს:

დანართი

შეცდომების კოდები

შეცდომები MQTT კომუნიკაციაში იწვევს ციფრულ კოდს. ქვემოთ მოცემული ცხრილი ხელს უწყობს მის დაშლას.

ტვირთის დატვირთვის პარამეტრები

დატვირთვა მხარს უჭერს სხვადასხვა პარამეტრებს კონტექსტიდან გამომდინარე. ქვემოთ მოყვანილი ცხრილი გვიჩვენებს, თუ რომელი პარამეტრი შეიძლება იყოს რომელ თემებში

ვერსიის შენიშვნები

• 1.00 VERSION

სიახლე:

• პირველი გამოცემა

დოკუმენტები / რესურსები

	DIVUS VISION API პროგრამული უზრუნველყოფა [pdf] მომხმარებლის სახელმძღვანელო VISION API პროგრამული უზრუნველყოფა, API პროგრამული უზრუნველყოფა, პროგრამული უზრუნველყოფა
	DIVUS Vision API პროგრამული უზრუნველყოფა [pdf] მომხმარებლის სახელმძღვანელო Vision API Software, Vision, API Software, Software

ცნობები

• მომხმარებლის სახელმძღვანელო