Tipps gesucht: eigenes Interface und Modul planen

Uef · 17 Dezember 2015, 17:52:43

Hallo,

ich hoffe, dass die Frage hier richtig plaziert ist und dass mir die erfahrenen FHEM-Entwickler weiter helfen können.

Ich besitze einen Heizkessel mit OpenTherm-Interface, den ich gerne an mein FHEM (auf Raspberry) anbinden möchte.

Da OpenTherm ein eigenes Protokoll (u.a. mit Manchester-Codierung, genau 1 Dialog (Request+Reply(von der Heizzung)) pro Sekunde ) und auch eine spezielle Schnittstelle (2-Draht-seriell mit Strom-/Spannungs-Pegeln) nutzt, setze ich einen Controller zwischen FHEM und die Heizung ein und habe da bereits mit einem Arduino und einem selbstentwickelten Shield begonnen. Das funktioniert auch schon rudimentär, so dass der Arduino Werte bei der Heizung abfragen und prinzipiell auch Kommandos senden kann.

Plan ist, dass der Arduino (oder ggf. ein anderer Controller, falls sich der im Verlauf als zu langsam herausstellen sollte) einerseits regelmässig die aktuellen Betriebsparameter der Heizung (Vor- und Rücklauftemperatur, Wasserdruck, Fehlerstati ...) abfagen und FHEM "zur Verfügung stellt". Zusätzlich soll FHEM dann auch Kommandos z.B. zum Verändern der Vorlauftemp o.ä.) an den Controller senden können, der sie dann an die Heizung weitergibt.
Für OpenTherm soll dann möglichst auch ein separates Modul entstehen (wäre allerdings mein Erstes und meine PERL-Skills haben leider noch massiv Luft nach oben $:-\$ , aber das gilt als Ausrede nicht)

Für die Verbindung zwischen Arduino und FHEM bin ich mir aktuell jedoch unsicher, wie man die Kommunikation am besten aufbaut:
Das einzige, wo ich mir halbwegs sicher bin ist, dass es - um bei der Platzwahl freier zu sein - über's Netzerk gehen sollte (also kein USB).
Aber:

soll ich Telnet oder HTTP (oder noch etwas anderes) nutzen ?
Welche Komponente fungiert dabei sinnvollerweise als Client, welche als Server, d.h. wer triggert die regelmässige Übertragung der aktuellen Heizungswerte vom Controller zu FHEM ?
(ich verstehe hier leider die FHEM-Interna noch viel zu wenig, um zu entscheiden, wie aktiv oder passiv FHEM dabei sein kann).
Ich würde mal auf FHEM als Client tippen ....
Welche existierenden Module könnte/sollte ich mir als geeignete Vorlage anschauen ?

Es wäre super, wenn Ihr mir da etwas auf die Sprünge helfen könntet, damit ich nicht zuviel Zeit in die falsche Richtung investiere (auch wenn mir aufgrund ausgiebiger Bastelerfahrung klar ist, dass das kein Durchmarsch werden wird

).

Liebe vorweihnachtliche Grüße aus der Region Aachen

CoolTux · 18 Dezember 2015, 06:26:28

Zitat von: Uef am 17 Dezember 2015, 17:52:43

soll ich Telnet oder HTTP (oder noch etwas anderes) nutzen ?
Welche Komponente fungiert dabei sinnvollerweise als Client, welche als Server, d.h. wer triggert die regelmässige Übertragung der aktuellen Heizungswerte vom Controller zu FHEM ?
(ich verstehe hier leider die FHEM-Interna noch viel zu wenig, um zu entscheiden, wie aktiv oder passiv FHEM dabei sein kann).
Ich würde mal auf FHEM als Client tippen ....
Welche existierenden Module könnte/sollte ich mir als geeignete Vorlage anschauen ?

Guten Morgen,

Ich finde Dein Vorhaben sehr gut. Genau so habe ich auch angefangen. Aus dem Bedarf heraus angefangen ein Modul zu schreiben. Viele wichtige Hinweise zum Aufbau eines Modules findest Du ja im Wiki. einfach mal Google anwerfen FHEM Development eingeben und dann siehst Du schon. Mir hat auch geholfen wenn ich mal bei anderen Modulen reingeschaut habe was die so machen.

Nun zu Deinen Fragen. Eines noch vorweg. Ich weiß nicht was ein Arduino ist. Daher versuche ich mich allgemein zu halten

Sicherlich meinst Du die Kommunikation von FHEM und Deinem Arduino. Interessanterweise steht das in direkten Zusammenhang zu Frage zwei und der Frage welche Kommunikationsart Dein Arduino Dir bietet.
Aber mal von Vorn. FHEM bietet die Möglichkeit einmal Abfragen selbst zu machen (pollen) oder aber auf Informationen von ausserhalb zu warten (eigener TCP Socket, da Du ja Netzwerk haben willst). Wäre also erstmal zu klären wie Zeitkritisch auf Deine Messwerte vom Arduino reagiert werden soll. Eigentlich ist ein Heizsystem eher sehr träge, da würde ich mal behaupten spielen 1-2 Minuten keine große Rolle. (ACHTUNG!!! Ich spreche hier nicht von Reaktionen auf Situationen für Notfallabschaltungen. CO2 oder Überhitzung), daher kannst Du Deinen Arduino ja in 1-2 Minutentakt pollen.
Auf welche Art und Weise liegt nun also am Arduino. Wie werden da die Daten zum holen bereit gestellt?
Das haben wir ja dann schon oben so gut wie beantwortet. Der Arduino stellt die Daten bereit und FHEM ruft sie ab.
Schau erstmal wie Dein Arduino die Daten bereit stellt und dann kann ich Dir sagen welches Modul in ähnlicher Weise arbeitet.

Grüße
Leon

rudolfkoenig · 18 Dezember 2015, 09:56:52

Meine Meinung:
Wenn moeglich, wuerde ich HTTP einsetzen, das erweitert den moeglichen Kundenkreis, und testen wuerde ich mit dem Browser.
Ein echter push ist mAn immer besser als poll, da ressourcenschonender. Leider ist das ueber HTTP entweder nur aufwendig (websocket) oder mit Tricks (longpolling) moeglich.
Ich wuerde mind. 2 HTTP Verbindungen ermoeglichen:
- eine fuer Befehle / Abfragen, die sofort beantwortet werden
- eine zweite, was die GET Anfrage erst dann beantwortet, wenn Aenderungen (Events) vorliegen (aka longpolling)
Die erste Variante koennte man mit FHEM "Out-of-the-Box" mit HTTPMOD bedienen, auch wenn das fuer Benutzer noch nicht sehr komfortabel sein sollte, und auf polling angewiesen ist.
Wenn man die zweite Variante auch benutzen moechte, oder den Benutzern das FHEM-Setup vereinfachen moechte, dann waere ein eigenes Modul notwendig. Als Beispiel koennte man auch den inzwischen schon aelteren contrib/00_TAHR.pm verwenden.

AndreasHH · 18 Dezember 2015, 14:15:41

Moin,

ein weiteres in Frage kommende Protokoll ist MQTT, welches meiner Erfahrung nach sehr gut von FHEM und Arduino unterstützt wird.

MQTT ist ein Protokoll welches seit Jahren stabil eingesetzt wird und speziell für Die Übertragung und Steuerung von Sensoren (jeglicher Art) entwickelt wurde.

Läuft bei mir in Verbindung mit einem ESP8266 (als "Arduino") seit Monaten stabil über WLAN.

Weitere Variante:

Arduino an Raspi oder nur Raspi und dann mittels FHEM2FHEM übers Netzwerk.

Diese Variante läuft bei mir ebenfalls seit Monaten stabil.

Gruss

Andreas

Uef · 18 Dezember 2015, 16:09:27

Vielen Dank für Eure ausführlichen Antworten.
Die haben schon wieder viele Gedanken in Gang gesetzt .....

@Leon:
der Arduino als Kleinst-Einplatinencomputer hält die Daten erstmal nur als Variablen in seinem C-ähnlichen Programmcode/RAM bereit. Eine vorgegebene Struktur gibt es nicht und da ich das selbst programmiere, sind alle Freiheiten gegeben. Man könnte also über die Möglichkeit zum Abruf einzelner Werte nachdenken oder auf Anfrage mit JSON einen kompletten Satz aller Werte bereitstellen.
Bzgl. des Protokolls bin ich aktuell noch völlig frei (soweit der Arduino mit seinem Atmel-Controller das schafft) - daher ja auch meine Frage, in welches Protokoll ich das sinnvollerweise packe, so dass FHEM damit (und vor allem mit der unterschiedlichen Kommunikation "Abfragen und Kommandos") am Besten klar kommt: HTTP, Telnet oder MQTT (wie Andreas schreibt) ....

Zeitkritisch ist das Ganze sicher nicht: es geht erstmal vorwiegend um's Monitoren (u.a. für Alarme wie z.B. "Wasserdruck zu niedrig") und ggf. leichte Regeleingriffe. Die Heizung hat aber eigene Intelligenz für die Überwachung der wichtigsten Dinge. Da muss - und will - ich also gar nicht ran. Aber von sich aus liefert die Heizung eh keinen Alarm, das bekommt man nur mit, wenn man die richtigen Register abfragt.
Man muss ggf. nur vorsehen, Parameter wie die Vorlauftemperatur gar nicht erst auf unsinnige Werte "regeln" zu können bzw. im Arduino einen Watchdog für einen Reset auf vernünftige Standardwerte zu implementieren, falls sich der Arduino aufhängt oder irgendwie spinnt.
Die Hinweise zur Implementierung der FHEM-Module werde ich mir auf jeden Fall noch genauer anschauen (hatte sie schon mal quer gelesen, um zu wissen, auf was ich mich einlasse

). Eine gute Vorlage, die halbwegs nahe am eigenen Projekt ist, ist nach meiner Erfahrung jedoch unbezahlbar, vor allem, wenn es so Vieles gleichzeitig zu lernen gibt ....

@Rudolf:
d.h. FHEM pollt den (Webserver ? auf dem) Arduino bzw. schickt einen Befehl (ebenfalls via GET?) ?
Ich denke, 1 Abfrage/Minute (das schwebt mir im Moment so vor) sollte keine zu hohe Last erzeugen.
Auf HTTPMOD war ich auch schon gestossen, aber das muss ich mir noch in Ruhe anschauen und mal mit meinem FHEM-Testsystem und dem Arduino rumtesten. Gleiches gilt für longpolling (na, da kommt wenigstens keine Langeweile auf ...)
Das mit den 2 Verbindungen habe ich noch nicht wirklich verstanden: meinst Du die Abarbeitung 2 unterschiedlicher GET-Befehle (?), von denen einer sofort, der andere im Falle eines Events beantwortet wird ?
Ich werde mir 00_TAHR.pm auf jeden Mal zu Gemüte führen - Danke für den Tipp.
Für Arduino-basierte Webserver habe ich bereits einiges gefunden; letztendlich würde die Heizung damit um ein Web-Frontend erweitert und der Rest wäre (fast) FHEM-Standard (naja, nicht für mich, aber egal ..)

@Andreas:
mit MQTT habe ich auch schon etwas herumgespielt und Daten der Heizung in eine JSON-DB (Cloudant) schreiben lassen (das war mit einem MCU-Board von Freescale, das kompatibel zu den Arduino-Shields ist).
Nach meinem Verständnis sind die Verbindungen über den Broker aber i.d.R. bestätigungslos (was für die Abfrage von Werten natürlich reichen würde) und daher ist mir nicht ganz klar, wie Kommandos von FHEM ("Vorlauftemperatur auf 60°C setzen" oder "Vorlauftemperatur um 2°C erhöhen") abgearbeitet und(!) auch quittiert werden können. Wegen der "Einschränkung" aus dem ersten Aspekt hatte ich mir das gar nicht mehr näher angeschaut (werde aber nochmal suchen).
Du schreibst ja auch von "... Steuerung von Sensoren": hast Du da ggf. noch Hinweise ? (würde mich auch für andere Themen als dieses Heizungsprojekt interessieren

)
Meinst Du mit der weiteren Variante, dass man den Arduino (oder die Heizung) direkt bzw. per USB an den den Raspi hängt ? Welches Modul wäre denn eigentlich für die dann relevante serielle Kommunikation zwischen FHEM und Arduino eine gute Vorlage ? Ich habe FHEM schon mal via ECMD mit dem Arduino sprechen lassen, aber wie ich das zu einem eignen Modul bringe, war mir nicht ganz klar (oder auch nicht nötig ?!?).

Liebe Grüße
Uwe

AndreasHH · 18 Dezember 2015, 17:11:33

Moin,

hier eine kurze Einführung in das MQTT-Protokoll im Bereich "Bestätigung" / ack

http://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels

Zur Anbindung von Arduino etc. an Raspi habe ich mir bisher keine tieferen Gedanken gemacht, da bei mir der Raspi zur Heizungssteuerung und Überwachung mit dem VControl-Modul und Opto-Link (seriell) arbeitet und somit FHEM2FHEM zum Einsatz kommt.
Für den Fall, dass ich GPIOs brauche würde ich die des Raspi nutzen.

http://www.fhemwiki.de/wiki/Raspberry_Pi:_GPIOs_schalten

Gruss

Andreas

Uef · 18 Dezember 2015, 17:57:34

Andreas, vielen Dank für die Links.

Den verwendeten QoS-Level müsste ich demnach dann auch in der Applikation berücksichtigen, da das mehrmalige Senden von "Vorlauftemperatur auf 60°C setzen" oder "Vorlauftemperatur um 2°C erhöhen" ja schon einen Unterschied macht - vor allem, wenn man nicht weiß, ob die Mitteilungen ankommen oder ggf. mehrfach verarbeitet werden.
Werde mir nochmal genauer anschauen, was die MQTT-Implementierungen für Arduino und FHEM bzgl. QoS unterstützen.

Die Nutzung des Raspi für IO ist zwar vermutlich auch nicht viel komplizierter als beim Arduino, aber ich habe aktuell zu wenig Zeit, um noch eine Hardware-nahe-Programmier-Front aufzumachen - da muss ich meine Ressourcen einfach etwas einteilen.

Gruss
Uwe

rudolfkoenig · 19 Dezember 2015, 18:45:56

Zitatd.h. FHEM pollt den (Webserver ? auf dem) Arduino bzw. schickt einen Befehl (ebenfalls via GET?) ?

Richtig.

ZitatDas mit den 2 Verbindungen habe ich noch nicht wirklich verstanden: meinst Du die Abarbeitung 2 unterschiedlicher GET-Befehle (?), von denen einer sofort, der andere im Falle eines Events beantwortet wird ?

Auch richtig. Die zweite Variante (longpolling) wuerde ich aber erst spaeter angehen.

AndreasHH · 19 Dezember 2015, 20:36:17

Moin,

ZitatDen verwendeten QoS-Level müsste ich demnach dann auch in der Applikation berücksichtigen, da das mehrmalige Senden von "Vorlauftemperatur auf 60°C setzen" oder "Vorlauftemperatur um 2°C erhöhen" ja schon einen Unterschied macht - vor allem, wenn man nicht weiß, ob die Mitteilungen ankommen oder ggf. mehrfach verarbeitet werden.
Werde mir nochmal genauer anschauen, was die MQTT-Implementierungen für Arduino und FHEM bzgl. QoS unterstützen.

Das MQTT-Modul unterstützt qos per
attr qos

Auf der Arduino-Seite wird sofern ich den Inhalt folgenden links richtig interpretiert habe qos 0 und 1 unterstützt, wobei qos 0 bereits ein ack zum Broker beinhaltet.

http://www.hivemq.com/blog/mqtt-client-library-encyclopedia-arduino-pubsubclient/

Gruss

Andreas

Uef · 20 Dezember 2015, 11:41:41

Danke für Eure Antworten.

@Rudi:
Dann habe ich jetzt eine bessere Vorstellung.
Ich muss eh erstmal mit den Basics beginnen.

Die beiden Verbindungen würden aber doch vermutlich auch (zumindest teilweise) parallel existieren können/müssen, da parallel zu einem "aktiven" Longpolling auch Kommandos von FHEM via GET erforderlich sein könnten. Oder würde man in so einem Fall vom Clients aus den "LongPolling-Request" abbrechen, das Kommando absetzen und nach dessen Abarbeitung einen neuen LongPolling-Request an den Server senden ?
Beziehungsweise: wie sollte sich ein FHEM-Modul da verhalten ? (sorry für die etwas grundlegenden Fragen zu den WebTechnologien bzw. FHEM , aber der Punkt ist mit nicht ganz klar und wegen der nachfolgend beschriebenen Einschränkung könnte sich der Arduino bereits deswegen als ungeeigent für die Aufgabe herausstellen).

Leider scheint nämlich der Arduino als WebServer nur mit Mühe mehrere Client-Connections (und max 4) zu unterstützen. Die bisherigen Implementierungen halten dabei die Clients (bzw. die Connections) wohl einfach anhand der IP-Adresse auseinander. Ob das und wie überhaupt für mehrere Verbindungen eines Clients (=FHEM) implementiert werden kann, muss ich nochmal versuchen herausfinden.
Das ist dann vermutlich das Thema Sockets ....
Eventuell muss ich da halt doch auf eine andere Plattform oder ein anderes Protokoll ...

@Andreas:
das ACK (bzw. kein Fehler im Returncode) bei Publish (nur QoS 0) bedeutet nach meinem Verständnis eigentlich nur, dass eine Verbindung zum Broker bestand bzw. die Message nicht zu groß war. Nicht unbedingt, dass der Broker sie erhalten hat. Aber immerhin ...

Na, ich werde das auf jeden Fall mal weiter verfolgen, auch wenn ich mir nicht sicher bin, ob es für eine Heizungssteuerung so das ganz Richtige ist (auch wenn ich eigentlich nur wenig eingreifen will).
Hängt aber auch vom Ergebnis des Themas Webserver (s.o.) ab ....
Für das Publishen der laufenden Heizungsparameter ist es aber sicher eine gute Option.

LG
Uwe

rudolfkoenig · 20 Dezember 2015, 11:48:20

Fuer die longpoll Loesung muesste die Implementierung mind. 2 Verbindungen vom gleichen Host (== gleiche IP) bedienen koennen. Auseinanderhalten muss man es anhand der Portnummer des Clients oder falls das einfacher ist, der Portnummer des Servers.
Auch ein Abbrechen ist moeglich, erfordert etwas mehr Netzwerk-Traffic. Um keine Events zu verpassen, muss der Client sie Puffern. FHEM wuerde dann "gib mir die Events ab Nummer X" absetzen.

justme1968 · 20 Dezember 2015, 12:35:27

nach meinen test funktionieren die web server auf arduinos nicht sehr zuverlässig. auch das pollen von fhem aus finde ich immer unschön. wenn der sensor/aktor von sich aus sendet hat das zusätzlich auch noch den vorteil das nur an einem ende der verbindung etwas zu konfigurieren ist und nicht an beiden.

hast du dir mal überlegt ob der arduino vielleicht einfach per broadcast oder mulitcast seine readings los wird und fhem einfach lauscht was kommt? ein beispiel findest du hier: http://forum.fhem.de/index.php/topic,45545.msg373296.html#msg373296. auf fhem seite wäre mit dem KeyValueProtokoll modul alles vorhanden.

nur für die gegenrichtung müsstest du dann noch etwas einbauen.

gruss
andre

Uef · 21 Dezember 2015, 21:10:11

@Rudi:
Danke, das ist dann glaube ich soweit klar. Muss jetzt mal die anderen Punkte klären.....

@Andre:
Danke für den Hinweis.
Hast Du die Erfahrungen mit allen bzw. generell mit TCP-Servern auf dem Arduino gemacht (also z.B. auch mit Telnet o.ä.) oder 'nur' speziell mit den HTTP-Implementierungen ?
Sonst wäre der Telnet-Weg ja eine Option für die Gegenrichtung.

Broadcast wäre sicher auch eine Möglichkeit. Muss ich mir auch mal anschauen; KeyValueProtokoll sagt mir bisher leider gar nichts ....
Das wäre dann ähnlich wie Andreas' Vorschlag mit MQTT .....

@all:

Ein Fallback-Plan, falls das mit dem Webserver nicht stabil klappt, wäre ja noch ( wie bereits von Andreas vorgeschlagen):

Heizung <--> Arduino <--(USB)--> RaspI(mit FHEM) <--(FHEM2FHEM)--> FHEM-Haupt-Server

Ist zwar HW-technisch etwas Overkill, reduziert für mich aber (erstmal) die Komplexität um die Programmierung des ganzen HTTP-Teils auf beiden Seiten (den zusätzlichen Raspi direkt als Heizungsinterface und WebServer zu programmieren, traue ich mir aktuell nicht zu).
Welches Modul kann ich mir denn am besten mal als Beispiel her nehmen, bei dem ein FHEM-Modul seriell mit einem via USB angeschlossenen Device(Arduino?) kommuniziert ?
Es gibt doch vermutlich noch etwas anderes als ECMD ....

Oha, da habe ich mir ja 'was vorgenommen .....

Vielen Dank für Euren Input soweit !

LG
Uwe