Modul: Technische Alternative (TA) UVR16x2, Temperatur Werte auslesen

Begonnen von ronny332, 25 September 2015, 12:28:07

Vorheriges Thema - Nächstes Thema

ronny332

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.
... Homematic Flüchtling und Freund der neu gewonnen Fhem-Freiheiten.

rudolfkoenig

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.

ronny332

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).
... Homematic Flüchtling und Freund der neu gewonnen Fhem-Freiheiten.

rudolfkoenig


Mounty-yo

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

ronny332

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).
... Homematic Flüchtling und Freund der neu gewonnen Fhem-Freiheiten.

Mounty-yo

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 :-)

ronny332

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.
... Homematic Flüchtling und Freund der neu gewonnen Fhem-Freiheiten.

Mounty-yo

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

ronny332

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.
... Homematic Flüchtling und Freund der neu gewonnen Fhem-Freiheiten.

UdoG

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
3x Raspi 2 / FHEM aktuelle Version (2x Echtsystem, 1x Testsystem)

HM-CFG-LAN, HM-CC-TC, HM-LC-Sw2-FM, HM-LC-Sw4-DR, HM-CC-VD

Johannes1982

Hallo,

hat auch bei mir auf Anhieb gut geklappt. Gibt es eine Möglichkeit den DL Bus auszulesen?

Grüße

ronny332

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
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 ;).
... Homematic Flüchtling und Freund der neu gewonnen Fhem-Freiheiten.

tremichl

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
Wir haben keine Ahnung davon, was wir nicht wissen

ronny332

Hallo,

die letzte Version habe ich hier hinterlegt: 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).
... Homematic Flüchtling und Freund der neu gewonnen Fhem-Freiheiten.