Hallo zusammen,
das Forum hat mir schon so viel gegeben, eventuell hat jemand Verwendung für das gestern geschriebene Modul um von einer TA UVR16x2 die Temperatur Werte (Fühler) zu lesen. Für mehr habe ich selber aktuell keine Verwendung, aber natürlich wäre es möglich auch Ausgänge zu lesen oder im nächsten Schritt Aktionen auszuführen.
Bei mir laufen 2 UVR16x2 an einem CMI. Nach Eingabe der Benuzerdaten + IP + Interval sucht sich das Modul die verfügbaren CAN Devices zusammen (da ich nur die beiden Geräte habe weiss ich natürlich nicht, wie es bei anderen Geräten abläuft) und holt alle Werte mit °C.
Der Ablauf geht dank fehlender offener API nur über das Webinterface des CMI, die Reaktionszeiten sind aber derart schnell, dass ich auf asyncrone Aufrufe verzichtet habe.
Es werden pro Intervall lediglich die Devices selber abgefragt, nur im ersten Anlauf, oder wenn sich die Definition ändert, wird nach neuen Steuerungen gesucht (das spart eine ganze Menge Aufrufe, auch wenn diese alle unter 100ms brauchen).
Das angehangene Bild sollte für jeden schon zeigen wie das Modul eingebunden wird:
define device_name UVR16x2 http://user:password@ip INTERVAL
also z.b.:
define uvr16x2 UVR16x2 http://admin:123456@192.168.0.76 300
Viel Spaß damit, falls Verwendung vorhanden!
P.S.: ich bin defintiv kein geübter Perl Programmierer, mein Geld wird mit JS, PHP, HTML, CSS verdient, als Hobby liebe ich C oder C++. Also bitte etwas Nachsicht, wenn der Code sicherlich nicht wirklich optimal ist ;).
Kleines Update:
ab jetzt werden Boolsche (AUS/EIN) Fix Werte gelesen. Ziel ist diese später schaltbar mittels "set" zu machen, u.A. um damit Ausgänge oder Funktionen schalten zu können. Vom direkten Schalten der Ausgänge halte ich nichts, aber Fixed Values bieten sich dafür geradezu an.
Update:
hier nun das versprochene Update um boolsche Werte in Fixwerte zu schreiben. Fixwerte mit EIN/AUS werden als "sw_NAME" Readings gespeichert und können via "set UVR16x2_INSTANZ_NAME sw_FIXWERT_NAME on/off" gesteuert werden.
Die Technische Alternative geht hier aus meiner Sicht etwas fremde Wege bei der internen Verwaltung der Hashwerte. So sind für das Setzen eines einzigen Werte 3 Zugriffe auf das CMI notwendig. Dank der schnellen Reaktionszeit kein großes Problem, aber irgendwie doch ungewöhnlich.
Wichtig zu beachten: die Fix Werte werden im normalen Intervall gelesen. Finden Änderungen direkt auf dem CMI oder der Steuerung statt so sind diese erst nach dem nächsten abgelaufenen Intervall in FHEM sichtbar (alles andere würde Unmengen an Requests verursachen).
Nun kann ich meinen manuellen Pelletofen doch endlich mit einem FHEM Notify steuern ;).
Update:
Fix Werte können nun mit "toggleOn" und "toggleOff" für jeweils eine Sekunde ein oder ausgeschlatet werden. In meinem Fall genutzt um manuell die Warmwasser Zirkulation anzustoßen.
Update:
Für das Einlesen der Werte doch die Nutzung von Blocking Call unausweichlich, es dauerte teilweise bei mir 1,x bis 2 Sekunden, was den Log geflutet hat. Nun werden die Werte "still" im Hintergrund geladen, einzig die Updates blockieren FHEM natürlich für einen sehr kurzen Moment.
Update 28.04.2016:
Die TA hat einige Änderungen an den Pfaden der Weboberfläche durchgeführt, hierfür waren Anpassungen notwendig.
Update 9.05.2016:
Nach einem Firmware Update der Steuerungen auf v1.17 ergaben sich wieder ein paar Änderungen in der Weboberfläche.
Bitte das Modul lieber 80_UVR16x2.pm nennen, damit wird es nicht immer, sondern nur beim Bedarf (define im config) geladen, und so hat es erheblich bessere Chancen in die normale Distribution integriert zu werden.
Sonst: Module sollten Log3($name,level,text) statt Log(level, text) verwenden, dann kann man naemlich pro Instanz via verbose Attribut die Ausgabenmenge steuern.
Das ändere ich doch direkt, sorry.
Nachtrag:
geändert, Vielen Dank. Log3 erfreut mich doch sehr zu kennen. Das muss mir immer wieder in anderen Modulen durch die Lappen gegangen sein. Ein Blick auf die Gründe der Nummerierung der Module lässt ebenfalls ein "Ahaaa" aufkommen ;-) (war wohl doch nicht nur um optisch für Ordnung zu sorgen).
War als Verbesserungsvorschlag gedacht, nicht als Schelte.
Hallo Ronny,
ich habe das bei mir mal probiert, aber ich bekomme es nicht hin. Im Logfile kommt nur ein Eintrag "unable to read". ?
Muss der Benutzer vom CMI der Experte sein, oder reicht auch der Anwender ?
Muss ich an der 80_UVR16x2.pm Datei Anpassungen vornehmen ?
Danke, Jörg
Hallo,
das kannst Du selber "ablesen" im Webinterface. Wenn das Webinterface als Benutzer auch die Eingänge anzeigt, so wollte es gehen.
"unable to read" deutet aber schon von der Code Seite darauf hin, dass es vermutlich am User und seinen Rechten liegt (das geschieht wenn Geräte gefunden wurden, die Rückgabe des Webservers für die einzelnen Werte aber leer ist).
Wenn du magst, so stell doch mal den Log Level auf 5. Dann müsste genau zu verfolgen sein ob Geräte gefunden werden. Falls nicht (dann dürfte aber auch das "unable to read" nicht erscheinen), kommt im Log "no temperature pages to read from".
Ich lese meinen CMI als admin aus, habe den aber komplett umbenannt und ein recht wirres Passwort verwendet. Die einzige wirkliche Gefahr würde damit von Fhem ausgehen, oder einem User, der dein Netzwerk sniffen kann (dank abgekapseltem Gast Zugang in meinem Netzwerk alles für mich zu ertragen).
Hallo,
konnte es heute erst probieren. Ich habe den Loglevel auf 5 gestellt. Das Passwort passt, nur leider funktioniert es nicht.
Kann es auch daran liegen, dass ich eine UVR1611 habe?
Hier ist der mitschnitt aus dem Logfile :
2015.10.17 22:14:20 4: searching for new temperature pages
2015.10.17 22:14:20 4: HttpUtils url=http://admin:admin@192.168.178.19/can_nodes.cgi?_=1445112860360
2015.10.17 22:14:20 4: http://admin:admin@192.168.178.19/can_nodes.cgi?_=1445112860360: HTTP response code 200
2015.10.17 22:14:20 4: HttpUtils http://admin:admin@192.168.178.19/can_nodes.cgi?_=1445112860360: Got data, length: 5
2015.10.17 22:14:20 4: HttpUtils url=http://admin:admin@192.168.178.19/can_knoten.cgi?node=1&_=1445112860373
2015.10.17 22:14:20 4: http://admin:admin@192.168.178.19/can_knoten.cgi?node=1&_=1445112860373: HTTP response code 200
2015.10.17 22:14:20 4: HttpUtils http://admin:admin@192.168.178.19/can_knoten.cgi?node=1&_=1445112860373: Got data, length: 405
2015.10.17 22:14:20 4: HttpUtils url=http://admin:admin@192.168.178.19/can_knoten.cgi?node=16&_=1445112860450
2015.10.17 22:14:20 4: http://admin:admin@192.168.178.19/can_knoten.cgi?node=16&_=1445112860450: HTTP response code 200
2015.10.17 22:14:20 4: HttpUtils http://admin:admin@192.168.178.19/can_knoten.cgi?node=16&_=1445112860450: Got data, length: 378
2015.10.17 22:14:20 4: found 0temperature pages
2015.10.17 22:14:20 4: no temperature pages to read from
2015.10.17 22:14:20 2: unable to read
Wäre schön, wenn es doch irgendwie klappt :-)
Hallo, sorry für die späte Antwort. Leider bekam ich keine Benachrichtigung über die Antwort. Da war wohl das Abo für das Thema fehlerhaft.
Für die UVR1611 wird das in der Tat nicht funktionieren, das Webinterface dürfte komplett unterschiedlich sein. Ich bin gerade an einem Umbau für die letzte CMI Firmware, da wurden leider recht viele Einträge verändert. Lesen funktioniert schon wieder, aber Variablen setzen noch nicht.
Hallo Ronny,
die neue Version, die lesen kann ist aber noch nicht über das Update verteilt , oder ?
Damit sollte dann auch die UVR1611 funktionieren ?
Danke, Jörg
Hallo Jörg,
nein. Das wird auch mit dem Update so schnell nichts, weil das Modul wirklich sehr knapp und nicht wirklich "fertig" ist. Mir fehlt da die Möglichkeit wirklich etwas an anderen Anlagen zu testen. Dank des freien Aufbaus kann letztlich jeder Programmierer seine Anlage anders absetzen, weshalb eine generelle Regelung per FHEM sehr schwierig werden dürfte. Ich steuere z.B. viele User Möglichkeiten über Variablen an, welche dann über die Logikfunktionen eine Reaktion erzeugen. Aber für die besagte Reaktion gibt es noch einige andere Wege.
Die ganz andere Art der Umsetzung in FHEM wäre die Nutzung des CANs via Ethernet. Aber dafür fehlte mir bisher die Zeit.
Eine UVR1611 habe ich nicht, daher kann ich die Oberfläche nicht auslesen und somit auch nicht die HTTP Requests anpassen. Wenn TA mal eine einheitliche API liefern würde, wäre das Problem natürlich ganz schnell aus der Welt und der Code um einiges schöner zu gestalten.
Hallo ronny332,
habe gerade das Modul getestet. Hat bei mir sofort funktioniert. Danke.
Da ich gerade meine UVR16x2 in Betreib genommen habe, war mir wichtig erst einmal die Temperaturen zu loggen. Als weiterer Schritt würde eine Übergabe von Daten vom FHEM an die UVR16x2 noch interessant sein. Hier ist bestimmt die Variante mit CANs via Ethernet bestimmt für die Zukunft eine sichere Methode. Ich werde mich mal dazu belesen.
Gruss Udo
Hallo,
hat auch bei mir auf Anhieb gut geklappt. Gibt es eine Möglichkeit den DL Bus auszulesen?
Grüße
Hallo,
von meiner Seite macht es fast keinen Sinn diese Art von Modul weiterzupflegen, da sich die CMI Seiten bei jedem Update leicht verändern. Das beutet automatisch, dass ein Modul immer nur mit einer Software-Version läuft, sowas macht man nicht.
Für die Zukunft denke ich über eine Umsetzung des CAN Protokolls via Ethernet nach, aber wann und ob das klappt, kann ich kaum abschätzen. Hier spielt es keine Große Rolle aus welcher Quelle die Werte stammen, sie müssen nur via CAN-Bus "freigegeben" werden. Die Installation in FHEM wird automatisch weniger komfortabel, da wie bei der eigentlichen Programmierung der Anlage jeder Wert einmal zugewiesen werden muss. Dafür sollte das Ganze danach rock stable sein. Ein CAN Protokoll ändert man nicht alle Tage ;-).
Edit 26.06.2016:
heute (Nacht) hatte ich etwas Zeit für das COE Protokoll, welches die Technische Alternative benutzt. Komplett verstanden habe ich es noch nicht, die reinen Temperatur Werte sind aber schon dekodierbar.
Wie lange der Vorgang dauern wird ist mir noch nicht bewusst, wie das Resultat aussieht ebenso wenig. Da Perl nicht wirklich meine Heimatsprache ist, könnte ich mir ein CAN Modul in C(++) vorstellen (die Sprachen liegen mir deutlich mehr), zuzüglich späterer Anbindung dieses Moduls in Perl (z.B. via Telnet, so wie auch Telegram realisiert ist).
Edit 28.06.16:
Lesen der CoE Werte funktioniert mittlerweile sehr gut. Ich denke darauf kann man aufbauen und weitere Details wie einen CSV-Import einbauen, welcher eventuell einiges wie die Benennung der Werte möglicht. CoE ist sowohl frei von Benennungen der Werte, noch werden die Indexe der Werte übertragen, auch Einheiten sind nicht vorhanden. Alles folgt daher einem festen Muster, welches über die auf dem CMI installierten CSV Datei generiert wird.
Edit 30.06.16:
Der CoE Receiver nimmt langsam Form an. Ich habe ein Repository bei Github erzeugt, hier findet sich der letzte Stand: https://github.com/ronny332/TA_CoE (https://github.com/ronny332/TA_CoE)
Aktuell fehlt ein CSV Import (um die Konfiguration vom C.M.I. direkt einlesen zu können), ebenso mehr Telnet Commands (aktuell geht nur "list", welches alle Werte auf einmal ausgibt). Wenn sich auch noch ein Perl Programmierer finden würde, der das Ganze in FHEM einlesen kann, wäre die Sache geritzt ;).
Hallo Ronny,
der Weg über CoE scheint sehr vernünftig zu sein. Ist noch mit einer Weiterentwicklung zu rechnen? CAN Daten in FHEM darstellen zu können wäre schon toll. Würde gerne meine 1611 mit einem CMI erweitern wenn eine nachhaltige Lösung für FHEM Anbindung in Aussicht ist.
Jedenfalls Danke für die Arbeit.
Gruß, tremichl
Hallo,
die letzte Version habe ich hier hinterlegt: https://github.com/ronny332/TA_COE_fhem (https://github.com/ronny332/TA_COE_fhem)
Sie läuft bei mir selber nun schon seit einer ganzen Weile problenlos. Da ich zwischen RPi und x86 Plattformen hin und herspringe war NodeJS (was meine Programmierkenntnisse angeht) die beste Wahl (ansonsten nutze ich fast ausschliesslich C++, was aber nicht so recht auf Anhieb klappen wollte).
Die Software stellt einen UDP Server zur Verfügung, welcher auf die im CMI konfigurierten Werte lauscht. Diese müssen aber zwingend in der config.json angelegt werden (sonst geht da gar nichts). Im Anschluss werden alle gefangenen Werte via Telnet an FHEM gesendet (mein Telnet läuft dank eigenem geschützen Netzwerk ohne User/Pass, diese fehlende Authentifikations-Funktion könnte bei manchem eventuell sinnvoll sein).
Hallo zusammen
Seit heute bin ich Besitzer einer Holzpelletts Anlage mit einer UVE16x2 (Version 1.31) und einem CMI (Firmware 130_2).
Wie kann ich das CMI in mit meinem fhem auslesen und im Log und auf dem Floorplan anzeigen?
Die Beschreibung mit dem CoE und dem git http..... schlägt bei mir beim Befehl "npm install" fehl. (Ich kenne den Linux Befehl "npm" auch gar nicht)
Gerne würde ich erfahren wie andere hier das machen?
Gruss Andi
Hallo Zusammen,
habe seit gesten auch meine Heizung mit Solarthermie an einem UVR16x2 (1.32) und einem CMI (1.31.3)
Habe versucht die Verbindung zu Fhem herzustellen hat aber nicht geklappt. Wie habt ihr das hinbekommen?
Hallo StaBre
Ich habe nach dem x... Versuch aufgegeben, weil ich vermutlich alle verfügbare und findbare Infos aus dem Web ausprobiert habe, dazwischen musste ich den Raspi und das fhem ein paar mal neu installieren, weil irgend ein Link einen absoluter Müll war.
Seit ich weiss vorher das CMI genau kommt, resp. wer es entwickelt hatte, versuche ich einen grossen Bogen darum zu machen. Ich habe es unterdessen sogar in eine eigene DMZ gestellt. Gem. Aussagen von meine Heizungsmonteur (hat sehr guten Kontakt zu den TA Entwickler) kommt das Teil aus russischen Geheimdienstkreisen und kann noch viel mehr als nur das was wir brauchen. Ich denke es ist zumindest Vorsicht angebracht, den meine Firewall hat bis jetzt noch nicht zugemacht wegen einem Alarm, aber zumindest ist das eingerichtet. Das heisst aber nicht, dass es nicht versucht wird.
Ich habe mir jetzt auf dem grossen Flohmarkt eine einfache CAN-Schnittstelle (aus China) für den Raspi bestellt, mal schauen ob es damit dann geht. Es ist klar da muss ich dann mit meinem Heizungsmonteur dann noch die Daten definieren, aber dafür bleiben die dann wo sie sind. Bei meinem CMI hat er ein Update der Firmware gemacht, danach waren alle meine definierten Versuchspunkte wieder weg.
Sobald das Teil da ist, werde ich mit dem Steckbrett mal versuchen das ganze zum laufen zu bringen. Meine Idee ist eigentlich die, dass ich auf dem Raspi mittels der Rs232 einen 1-W DS2480 und mit der MSIO dann den CAN Bus ansprechen und im fhem einbinden kann. Ob es geht werden wir dann sehen. Das CAN-Gateway hat auf alle Fälle einen MCP2515 drauf, und ich bin der Meinung davon hier im Forum schon mal gelesen zu haben.
Sobald ich mehr weiss und habe versuche ich mich dann zu melden, ich gehe davon aus, dass ich am Schluss an meinen mangelnden fhem-Kentnisse scheitern werde.
Gruss Andi
Hallo Zusammen!
die CMI hat ab einer bestimmten Firmware Version auch ein Http-Interface, welches viele Daten über JSON liefert:
https://www.ta.co.at/download/datei/17511763-cmi-json-api/
Für Logging optimal, für eine Echtzeit Anzeige aber nicht so sehr, da man maximal ca 1x pro Minute Abfragen kann, bevor gedrosselt wird.
Ich hab aber noch nicht geschafft, das in ein fertiges FHEM Modul zu gießen, da meine Perl Kenntnisse arg begrenzt sind und das JSON doch sehr komplex ist.
schöne Grüße
Martin
Zitatdas JSON doch sehr komplex ist.
Es gibt seit kurzem eine Funktion json2reading($hash, $json) in fhem.pl, evtl. hilft dir das.
Wenn nicht, dann zeig mal die Daten, evtl. kann ich diese Funktion anpassen.
Zitat von: rudolfkoenig am 12 Oktober 2018, 10:18:26
Es gibt seit kurzem eine Funktion json2reading($hash, $json) in fhem.pl, evtl. hilft dir das.
Wenn nicht, dann zeig mal die Daten, evtl. kann ich diese Funktion anpassen.
Danke für das Angebot. Macht json2reading das selbe wie das Attribut extractAllJSON in HTTPMOD?
Rein technisch funktioniert extractAllJSON einwandfrei, die Readings haben dann aber nicht die Namen, die die Werte im UI der Steuerung haben, sondern zB Data_Outputs_05_Value_Unit.
Um anderen den Einstieg zu erleichtern, und verirrte Suchende, die hier stranden nicht auf dem trockenen sitzen zu lassen, dokumentiere ich einen API-call und die Antwort:
http://192.168.4.250/INCLUDE/api.cgi?jsonnode=1&jsonparam=I,O,DAntwort
{
"Header": {
"Version": 3,
"Device": "87",
"Timestamp": 1539361037
},
"Data": {
"Inputs": [
{
"Number": 1,
"AD": "A",
"Value": {
"Value": 57.3,
"Unit": "1"
}
},
{
"Number": 2,
"AD": "A",
"Value": {
"Value": 35.8,
"Unit": "1"
}
},
{
"Number": 3,
"AD": "A",
"Value": {
"Value": 9999.9,
"Unit": "1"
}
},
{
"Number": 4,
"AD": "A",
"Value": {
"Value": 67.9,
"Unit": "1"
}
},
{
"Number": 5,
"AD": "A",
"Value": {
"Value": 25.3,
"Unit": "1"
}
},
{
"Number": 6,
"AD": "A",
"Value": {
"Value": 19.9,
"Unit": "1"
}
},
{
"Number": 7,
"AD": "A",
"Value": {
"Value": 26.9,
"Unit": "1"
}
},
{
"Number": 8,
"AD": "A",
"Value": {
"Value": 19.9,
"Unit": "1"
}
},
{
"Number": 9,
"AD": "A",
"Value": {
"Value": 29.8,
"Unit": "1"
}
}
],
"Outputs": [
{
"Number": 1,
"AD": "D",
"Value": {
"Value": 1,
"Unit": "43"
}
},
{
"Number": 2,
"AD": "D",
"Value": {
"Value": 0,
"Unit": "43"
}
},
{
"Number": 6,
"AD": "A",
"Value": {
"State": 0,
"Value": 0,
"Unit": "0"
}
},
{
"Number": 12,
"AD": "A",
"Value": {
"State": 1,
"Value": 70,
"Unit": "8"
}
},
{
"Number": 13,
"AD": "A",
"Value": {
"State": 1,
"Value": 5,
"Unit": "13"
}
}
],
"DL-Bus": [
{
"Number": 1,
"AD": "A",
"Value": {
"Value": 483,
"Unit": "3"
}
},
{
"Number": 2,
"AD": "A",
"Value": {
"Value": 25.4,
"Unit": "1"
}
}
]
},
"Status": "OK",
"Status code": 0
}
Die Antwort ist natürlich nicht schwer zu verstehen für mich, aber mein Perl-Verständnis verabschiedet sich bei der Verschachtelung und den Arrays zwischendrin.
Vorschweben würde mir ein Modul, dass die Daten holt (sehr unspektakulär), wo man aber zB mit einem Attribut readingsConfig oder inputReadings mit Leerzeichen getrennt Namen vergeben kann. Die Werte werden dann automatisch einem Reading mit sprechendem Namen zugeordnet.
Ich hoffe, das ist soweit verständlich.
Das Modul würde ich schon bauen, aber ich scheitere wie gesagt am Auslesen der Daten.
Danke
schöne Grüße
Martin
ZitatMacht json2reading das selbe wie das Attribut extractAllJSON in HTTPMOD?
Weiss nicht genau, da ich extractAllJSON nicht genau kenne.
Soweit ich sehe, braucht extractAllJSON das JSON Perl Modul. json2reading ist eine reine Perl Implementierung, und kam mit MQTT2_DEVICE. Da ich MQTT2_SERVER/MQTT2_DEVICE einfach fuer den Anwender halten wollte, wollte ich keine externe Module einsetzen.
json2reading baut aus den gezeigten JSON folgende Readings:
2018-10-12 16:55:18 Data_DL-Bus_1_AD A
2018-10-12 16:55:18 Data_DL-Bus_1_Number 1
2018-10-12 16:55:18 Data_DL-Bus_1_Value_Unit 3
2018-10-12 16:55:18 Data_DL-Bus_1_Value_Value 483
2018-10-12 16:55:18 Data_DL-Bus_2_AD A
2018-10-12 16:55:18 Data_DL-Bus_2_Number 2
2018-10-12 16:55:18 Data_DL-Bus_2_Value_Unit 1
2018-10-12 16:55:18 Data_DL-Bus_2_Value_Value 25.4
2018-10-12 16:55:18 Data_Inputs_1_AD A
2018-10-12 16:55:18 Data_Inputs_1_Number 1
2018-10-12 16:55:18 Data_Inputs_1_Value_Unit 1
2018-10-12 16:55:18 Data_Inputs_1_Value_Value 57.3
2018-10-12 16:55:18 Data_Inputs_2_AD A
2018-10-12 16:55:18 Data_Inputs_2_Number 2
2018-10-12 16:55:18 Data_Inputs_2_Value_Unit 1
2018-10-12 16:55:18 Data_Inputs_2_Value_Value 35.8
2018-10-12 16:55:18 Data_Inputs_3_AD A
2018-10-12 16:55:18 Data_Inputs_3_Number 3
2018-10-12 16:55:18 Data_Inputs_3_Value_Unit 1
2018-10-12 16:55:18 Data_Inputs_3_Value_Value 9999.9
2018-10-12 16:55:18 Data_Inputs_4_AD A
2018-10-12 16:55:18 Data_Inputs_4_Number 4
2018-10-12 16:55:18 Data_Inputs_4_Value_Unit 1
2018-10-12 16:55:18 Data_Inputs_4_Value_Value 67.9
2018-10-12 16:55:18 Data_Inputs_5_AD A
2018-10-12 16:55:18 Data_Inputs_5_Number 5
2018-10-12 16:55:18 Data_Inputs_5_Value_Unit 1
2018-10-12 16:55:18 Data_Inputs_5_Value_Value 25.3
2018-10-12 16:55:18 Data_Inputs_6_AD A
2018-10-12 16:55:18 Data_Inputs_6_Number 6
2018-10-12 16:55:18 Data_Inputs_6_Value_Unit 1
2018-10-12 16:55:18 Data_Inputs_6_Value_Value 19.9
2018-10-12 16:55:18 Data_Inputs_7_AD A
2018-10-12 16:55:18 Data_Inputs_7_Number 7
2018-10-12 16:55:18 Data_Inputs_7_Value_Unit 1
2018-10-12 16:55:18 Data_Inputs_7_Value_Value 26.9
2018-10-12 16:55:18 Data_Inputs_8_AD A
2018-10-12 16:55:18 Data_Inputs_8_Number 8
2018-10-12 16:55:18 Data_Inputs_8_Value_Unit 1
2018-10-12 16:55:18 Data_Inputs_8_Value_Value 19.9
2018-10-12 16:55:18 Data_Inputs_9_AD A
2018-10-12 16:55:18 Data_Inputs_9_Number 9
2018-10-12 16:55:18 Data_Inputs_9_Value_Unit 1
2018-10-12 16:55:18 Data_Inputs_9_Value_Value 29.8
2018-10-12 16:55:18 Data_Outputs_1_AD D
2018-10-12 16:55:18 Data_Outputs_1_Number 1
2018-10-12 16:55:18 Data_Outputs_1_Value_Unit 43
2018-10-12 16:55:18 Data_Outputs_1_Value_Value 1
2018-10-12 16:55:18 Data_Outputs_2_AD D
2018-10-12 16:55:18 Data_Outputs_2_Number 2
2018-10-12 16:55:18 Data_Outputs_2_Value_Unit 43
2018-10-12 16:55:18 Data_Outputs_2_Value_Value 0
2018-10-12 16:55:18 Data_Outputs_3_AD A
2018-10-12 16:55:18 Data_Outputs_3_Number 6
2018-10-12 16:55:18 Data_Outputs_3_Value_State 0
2018-10-12 16:55:18 Data_Outputs_3_Value_Unit 0
2018-10-12 16:55:18 Data_Outputs_3_Value_Value 0
2018-10-12 16:55:18 Data_Outputs_4_AD A
2018-10-12 16:55:18 Data_Outputs_4_Number 12
2018-10-12 16:55:18 Data_Outputs_4_Value_State 1
2018-10-12 16:55:18 Data_Outputs_4_Value_Unit 8
2018-10-12 16:55:18 Data_Outputs_4_Value_Value 70
2018-10-12 16:55:18 Data_Outputs_5_AD A
2018-10-12 16:55:18 Data_Outputs_5_Number 13
2018-10-12 16:55:18 Data_Outputs_5_Value_State 1
2018-10-12 16:55:18 Data_Outputs_5_Value_Unit 13
2018-10-12 16:55:18 Data_Outputs_5_Value_Value 5
2018-10-12 16:55:18 Header_Device 87
2018-10-12 16:55:18 Header_Timestamp 1539361037
2018-10-12 16:55:18 Header_Version 3
2018-10-12 16:55:18 Status OK
2018-10-12 16:55:18 Status_code 0
und damit vermutlich dem extractAllJSON sehr aehnliche. Was auch kein Wunder ist, da man die Namen automatisch generieren muss. Du kannst auch json2nameValue verwenden, was die Vorstufe von json2reading ist, und dann selbst entscheiden, was du wie zum Reading wandelst. Ist aber alles nur ein Angebot und keine Vorschrift.
P.S.:Habe gerade leichte Fixes fuer json2nameValue eingecheckt, damit man keine Fehlermeldungen beim Parsen von Leerzeichen an unerwateten Stellen bekommt.
Wow! json2nameValue funktionert haarscharf so, wie man es sich vorstellt und wie man's benötigt.
Hier wurde sehr sauber gearbeitet :-)
Ich bau da jetzt wie vorher angedroht ein Modul um dieses JSON herum und stell das dann hier rein.
schöne Grüße
Martin
Auf https://github.com/delMar43/FHEM/blob/master/72_TA_CMI_JSON.pm gibt's eine erste Version zum Testen.
Derzeit wird nur die UVR16x2 unterstützt und auch nur Input, Output und DL-Bus Inputs.
Wenn jemand Bedarf an weitergehender Unterstützung hat (siehe vorher erwähnte API-Doku), bitte Bescheid geben.
Ich will nix Implementieren, was nachher garniemand testen kann (schon garnicht ich selber).
defmod <name> TA_CMI_JSON <ip> <nodeId> <queryParams>
Die nodeId sieht man auf http://<ip>/#can.cgi Beim Bild der UVR16x2 steht Node: <id>
Die queryParams können I für Inputs, O für Outputs und D für DL-Bus sein. Wenn man alle drei holen will, gibt man hier I,O,D an (achtung, nur komma getrennt, keine Leerzeichen).
Beispiel:
defmod cmi TA_CMI_JSON 192.168.4.250 1 I,O,D
Intervall ist derzeit auf 70 Sekunden. Über get update kann man die Daten auch früher holen. Es gibt aber nur 1x pro Minute neue Daten.
Es werden nur jene Daten in Readings abgelegt, die auch Konfiguriert wurden.
Dafür gibts 3 Attribute:
* readingNamesInputs
* readingNamesOutputs
* readingNamesDL-Bus
Eine Beispiel-Konfig schaut so aus:
attr cmi readingNamesDL-Bus 1:Durchfluss_Solar 2:T.Solar_RL
dh, was vom DL-Bus auf 1 kommt, wird unter Durchfluss_Solar abgelegt.
geplante Features:
* Die Einheit möchte ich noch als weiteres Reading hinzufügen. zb Durchfluss_Unit l/h
* Konfigurierbarer Interval
* Unterstützen von Abfragen einzelner Daten. Laut Doku kann man zB I2 angeben, um nur Input Wert 2 abzufragen.
Wer was damit anfangen kann, bitte gerne Testen.
Wenn das Modul breiteren Anklang findet, reiche ich es gern als offizielles Modul ein.
Dokumentation im Wiki hinzugefügt:
https://wiki.fhem.de/wiki/UVR16x2
Hallo Martin,
habe Dein Modul mit meinem CMI und dem UVR1611 ausprobiert. Fhem häng nach der installation und ich muss den Raspi neu starten.
Im Logfile steht dann folgendes:
2018.10.18 21:42:57 3: TA_CMI_JSON - Initialize done ...
Undefined subroutine &main::json2nameValue called at ./FHEM/72_TA_CMI_JSON.pm line 109.
An meinem CMI muss ich ein Passwort eingeben. Wie kann ich das mit Deinem Modul machen ?
So habe ich es auch pobiert, geht aber nicht:
define cmi TA_CMI_JSON xxx:xxx@192.168.178.85 1 I,O,D
2018.10.18 21:38:30 0: error while requesting http://xxx:xxx192.168.178.85/INCLUDE/api.cgi?jsonnode=1&jsonparam=I,O,D - http://xxx:xxx172.168.178.85/INCLUDE/api.cgi?jsonnode=1&jsonparam=I,O,D: malformed or unsupported URL
Undefined subroutine &main::json2nameValue called at ./FHEM/72_TA_CMI_JSON.pm line 109.
Der CMI liefert aber Werte :
192.168.178.85/INCLUDE/api.cgi?jsonnode=1&jsonparam=I,O,D
{ "Header":{ "Version":3, "Device":"80", "Timestamp":1539899696 }, "Data":{ "Inputs":[ { "Number":1, "AD":"A", "Value":{ "Value":14.9, "Unit":"1" } } , { "Number":2, "AD":"A", "Value":{ "Value":30.0, "Unit":"1" } } , { "Number":3, "AD":"A", "Value":{ "Value":43.3, "Unit":"1" } } , { "Number":4, "AD":"A", "Value":{ "Value":45.1, "Unit":"1" } } , { "Number":5, "AD":"A", "Value":{ "Value":30.4, "Unit":"1" } } , { "Number":6, "AD":"A", "Value":{ "Value":28.5, "Unit":"1" } } , { "Number":7, "AD":"A", "Value":{ "Value":14.3, "Unit":"1" } } , { "Number":8, "AD":"A", "Value":{ "Value":50.3, "Unit":"1" } } , { "Number":9, "AD":"A", "Value":{ "Value":48.2, "Unit":"1" } } , { "Number":10, "AD":"D", "Value":{ "Value":0, "Unit":"43" } } , { "Number":11, "AD":"D", "Value":{ "Value":0, "Unit":"43" } } , { "Number":12, "AD":"D", "Value":{ "Value":0, "Unit":"43" } } , { "Number":13, "AD":"A", "Value":{ "Value":32.2, "Unit":"1" } } , { "Number":14, "AD":"D", "Value":{ "Value":0, "Unit":"43" } } , { "Number":15, "AD":"D", "Value":{ "Value":0, "Unit":"43" } } , { "Number":16, "AD":"D", "Value":{ "Value":1, "Unit":"43" } } ], "Outputs":[ { "Number":1, "AD":"A", "Value":{ "State":0,"Value":0, "Unit":"0" } } , { "Number":2, "AD":"A", "Value":{ "State":0,"Value":0, "Unit":"0" } } , { "Number":3, "AD":"D", "Value":{ "Value":0, "Unit":"0" } } , { "Number":4, "AD":"D", "Value":{ "Value":0, "Unit":"0" } } , { "Number":5, "AD":"D", "Value":{ "Value":0, "Unit":"0" } } , { "Number":6, "AD":"A", "Value":{ "State":0,"Value":0, "Unit":"0" } } , { "Number":7, "AD":"A", "Value":{ "State":1,"Value":30, "Unit":"0" } } , { "Number":8, "AD":"D", "Value":{ "Value":0, "Unit":"0" } } , { "Number":9, "AD":"D", "Value":{ "Value":0, "Unit":"0" } } , { "Number":10, "AD":"D", "Value":{ "Value":0, "Unit":"0" } } , { "Number":11, "AD":"D", "Value":{ "Value":0, "Unit":"0" } } , { "Number":12, "AD":"D", "Value":{ "Value":0, "Unit":"0" } } , { "Number":13, "AD":"D", "Value":{ "Value":0, "Unit":"0" } } ]}, "Status":"OK", "Status code":0 }
Oh Mann, da geht ja alles schief.
Sorry, und danke für die Logs, die helfen sicher.
schöne Grüße
Martin
Oh, du musst dein fhem updaten.
Json2nameValue ist relativ neu.
,update' hilft
Achja: das Passwort ist derzeit das default.
Wenn du Werte kriegst, dürfte es passen :)
Hallo Martin,
auf das update hätte ich auch kommen können.
Jetzt funktioniert es 8)
Werde die Tage mal die einzelnen Werte als readings anlegen. Ein paar Testreadings funktionieren.
Werde berichten.
Jörg
Update: username und passwort für die CMI können jetzt über genau diese Attribute definiert werden.
Analog dazu hab ich die commandref und die Wiki-Seite aktualisiert.
Hab ich mal probiert (CMI UVR1611) im Augenblick bekommen ich Werte für die Eingänge. Keine Werte für den DL Bus (da sind Raumsensoren).
Und für die Ausgänge 0 für Aus 30 für Ein.
Und ständig TOO MANY REQUESTS
Auf jeden Fall ein Lichtblick. Das Erste brauchbare Modul für das CMI.
Ich hab noch ein CAN-IO wie komme ich da dran?
Gruß Jens
Hallo Jens
Zitat von: cmburn am 31 Oktober 2018, 09:26:52
Keine Werte für den DL Bus (da sind Raumsensoren).
Was kriegst du, wenn du direkt im Browser
http://ip.des.cmi/INCLUDE/api.cgi?jsonnode=1&jsonparam=Daufrufst? Das D in jsonparam liefert DL-Bus Daten.
Wenn da nix drin steht, weiß ich leider nicht, warum das so ist.
Zitat von: cmburn am 31 Oktober 2018, 09:26:52
Und für die Ausgänge 0 für Aus 30 für Ein.
Den Fall hab ich auch, und zwar bei der Umwälzpumpe für die Solaranlage. Die kann variable Drehzahlen annehmen. Dort wird nicht zwischen 0 und 100 % geregelt, sondern von 0 bis 30.
Wenn bei dir nur 0 und 30 vorkommt, dann wohl deshalb, weil der Ausgang zwar Regelbar ist, aber nur für Ein und Aus verwendet wird.
Das sollte übrigens auch so am UI des CMI aufscheinen.
Zitat von: cmburn am 31 Oktober 2018, 09:26:52
Und ständig TOO MANY REQUESTS
Das CMI erlaubt eine Abfrage pro Minute. Und zwar insgesamt, nicht pro Client.
Wenn du also die API mal im Browser und mal in FHEM aufrufst, kann das schon vorkommen.
Beim Experimentieren also am besten sicherstellen, dass nicht parallel wo ein Skript läuft, dass ebenfalls Abfragen macht.
Zitat von: cmburn am 31 Oktober 2018, 09:26:52
Auf jeden Fall ein Lichtblick. Das Erste brauchbare Modul für das CMI.
Freut mich.
Ohne den Hinweis von Rudi, dass es jetzt json2keyValue gibt, wäre ich aber gescheitert (bin ich auch, um genau zu sein).
Zitat von: cmburn am 31 Oktober 2018, 09:26:52
Ich hab noch ein CAN-IO wie komme ich da dran?
Ich hab das selber nicht im Einsatz.
Falls es über eine eigene CAN-ID verfügt, solltest du in FHEM einfach ein zweites TA_CMI_JSON Device anlegen können und die entsprechende Can-ID angeben (Parameter nodeId).
Du kannst es auch direkt im Browser ausprobieren, der http-Parameter heißt da jsonnode
Falls es keine eigene CAN-ID hat, weiß ich erstmal auch keine Antwort.
Der Hersteller war mir gegenüber aber immer extrem Auskunftsfreudig (selbst als ich nach Verbindungen zum russischen Geheimdienst gefragt habe, habe ich eine sehr professionelle Antwort erhalten, inklusive einer Liste aller ausgehenden Ports des CMI), wenn es also eine Lösung gibt, werden sie dir diese auch verraten :-)
Ich arbeite aber auch parallel an einem weiteren Modul für die CMI, welches nicht über die JSON-API arbeitet, sondern die CAN-Over-Ethernet Pakete empfängt. Darin sind dann alle Werte, die man im CMI per Output definiert.
Das wird dann eine mächtigere Lösung sein (mehr Werte; quasi Echtzeit, weil Push, etc), allerdings auch viel Aufwändiger seitens CMI zu konfigurieren.
Dauert aber noch
schöne Grüße
Martin
Was kriegst du, wenn du direkt im Browser
Code: [Auswählen]
http://ip.des.cmi/INCLUDE/api.cgi?jsonnode=1&jsonparam=D
aufrufst? Das D in jsonparam liefert DL-Bus Daten.
{ "Header":{ "Version":3, "Device":"00", "Timestamp":1540998464 }, "Data":{ }, "Status":"NODE ERROR", "Status code":1 }
DA ist nix drin...
Ok, dann bin ich glücklich. Der Abfrageintervall, welche Zeiteinheit ist das? ich würde das auf ca. 5 minuten verlängern wollen.
Mal schaun der Knoten 20 im CAN liefert auch Werte....
laut handbuch hat can io per default die node id 32.
intervall ist in sekunden.
Der CAN/IO ist auf Adresse 20
http://192.168.17.17/INCLUDE/api.cgi?jsonnode=20&jsonparam=I
{ " Header":{ "Version":3, "Device":"82", "Timestamp":1541000683 }, "Data":{ }, "Status":"DEVICE NOT SUPPORTED", "Status code":5 }
:-\
Schade.
Das Modul, das gerade in Arbeit ist, sollte das aber können.
Gib mir noch eine Woche
Ich denke das ist eher ein Problem des CMI
PS: ich hatte heute die Firmware 1.33.2 drauf (C.M.I hat Update angezeigt) ->>>>> dann ging gar nix mehr!
Ich hab dann auf 1.30.2 zurück geflasht.
Zitat von: cmburn am 31 Oktober 2018, 22:41:27
Ich denke das ist eher ein Problem des CMI
Laut Doku ist dein Gerät schlicht und ergreifend nicht von der JSON-API unterstützt:
https://www.ta.co.at/download/datei/17511763-cmi-json-api/
Punkt 6.1.2 auf Seite 5
Wenn du aber im CMI Daten aus dem CAN I/O über CAN-over-Ethernet exportieren kannst (Einstellungen -> Ausgänge -> CoE), dann wird dir mein anderes Modul helfen können.
Zitat von: cmburn am 31 Oktober 2018, 22:41:27
PS: ich hatte heute die Firmware 1.33.2 drauf (C.M.I hat Update angezeigt) ->>>>> dann ging gar nix mehr!
Ich hab dann auf 1.30.2 zurück geflasht.
Ich hab auch unlängst von 1.30.2 aktualisiert. Allerdings auf 1.31.3, das funktioniert problemlos. An der API hat sich da aber nix geändert.
schöne Grüße
Martin
Top Modul! Funktioniert wunderbar mit meinem CMI und einem UVR1611. Vielen Dank an den Ersteller für die TOP-Arbeit!
Zitat von: fgraf am 01 November 2018, 15:23:57
Top Modul! Funktioniert wunderbar mit meinem CMI und einem UVR1611. Vielen Dank an den Ersteller für die TOP-Arbeit!
Danke für das Feedback.
Dann werd ich das Modul die nächsten Tage ins SVN geben.
Hallo zusammen!
Das Modul ist nun offiziell: bitte weitere Fragen dazu im "offiziellen" Thread des Moduls hier stellen:
https://forum.fhem.de/index.php/topic,92740.0.html
Danke für euer Interesse und eure Mithilfe beim Testen und Ideen sammeln.
schöne Grüße
Martin
Wie schon öfter erwähnt, ist auch ein Modul für CanOverEthernet in Entwicklung.
Die erste Version davon liegt nun auf GitHub, genaue Infos gibts hier:
https://forum.fhem.de/index.php/topic,96170.0.html
schöne Grüße
Martin