Technische Alternative: C.M.I. - Control and Monitoring Interface

Heimgeist · 2. November 2020 um 09:45

Hallo Paresy,

ich habe mir vor ein paar Tagen eine X2 Steuerung von Technische Alternative gekauft.
In Deinem Post #119 vom 15.06.20 schreibst Du, dass die neuen API V5 Funktionen in Symcon 5.5 integriert sind.
Ich benötige in Symcon Werte aus Funktionen der Tapps2 Programme. Im C.M.I. sind diese verfügbar, wenn ich die entsprechende Funktionswerte in Tapps2 für das Logging freigebe.

Über die CMI API kann ich sie auch abfragen (jsonparam = La, Ld). Allerdings komme ich nicht über die Symcon TA Instanz an diese Werte. Wenn ich die Symcon Instanz Konfiguration und API Beschreibung vergleiche, fehlen meiner Meinung nach die Parameter M, AM, AK, La, Ld.

Sind diese noch nicht in Symcon 5.5 implementiert?

kabo63 · 2. November 2020 um 21:48

Hm…das mit CAN-EZ3(Gateway/Instanz) klappt nicht so richtig, könnte aber auch(unbekanntes?) Autorisierungsproblem sein…eine Idee? Gruß, kabo63.

Heimgeist · 3. November 2020 um 07:32

Bist Du sicher, dass Du die passende Instanz für Dein Gerät hast?
Das CAN-EZ3 https://www.ta.co.at/x2-energiemanagement/can-ez3/ meldet sich doch bestimmt nicht mit KEIL.com wie in Deiner Fehlermeldung.

kabo63 · 3. November 2020 um 08:47

…Hm, ganz so „grün“ hinter den Ohren bin ich hoffentlich nicht *g - oder sieht die Instanz(Anhang) nicht so aus, wie diese solte?
Gruß, kabo63.

paresy · 3. November 2020 um 18:59

@Heimgeist: Magst du mal im Debug vom I/O schauen was wirklich angefragt wird? Denn eigentlich sollte bei den x2 diese beiden Dinge auch abgefragt werden.
@kabo63: Ich vermute du das Username/Passwort im I/O eingetragen?

paresy

kabo63 · 4. November 2020 um 08:38

ja - allerdings erhalte ich die gleiche Meldung, wenn ich nix eintrage…
kabo63.

Heimgeist · 4. November 2020 um 09:12

Wenn ich im CMI Webinterface bei der Nutzername/Passwort Eingabe auf den Button Abbrechen klicke, bekomme ich die Fehlermeldung mit www.keil.com. Sorry für Post #123.:o


Error 401 - Unauthorized Access
You are not authorized to access this server.

Keil Embedded WEB Server V2.20, 2019
www.keil.com - Embedded Development Tools

Da die API auf diesem Webinterface gehostet wird, ist vermutlich Account/Passwort in Symcon nicht identisch wie im CMI unter -> Einstellungen -> Passwörter. ???

Heimgeist · 4. November 2020 um 09:55

Auf die Idee in die Debug Anzeige des WWW Reader zu schauen hätte ich selber kommen sollen.

Ich habe mich daraufhin ein bisschen mit CMI_JSON_API_V5.pdf (265 KB) beschäftig und dort einen Bug gefunden. Ein Ticket an TA habe ich bereits eröffnet aber noch keine Rückmeldung. Folgendes Problem habe ich an TA gemeldet:

Guten Tag,

wenn ich folgenden Request an die CMI JSON API absetze:

http://192.168.32.19/INCLUDE/api.cgi?jsonnode=3&jsonparam=I,O,D,Sg,Sd,St,Ss,La,Ld

müssten in der JSON Antwort ja alle angefragten Parameter Objekte vorhanden sein.
Allerdings bekomme ich nur die Objekte bis „Sun“ -> Ss.
„Logging Analog“ -> La und „Logging Digital“ -> Ld fehlen in der JSON Response…

Wenn ich Parameter weglasse (z.B. Sd, St, und Ss):

http://192.168.32.19/INCLUDE/api.cgi?jsonnode=3&jsonparam=I,O,D,Sg,La,Ld

Jetzt bekomme ich in der JSON Response alle gewünschten Parameter Objekte.

Ist dies ein Bug in der API oder gibt es eine Limitierung der Objekte?

Ich finde in der API Dokumentation unter 5.3.2 allerdings nur einen Hinweis auf „max. 16 value/parameter“

Was ist genau damit gemeint?

Meine Meinung nach ist die Implementierung der CMI API in Symcon nicht optimal gelöst.
Ich hätte folgende Kritik und Verbesserungspunkte

Ich habe durch Ausprobieren herausgefunden, dass die Stellung der Schalter in der Instanzkonfiguration (gelb) keinen Einfluss auf den Anfrageparameter hat. Laut Log wird immer der komplette Parametersatz jsonparam=I,O,D,Sg,Sd,St,Ss,La,Ld angefragt.

Die Angabe des Gerätes erschließt sich mir nicht direkt. Ich vermute, dass ihr dann intern andere Parameter in jsonparam einsetzt.

Ich würde folgende Änderungen vorschlagen:

Die Schalter in der Instanzkonfiguration sollten sich an den API Parametern (5.3.2) orientieren:

() I - Inputs
() O - Outputs
() D - DL Inputs
() Sg - Sytem Values
…
…
() La - Analog Logging
() Ld - Digital Logging

Nur wenn der Schalter gesetzt wird, sollte der zugehörige Parameter bei jsonparam=x,y,z eingefügt werden. In diesem Fall würde der vermeintliche Bug der API auch nicht zum tragen kommen, da nur die Objekte bei der API angefragt werden, die am Ende auch gebraucht und ausgewertet werden.

Die Geräte Angabe (rot) ist eigentlich überflüssig.

Man könnte jetzt natürlich einen Filter implementieren, welcher nur die Parameter angezeigt, welche für das entsprechende Gerät auch möglich sind. Da gibt es aber natürlich auch viele Variationen zu beachten.

Ich habe z.B. eine UVR610 mit Modbus statt M-Bus. Diese unterstützt den Parameter AM=Modbus aber nicht M=M-Bus.

Daher würde ich die Auswahl der passenden Parameter in die Hände der User legen und auf die API Dokumentation verweisen.

paresy · 4. November 2020 um 10:07

Aktuell ist es so, dass wir alles anfragen, was das Gerät kann - jedoch nur das in Variablen schreiben, was du „aktiviert“ hast. Du hast recht, dass man dies sicherlich optimieren könnte.

paresy

Heimgeist · 4. November 2020 um 10:32

Hallo Paresy,

vielen Dank für die schnelle Rückmeldung. Dann hat sich das ja doch bestätigt, was ich mir zusammengereimt habe.

Wie ist denn Deine Einschätzung bzgl. eines Zeitplans für eine Änderung auf Symcon Instanz Seite?

Ich denke TA kann die API nur in einer neuen Firmware fixen, da diese integraler Bestandteil der C.M.I. ist.
Ich habe die Befürchtung, dass dies dauert.

Leider kommt man an so tolle Sachen wie z.B. die Daten der Wärmemengenzähler Funktion nur über „Analog Logging“, welche aber momentan von der API nicht geliefert werden, wenn zu viele (nicht benötigte) Objekte angefragt werden.

Würde es sich lohnen dafür ein Modul zu schreiben oder seit Ihr schneller?

kabo63 · 4. November 2020 um 11:09

huch, aber genau um diese analogen Werte(ATON) geht es mir auch…momentan kann ich mir immer nur für einen begrenzten Zeitraum über das TA-Weblogging diese Werte anzeigen lassen - theoretisch bis zu 40(!) Variablen, wovon ich 5 ausgewählt habe, aber nur 2 standartmäßig anzeigen lasse - siehe Anhänge…
Scheinbar ist aber mein Authorisierungsproblem noch das „kleinere Übel“…hm
kabo63.

Heimgeist · 5. November 2020 um 09:52

Hallo,

ich habe heute eine Rückmeldung von TA auf mein Ticket bekommen:

Guten Tag,

wie Sie schon richtig erraten haben, handelt es sich hier um eine Begrenzung seitens des CMI’s. Deswegen werden die entsprechenden Parameter nicht angezeigt, da diese die Objekt-Limitierung überschreiten. Das angesprochene „max. 16 value/parameter“ bezieht sich hierbei auf die Anzahl der limitierten Werte pro Parameter.
Zum Beispiel kann man die Anzahl der Analogen Loggingdaten mit „jsonparam=La1,La2“ beschränken, sodass nur der erste und zweite Wert mitgeschickt wird. Hierbei tritt dann die von Ihnen erwähnte Regel mit „max. 16 value/parameter“ in Kraft. D.h. man kann die Ausgabe auf maximal 16 Werte pro Parameter beschränken.

Wenn sie mehr Parameter/Objekt abfragen möchten müssten Sie diese auf zwei separate Anfragen aufteilen.

Ich lese daraus, dass die CMI API eine Limitierung hat und man bei einer größeren Anzahl von Objekten diese auf mehrere Anfragen aufteilen soll.
Mit den Symcon Bordmitteln könnte ich aber keine separaten Anfragen stellen, um z.B. nur die Logging Daten auszulesen, da die Symcon Instanz immer per Default alle Parameter für einen Gerätetyp abfragt.

Könntet ihr da bei Gelegenheit nochmal ran und bei der Instanz die einzelnen Parameter trennen wie z.B. bei #128 vorgeschlagen?

kabo63 · 7. November 2020 um 10:26

Wie geht es denn nun konkret weiter?
Momentan sehe ich (für mich) 2 Punkte:

Authorisierungsproblem(?), um überhaupt auf die Instanz zugreifen zu können
Auslesen der analogen und/oder digitalen Werte aus dem CAN-Bus

Falls das Thema auf der Prioritätenliste nicht so weit oben steht kann ich es halt nicht ändern/lösen, hätte aber gerne einen Zeithorizont…
Gruß, kabo63.

Heimgeist · 7. November 2020 um 11:24

Hi,

prüfe doch mal, ob an Deinem Authorization Problem wirklich Symcon schuld ist. Das glaube ich eher nicht.

Mit einem Programm wie z.B. „Postman“ kannst Du einfach JSON Requests absetzen und die Antworten analysieren.
Prüfe doch mal anhand des anhängendem Screenshot, ob die Einstellungen bei Dir so stimmen.

Die Request URL lautet:


http://192.168.32.19/INCLUDE/api.cgi?jsonnode=3&jsonparam=I,O,D,Sg,La,Ld

Die IP 192.168.32.19 musst Du natürlich durch die IP Deines lokalen CMI ersetzen

Username/Password bei Authorization in Postman müssen natürlich identisch wie im CMI sein.

jsonnode=3 -> Ich frage das CAN-BUS Device mit der CAN Nummer 3 ab. Musst Du natürlich anpassen
jsonparam=I,O,D,Sg,La,Ld -> Die gewünschten Datenobjekte als Komma separierte Liste (siehe Punkt 5.3.2 in der API Dokumentation CMI_JSON_API_V5.pdf)

Diese Limitierung der TA API ist natürlich blöd. Mein Anwendungsfall würde sofort laufen, wenn Symcon nicht grundsätzlich die Parameter Sd, St, Ss (System Date, System Time,System Sun) anfragen würde, die meiner Meinung nach auch noch absolut überflüssig sind, da sie auch direkt von Symcon Systemvariablen zu bekommen wären.

Auf der anderen Seite kann ich natürlich auch verstehen, dass es nun schwierig ist, alles umzustellen. Es mag User geben, bei denen es so problemlos läuft. Man muss dann bei Änderungen immer die Kompatibilität bewahren.

Am einfachsten wäre es ein neues Instanzobjekt „Technische Alternative API“ hinzuzufügen, welches geräteunabhängig die gewünschten jsonparam Parameter auswählen lässt.

Dieses wäre grundsätzlich auch als PHP Modul möglich oder man nutzt einen einfachen Webrequest in einem Script und wertet die JSON Response darin auch aus.

Ich würde sowas dann programmieren und auch gerne als Lösung zur Verfügung stellen. Dauert aber noch was, da ich erstmal meine Heizungs und Solarsteuerung auf Tapps2 umstellen muss. Symcon wollte ich nur zum Loggen verwenden.

kabo63 · 7. November 2020 um 17:49

Hallo Uwe,
Danke für Deinen Hinweis…ich taste mich mal ran…

kabo63 · 7. November 2020 um 18:08

…so hab das mal soweit erledigt - sieht in Zeile 9 und 10 nicht wirklich prickelnd aus…oder?

Heimgeist · 7. November 2020 um 22:04

Hi, das sieht doch schon mal gar nicht so schlecht aus.

Schaue doch mal hier: https://www.ta.co.at/download/datei/17511763-cmi-json-api/

Punkt 6.3.
Status Code: FAIL -> Failure during the CAN-request/parameter not available for this device.

Vermutlich hast du in dem Abfrage String ein Parameter, welcher von Deinem Gerät nicht unterstützt wird.
Versuche doch nun mal nur jeweils einen Parameter für jsonparam anzufragen. Also in meinem Beispiel:


http://192.168.32.19/INCLUDE/api.cgi?jsonnode=3&jsonparam=I
http://192.168.32.19/INCLUDE/api.cgi?jsonnode=3&jsonparam=O
http://192.168.32.19/INCLUDE/api.cgi?jsonnode=3&jsonparam=D
....

Die Bedeutung der Parameter findest Du unter Punkt 5.3.2.jsonparam

Ich vermute der CAN-EZ3 hat keine Ausgänge, wenn ich mir das Foto auf der TA WebSeite so anschaue.
Daher wird der Parameter O zum Auslesen der Ausgänge vermutlich diesen Fehler werfen.

Daher die Parameter am besten einzeln ausprobieren!

kabo63 · 8. November 2020 um 10:03

…geht klar Uwe - vielen Dank!

zonex · 12. November 2020 um 16:44

Hallo:)

Ich würde gerne Diverse Einstellung schalten von meiner UVR1611 via CMI statt mir ein Script für Jeden Befehl anzulegen ist es sicher einfacher eine WebView in das IPSView zu integrieren.

Jedoch bekomme ich einen Fehler wenn ich

http://192.168.0.63:50063/menupage.cgi?page=0108580F
eintrage mit

You are not authorized to access this server.

Kann einer sagen wo ich den Benutzer und Pass in der URL einfüge um das hinzubekommen oder ist das nicht so einfach bzw gibt es einen anderen optisch schöneren Weg zur integration?

Danke:loveips:
Alex:)

Heimgeist · 12. November 2020 um 18:13

Versuch doch mal den Klassiker


http://username:password@192.168.0.63:50063/menupage.cgi?page=0108580F

username und password natürlich von Deinem CMI.