5 Gründe zur Erweiterung deines FHEM-Servers mit Loxone + Howto
Glaubt man den Versprechen der Hersteller, dann ist Smart Home der Sammelbegriff schlechthin für Alles, was im Bereich der eigenen vier Wände blinkt, schaltet, misst und heizt – am besten per Smartphone. Dabei gilt es jedoch unterschiedliche Stufen des Smart Homes zu unterscheiden: Wann ist ein Zuhause wirklich “intelligent”? In diesem Howto möchte ich darstellen, wie man Schritt für Schritt eine Nachrüsterlösung auf das nächste Level in Sachen intelligenter Automatisierung bringen kann. Dabei wird eine bestehende FHEM-Lösung durch den Einsatz eines Loxone Miniserver Go (Affiliate-Link) ergänzt und zum perfekten Nachrüst-Smart-Home getunt.
Vorab: Hier der Loxone Onlineshop meines Vertrauens, sofern ihr “akuten” Bedarf habt: smarthirsch.de (Affiliate-Link)
Lange Zeit war es still um mich. Während Jörg rund um seine “Operation Smart Home“, sein Hausbauprojekt, zahlreiche Beiträge zu dem Thema Smart Home im Neubau verfasst hat, habe ich die Zeit genutzt und das Smart Home in meinem Kontext, dem Nachrüsterbereich, reflektiert. Ich habe bisher nahezu ausschließlich auf FHEM gesetzt und bin gerade wegen der Offenheit des Systems auch nach wie vor einer der größten Fans der Open-Source-Lösung.
Bei der Analyse meiner umgesetzten Szenarien und meiner mittels PERL programmierten Smart-Home-Logik, habe ich allerdings erkannt, dass sich zu häufig das Spielkind in mir durchgesetzt hat. Während ich einerseits zahlreiche, total verspielte Szenarien realisiert hatte, z.B. die Temperaturüberwachung im Gefrierschrank mit leisem Warnton über den Rauchmelder bei signifikantem Temperaturanstieg, falls ein Bewohner zuhause war, stellte ich fest, dass wirklich zentrale Smart-Home-Szenarien mit vom System bereitgestellter Intelligenz, wie z.B. eine ordentliche, automatisierte und intelligente Heizungssteuerung, ausbaufähig oder gar nicht vorhanden waren.
Häufig funktionierten Abläufe dann im echten Betrieb nicht, weil ich gerade mal wieder etwas “ausprobiert” hatte oder anfängliche Freude und Nutzung des vorher sehr aufwändig programmierten Features ließen schnell nach, weil man nach vier Wochen eben kein Interesse mehr daran hat, das RGBW-LED-Stripe hinter dem TV mit dem Smartphone fernzusteuern. Ich habe also festgestellt, dass mein Smart Home kein solches war und es dringend Nachholbedarf in Sachen intelligenter Regelung zentraler Funktionen gab. Das nächste Level, das Smart Home 3.0, musste erklommen werden!
Da allein aus Kostengründen ein kompletter Austausch des gesamten Smart-Home-Systems nicht in Frage kam, habe ich nach einer Upgrade-Lösung gesucht und mit dem Loxone Miniserver Go (Affiliate-Link) gefunden!
Warum FHEM mit Loxone upgraden? 5 ultimative Gründe!
Die Antwort auf die Frage, weshalb ein bestehendes FHEM Smart Home mit Loxone upgegradet werden kann, ist einerseits in den Vorteilen von Loxone und andererseits in den Nachteilen von FHEM zu finden. Die folgenden 5 Gründe sind dabei allerdings nicht als Wechselgründe von FHEM auf Loxone zu verstehen, sondern wirklich als Argumente für eine Erweiterung des bestehenden FHEM-Servers.
1. Professionelle Smart-Home-Visualisierung nutzen!
Während FHEM eine am Markt einzigartige Integrationsbreite besitzt und mit zahlreichen Systemen interagieren kann, liegen die “Schwächen” des Systems eindeutig in dessen Visualisierung. Hier kommen die Potentiale von Loxone ins Spiel. Das System beeindruckt durch eine klare, nicht verspielte und einfach zu bedienende Visualisierung, die sich automatisch aus der Konfiguration heraus erstellt. Loxone hat somit im direkten Vergleich zu FHEM eine deutlich ansprechendere und einfacher zu erstellende Visualisierung. Der nachfolgende, graphische Vergleich sollte klar machen, was damit gemeint ist.
2. Einfacher programmieren dank Bausteinen!
Smart-Home-Szenarien unterschiedlichen Schwierigkeitsgrades lassen sich in FHEM allesamt einzig und allein mittels PERL Code realisieren. Dies ermöglicht zwar einerseits Freiheit in der Programmierung, jedoch ist der PERL-Code für Einsteiger schwerer zu erlernen als eine Drag-and-Drop-Programmierung mit Bausteinen. Außerdem wird ein wachsendes Smart Home mit zunehmender Anzahl an Geräten, Szenarien und Abläufen selbst für “Profis” schnell unübersichtlich.
Die bausteinbasierte Programmierung von Loxone ermöglicht hingegen durch Verbindung gewisser Logikbausteine miteinander einerseits und mit Geräten im Smart Home andererseits ein schnelles Erlernen und einen guten Überblick, selbst bei gewachsenen Installationen. Dank der eingebauten Hilfe-Funktion mit detaillierter Beschreibung aller Ein- und Ausgänge für jeden Baustein, kann jeder Einsteiger – Technikaffinität vorausgesetzt – hier schnell Erfolge erzielen, zumindest schneller als mit PERL-Code.
3. Besser programmieren durch eingebaute “Intelligenz”!
Die Loxone-Bausteine ermöglichen es einerseits, einfacher zu programmieren. Andererseits sind diese Logikbausteine ferner bereits von Haus aus mit einer gewissen “Intelligenz” ausgestattet, die eine individuelle Programmierung in vielen Fällen überflüssig macht (Smart Home 3.0).
Als Beispiel kann hier die “Fuzzy”-Logik im Baustein für die zentrale Heizungsregelung genannt werden, die für jeden Raum selbstlernend aus der Dauer von Temperaturänderungen die notwendigen Aufheizphasen berechnet, damit zur gewünschten Uhrzeit tatsächlich die gewünschte Temperatur herrscht – nicht früher und nicht später. Derartige “Intelligenz” ist in zahlreichen weiteren Loxone-Bausteinen zu finden, die eine qualitativ weitaus bessere Programmierung ermöglichen als über FHEM. Nachfolgend ist beispielhaft ein Screenshot aus der Heizzeiten-Tabelle in Loxone zu sehen.
4. Freiheit durch nahezu unbegrenzte Systemauswahl!
Würde man von FHEM auf Loxone umsteigen, müsste die Liste der Vorteile hier enden. Hier soll jedoch gezeigt werden, warum es sinnvoll ist, einen bestehenden FHEM-Server mit Loxone zu erweitern. Denn auch der FHEM-Server hat seine Vorteile, die es mit denen des Loxone-Servers zu kombinieren gilt.
Obwohl Loxone zahlreiche Protokolle und Systeme integriert (z.B. EnOcean, KNX, 1wire, DALI oder DMX), ist eine Plattformoffenheit wie bei FHEM nicht annähernd gegeben, die nicht nur funktional gesehen zahlreiche Vorteile bietet, sondern auch den Geldbeutel schont: Für jeden speziellen Einsatzzweck kann mit FHEM das passende (bzw. preislich attraktivste) System ausgewählt werden.
FHEM-User erweitern das FHEM-Anwendungsspektrum täglich durch die Entwicklung systemspezifischer Module, die per Update-Funktion Teil der FHEM-Standardsoftware werden. Als Beispiel können hierfür die Technoline Funk-Temperatur-Luftfeuchtigkeitssensoren (Affiliate-Link) genannt werden (siehe: FHEM mit JeeLink: Luftfeuchte und Temperatur zum Low-Cost-Tarif messen).
Mit Hilfe eines Jeelink-USB-Transceivers kann hier eine sehr gute und preislich hoch attraktive Raumüberwachung hinsichtlich Temperatur und Luftfeuchtigkeit realisiert werden, die mittels eines FHEM-Servers derart verarbeitet wird, dass z.B. HomeMatic- oder EnOcean-Komponenten diese Informationen nutzen und gewisse Aktionen starten können. Diese breite Palette nutzbarer und mittels FHEM interoperabel verwendbarer Systeme bzw. Protokolle ist der Vorteil von FHEM schlechthin, weshalb ein kompletter Umstieg auf Loxone hier auch Nachteile beinhalten würde.
5. Unbegrenzte Smart-Home-Szenarien
Schließlich ist der PERL-Code-Nachteil von FHEM auch gleichzeitig wieder ein Vorteil, wenn es darum geht, unbegrenzt verrückte Szenarien im Smart Home zu realisieren. Durch die PERL-basierte Programmierung sind einem hier keine Grenzen gesetzt. Die vorgefertigten Logik-Bausteine von Loxone können so über FHEM stark erweitert werden. Als Beispiel hierfür kann die Bluetooth-basierte Anwesenheitserkennung von Personen im Haushalt genannt werden, die so in Loxone nicht umgesetzt werden kann, über FHEM auf einem Raspberry Pi hingegen mit einfachsten Mitteln Realität wird.
Step-by-Step zum Upgrade der Extraklasse
Da auch Loxone über APIs und Schnittstellen verfügt, ist es möglich, das Herzstück eines Loxone-Setups, den Loxone Miniserver (bzw. den günstigeren Miniserver Go (Affiliate-Link)), mit einem FHEM-System zu verbinden. Dadurch bleiben die Plattformunabhängigkeit und die Freiheit der Smart-Home-Szenarien von FHEM bestehen und die Potentiale der Loxone-Logik, -Programmierung und -Visualisierung können zusätzlich in vollem Umfang genutzt werden: Ein Upgrade, das sich schnell lohnen kann!
In diesem Howto wird Schritt für Schritt gezeigt, wie dieser Upgrade funktioniert.
1. Schritt: Inbetriebnahme des Loxone Miniservers (Go)
Zunächst sollte man einen funktionierenden FHEM-Server, beispielsweise auf einem Raspberry Pi, laufen haben. Ein upgedateter Artikel zur Installation von FHEM ist hier zu finden: FHEM-Server auf dem Raspberry Pi in weniger als einer Stunde einrichten.
Der Einstieg in das Loxone-Universum erfolgt dann über den Erwerb eines Miniserver. Hier gibt es zwei verschiedene Varianten: Den originären Miniserver (Affiliate-Link) zur Montage auf einer Hutschiene (hat zahlreiche digitale und analoge Ein- bzw. Ausgänge, KNX-Link und Schaltrelais an Bord) oder den günstigeren Miniserver Go (Affiliate-Link) mit eingebautem Funk-Gateway für Loxone-Air-Komponenten. Beide Miniserver-Varianten verfügen über die gleiche Programmier- und Visualisierungsoberfläche. Für den hier vorgestellten Zweck, einen FHEM-Server zu erweitern, bietet sich vor allem wegen des günstigeren Preises der Miniserver Go besonders gut an.
Die Erstinstallation ist relativ einfach und straight forward: Hardwareseitig muss lediglich eine Stromversorgung per USB und eine Netzwerkverbindung per Ethernet hergestellt werden. Mit der Loxone Config Software, die es leider nur für Windows gibt, wird der Miniserver Go schnell im Netzwerk gefunden und mit den essentiellen Informationen gefüttert. Ich nutze Parallels (Affiliate-Link) auf dem Mac, um eine Windows-Umgebung zu simulieren.
Ist der Miniserver Go erst einmal eingerichtet, geht es an das Eingemachte, um die Kommunikation des vorhandenen Smart Homes mit Loxone umzusetzen.
2. Schritt: UPD-Kommunikation in FHEM einrichten
In diesem Howto zur Erweiterung von FHEM durch Loxone, wird die Kommunikation vom FHEM-Server zum Loxone Miniserver über UDP (User Datagram Protocol) ablaufen. Mit Hilfe dieses Netzwerkprotokolls wird FHEM sämtliche Informationen über seine Geräte wie Sensoren und Aktoren an Loxone weitergeben. FHEM agiert dann sozusagen dem Loxone Miniserver “vorgeschaltet”. Dazu wird zunächst FHEM-seitig die UPD-Kommunikation eingerichtet.
Hierzu wird in FHEM in der Datei “99_myUtils.pm” (zu finden im FHEM-Webinterface über “Edit files” -> “99_myUtils.pm”) folgender Code eingefügt (Achtung! Stelle im Code beachten: Nach “# Enter your functions below _this_ line.” einfügen).
#UDP Befehle senden sub UDP_Msg($$) { my ($dest,$port,$cmd) = @_; my $sock = IO::Socket::INET->new( Proto => 'udp', PeerPort => $port, PeerAddr => $dest ) or die "Could not create socket: $!\n"; $sock->send($cmd) or die "Send error: $!\n"; return "send $cmd"; }
Hierdurch ist FHEM jetzt grundsätzlich für die UDP-Kommunikation vorbereitet.
3. Schritt: UDP-Befehle aus FHEM senden
Im dritten Schritt muss FHEM-seitig definiert werden, wann welche Werte an Loxone übergeben werden sollten. Dies sollte der Einfachheit halber pro Device-Klasse gemacht werden (z.B. Alle On/Off-Geräte, alle Temperatursensoren, alle …).
Hierzu wird in FHEM in der Datei “fhem.cfg” (zu finden im FHEM-Webinterface über “Edit files” -> “fhem.cfg”) für jede Status-Art ein eigener notify-Code hinterlegt. Nachfolgend ist der Code für die folgenden “Status”-Arten aufgeführt:
- Lichter, Lampen, Schaltaktoren: Geräte mit den Status “on” und “off”
- Fenster und Türen: Geräte mit den Status “open”, “closed” und “tilted”
- Temperatursteuerung: Geräte, die Werte vom Typ “measured-temp”/”temperature” und “desired-temp” erfassen
- Bewegungserkennung: Geräte mit dem Status “motion”
- Spezialanwendungen Energiemessung: Status “sensor” meiner Eltako-Hutschienen-Energieverbrauchsmessung
define OnOffToLoxone notify .*:(on|off) {OnOffToLoxone("$NAME")} define OpenClosedToLoxone notify .*:(open|closed|tilted) {OpenClosedToLoxone("$NAME")} define ClimateToLoxone notify .*:measured-temp.* {ClimateToLoxone("$NAME")} define ClimateToLoxone2 notify .*:desired-temp.* {ClimateToLoxone("$NAME")} define EnergyToLoxone notify .*:sensor3.* {EnergyToLoxone("$NAME")} define EnergyToLoxone2 notify .*:current.* {EnergyToLoxone2("$NAME")} define MotionToLoxone notify .*:motion.* {MotionToLoxone("$NAME")} define TempHumidityToLoxone notify .*:temperature.* {TempHumidityToLoxone("$NAME")}
Dieser Code legt fest, dass sobald ein Device einen dieser Status aktualisiert (z.B. “on” oder “off”, “open”, “closed” oder “tilted”, usw.), eine Funktion zur UDP-basierten Übertragung der neuen Statuswerte an Loxone angetriggert wird. Diese Funktionen werden jetzt noch in die Datei “99_myUtils.pm” eingetragen. Dazu kann der nachfolgende Code verwendet werden.
Für jede Funktion muss hier noch die IP-Adresse an die des eigenen Loxone-Servers angepasst werden (hier: 192.168.178.76).
#OnOffToLoxone #device: #1 state(0,1) #2 pct(0-100) sub OnOffToLoxone($) { my ($device) = @_; my $state = ReadingsVal("$device","state","-1"); if ($state eq "on") { $state = "1"; } if ($state eq "off") { $state = "0"; } my $pct = ReadingsVal("$device","pct","-1"); #fhem("set $device: $state $pct"); UDP_Msg("192.168.178.76" , "7000" , "$device: $state $pct"); } #OpenClosedToLoxone #device #1 state(0,1) #2 alive(1-0) #3 battery(0,1) sub OpenClosedToLoxone($) { my ($device) = @_; my $state = ReadingsVal("$device","state","-1"); if ($state eq "closed") { $state = "0"; } if ($state eq "open") { $state = "1"; } if ($state eq "tilted") { $state = "2"; } my $alive = ReadingsVal("$device","alive","-1"); if ($alive eq "yes") { $alive = "1"; } if ($alive eq "no") { $alive = "0"; } my $battery = ReadingsVal("$device","battery","-1"); if ($battery eq "ok") { $battery = "1"; } if ($battery eq "low") { $battery = "0"; } my $sabotage = ReadingsVal("$device","sabotageError","-1"); if ($sabotage eq "on") { $sabotage = "1"; } if ($sabotage eq "off") { $sabotage = "0"; } UDP_Msg("192.168.178.76" , "7000" , "$device: $state $alive $battery $sabotage"); } #ClimateToLoxone #device: #1 measured-temp #2 humidity #3 alive #4 battery #5 desired-temp #6 controlMode #7 dewpoint sub ClimateToLoxone($) { my ($device) = @_; my $measuredTemp=ReadingsVal("$device","measured-temp","-1"); my $humidity=ReadingsVal("$device","humidity","-1"); my $alive = ReadingsVal("$device","alive","-1"); if ($alive eq "yes") { $alive = "1"; } if ($alive eq "no") { $alive = "0"; } my $battery = ReadingsVal("$device","battery","-1"); if ($battery eq "ok") { $battery = "1"; } if ($battery eq "low") { $battery = "0"; } my $desiredTemp=ReadingsVal("$device","desired-temp","-1"); my $controlMode=ReadingsVal("$device","controlMode","-1"); if ($controlMode eq "manual") { $controlMode = "0"; } if ($controlMode eq "auto") { $controlMode = "1"; } my $dewpoint=ReadingsVal("$device","dewpoint","-1"); my $actuator=ReadingsVal("$device","actuator","-1"); UDP_Msg("192.168.178.76" , "7000" , "$device: $measuredTemp $humidity $alive $battery $desiredTemp $controlMode $dewpoint $actuator"); } #EnergyToLoxone sub EnergyToLoxone($) { my ($device) = @_; my $energy=ReadingsVal("$device","sensor3","-1"); UDP_Msg("192.168.178.76" , "7000" , "$device: $energy"); } #Energy2ToLoxone sub Energy2ToLoxone($) { my ($device) = @_; my $energy=ReadingsVal("$device","current","-1"); UDP_Msg("192.168.178.76" , "7000" , "$device: $energy"); } #MotionToLoxone sub MotionToLoxone($) { my ($device) = @_; my $motion=ReadingsVal("$device","motion","-1"); if ($motion eq "on (to HMLAN1)") { $motion = "1"; } UDP_Msg("192.168.178.76" , "7000" , "$device: $motion"); } #TempHumidityToLoxone sub TempHumidityToLoxone($) { my ($device) = @_; my $temperature=ReadingsVal("$device","temperature","-1"); my $humidity=ReadingsVal("$device","humidity","-1"); UDP_Msg("192.168.178.76" , "7000" , "$device: $temperature $humidity"); }
Ab diesem Schritt sendet FHEM sämtliche Änderungen seiner Geräte per UDP an den Loxone Server. Nun gilt es, diese Informationen Loxone-seitig zu verarbeiten.
3. Schritt: UDP-Informationen in Loxone empfangen und verarbeiten
In Loxone muss nun zunächst per Hand jedes Smart-Home-Device angelegt werden. Dazu geht man am besten Raum für Raum vor. Da die Anlage neuer Geräte in Loxone sehr einfach und unkompliziert von der Hand geht, ist dieser Schritt, der zunächst nach viel Arbeit klingt, relativ schnell erledigt.
Zuerst wird der FHEM-Server als virtueller Eingang in Loxone angelegt. Hierfür wird in der Loxone-“Peripherie”, wie auf dem Screenshot zu erkennen ist, zuerst der Bereich “Virtuelle Eingänge” angeklickt (1) und im Anschluss im oberen Bereich ein neuer “Virtueller UDP Eingang” angelegt (2). Dieser wird benannt (z.B. FHEM UDP) (3) und im Anschluss im linken “Eigenschaften”-Bereich auf den Port 7000 eingestellt (4).
Durch diesen virtuellen UDP-Eingang ist Loxone nun empfangsbereit und erhält bei Statusänderungen in FHEM sofort Meldung. Diese Meldungen gilt es nun zu verarbeiten. Daher werden jetzt eingangsseitig sämtliche Smart Home Devices in Loxone als “Virtuelle UDP Eingang Befehle” angelegt. Dazu wird wie folgt vorgegangen.
Zunächst wird der gerade eben angelegte “Virtuelle UDP Eingang” angewählt (1). Anschließend wird im oberen Navigationsbereich durch Klick ein neuer “Virtueller UDP Eingang Befehl” angelegt (2). Dies entspricht einem Smart Home Device in FHEM. Der Übersicht halber kann anschließend im linken Bereich eine frei gewählte Bezeichnung vergeben werden (3). Der wichtigste Teil folgt nun im Rahmen der sog. Befehlserkennung (4). Hier muss der exakte Name des Devices, so wie es in FHEM benannt ist, angegeben werden, gefolgt von einem Doppelpunkt und einem “\v”, was bedeutet, dass der erste Wert (v) der UDP-Nachricht nach dem Device-Namen verarbeitet werden soll.
Für ein Device, das in FHEM “Sz.Temp” heißt und z.B. Temperatur sowie Luftfeuchtigkeit misst, muss dann jeweils ein eigener Befehl angelegt werden. Im Screenshot ist der Befehl für den Empfang der Temperatur dargestellt, weil die in FHEM angelegte Funktion Werte vom Typ Heizungs- bzw. Temperatur-Devices in folgender Reihenfolge übermittelt (vgl. Code in der 99_myUtils):
UDP_Msg(“192.168.178.76” , “7000” , “$device: $measuredTemp $humidity $alive $battery $desiredTemp $controlMode $dewpoint $actuator”)
Das heißt, dass “measured-temp”, also die gemessene Temperatur, der erste Wert in der UDP-Nachricht ist, “humidity”, also die Luftfeuchtigkeit, der zweite Wert, usw. Diese Reihenfolge ist ausschlaggebend für die “Befehlserkennung” in Loxone. Wie gezeigt, wird also der erste Wert des Devices “Sz.Temp” in Loxone wie folgt erkannt: “Sz.Temp: \v”. Der zweite Wert würde dann wie folgt erkannt werden: “Sz.Temp: \# \v” usw…
Entsprechend diesem Ablauf wird für jedes FHEM Device ein sog. “Virtueller UDP Eingang Befehl” in Loxone angelegt, damit die per UDP erhaltenen Nachrichten interpretiert und empfangen werden können.
4. Schritt: Schaltbefehle von Loxone an FHEM weitergeben
Während für alle Smart Home Devices der Kategorie “Sensor” die Integration in Loxone abgeschlossen ist, da hier lediglich eine unidirektionale Kommunikation vorliegt, muss für bidirektionale Devices, wie z.B. alle Aktoren, auch die Senderichtung in Loxone implementiert werden. Analog zum “Virtuellen UDP Eingang” wird hierfür ein Ausgang angelegt. Allerdings wird zur ausgehenden Kommunikation nicht UDP sondern HTTP als Protokoll genutzt.
Das Vorgehen ist analog zur Anlage eines “Virtuellen Eingangs”. Dafür wird zunächst der Bereich “Virtuelle Ausgänge” in der Loxone Peripherie markiert (1). Anschließend wird ein neuer “Virtueller Ausgang” angelegt (2). Dieser kann zur Übersicht z.B. “FHEM HTTP” genannt werden (3). Im Bereich der Adresse im Eigenschaften-Feld links wird die URL des FHEM-Servers in folgendem Format eingegeben: http://Nutzer:Passwort@IP-ADRESSE-FHEM-SERVER
Analog dem Vorgehen auf der Eingangsseite, wird nun auch hier unter dem eben angelegten HTTP-Ausgang pro Smart Home Device der Kategorie “Aktor” ein Ausgangs-Befehl angelegt.
Dazu wird zunächst wieder der “Virtuelle Ausgang” markiert (1) und anschließend im oberen Navigationsbereich ein “Virtueller Ausgang Befehl” angelegt (2). Jetzt werden noch die HTTP-Commands zum An- bzw. Ausschalten vergeben (3) (4). Die Syntax dafür ist z.B. für das Device “Ga.Licht” wie folgt: “/fhem?cmd=set Ga.Licht on” bzw. “/fhem?cmd=set Ga.Licht off”. Handelt es sich um ein Heizungs-Device, wird lediglich im Feld “Befehl bei EIN” (3) ein Befehl in der Syntax “/fhem?cmd=set Ga.Heizung desired-temp <v>” eingetragen.
Alle Sensor-Devices in FHEM sind nun mittels UDP an Loxone angebunden sowie alle Aktor-Devices per UDP und HTTP in beide Kommunikationsrichtungen angeschlossen. Die Verbindung steht also und kann im weiteren Verlauf zur Programmierung des Smart Home genutzt werden.
5. Schritt: Smart Home programmieren
Im letzten Schritt kann es dann endlich ans Eingemachte gehen: Die Programmierung mit den Loxone-Logikbausteinen steht an. Hierfür wird im rechten Fenster (im unteren Bildbereich) zunächst eine neue Programmierseite angelegt (1) und anschließend benannt (2) und einem Raum zugewiesen (3). Danach kann aus der Baustein-Liste (erscheint beim Tastendruck F5) ein Logikbaustein in die neue Seite gezogen werden (4) (hier z.B. die Lichtsteuerung für den Raum Wohnzimmer).
An den Aus- (5) und Eingängen (6) eines Bausteins werden dann die in FHEM angelegten Smart Home Devices per Drag and Drop aus dem Peripheriebaum in der Mitte in die Programmierseite hinübergezogen und verbunden. Mit den Ausgängen am Lichtsteuerungs-Baustein sind beispielsweise Lichter verbunden, mit den entsprechenden Eingängen z.B. Taster. Was ein Baustein kann und was die Ein- bzw. Ausgänge bedeuten, kann über einen Klick auf das “i” am rechten oberen Rand des Bausteins herausgefunden werden.
Das Upgrade der Extraklasse ist gemeistert! Mit der iPhone App von Loxone oder über das Webinterface lässt sich die Visualisierung des Smart Home aufrufen. Auch hier können einige Einstellungen (z.B. Heizzeiten) vorgenommen werden.
Aus meinem täglichen Leben
Ich bin sehr froh, mit Loxone eine Lösung gefunden zu haben, die meinen Ansprüchen an Visualisierung, Intelligenz und Programmierung gerecht wird. Dass ich meine bisherigen Smart Home Devices von HomeMatic, FS20, EnOcean etc. über FHEM dank der hier gezeigten Upgrade-Methode weiterhin nutzen kann, hat das Ganze auch preislich sehr interessant gemacht.
Ich rüste nun Schritt für Schritt auch die Szenarien in FHEM ab und übertrage die Logik aus dem frickeligen PERL Code in die intelligente Programmierumgebung von Loxone. So erhalte ich mit dem Loxone Miniserver Go (Affiiate-Link) das höchste Maß an Smart Home 3.0, das man im Nachrüsterbereich aktuell haben kann! Für mich eine komplett zufriedenstellende Lösung, die vermutlich auch für andere Anwender interessant sein wird.
142 Kommentare
Hi Christoph,
super Zusammenfassung und tolle Anleitung! Vielen Dank dafür.
Ich bin dabei unseren Neubau mit Loxone auszustatten und würde dann eher von der anderen Richtung kommen und evtl. mit FHEM erweitern. Was mich aber etwas von der Lösung abhält ist das Thema Sicherheit.
Die reine UDP Anbindung öffnet natürlich für “böse” Netzwerkpakete Tür und Tor… Ist hier das Thema Verschlüsselung möglich oder eine andere Verbindungsmethode? Andernfalls müsste man über VLAN’s nachdenken zur Isolierung der Kommunikation.
Viele Grüße,
Benni
Die “bösen” Netzwerkpakete würde ich bei der UDP-Anbindung garnicht als das größte Problem sehen sondern UDP selbst. UDP bietet keinerlei Transaktionssicherheit, d.h. es gibt keine Garantie, das ein ausgesendetes Packet auch tatsächlich beim Empfänger ankommt (im Gegensatz zu TCP und darauf aufbauenden Protokollen wie HTTP). Dadurch ist es möglich, dass Pakete verloren gehen, weil das Netzwerk gerade z.B. mit einem HD-Videostream voll ausgelastet ist.
Statt UDP lässt sich genauso auch HTTP nutzen. Das habe ich auch schon einmal im Artikel Integration: Daten zwischen Loxone und FHEM austauschen beschrieben.
Ich selbst nutze die UDP-Anbindung übrigens auch schon seit knapp 2 Jahren in einem teilweise recht “ausgelasteten” Netzwerk, bisher ohne Probleme.
Aber danke für den Hinweis, der natürlich plausibel klingt. Da ich beim anstehenden Neubau sowieso auf der grünen Wiese anfange, werde ich mir das Thema HTTP auch noch einmal genauer durch den Kopf gehen lassen.
Grüße
Jörg
Ja, da hat Reiner natürlich noch einen weiteren Punkt angesprochen der auf jeden Fall zu berücksichtigen ist. Die Robustheit des Systems ist natürlich davon abhängig, dass die Pakete nicht verloren gehen. Ich denke zu 99% sollte das auch hinhauen (wie Jörg ja auch bestätigt), aber darauf verlassen kann man sich eigentlich nicht. Die Frage ist, ob einem das stört. Bei Funk ist das ja ähnlich, sollte zu 99% funktionieren, kann aber auch mal gestört sein.
Grüße,
Benni
Danke für den interessanten Bericht, allerdings ist der Umstieg nicht ganz so einfach. Für mich kein Thema, da Z-Wave von Loxane nicht unterstützt wird.
Wenn man sich wie ich als (Programmier)neuling erst mal mit FHEM eingehend beschäftigt hat und PERL Befehle in den Grundzügen versteht, um diese einzusetzen, wird sehr zufrieden mit FHEM sein. Für mich wäre es schade, die Erfahrung und das Know-How, welches ich mir mit FHEM erworben habe, nicht mehr zu nutzen.
Hallo Tom,
absolut richtig. Genau deshalb ist die Kombo von FHEM + Loxone unschlagbar. Zentrale Themen über Loxone abbilden, Extra-Szenarien in PERL über FHEM coden! Durch die Weiternutzung von FHEM kannst du deine Z-Wave-Hardware dann auch mit Loxone nutzen!
Viele Grüße
Christoph
Ich bin momentan dabei meine neue Wohnung mit einem Loxone-Grundsystem, erweitert um FHEM und KNX in Betrieb zu nehmen.
Vorteil ist in meinen Augen vor allem die Zukunftssicherheit.
Loxone passt hervorragend in mein System und ist optisch wunderschön – allerdings stört mich ein wenig der Fokus auf Tree und Air, anstatt KNX und Z-wave besser zu integrieren.
Durch FHEM habe ich aber immerhin alle Möglichkeiten mich jederzeit in eine andere Richtung zu entwickeln. Euer Blog ist mir dabei schon oft eine große Hilfe gewesen.
Interessant wäre für mich eine Alternative für den Loxone Music Server für mein verkabeltes Multiroom-System. Habt ihr diesbezüglich Erfahrungen mit dem Logitech Squeeze System?
Hi Nico,
ich sehe das Ähnlich wie du. Aus Unternehmenssicht ist es aber klar, dass Loxone primär eigene Lösungen wie Tree bzw. Air pusht. Loxone sieht sich eben nach wie vor als Hardwareunternehmen und erzielt Gewinne ausschließlich über eigene Hardwarekomponenten. Schade ist dabei natürlich, dass “fremde” Protokolle wie KNX eher halbherzig implementiert sind (z.B. Jalousiesteuerung) und auch keine Weiterentwicklung auf diesem Gebiet zu erwarten ist. Zum Glück gibt es viele Workarounds, aber entsprechend ist die Einrichtung auch aufwändiger.
Ich habe den Loxone Music Server schon länger im Testeinsatz und bin damit insgesamt sehr zufrieden. Gerade die Integration in die Loxone-Umgebung ist natürlich super gelöst. Auf der anderen Seite kostet die “Hardware” schon wirklich Kohle, keine Frage. Mit dem Squeeze-System wollte ich mich auch schon länger einmal intensiver auseinandersetzen. Auf den ersten Blick ist das aber nach wie vor eher frickelig und ermöglicht auch erstmal keine “sexy” Visualisierung per Loxone-App, was zumindest für mich wichtig ist.
Grüße
Jörg
Hallo Christoph,
Habe auch schon überlegt fhem in mein loxone system zu integrieren, da es von loxone noch keine Air Licht dimmer gibt. Suche daher nach einer Lösung mit der ich von loxone aus Funk dimmer steuern kann. Ist das für Dimmer eines FHEM systems genauso möglich wie für on-off Aktoren diese in loxone zu integrieren oder gestaltet sich das ganze etwas komplizierter? ich meine vor allem was die PERL Programmierung angeht, bin damit nicht so bewandert.
Gruß, Anatol
Hallo Anatol,
das müsste entsprechend der Heizungs-Logik auch funktionieren. Dim-Befehle werden in FHEM ja z.B. als “set xyz dim 50” umgesezt. Mit einem Loxone-Befehl bei “EIN”, der in etwa wie folgt aussieht, geht das dann genau so: /fhem?cmd=set Dimmer dim
Viele Grüße
Christoph
Hallo,
ein interessanter Artikel, wie immer. Danke.
Allerdings kann ich nicht alle Gründe so ganz nachvollziehen. Das user interface ist sicherlich nicht mehr zeitgemäß, aber mit FTUI und smartVISU gibt es hier einfach zu implementierende Erweiterungen, deren Flexibilität von einer APP niemals erreicht werden wird.
Die unbegrenzte Systemauswahl habe ich in FHEM schon. Welche Erweiterung bringt mir Loxone konkret, die in FHEM nicht vorhanden ist?
Im Gegenteil, wenn ich vorhandene Infrastruktur in Loxone nutzen möchte, muss ich erst das Interface für jeden Sensor/Aktor implementieren?
Bleibt einzig die graphische Oberfläche und die vermeintlich einfachere Programmierung, wenn man Perl nicht beherrscht. Beides Software-Aspekte, die ich persönlich mir nicht mit zusätzlicher Hardware einkaufen würde.
Gruß
Jo
Hi Jo,
das ist sicherlich Ansichtssache, weshalb ich deinen Punkt gut nachvollziehen kann. Grundsätzlich kann man natürlich mit einer Sprache wie PERL immer auch das umsetzen, was eine SW-Umgebung wie Loxone Config kann. Mit smartVISU und co. kann man dann sicherlich auch mit ähnlich hohem Aufwand Visualisierungen entwickeln, die deutlich zufriedenstellender sind als der FHEM-Standard.
Die Frage ist jedoch sicherlich, wie lange es dauern würde, bzw. wie komplex der Code werden würde, wenn man die in den Loxone-Bausteinen implementierten Heuristiken und Logiken nachbauen müsste.
Ich nehme erneut die Fuzzy-Logik in der Heizungssteuerung -> Ein Feature, das ich im Smart Home nicht mehr missen möchte, gerade in der Heizperiode! Weitere Beispiele sind Loxone-Bausteine zur Steuerung von Raffstoren, bei denen exakt das Ablaufverhalten (Neigung, Steigung, Senkung) zahlreicher Hersteller implementiert ist. Heizzeitverlängerung, Alarmlogik, etc. sind weitere Themen, die sicherlich alle mit PERL realisiert werden können, jedoch meines Erachtens nach alle das Rad nur neu erfinden würden.
Im Endeffekt geht es hier um die weit verbreitete Debatte Individual- vs. Standardsoftware, die auch im betriebswirtschaftlichen Umfeld immer wieder zentraler Diskussionspunkt ist: SAP implementieren, oder nicht?
Sicherlich könnte man hier ebenfalls eine ähnliche Argumentation anführen und “pro” Individualsoftware plädieren, sämtliche Prozesse nachprogrammieren und selbst warten und weiterentwickeln. Die Alternative wäre allerdings, die Expertise und zigtausend Personenmonate an Entwicklungsleistung, die in einer Standard-Lösung stecken zu adaptieren und davon zu profitieren.
Sicherlich, alles nur Softwarevorteile. Aber worum geht es am Ende des Tages im Smart Home? Um austauschbare Hardware oder um Software?
Viele Grüße
Christoph
Hallo,
zunächst danke für den interessanten Artikel.
Ich bin momentan dabei unseren Neubau mit Loxone durch FHEM zu erweitern um evtl. noch andere Systeme zu kombinieren. Ich habe FHEM auf einem Raspberry Pi laufen und dort auch Homebridge installiert. Jetzt hätte ich für dieses Setup ein paar Fragen (bin allerdings Anfänger).
Kann ich in FHEM die Loxone Geräte definieren und dann durch Homebridge diese mit Siri steuern? Kommunikation zw. Loxone und FHEM sollte ja kein Problem sein. Ziel ist folgendes: Siri/Homekit FHEM Loxone. Dadurch könnte ich prinzipiell über FHEM auch noch andere Systeme anbinden.
Über ein paar Tipps wäre ich euch sehr dankbar!
Viele Grüße,
Christopher
Hallo zusammen,
vielen Dank für den interessanten Artikel.
Die ersten Erfahrungen in der Heimautomatisierung habe ich auch mit FHEM vollzogen, aber wegen der im Artikel genannten Schwächen (Visualisierung und Perl) habe ich mich nach einer Alternative umgesehen und bin mittlerweile auf Home Assistant https://home-assistant.io umgestiegen, dass auf Python 3 basiert und für mich alle wichtigen Komponenten anbietet (insgesamt werden mittlerweile über 200 Komponenten unterstützt – https://home-assistant.io/components/#all).
Meine Erfahrungen sind sehr positiv. Vor allem das schnelle ausprobieren mittels Docker-Container hat mir gefallen. So entstand in einem Nachmittag fast eine komplette Portierung der bestehenden FHEM Konfiguration nach Home Assistant, dass auf YAML setzt inklusive der Automatisierung und Trennung der Konfiguration in unterschiedliche YAML-Dateien.
Die Installation auf dem RaspberryPi lief problemlos. Mittlerweile wird meine zentrale Heimautomatisierung durch Home Assistant erledigt und steuert FHEM über HTTP an, um die verbleibenden Empfänger via CUL-Stick zu erreichen. Sind diese Empfänger auch mal ersetzt, wird FHEM wohl komplett verschwinden.
Die Visualisierung ist sehr ansprechend und das was ich mir von FHEM eigentlich immer gewünscht habe. Klar gibt es viele Projekte in der FHEM-Community und die einzige, die annähernd akzeptable ist, ist http://www.fhemwiki.de/wiki/FHEM_Tablet_UI. ABER ich will mich auf die Heimautomatisierung konzentrieren und nicht auf eine umständliche Konfiguration der Widgets und CSS. Eine Demo-Seite von Home Assistant gibt es hier: https://home-assistant.io/demo/
Weitere Plus-Punkte sammelte Home Assistant bei mir vor allem wegen der guten Dokumentation. Man wird Schritt-für-Schritt an eine saubere Konfiguration herangeführt und alle Möglichkeiten und Komponenten werden mit Beispielen hinterlegt + zahlreiche Konfigurationen sind auf Github verlinkt, wo man sich die eine oder andere Idee abgucken kann. Auch das Mitentwickeln ist sauber dokumentiert und sollte vielen Einsteigern die Hürde sehr erleichtern.
Wie gesagt war neben der Visualisierung Perl ein Grund, was mich an FHEM immer etwas gestört hat. Ich bin zwar Informatiker und hätte mich bestimmt in FHEM/Perl einarbeiten können, aber wenn ich die Auswahl zwischen FHEM auf Perl-Basis in SVN und ein gut dokumentiertes System auf Python-Basis in Git habe, dann war es nicht all zu schwer mich für Home Assistant zu entscheiden. Jaja…SVN und Git….eine Grundsatzfrage wie Windows oder Linux…ich habe mich schon vor langer Zeit für Git entschieden, was ich auch sehr angenehm bei Home Assistant im Vergleich zu FHEM empfand.
Ich denke das mich bei Home Assistant in naher Zukunft aufgrund von Python und Git früher und mehr in der sehr aktiven Community beteiligen werde, als das ich es bei FHEM gemacht habe.
IMHO: auch wenn FHEM viele Komponenten, Protokolle und Hardware unterstützt, ich sehe ernsthafte Probleme auf FHEM zukommen, wenn es sich nicht bald mordenisiert und mehr mit der Zeit geht.
Beste Grüße,
Christian
Hallo,
interessante Alternative. Allerdings mit einer noch recht kleinen community und in Version 0.23.
Und auch dort basteln sich die user ihr eigenes UI: https://community.home-assistant.io/t/wall-mounted-dashboard/1896
Und das sieht irgendwie ziemlich nach tablet UI aus 🙂
Ben
Hallo Christian,
danke für dein Feedback. Wie man sieht, gibt es immer mehr Lösungen am Markt. Smart Home sondiert sich allmählich …
Die Optik ist ansprechend. Wie sieht es mit “Intelligenz” aus?
Das Map-Feature gefällt mir sehr gut!
Viele Grüße
Christoph
@Ben
Dafür das Home Assistant erst wenige Monate alt ist, hat es aber schon beachtlich viele Komponenten und Protokolle die es unterstützt, zudem bereits 195 Contributors und über 800 forks – das ist beachtlich.
Das ist doch spitze, dass man out-of-the-box ein ansehnliches Front-End hat und das ganze aber dennoch offen für Spielereien ist, wie du es im Link gepostet hast. Das wall-mounted-dashboard basiert anscheinend auf Dashing, also Ruby und hat weniger was mit Tablet UI von FHEM zu tun als es vielleicht aussieht.
Ich finde die Test-Coverage von Home Assistant mit 94% und den dazugehörigen CI Prozess erwähnenswert…kann jemand etwas über die Test-Coverage von FHEM sagen?
Wie genau ist “test-coverage” in diesem Zusammenhang denn definiert? Was genau sagen die 94% aus?
Ben
Hallo liebes meintechblog-Team,
vorab möchte ich einmal Danke für die vielen nützlichen und hilfreichen Tipps rund um das Thema Smarthome sagen, euer Blog hilft ungemein bei diversen Fragestellungen. Meine Frage bezieht sich bei der Verknüpfung von FHEM und Loxone auf die Intergration der Rolladensteuerung.
Ich habe eine Immobilie erworben, in der Großteils Homematic wired Buskomponenten verbaut sind. Auf Basis eurer Dokus habe ich dann auf dem Rasperri FHEM installiert und mich dort auch weiter eingearbeitet. Nun möchte ich das Ganze auch gerne in Loxone integrieren.
Die „Programmierung“ mit der Loxconfig klappt auch schon ganz gut, Temperatur und Lichtsteuerung funktionieren schon sehr gut. Allerdings habe ich noch ein Problem mit der Integration der Rolladensteuerung. Die Rolladen waren in meiner Immobilie schon über das Homematic I/O Modul via Koppelrelais geschaltet, nicht über einen Rolladenaktor. Habe ich eine Chance, auf Basis dieser Verdrahtung, die Loxone Logik zu verwenden ? Ich habe schon ein wenig herumprobiert, allerdings nicht sehr zielführend. Mit dem Automatikjalousie-Baustein von Loxone bekomme ich die Rolladen zwar zum Laufen, allerdings kann ich diese nur ganz hoch oder ganz herunter fahren, dafür genügt auch schon ein kleiner Impuls am Taster. Sie lassen sich aber nicht stoppen. Die eigentlichen Funktionen des Logikbausteins klappen leider nicht (jederzeit anhalten, Ganzfahrt nur bei längerem Tastimpuls etc.). Zudem bleiben die jeweiligen Ausgänge des I/O Moduls in der FHEM-Oberfläche auch gesetzt, ich vermute, das die Logik am virtuellen Ausgang „Befehl bei Ein, Befehl bei AUS“ nicht so funktioniert, wie ich mir das vorstelle, oder wie es mein Verständnis wäre. Ich habe bei den virtuellen Ein + Ausgängen schon diverse Einstellungen versucht, leider ohne Erfolg. Habt ihr vielleicht einen Ansatz, wie und ob ich das Ganze doch noch auf diesem Weg realisiert bekomme ?
Vielen Dank vorab und Gruß
Hans Werner
Eine dumme Anfängerfrage: Wird Code “#OnOffToLoxone” in fhemconfig oder in 99myutils hereingekopiert?
Hallo Raimo,
wie im Howto beschrieben: “Diese Funktionen werden jetzt noch in die Datei “99_myUtils.pm” eingetragen. Dazu kann der nachfolgende Code verwendet werden.” -> Die Antwort lautet also: in die 99_myUtils.pm.
Viel Erfolg und viele Grüße
Christoph
Schönen Dank Christoph! Man könnte es nämlich auch anders verstehen!……
Raimo
Hallo Christoph,
ich sehe auch, dass LOXONE das Potenzial zu einem übergreifenden Standard zu werden hat. Leider sehe ich aber auf der Konfigurationsseite wieder nur Windows-basierte Software. Solange sich dies nicht ändert, wird ein Großteil der Interessierten ausgeschlossen. Ich werde mir deshalb jedenfalls nicht Windows installieren. Ich denke, man sollte eine Konfigurationsoberfläche Betriebssystem-unabhängig gestalten, z.B. WEB-basiert.
Übrigens Euer BLOG ist immer sehr informativ und vielfältig. Ich schaue immer wieder gerne vorbei und hole mir Anregungen für eigene Projekte. Weiter so!
Viele Grüße
Rainhard
Hallo Reinhard,
Windows-basierte Konfiguration missfällt mir als Mac-Nutzer ebenfalls. Ich denke, langfristig wird sich da schon was tun.
Danke für dein Lob bzgl. unseres Blogs! Wir geben unser Bestes!
Danke und viele Grüße
Christoph
Hallo Rainhard,
das sehe ich genauso. Windows ist für mich das Ausschlusskriterium Nr. 1!
Grüße
Peter
Hallo,
danke nochmals für den Beitrag. Mittlerweile habe ich auch schon etwas mit Loxone und FHEm “gespielt”.
Leider habe ich es noch nicht geschafft eine Lampe (über Loxone gesteuert) über FHEM zu steuern bzw. dort verfügbar zu machen.
Dem virtuellen UDP Eingang ist ein virtueller UDP Befehl L_Esszimmer zugeordnet und dieser schaltet dann einen Taster. Wie kann ich nun L_Esszimmer in FHEM bekannt machen. Wird der Status einer Lampe auch an FHEM übermittelt? Also ob sie gerade aus oder an ist.
Über Hilfe oder Tipps wäre ich sehr dankbar!
Viele Grüße,
Christopher
Hallo erst mal an das Team
Kann ich den loxone miniserver go mit dem knx System verbinden (es hat ja kein knx oder usb Anschluss) – geht es per lan?
Den Miniserver Go bekommst du nicht direkt an den KNX-Bus, da ihm schlicht die Busklemmen fehlen. Um dennoch auf den KNX-Bus zugreifen zu können, benötigst du ein passendes Gateway, welches die KNX-Informationen per IP (HTTP) zugänglich macht. Hier bietet sich z.B. ein FHEM-Server mit TUL-Stick oder Wiregate an. So oder so wird das wohl nicht ohne Basteln funktionieren…
Grüße
Jörg
Hallo, bin ein totaler NOOB was FHEM betrifft.
Ich glaube da sind noch ein paar Fehler in der Config drin.
Ich habe alles umgesetzt was oben stand aber in Loxone kommt nichts an.
Was ich dann gefunden habe ist in der 99_Myutils wird die Variable #Energy2ToLoxone falsch definiert. Muss heißen EnergyToLoxone2.
Nun erscheint keine Fehlermeldung im log von FHEM.
Was aber nicht passiert ist dass ein On/Off Status von meinem Beamer über die Aktion “Beamer@TV” übertragen wird.
Fehlt hier evtl noch die Device-Klasse “Power” !?!
Bitte um Hilfe.
Danke
Tom
Hallo,
ich habe mich endlich auch dazu durchgerungen mir den Loxone Miniserver zuzulegen (und er sollte im laufe der Woche ankommen).
zum Bild 10 habe ich aber noch eine Frage bzw evtl einen verbesserungsvorschlag:
statt http://Nutzer:Passwort@IP-ADRESSE-FHEM-SERVER:8083 zu verwenden könnte man doch gleich “http://Nutzer:Passwort@IP-ADRESSE-FHEM-SERVER:8083/fhem?cmd=” verwenden. Das hätte den Vorteil das man bei den einzelnen Ausgängen sich jeweils das /fhem?cmd= sparen könnte. Damit könnte man die einzelnen Ausgänge nur noch mit dem FHEM Befehl initalisieren (also statt /fhem?cmd=set Ga.Licht on nur noch set Ga.Licht on). weiterhin würde ich lieber den DNS Namen statt die IP verwenden. Würde es so funktionieren?
also würde ich bei meiner installation den HTTP Ausgang (bei mir ohne PW):
Vorher: “http://192.168.0.57:8083”
Nachher: “http://fhem.fritz.box:8083/fhem?cmd=”
Virtueller UDP Ausgang
Vorher: “/fhem?cmd=set Lampe pct ”
Nachher: “set Lampe pct ”
Wie man sieht müsste ich nicht mehr bei jedem Virtuellem UDP Ausgang an /fhem?cmd= denken und könnte stattdessen direkt den FHEM befehl verwenden.
Hi Tobias,
damit hast du vollkommen Recht!
Den UDP-Ausgangsbefehl kannst du genau so ändern, wie du es beschrieben hast. Im Grunde ist man mit der im Blogpost beschriebenen Methode natürlich flexibler, wenn man aber eh nur solche gleichartigen Steuerbefehle verschickt, kann man das Ganze auch – wie von dir vorgeschlagen – vereinfachen.
Mit der Nutzung des DNS-Namens wäre ich etwas vorsichtig. Hier hatte ich schon einmal Probleme beim korrekten Routing, sobald die IP-Adresse des Miniservers über DHCP von einer Fritzbox vergeben wurde. Woran das im Detail lag, konnte ich jedoch leider nicht wirklich in Erfahrung bringen und nutze seitdem einfach wieder die IP-Adresse. In der Theorie sollten beide Verfahren aber genauso reibungsfrei funktionieren.
Grüße und viel Erfolg bei der Einrichtung deines neuen Miniservers!
Jörg
Hallo Jörg,
ich bin auch nach und nach alles zu Loxone am umschwenken und bin direkt auf eine Hürde gestoßen.
Ich möchte gerne meinen Homematic Dimmaktor mittels Loxone steuern. An/Aus funktioniert, allerdings stehe ich ziemlich auf dem Schlauch, wie der CMD Befehl sein muss um zu dimmen.
Vielleicht kannst du mir ja auf die Schnelle weiter helfen?
Liebe Grüße
Hi Michael,
aber klar, kein Thema.
Wenn bei einem On/Off-Aktor die Loxone-Befehle bspw. so lauten:
Befehl bei Ein: /fhem?cmd=set WZ.Schalter on
Befehl bei Aus: /fhem?cmd=set WZ.Schalter off
…wird der Loxone-Befehl bei einem Analogaktor (z.B. Dimmer) entsprechend so umgesetzt:
Befehl bei Ein: /fhem?cmd=set WZ.Dimmer <v>
Die Ergänzung <v> am Ende bewirkt dabei, dass der anliegende Loxone-Wert direkt in den Befehl gepackt und an FHEM gesendet wird.
Grüße und viel Erfolg
Jörg
Da tut sich bei mir leider nichts, Jörg.
Der virtuelle Schaltbefehl, um den Dimmer zu schalten, lautet bei On und Off nun: /fhem?cmd=set Licht.WZ
Dann regt sich allerdings nichts mehr. Wenn ich ein On oder Off dahinter setze, funktioniert es ja…
Hab das Ganze an einem Lichtsteuerungsbaustein in Loxone hängen. Kann das irgendwo Probleme machen?
Wie funktioniert es bei dir im Detail?
Vielleicht habe ich mich etwas blöd ausgedrückt…
“Befehl bei Ein” ist bei mir so gesetzt: /fhem?cmd=set Licht.WZ
Dabei passiert leider nichts, wenn ich den Schieberegler in der App hoch setze.
Auch mit einem /fhem?cmd=set Licht.WZ pct
habe ich es, ohne Erfolg, versucht.
Der Blog schmeisst bei den Kommentaren gerade Werte in eckigen Klammern raus. Deshalb wurde der Befehl <v> am Ende nicht vollständig angezeigt. Ich hab meinen obigen Kommentar provisorisch angepasst, damit du siehst, was ich meine. Hoffe das hilft dir weiter.
Grüße
Jörg
Update: Problem gelöst. Jetzt sollte es oben korrekt angezeigt werden…
Danke, Jörg.
Genau so hab ich es konfiguriert.
Befehl bei Ein: /fhem?cmd=set WZ.Dimmer
Befehl bei Aus: /fhem?cmd=set WZ.Dimmer off
Scheinbar hat sich irgendwo ein Fehler eingeschlichen zu haben, denn es funktioniert so nichts.
In Loxone habe ich den Dimmer an dem Baustein Lichtsteuerung AQ1 hängen, sowie im Baustein Dimmer 0-100% eingestellt.
Problem gelöst.
Der Homematic-Aktor muss wiefolgt konfiguriert werden:
Befehl bei EIN: /fhem?cmd=set Licht.WZ <v>
Befehl bei AUS: /fhem?cmd=set Licht.WZ off
Haken bei “Als Digitalausgang verwenden” entfernen.
Anzeige Einheit auf setzen und “nur Statusanzeige” anhaken.
Per Doppelklick auf die Lichtsteuerung muss der jeweilige Ausgang als Typ “Dimmer 0-100%” eingestellt werden. Schon funktioniert das ganze via Schieberegler in Loxone.
Mein Anschaltbeispiel in Loxone sieht derzeit so aus:
http://fs5.directupload.net/images/160820/7axwt7sy.png
Super Artikel, wurde von mir direkt umgesetzt. Leider habe ich jetzt ein Problem, dass nicht alle UDP Nachrichten ausgewertet werden. Im UDP-Monitor von Loxone erhalte ich bei Daten uum Beispiel: SZ_TempHumidity: 23.7 55 1 (SZ_Temperatur [23,70000],SZ_Luftfeuchte [55,0000000])
Wenn ich den Virtuellen Eingang Befehl (SZ_Temperatur oder SZ_Luftfeuchte) verwende, zeigt mir Loxone in der Liveview bei beiden werten nur 0 an, obwohl er ja die Nachricht augenscheinlich richtig interpretiert hat.
Grüße Sebastian
Dann ist bei dir vermutlich noch irgendwas falsch konfiguriert. Ich nutze das Ganze aktuell genauso wie im Blogpost beschrieben und es funktioniert perfekt.
Beim Homematic Thermostat hänge ich ebenso fest.
Ich hoffe es kann jemand weiter helfen. Die IST Temperator bekomme ich zwar angezeigt, allerdings wird die desired-temp nicht geändert.
Hallo,
Also ich habe den Miniserver jetzt am laufen und ich bekomme auch alle Werte korrekt angezeigt. Allerdings habe ich mir die einzelnen Funktionen für FHEM neu geschrieben und an meine Umgebung angepasst. Jetzt geht es ans steuern und automatisieren. Also am beispiel eines Homematic Dimmers: Loxone Baustein Dimmer den ausgang verbunden mit meinem Virtuellem Ausgang zu FHEM. Schalten über die Weboberfläche funktioniert (AN, AUS, DIM, …). was nicht funktioniert ist wenn ich den schalter betätige das er den aktuellen stand in die Weboberfläche übernehme. Ich habe zwar den Virtuellen Eingang des Dimmers an Loxone und dieser wird auch richtig angezeigt (!) – Aber ich weiß nicht wo ich den als “info” Kanal anschließen kann um Daten an Loxone zurückzugeben. Die einzige Möglichkeit die mir bisher eingefallen ist ist folgende:
Trennen von Dimmer und Taste durch einblenden und auflösen der internen HM Bindings. Dann MÜSSTE jeder Dim Befehl über den Miniserver laufen. Nachteil: wenn der Miniserver ausgefallen ist tut der Lichtschalter überhaubt nicht mehr da er nicht weiß das er sich an den eingebauten Dimmer richten soll –> nicht sehr ausfallsicher. Wie hast du das gelöst?
Für das Arduino FRM_RGB Modul suche ich noch eine Möglichkeit die Farbe von Loxone zu übernehmen. Loxone kann im RGB Modul ja die einzelnen Farben mischen und als 0-10er werte ausgeben. diese könnte ich an drei Dummys in FHEM übergeben und dort per PERL Funktion mit 25,5 Multiplizieren (um werte von 0 bis 255 zu bekommen), dann umwandeln in HEX (z.b. 255 –> FF) und dann verketten um den HEX Farbwert dann an den Arduino weiter zu geben. Gibt es hierzu noch eine schönere Möglichkeit?
@Sebastian: wenn am Loxone die Daten ankommen: SZ_TempHumidity: 23.7 55 1 und du alle drei Daten benötigst musst du drei Virtuelle Eingänge anlegen.
Befehlserkennung für Temperatur: “SZ_TempHumidity: \v”
Befehlserkennung für Humidity: “SZ_TempHumidity: \# \v”
Befehlserkennung für das Letzte: “SZ_TempHumidity: \# \# \v”
jeweils ohne anführungszeichen.
@Michael P: Evtl läufst du auch in den gleichen Fehler den ich auch begangen habe: Anfangs habe ich versucht direkt den Virtuellen Ausgang über die Weboberfläche zu steuern. Das funktioniert nicht. Versuche einmal einen Thermostatbaustein (kp ob der wirklich so heißt) oder zur not einen Dimmer zu verwenden. Den ausgang des Bausteins verbindest du dann mit dem Virtuellen Ausgang zu FHEM. Stelle jetzt den Baustein über die Weboberfläche auf die passende Temperatur ein und überprüfe ob die Daten bei FHEM ankommen (Das HM Thermostat bekommt die Daten normalerweise erst Zeitverzögert mit). Wenn die Daten bei FHEM ankommen hast du eigentlich schon gewonnen.
Wie oben von dir schon geschrieben funktioniert es (auch bei mir) nur mit dieser Schreibweise: “/fhem?cmd=set Licht.WZ <v>”
Achja und nochweiter oben: für den Homematic Dimmer muss der Befehl “/fhem?cmd=set Licht.WZ pct <v>” heißen. Das PCT habe ich aus der FHEM Weboberfläche dem Dimmer entnommen. Bei meinem Arduino FRM_PWM Dimmer würde der Befehl übrigens “/fhem?cmd=set Licht.WZ dim <v>” heißen.
Hi Tobias,
beim normalen Loxone-Lichtsteuerungsbaustein ist kein Rückmeldungseingang vorgesehen. Das Konzept bei Loxone ist eben, dass alle Befehle über den Miniserver laufen. Wenn du den EIB-Dimmer nimmst, hast du die gewünschte Funktion, da dieser Baustein einen passenden Rückmeldungseingang besitzt. Einschränkung ist dabei natürlich, dass man damit nur ein Licht steuern kann.
Folglich müsstest du das Bindung aufheben, wenn du Lichtszenen über den Lichtsteuerungsbaustein benutzen möchtest und alle Befehle über den Miniserver laufen lassen.
Bei der Übernahme der RGB-Farbwerte musst du wohl in der Tat etwas basteln. Wenn du eine funktionierende Lösung gebaut hast, würde ich mich freuen, wenn du diese mit uns teilen würdest.
Grüße
Jörg
Hallo,
danke für die Antwort, Tobias.
Meine Dimmer laufen inzwischen schon.
Könntest du, sofern du die Heizungssteuerung am laufen hast nochmals etwas genauer erläutern? Das Auslesen der Werte ist mir klar, mein Problem besteht darin, die Thermostate zu schalten bzw. diesen dann die gewünschte Temperatur etc. durchzugeben.
Grüße
nachtrag: die ganzen (größer als+v+kleiner als) hat er wohl verschluckt. Warscheinlich wollte er HTML Code drauß machen.
Die Größer-Kleiner-Zeichen habe ich in deinem Kommentar berichtigt. Das ist ein Schutz der Kommentarfunktion, sodass kein Schadcode eingespielt werden kann. Wenn du Sonderzeichen in Kommentaren nutzen möchtest, nutze am besten diese Sonderzeichenliste. Für das gewünschte “Symbol” dann direkt den “HTML-Code” einfügen. Nervig, aber spontan weiss ich leider keine bessere Lösung.
Wie immer ein super Beitrag! 🙂 Danke Christoph!
Vielen dank für die Korrekturen 🙂
@Michael P.: ich habe hier mal die Loxone steuerung für die Heizung als Bild zusammengefasst: https://www.dropbox.com/s/2hm6mrw7hb6x6o3/Loxone%20HM%20Heizung.png?dl=0
Der Baustein Dimmer ist zwar nicht ideal, aber zur steuerung funktioniert es. Richtig könnte man wohl die Intelligente Raumregelung verwenden – da muss ich mir aber erst mal die Konfigurationsanleitung ansehen.
Danke für dein Bild.
Meine Heizungssteuerung läuft inzwischen nun mit dem Baustein “Intelligente Raumregelung” inkl. Heizprogrammnutzung.
Ebenso funktioniert die Alarmanlage mit Bewegungsmeldern und Magnetkontakten, in Verbindung mit Geofancy (automatisch scharf/unscharf je nach Anwesenheit).
Sonos habe ich auch schon integriert, dafür hab ich aber noch keine sinnvollen Schaltmöglichkeiten gefunden. Steuern ist aber theoretisch über Loxone möglich.
Mein QNAP fährt auch automatisch auf Knopfdruck in Loxone hoch bzw. runter.
Trockner und Waschmaschine kann ich schonmal ein/aus schalten, Ziel ist es hier noch in Loxone den Verbrauch zu überwachen und sobald die Wäsche fertig ist auf Sonos ein Audiofile abzuspielen.
Über FHEM funktioniert das derzeit, nur wenn schon umprogrammieren, dann richtig.
Dementsprechend, denke ich, kann ich jemanden der Interesse an diesen Funktionen hat, schon ein wenig Hilfestellung geben.
Hallo zusammen, ich habe danke der Anleitung FHEM and Loxone anbinden können. Mein Problem ist derzeit noch die Heizungssteuerung über die intelligente Raumregelung. Die Ist-Temperatur wird angezeigt und in der Liveview sehe ich die Soll-Temperatur korrekt am Ausgang AQt. Meine Hoffnung war, dass diese Soll-Temperatur als Variable in den Befehl “/fhem?cmd=set FHT_140b desired-temp ” übernommen wird. Wird sie aber nicht. Habt ihr eine Idee? Vielen Dank Axel
Hallo nochmal.
also hier mal meine Q&D lösung für den RGB streifen.
In die 99_myUtils.pm:
###############################################
sub DecToHexRGB($$$$$)
{
my ($target,$cmd,$Red,$Green,$Blue) = @_;
my $hexRed;
my $hexGreen;
my $hexBlue;
my $colorCode;
$Red=$Red*25.5;
$Green=$Green*25.5;
$Blue=$Blue*25.5;
$hexRed = sprintf(“%02X”, $Red);
$hexGreen = sprintf(“%02X”, $Green);
$hexBlue = sprintf(“%02X”, $Blue);
$colorCode=$hexRed.$hexGreen.$hexBlue;
fhem(“set $target $cmd $colorCode”);
}
###############################################
dann drei Dummy Werte die von Loxone beschrieben werden:
define RGB_R dummy
define RGB_G dummy
define RGB_B dummy
und dann noch ein notify das bei Änderungen an RGB_R,RGB_G,RGB_B jeweils die DecToHexRGB($$$$$) aufruft mit
define decToRGB notify RGB_B:.*|RGB_G:.*|RGB_R:.* {DecToHexRGB(“RGB_Lampe”,”rgb”,Value(“RGB_R”),Value(“RGB_G”),Value(“RGB_B”))}
In Loxone jetzt die drei dummys als virtuelle Ausgänge anlegen (Analoge Ausgänge mit einer Kommastelle) und mit den Ausgängen des RGB-Lichtszene Bausteins in Loxone verbinden. (AQr an RGB_R, AQg an RGB_G und AQb an RGB_B)
Loxone setzt also die drei Dummys in FHEM, das notify decToRGB merkt die veränderung und startet die Perl funktion DecToHexRGB. dieser wird folgendes übergeben:
Ziel Lampe: RGB_Lampe
der RGB befehl (damit man auch andere lampen mit steuern kann die nicht rgb verwenden): rgb
Farbe Rot: RGB_R
Farbe Grün: RGB_G
Farbe Blau: RGB_B
die funktion multipliziert die werte mit 25,5 da die daten von Loxone von 0 bis 10 reichen, der FHEM Farbcode aber von 0-255 reicht.
Danach werden die Farben zweistellig umgerechnet (255 zu FF und 10 zu 0A) und der Farbcode zusammengestellt.
Jetzt wird das $target per $cmd auf den Farbcode gesetzt
Hallo, nocheinmal eine verbesserte Version die mit dem Loxone Wert zurecht kommt und nur ein übergebe dummy braucht statt drei:
sub StringToHexRGB($$$)
{
my ($target,$cmd,$colorCode) = @_;
$colorCode=sprintf(“%09d”,$colorCode);
my $length = length($colorCode);
my $blue = sprintf(“%02X”, substr($colorCode,$length-9,3)*2.55);
my $green = sprintf(“%02X”, substr($colorCode,$length-6,3)*2.55);
my $red = sprintf(“%02X”,substr($colorCode,$length-3,3)*2.55);
$colorCode=$red.$green.$blue;
fhem(“set $target $cmd $colorCode”);
}
Andere Sache. Wenn ich von FHEM an Loxone einen Wert übergebe (zum Beispiel UG.Fenster 1) dann triggert es bei Loxone nur, das heißt der Digitale Eingang geht nur ganz kurz auf an und dann wieder auf aus. Das ist bei einem Fenster nicht besonders hilfreich da der Digitale Eingang dann wieder auf aus steht und zum Beispiel die Klimasteuerung wieder von einem geschlossenen Fenster ausgeht. Kann man dieses Verhalten irgendwie umbiegen das der Eingang solange auf 1 bleibt bis ich UG.Fenster 0 sende?
Hi Tobias,
danke für deinen Code! Sehr hilfreich!
Benutze in Loxone statt des Digitaleingangs einfach einen Analogeingang, dann klappt das. Lediglich bei aktiver Visualisierung hat man dabei den Nachteil, dass eben nicht Ein / Aus angezeigt wird, sondern 1 / 0. Wer eine bessere Lösung kennt, immer gerne her damit. Das Problem hatten nämlich bereits mehrere Leser.
Grüße und viel Erfolg
Jörg
Hi,
jemand eine Idee, wie ich von meinen BWM die aktuelle Helligkeit in Loxone übertragen bekomme?
LG
Einfach das obige Beispiel abwandeln…
Also den Helligkeitswert (ReadingsVal) des Bewegungsmelders auslesen und dann per UDP an Loxone schicken. Je nachdem, wie das Reading heisst – nachstehend “Helligkeit”, sieht das dann so aus:
my $state = ReadingsVal(“$device”,”Helligkeit”,”-1″);
Grüße
Jörg
Danke für deine Antwort.
Habe das ganze so in die 99_myutils geschrieben:
#HelligkeitToLoxone
sub Helligkeit2ToLoxone($)
{
my ($device) = @_;
my $brightness=ReadingsVal(“$device”,”brightness”,”-1″);
UDP_Msg(“10.0.0.37” , “7000” , “$device: $brightness”);
}
Mittels “BWM.Kueche_Motion: \v” wollte ich diesen Wert nun auslesen, doch ich erhalte nur 1.0 bei Bewegung bzw. eine 0.0.
Obwohl ich doch brightness auslese? Kann das Ganze nicht richtig nachvollziehen.
Hallo Michael,
der Fehler liegt darin, dass FHEM per UDP nur das erste, ausgelesene Value übermittelt. Du überträgst ja sicherlich in einem anderen Code-Teil die Bewegung für das Device “BWM.Kueche_Motion” (1 oder 0).
In deinem neuen Code liest du zwar die Brightness aus, aber als erstes Value zählt weiterhin der Code für die Übertragung der Bewegung. Daher machst du jetzt folgendes:
Du integrierst den Code für Bewegung und Helligkeit in einen Codebestandteil, also in EINE UDP-Message:
#HelligkeitUndBewegungToLoxone
sub Helligkeit2ToLoxone($)
{
my ($device) = @_;
my $brightness=ReadingsVal(“$device”,”brightness”,”-1″);
my $motion=ReadingsVal(“$device”,”motion”,”-1″);
UDP_Msg(“10.0.0.37” , “7000” , “$device: $motion $brightness”);
}
Bitte prüfe, ob das Reading “motion” bei deinem BWM so stimmt (habe ich jetzt einfach mal frei definiert). Dann liest du die Bewegung so aus:
BWM.Kueche_Motion: \v
Und die Helligkeit so:
BWM.Kueche_Motion: \# \v
Viel Erfolg und viele Grüße
Christoph
So funktioniert es, Top!
Vielen dank – wieder was dazu gelernt 🙂
Gerne! Bleib unserem Blog treu!
Viele Grüße
Christoph
Hallo 🙂
Mein Problem ist ähnlich wie das von Michael P.
Ich möchte gerne aus einem Enocean Schaltaktor die aktuelle Leistung übertragen.
Es wird ja bereits der Status (state) ob “AN” oder “AUS” per UDP übermittelt.
Zusätzlich soll jetzt noch das device “power0” übertragen werden für die aktuelle Leistung.
Was muss ich nun in die 99_myutils schreiben?
Das müsste ja mit rein in Message vom State.
Mein Ansatz ?!
#Power0ToLoxone
sub Power0ToLoxone($)
{
my ($device) = @_;
my $state=ReadingsVal(“$device”,”state”,”-1″);
my $power0=ReadingsVal(“$device”,”power0″,”-1″);
UDP_Msg(“IP-Adresse” , “7000” , “$device: $state $power0”);
}
Ich hab es versucht zu lösen, indem ich die Leistung in fhem in ein eigenes Dummy in Fhem geschrieben habe. Dieses Dummy versuch ich nun in Loxone auszulesen.
Das Reading in dem Dummy habe ich als “Power” definiert. Das klappt auch in fhem. Die Leistung des Enocean-Aktors wird in das device “Leistung Lampe” in das Reading “Power” geschrieben. Um das Reading an Loxone zu übergeben hab ich folgendes versucht.
#PowerToLoxone
sub PowerToLoxone($)
{
my ($device) = @_;
my $Power=ReadingsVal(“$device”,”Power”,”-1″);
UDP_Msg(“196.168.178.45” , “7000” , “$device: $Power”);
}
Leider bekomme ich den Wert im UDP Monitor nicht rein.
Was einer Rat?
Hi Matthias,
ich würde dir empfehlen grundsätzlich keine Leerzeichen in Device-Namen zu verwenden. Das schmeckt FHEM nicht besonders. Also aus “Leistung Lampe” am besten “LeistungLampe” machen und nochmal versuchen…
Grüße und viel Erfolg
Jörg
Das mit dem Leerzeichen ist ein Schreibfehler meinerseits hier im Blog.
In fhem als auch im Loxone habe ich das device “Leistung_Stehlampe” genannt.
Ob “Hardware” device (beispielsweise Aktor) oder dummy device ist für fhem egal oder?
Wer suchet -> der findet.
Ich hab meinen Fehler gefunden.
Danke für eure Mühe.
Hi Grosse frage an die die sich auskennen
Hat jemand von euch eine Dect200 von avm
Auf diese Weise mit loxone verbunden (fhem -> loxone ) komme irgend wie seit drei Tagen nicht weiter. Temperatur wird angezeigt aber keine Leistung kein on off ( steht immer -1)
Weiss nicht mehr weiter kann mir einer helfen ( am besten mit einer ausführlichen Schritt für Schritt Anleitung
Ich habe heute ein altes FS20 4er Funk-Taster über FHEM mit Loxone verbunden.
Ich bin erstaunt – es funktioniert wirklich sehr gut. Es ist mir sogar lieber als mein Loxone Air Taster.
Danke Jörg!
und danke Christoph!
Immer gerne 🙂
Hi Jörg,
mir imponieren die Möglichkeiten enorm die sich mit der Kopplung ergeben und ich fange gerade an einiges zu probieren und habe deinen Code erst mal zu Anfang übernommen. Vielen Dank für deine Mühe !!
Ich habe da einen kleinen Dreher bemerkt. (KA ob ich der erste bin ??) Die Subroutine die aufgerufen wird ist Energy2ToLoxone, im Notify steht EnergyToLoxone2. Eins muss geändert werden.
Ich möchte nun meine Lichtsteuerung anpassen: Dazu habe ich den 6fach Schalter von Homematic. Der macht jedoch keine on/off, sondern schickt entweder ein short oder long respektive longrelease. Ich würde die Taste an einen Eingang legen und sozusagen togglen. Da hören meine Kenntnisse jedoch auf. Hätte einer einen Hinweis für mich ??
Hallo Andreas,
danke für dein Feedback. Energy2Loxone und Energy2ToLoxone sind zwei verschiedene Aufrufe. Diese rühren daher, dass ich zur Energiemessung an der Hutschiene zwei verschiedene Arten von Energiemessgeräten nutze (Einmal ein altes “EM” und einmal “Enocean”). Ersteres liefert die Energiedaten im State “sensor3” und Letzteres im State “current”. Daher die Unterscheidung.
Dein geäußertes Problem mit “long” und “short” habe ich leider nicht ganz verstanden, da ich den Aktor nicht kenne. Vielleicht meldest du dich mal mit einem Screenshot per Mail.
VG
Christoph
Hi kleine Frage
Hat jemand von euch eine dect200 Schaltbare stekdose von AVM verbunden bekommen ich würde gerne auf alle Werte zugreifen. Bei mir geht außer Temperatur nichts?
Hi Christoph & Jörg,
Ich bin fleißig dabei ALLES vom FHEM zu Loxone zu schicken (viel neu programmieren), am Ende wird es ganz schon viele UDP Nahrichten werden.
Kennt ihr eine Grenze, gibt es irgendwann Probleme? Wann ist zu viel mit UDP?
Kennt ihr Tricks, z.B. fhem Notify nur alle 10 Minuten?
Ich schau mir auch die 1-Wire Produkte von www.eservice-online.de an, ich werde bestimt bald etwas kaufen (Preis-Leistung ist Top). Die funktionieren aber auch mit Loxone über UDP…..
Danke schön!
Hi Oisin,
ich habe gerade mal einen kleinen “Stresstest” mit 50 Mitteilungen/Sekunde realisiert, die – neben meinen normalen UDP-Messages – von FHEM in Richtung von Loxone gesendet wurden. Das lief über den Zeitraum von einer halben Stunde ohne Einschränkungen bzw. Nachrichtenverluste. Ich denke, dass man schon enorm viele Mitteilungen übertragen muss, um in Probleme zu laufen.
Dabei sollte man natürlich insgesamt etwas darauf achten, dass nicht jedes Gerät sekündlich seine Nachrichten absetzt. Das wäre ja auch irgendwie völlig übertrieben. Wenn man bei Sensoren mit dem Attribut “event-on-change-reading” arbeitet, sollte es eigentlich gut funktionieren.
Grüße
Jörg
wow, 50 pro Sekunde….! okay – danke!
Der Netzwerkschalter (und evtl. die Verlablung wegen Paketverlust) ist bestimmt auch nicht unwichtig.
p.s. kann dein Stress-Test die Latenz messen? Das wäre auch Interessant!
Wie lange braucht so eine Nachricht und wie viel Variation gibt es.
die Latenz wäre bestimmt nicht leicht, aber die Variation geht bestimmt. 🙂
Hallo meintechbloger
ich bin etwas weiter gekommen mit meinem Problem (von oben )
aber immer noch nicht am ziel habe jetzt folgendes Problem
in dem UDP-Monitor wird jetzt volgende meldung angezeigt
HR.Spuehlmaschine 198301 Wh 0,5 W
und in der config
HR.Spuehlmaschine: \v
soweit so gut der wert 198301 wird auch angezeigt
wie kriege ich die 0,5 angezeigt
wenn ich ein zweiten UDP_eingang befehl anlege
HR.Spuehlmaschine: \# \v
bleibt der wert auf 0
Hallo Jungs
Ich habe den Code wie von Euch beschrieben konfiguriert, im notify TempHumidityToLoxone sehe ich auch das er die Daten aktualisiert. Im Log habe ich aber eine Meldung stehen, diese zhaelt hoch:
TempHumidityToLoxone return value: Undefined subroutine &main::TempHumidityToLoxone called at (eval 28) line 1.
Im Loxone udp monitor kommt auch nichts an und mit dem Wireshark sehe ich auch nichts kommend vom Raspi?
Koennt Ihr mir weiterhelfen bitte
Hat sich erledigt, es kommen nun UDP Werte an
Hallo Leute,
sagt mal, Visualisiere ich denn die Luftfeuchtigkeit im Loxone ?
übertragen wird sie ja vom meinem Homematic Wandthermostat per UDP aber wo und wie binde ich sie sein ?
Aktiviere beim UDP-Eingangsbefehl im Menü einfach den Haken “Verwenden” bei “Visualisierung” und der Wert wird angezeigt. Alternativ kannst du den Wert auch an ein “Status”-Element übergeben und dort je nach hinterlegten Regeln verschiedene Symbole anzeigen lassen.
Grüße
Jörg
Hallo!
Ich habe einen Problem, und ich glaube nicht dass ich damit allein bin.
Seit Wochen versuche ich die Lilchtsteuerung zum Funktionieren zu bringen.On/Off-informationen laufen durch Lichtsteuerung-Modul richtig. Mit Dimmer gehen nur DIMUP- und DIMDOWN- Befehle ohne Lichtsteuerung-Modul, also “direkt” überVQ:s.
Die FS20-Dimmer brauchen aber Befehle in Format “WZLicht 56%”, um Lichtscenen richtig zu steuern.
In Virtueller Ausgang VQ habe ich u.a. folgendes probiert: “/fhem?cmd=set WZLicht %”, mit oder ohne %-Zeichen, mit und und und…. Nichts geht, FHEM erkennt das nicht und sendet nichts.
Weiss jemand, wie ich den Dimmer-ausgangswert an VQ evtl. über Lichtsteuerungsmodul an Virtueller Ausgang schicken muss?
Hi Raimo,
fast richtig. Virtuellen Ausgang an VQ in der Form “/fhem?cmd=set WZLicht <v>”. Dann sollte das funktionieren.
Viel Erfolg
Jörg
Anscheinend schluckt das Blogprogram die kleiner/grösserzeichen. es sollte oben stehen “/fhem?cmd=set WZLicht (kleineralszeichen)v(grösseralszeichen)%”
Ah ok, ja. Man muss solche “Sonderzeichen” im Blog als HTML-Code formatieren, damit sie korrekt angezeigt werden: http://www.millin.de/downloads/3-935922-52-3/src/sonderzeichhtml.htm
Danke Jörg! exakt so habe ich das probiert, aber ohne %-Zeichen im Befehl geht nichts!
Hm ok… Blöd das. FHEM erwartet also ein % am Ende, damit der Aktor dimmt. Puh, da bin ich leider spontan überfragt. Am besten mal im https://www.loxforum.com nachfragen?!
Wenn du das Problem lösen konntest, würde ich mich freuen, wenn du uns hier daran teilhaben lässt.
Grüße
Jörg
PS: Bitte nutze die Antwort-Funktion bei den Blogkommentaren, sonst sind deine zusammengehörigen Kommentare alle auseinandergerissen.
OK! Danke!
Hallo Jörg!
Noch immer keine Lösung. Auf Loxforum 20 Hits, aber keine Antwort, inzwischen bereits au Seite 5 gelangt. Während der Woche Abwarten habe ich alle mögliche kombinationen mit Klammern, %-Zeichen, \, v.X, PUSH,GET usw probiert, mit und ohne Lichtsteuerung-Baustein, ohne Erfolg. Langsam glaube ich daß man mit Loxone keine FS20-Dimmer steuern kann, nur Loxone-eigene. Das wäre Schade, dann wäre die Investition an Loxone bzw. an FS20-Dimmern ein Fehler gewesen.
Mir bleibt anscheinend nur noch übgrig alles in FHEM-config einzustricken. Und Loxone wieder abzuschalten.
Oder könnte man vielleicht die Umwandlung von beliebigen HTTP-Loxone-Befehle in FHEM mit irgendeiner Routine wieder FS20-tauglich machen? Meine Programmierkenntnisse reichen leider nicht dazu.
Raimo
Hallo ins Blog-Forum, 😉
prima, dass hier Fragen zum Blogpost FHEM/Loxone so umfangreich beantwortet werden, dass man denken darf, warum entsteht daraus kein Forum oder gar ein Wiki, wie das eine oder das andere anfängerverständlich bewerkstelligt werden kann.
Vieles hat mir hier schon gut geholfen. Bei der Ansteuerung der FS20 Dimmer über FHEM aus der Loxone Visualisierung heraus ist aber nun auch Schluss.
Ich habe den Dimmer-Baustein 0-10V über einen Skalierer 0-100% mit dem VQ verknotet, darin den Befehl für den FS20 Dimmer´dim%´ URL-encoded eingetragen – aber alles hat nicht wirklich geholfen.
Daher hier mal die Frage, ob es Neuigkeiten zur Anfrage von Raimo gibt. Leider ist die Antwortkaskade hier ein wenig unterbrochen – aber der aufmerksame Leser wird den Zusammenhang (FS20 Dimmer über Loxone steuern) schnell erfasst haben.
Vielen Dank und Gruß in die Runde
Hi Rosco,
meine Sicht zum Thema Forum habe ich in diesem Kommentar dargelegt.
Ich habe gerade keine HM-Dimmer im Einsatz, die ich für Testes nutzen könnte. Die Frage ist tatsächlich, wie der passende URL-Aufruf aussehen muss, damit der Aktor in FHEM auch tatsächlich mit Prozentwerten versorgt wird. Das muss irgendwie gehen… Kannst du als Anhaltspunkt schon mal die korrekte URL posten, die den Dimmer aus dem Browser heraus ansteuert? Also sowas wie:
http://192.168.3.154:8083/fhem?cmd=set%20Wohnzimmerlampe%20on (nur eben mit Prozentwert)
Und dann wäre ein Screenshot der Readings und Attribute deines HM-Dimmers in FHEM sinnvoll (also die Detailansicht). Das Bild am besten an meine E-Mail-Adresse senden, lässt sich hier ja nicht direkt hochladen. Dann schau ich mir das mal im Detail an.
Grüße
Jörg
….Und wie habe ich mein Problem gelöst?
Ich habe es aufgegeben, die Beleuchtung mit Loxone zu steuern. Baute das gesamte in FHEM um, funktioniert jetzt zufriedenstellend.
Dabei habe ich aber festestellt, dass mindestens ein Teil von meinen Loxone-Problemen einfach durch Overflow in FHEM-Kommunikation verursacht wurden. Durch Verwendung von Loxone für gleichzeitige Steuerung von ca. 6 Kanälen für Beleuchtunsregelung verstopften die Befehle die Übertragung.
Dann habe ich auch festgestellt dass das og. “%-Problem” lösbar wäre, wollte aber nicht mehr rückbauen.
Jetzt verwende ich Loxone für Heizunsregelung zusammen mit FHEM usw.
Hallo Jörg,
vielen Dank für deine schnelle Rückantwort. Das “Blog-Forum” sollte auch eher die Wertigkeit dieses Blogs, insbesondere inklusive der hier zur Verfügung gestellten Antworten, darstellen.
Ich habe die Sorgen mit einem FS20-Dimmer, so wie Raimo seinerzeit auch; nicht mit einem Homematic Dimmer. Hinsichtlich Homeatic hatte ich irgendwo gelesen, dass die Übergabe nach FHEM funktioniert(?).
Beim Absetzen des Http-Befehls für die Ansteuerung des FS20-Dimmaktors (Zwischenstecker) hatte ich mich an der Befehlszeile in FHEM orientiert:
/fhem?cmd=set sz_Licht dim25%
Wenn ich dieses per Browser absetze, wird die Latüchte zu 25% hell.
Aus Loxone gesendet, wird diese Zeile mit eingesetztem für den Prozentwert (25) jedoch nicht in FHEM behandelt.
Also habe ich die Zeile auch mal URL-encoded in Loxone eingegeben:
/fhem%3Fcmd%3Dset%20sz_Licht%20dim%3Cv%3E%25
Da geht am FS20-Dimmer nix – weder an, noch aus.
UDP hängt am TR-Eingang des Loxone Dimmer Bausteins (Ist der überhaupt nötig, denn der FS20-Dimmer gibt doch keinen Status o.ä. aus).
Da ich der Meinung bin, dass der Dimmer-Baustein 0-10 V am AQ-Ausgang setzt (Min-Wert: 1, Max-Wert: 10), habe ich vor den VQ einen Skalierer-Baustein gesetzt mit Parameterwerten I1:0, O1: 0 und I2: 10, O2: 100
Am VQ (Richtung Fhem) habe ich mit den Korrekturwerten gespielt. Aber nichts sinniges herausgefunden.
Die Lampe lampt nicht.
Hey Raimo,
prima, dass du noch mitliest.
Wie wäre das Szenario denn lösbar gewesen?
Habe bereits gefürchtet dass du Rosco das fragst…..
Ich muss mal untersuchen, heutzutage bleiben ja von Versuchen keine Dokumente übrig.
Ich meine ich konnte dann über einen Skalier-baustein mit %-Ausgang einen einzelnen Befehl an Dimmer senden. Muss mal noch untersuchen, ich melde mich falls ich was brauchbares finde.
Nochmals Hallo!
Habe noch mal die zahllosen Versionen von Loxone Cofig angeschaut. Ich denke, es passierte folgendes:
-%-Befehle funktionierten mit dutzendfachen Variationen und Umskalierungen auch bei mir nicht
-Ich bin dann zu up-down Funktionen übergegangen
-dort habe ich als Schrittweite an Lichtsteuerung (Eingang SI) 6,25 eingegeben
-ST-Eingang 1000
-Einzelne Toggle-befehle über I1-3 und Scenes über S1… funktionierten, aber nur ein Paar Mal
-dann habe ich aufgegeben, und alles in FHEM eingebaut
Später habe ich erst verstanden, dass die Befehle schon richtig waren, aber beim umschalten von unterschiedlichen Szenen so viel Verkehr entstand, dass alles blockiert wurde.
Viel Glück! Lese gern noch mit!
Raimo
Ich hake einfach mal beim Loxone-Support nach… Vielleicht wissen die ja mehr, wie man ein % in den URL-Aufruf packen kann.
Also wenn ich es richtig verstanden habe, muss man schlicht das “normale” URL-Encoding verwenden. Für % muss man entsprechend den Ausdruck %25 nehmen. Möchte man den Dimmer also bspw. auf 20% einstellen, lautet der gesamte Aufruf: http://username:password@192.168.3.154:8083/fhem?cmd=set%20sz_Licht%20dim20%25
Aber wenn das schon beim Ausruf im Browser nicht funktioniert, erwartet FHEM etwas anderes… Könnt ihr das einfach mal testen?
Grüße
Jörg
Moin Jörg,
vielleicht etwas Licht im Dunkel:
Der URL-encodete Befehl über den Browser wird in FHEM verarbeitet – aber:
Das klappt gut bei 25% (Beispiel). Nimmt man aber einen anderen Wert, wie z.B. 20%, dann gibt´s Mecker von FHEM:
Unknown argument dim20%, choose one of dim06% dim100% dim12% dim18% dim25% dim31% dim37% dim43% dim50% dim56% dim62% dim68% dim75% dim81% dim87% dim93% dimdown dimup dimupdown off off-for-timer on on-100-for-timer-prev on-for-timer on-old-for-timer on-old-for-timer-prev ramp-off-time ramp-on-time reset sendstate timer toggle dim blink off-till-overnight intervals off-till on-till-overnight on-till
Wird wohl heißen, dass FHEM exakt einen der vorgenannten dim-Werte erwartet. Einfach mal 20% einstellen auswählen geht nicht.
In FHEM selber sind im Dropdown zum “set” Befehl die oben genannten Argumente gelistet. Dort gibt es auch einen Schieberegler, der aber ebenfalls die oben genannten Argumentwerte beginnent mit “06” und den entsprechenden Zwischenwerten bis “100” vorgibt.
Ok, dann ist das Problem wohl gelöst. Man baut zwischen Lichtsteuerungs-Modul und virtuellem Ausgangsbefehl einfach ein Status-Element ein, welches beim Dimmen nur die passenden Werte weitergibt. Ich habe mal schnell ein Beispiel erstellt: [download id="12077"] -> Login ist admin/admin
Viel Erfolg
Jörg
Ich habe jetzt mal die Zeichenfolge /fhem?cmd=set sz_Licht dim25% im Virtuellen Ausgang (http) an den Dimmer-Baustein von Loxone gehängt.
Der Befehl wird so tatsächlich verarbeitet, also auch nicht URL-encoded!
Aber ein /fhem?cmd=set sz_Licht off aus Loxone heraus schlägt leider fehl.
Per Browser ist das kein Problem, wird so direkt verarbeitet.
(Ach so, ich habe Chrome verwandt, falls das zum Nachstellen relevant ist.)
Also, gerade aus diesem Grund stellte ich als SI die Schrittweite auf 6,25. Dann gibt es an Ausgängen nur die von FHEM gekannten Werte. Ausgang 0…100% definieren. Ob ich dazu noch zusätzlich “Ganzzahl”-modul eingesetzt habe weiss ich nicht mehr.
Hallo Jörg,
der Status-Baustein ist ein (halber)voller Erfolg. So lässt sich der FS20-Dimmaktor ansprechen und entsprechend den erwarteten Dimm-Werten schalten. Prima, vielen Dank!
Ich habe den Status-Baustein direkt hinter den Dimmer-Baustein, also vor dem virtuellen HTTP-Ausgang gesetzt (ohne Lichtsteuerungs-Baustein).
Nun zur anderen Hälfte der halben Erfolgs. Leider lässt sich der FS20-Dimmaktor nicht über den Dimmer-Baustein abschalten.
Wenn der Schieberegler auf Linksanschlag gesetzt gibt der noch 1% raus, was über den Status-Baustein als “6” übertragen wird. Daran könnte man basteln. Aber warum schaltet er nicht den “Aus” Befeh über den Schalter in der Web-Oberfläche bzw. in der App?
Der http-Befehl über den Browser wird hingegen anstandlos angenommen.
Wenn der Schalter des Dimmer-Bausteins auf “off” gesetzt wird, wird am AQ des Dimmers bzw. des Status-Bausteins eine “0,0” ausgegeben. FHEM will für “aus” aber ein “off”. Wie kann die Logik ergänzt werden, dass aus einem “0,0” ein “off” an den Virtuellen Ausgang übertragen wird?
Nichts leichter als das… Dazu den ersten Eintrag aus dem Status löschen und am Ausgang des Dimmers/Lichtbausteins einen zusätzlichen virtuellen Ausgang koppeln, der beim Deaktivieren der Beleuchtung eine “off”-Mitteilung sendet: [download id="12080"]
Viel Erfolg
Jörg
Hey,
hab das mal nur überflogen.
Mich plagen zur Zeit auch die Dimmer und RGBW Stripe Einbindungen.
Ich habe gerade erfolgreich den Homematic Dimmer HM-LC-Dim1PWM-CV eingebunden.
Er erwartet FHEM z.B. den folgenden Web Befehl zum Dimmen auf 30%
http://192.168.167.239:8083/fhem?cmd.EG.ez.DI.LichtDecke.Schalter.1=set EG.ez.DI.LichtDecke.Schalter.1 pct 30
Im Loxone lautet der “Befehl bei Ein” -> “/fhem?cmd=set EG.ez.DI.LichtDecke.Schalter.1 pct ”
der “Befehl bei Aus” -> “/fhem?cmd=set EG.ez.DI.LichtDecke.Schalter.1 off”
Wichtig ist noch, dass der Haken “Als Digitaleingang verwenden” aus ist.
Ich habe jetzt den normalen Dimmerbaustein genommen und den HTTP Befehl an AQ angeschlossen.
Damit kann ich schon Mal stufenlos dimmen und Ausschalten über Loxone.
Ich wollte nachher nochmal den EIB Dimmer Probieren um den Zustand auch aus FHEM auslesen zu können.
Aktuell hänge ich aber an anderen Problemen fest.
Falls ich jetzt was beantwortet habe, was nicht gefragt war, dann sorry, habs nur überflogen.
oh, die spitzen Klammern wurden entfernt….
Ein Test:
Im Loxone lautet der “Befehl bei Ein” -> “/fhem?cmd=set EG.ez.DI.LichtDecke.Schalter.1 pct ”
Umschrieben:
Im Loxone lautet der “Befehl bei Ein” -> “/fhem?cmd=set EG.ez.DI.LichtDecke.Schalter.1 pct “”spitze Klammer auf” v “spitze Klammer zu””
@Jörg, perfekt! Das funktioniert! *jubel*
Und ich bastle da am Status-Baustein mit Statustext, falle darüber, dass man einen Ausgang nicht zweimal verwenden kann – und die Lösung ist so (naheliegend) einfach. Vielen Dank für die Hilfestellung. FS20 Dimmaktor: löppt!
Vielleicht solltet ihr alle Loxone/FHEM Lösungsszenarien sammeln und daraus ein Kompendium (nächstes eBook) erstellen. Mit einem solchen Nachschlagewerk helft ihr vielen Umsteigern/Erweiterern wie mir sehr weiter.
Ich habe noch einen Tipp für Lichtschaltungen mit nur einem Leiter, der Neutralleiter wird hierbei über einen anderen Weg zurückgeführt. Wichtig für Nachrüster: Klappt super, wie hier beschrieben mit den Bausteinen 2 Taster und EIB-Taster. Wo soll ich den posten, in dieser Tapete passt das nicht so recht.
@Jens,
vielen Dank für deine Lösung für den Homematic Dimmer; auch ein wichtiger Beitrag für “Nachforscher”.
Ich habe aus der “alten Welt” FS20 und Homematic im Einsatz und schwitsche nun langsam auf Loxone, ohne die Investitionen aufgeben zu wollen.
Bei der Gelegenheit (für alle Mitleser und die, die es interessiert):
Ein Statustext am Ausgang des Status-Bausteins wird in der Loxone Config (V8.3.3.21) nicht wie z.B. ein Statuswert rechts neben dem Baustein dargestellt. Man muss über die Buchstaben TQ “hoovern”, also mit dem Mauszeiger drüberfahren, dann wird der betreffende Statustext in einer Sprechblase ausgegeben. Warum das so ist, weiß nur Loxone allein..
Hallo zusammen,
ich bin derzeit am verzweifeln. Ich setze auf eine Kombo aus Homematic und Z-Wave. HM ist mehr für die Heizungssteuerung während sich Z-Wave auf Jalousie und Garagentor derzeit beschränkt (Licht soll aber noch ausgebaut werden). Darüber hinaus bediene ich noch mehrere Hue und SONOS Geräte. Zusammengeführt habe ich derzeit alles mit IP-Symcon. Was mich hier jedoch stört ist der Programmier und Konfigurationsaufwand. Auch die Visualisierung ist nicht wirklich zeitgemäß.
Durch Zufall bin ich nun über euren Blogpost hier gestolpert und bin fasziniert. Was mich nun jedoch interessieren würde: Wie sieht die Langzeiterfahrung nun aus? Läuft alles rund ohne Probleme? Habt Ihr eine Heizungssteuerung implementiert? Kann ich Heizpläne in der App erstellen die an FHEM übertragen werden?
Ansonsten zögere ich noch soviel Geld für den Miniserver auszugeben 🙂
Hi Flo,
habe die Kombination aus FHEM und Loxone seit mind. 2 Jahren im Dauereinsatz. Christoph auch schon seit mind. einem Jahr. Bisher keine Probleme – bis auf die Tage, an denen man einfach mal wild herumtestet. 🙂
Die Logik der Heizungssteuerung machst du am besten direkt in Loxone. Hier kannst du dich total austoben mit den vorhandenen Modulbausteinen. Die Visualisierung ist wirklich schick und praktisch. Die Heizzeiten lassen sich auch super über die App einsehen und anpassen. An FHEM sendet man dann nur noch den Heizbefehl für den Heizungsaktor (0-100%) und liest umgekehrt von FHEM die aktuelle Raumtemperatur aus (bzw. lässt diese von FHEM zu Loxone pushen).
Viele Grüße und Erfolg bei der Umsetzung
Jörg
PS: Die Einarbeitung ist anfangs schon etwas tricky, mit etwas technischem Hintergrund und Durchhaltevermögen aber machbar. Und Anleitungen dazu gibt es im Blog ja mittlerweile genug.
Hi Jörg,
Vielen Dank für Dein Feedback. Dann bin ich schon mal zuversichtlicher 🙂 Mit der App kann man ja im Demo Modus ein wenig spielen und es ist einfach super. Habt ihr schon eine HomeKit Integration via Homebridge getestet?
Hi Flo,
Homekit habe ich schon letztes Jahr im Blogpost Mit Siri und FHEM das gesamte Smart Home per Stimme steuern behandelt. Seitdem ist aber viel passiert und die Integration in FHEM ist einfacher geworden. Da ich gerade andere Baustellen habe (im wahrsten Sinne des Wortes), wird ein Update dazu noch dauern. Werde mich aber auf jeden Fall wieder ausgiebig damit beschäftigen und darüber berichten.
Grüße
Jörg
Danke nochmals für Deine Antwort. Ich bin ein gebranntes Kind was Homebridge angeht, da das IPS Modul ohne Vorwarnung aussteigt und aus irgendwelchen Gründen nicht mehr läuft. Erklärung dafür hat niemand.
Wenn ich jetzt noch eine vernünftige Geofencing Implementierung für FHEM oder Loxone finde bin ich happy und es geht los 🙂
Schau dir mal das Kapitel “Das GEOFANCY Modul” im FHEM Wiki an.
Grüße
Jörg
Hallo Jörg,
vielen Dank für die tolle Anleitung. Ich bin selbst von der “anderen” Seite gekommen. Habe eine komplette Loxone Installation und diese um FHEM erweitert um meine Viessmann WP zu steuern. Jetzt würde ich gern Alexa mit FHEM einsetzen und Loxone steuern, da ich den Umweg über die HA-Bridge nicht smart finde. Gibt es einen Weg meine Loxone Lampen, Thermostate etc. als quasi virtuelle Geräte in FHEM einzubinden, so dass ich diese über Alexa-FHEM ansprechen kann und FHEM dann einen UDP oder HTTP-Befehel an Loxone sendet?
Grüße Norman
Hallo Norman,
klar. Was von FHEM zu Loxone geht, klappt auch andersherum. Du kannst für deine Loxone-Devices in FHEM dummys anlegen und aus Loxone heraus über einen virtuellen HTTP-Ausgangs-Befehl die Werte an die FHEM-Dummys übergeben. Über Alexa-FHEM steuerst du dann den STATE der dummys und übergibst die Statusänderung via UDP wieder zurück an Loxone.
Viel Erfolg, klingt spannend!
VG
Christoph
Hallo Christoph,
ich habe zumindest schon mal die Lichter eingebunden, so dass ich diese über Alexa steuern kann. Leider habe ich noch nicht den richtigen http-Request gefunden um auch die Rolläden zu steuern. Weißt du, ob man das direkt über den Aufruf der UUID machen kann oder ob ich dafür VI anlegen und diese dann ansprechen muss?
Viele Grüße
Norman
Hallo Norman,
na das sind doch schon einmal gute Nachrichten. Schön, dass du mit dem Tipp etwas anfangen konntest. Ich bin mir nicht ganz sicher, ob ich verstanden habe, was du vorhast, aber ich denke, du hast deine Rolläden in Loxone und willst einen dummy in FHEM per Alexa ansteuern, der diese dann auf- und abfährt. Dazu brauchst du einen virtuellen UDP-EIngang-Befehl in Loxone, der so lange eine “1” auf den Up- bzw. Down-Eingang am Rollo-Baustein sendet, wie du es für die Fahrt benötigst. Das muss die Logik sein.
Viele Grüße
Christoph
Hallo,
Seit langer Zeit lese ich hier im Blog mit und bin begeistert. Ich habe bisher noch keine Erfahrung mit fhem oder Loxone oder anderen Smart Home Komponenten. Nun möchte ich mich heranwagen. Daher meine Frage: welches System, Fhem und Loxone oder doch Fhem und etwas anderes, wird auf Grund der Erfahrungen als visuell ansprechend, “simple” programmierbar und in Bezug auf die Sicherheit beim Datenversand empfohlen. Mein angedachtes Projekt wird wohl leider sehr umfangreich (2-Familien-Haus), mit Fenstersensoren, heizungssteurung, Rollläden, Rauch-temperaturmelder, Lichtsteuerung,Einbindung einer Alarmanlage, RFID/ Fingerabdruck Haustür und abschließend IP/WLAN kameraüberwachung.. Suche daher
Infos und Erfahrungen. Wenn es hier zu lang wurde, bitte ich um Entschuldigung:-)
Hallo, durch deine Begeisterung angeregt, stelle ich auch gerade von einem reinen FHEM auf eine Kombi aus FHEM und LOXONE um – Miniserver go.
Übernahme der readings aus FEHM via UDP klappt prima und auch die Programmierung in LOXONE ist klasse.
Ich kriege aber aktuell via http keine Ausgangsbefehle an FHEM raus.
– Virtueller Ausgang ist angelegt
– Virtueller Ausfgangsbefehl auch
Der dadurch erzeugte “Gesamtstring”, “http://user:passwort@192.168.178.43:8083/fhem?cmd=set EG.fl.LA.Decke on” in meinem Beispiel mit einem Eoncean-Aktor im FHEM funktioniert, wenn ich ihn über den Browser absetze….abe nicht aus LOXONE heraus.
In der Visulisierung wird die “Lampe” auf Ein gesetzt – bleibt aber im richtigen Leben dunkel.weder im Log noch im Eventmonitor kommt bei FHEM etwas an.
Was mache ich falsch?
Jörn
Hallo, ich habe ein Problem beim Datenaustausch über udp, wofür ist am ende jedes mal eine -1??? z.b.
my $state = ReadingsVal(“$device”,”state”,”-1″);
denn Loxone bekommt auch am ende die -1 übergeben, und manchmal übernimmt er die -1 bei mir als wert. Könnte ich die -1 einfach wech lassen??
Hallo Zusammen,
bei mir läuft auch FHEM und Loxone zusammen schon längere Zeit problemlos. Nur seit dem Update auf die Loxone Version 8.3 werden von Loxone zu FHEM über http keine Befehle mehr gesendet. Status von FHEM zu Loxone werden weiterhin problemlos übertragen. Das selbe ist bei mir wenn von Loxone ein TCP Befehl abgesetzt wird. Habt ihr das Problem auch beobachten können ?
Vielen Dank,
Andi
Glaube, dass FHEM mit den letzten Updates jetzt Sicherheitsmechanismen eingeführt hat. Glaube dazu gab es schon einen anderen Kommentar. Hatte leider noch keine Zeit mich damit zu beschäftigen…
Grüße
Jörg
schau mal im FHEM Forum, Jörg hat Recht.
Ich musste meine HTTP Befehle anpassen und in FHEM etwas eingeben, danach hat es wieder funktioniert.
Melde dich wenn du es nicht findest.
Hi Oisin,
vielen Dank für die Info! Ein Link zum Forumsthread wäre natürlich grandios. 🙂
Grüße
Jörg
Hi Oisin,
das wäre super, wenn du da einen genaueren Hinweis (oder Link) hättest, was du da angepasst hast.
Ich dachte nur, das Problem war nach dem Loxone Update, da seither meine TCP Befehle von Loxone zum Raspi auch nicht mehr gehen.
Man sollte nicht immer zwei Updates zur gleichen Zeit machen…
Vielen Dank,
Andi
war das diese Änderung ?
https://wiki.fhem.de/wiki/CsrfToken-HowTo
wenn ich es temporär ausschalte: attr WEB.* csrfToken none
dann gehen die Befehle zu FHEM wieder, jetzt ist nur die Frage wie man das Token beim Loxone Befehl einbauen kann. Wie hast du denn das gelöst ?
Danke
Hi, ich glaube, in deinem Quelltext hat sich ein Fehler eingeschlichen.
Im notify rufst du EnergyToLoxone2 auf (Die 2 ist hier am Ende).
define EnergyToLoxone2 notify .*:current.* {EnergyToLoxone2(“$NAME”)}
In der 99_myUtils.pm heißt das Modul aber:
sub Energy2ToLoxone($)
Gute Arbeit übrigens, darauf kann man gut aufsetzen.
Hallo !!
Ich habe eine Z-Wave controlle (NodON CRC3-3-x). da wird mir bei Fhem folgendes ausgegeben.
2017-06-25 10:33:11 ZWave ZWave_GENERIC_CONTROLLER_2 cSceneSet: 1
2017-06-25 10:33:11 ZWave ZWave_GENERIC_CONTROLLER_2 wakeup: notification
wie kann ich das an loxone weitergeben ??
Temperatur aus HMS100T über FHEM in Loxone darstellen
Hallo zusammen,
dank der tollen Anleitung konnte ich bereits Schalter und sogar den Dämmerungswert aus dem FHEM Modul “Twilight” in Loxone verarbeiten.
Probleme habe ich aber mit der Temperatur aus einem HMS100T, welcher munter in FHEM die Temperaturen ausgibt. Leider werden diese nicht nach Loxone übertragen, dort wird ständig der Wert “0” ausgegeben.
Hier die Informationen aus FHEM für den HMS100T:
https://www.dropbox.com/s/g2k3lurlz5545kw/hms100T_device_overview.JPG?dl=0
In Loxone wurde ein virtueller UPD-Eingang gesetzt und in der Befehlserkennung die device-Bezeichung aus FHEM übernommen:
https://www.dropbox.com/s/n3ry6pp6p8a531s/Loxone_Eigenschaften_VI_UDP.JPG?dl=0
An der 99_myUtils.pm wurden keine Änderungen vorgenommen, da das Reading ´temperature´ ja dort bereits beschrieben ist:
https://www.dropbox.com/s/fs8ttee0164sem0/FHEM_99_myUtils.pm.JPG?dl=0
Somit stehe ich im Moment mit meinem Anfänger-Latein am Ende.
Schön wäre es auch, wenn der Status der Batterie nach Loxone übertragen würde, so dass ich mir eine Benachrichtigung per Mail bei einer schwächelnden Batterie zusammenbasteln kann.
Vielen Dank für euer Interesse an meinem Post, ich freue mich über jegliche Hilfestellung.
Beste Grüße
Hey Rosco,
danke für dein Feedback. Ich habe mir deine Screenshots einmal angesehen und kann zunächst kein Problem erkennen. Ich würde zunächst mal die Einheit in Loxone auf “” zurückstellen, um hier einen Fehler bei der Werteinterpretaion auszuschließen. Als nächstes würde ich den UDP-Monitor in Loxone öffnen und nachsehen, welche UDP-Nachrichten eingangsseitig reinkommen. Gleichzeitig solltest du mal den FHEM-Event-Monitor öffnen, um sicherzustellen, dass die Temp-Änderung an deinem Device in FHEM auch ein Event auslöst – das ist nämlich die Basis für eine UDP-Nachricht nach Loxone.
Den Tipp mit den Batteriewerten habe ich in mein Backlog aufgenommen – danke!
Viel Erfolg und melde dich, ob du weitergekommen bist.
VG
Christoph
Moin Christoph,
vielen Dank für deine Rückantwort. Urlaubsbedingt etwas verspätet kommt hier nun mein Statusbericht.
“Reboot tut gut” – das scheint auch für den Miniserver zu gelten. Denn nach Änderungen der Loxone Config an anderer Stelle wurden plötzlich die Werte des HMS100T im Miniserver verarbeitet und angezeigt. Die Übertragung von fhem war also korrekt eingestellt gewesen.
Hinsichtlich der Batteriewerte habe ich ein bisschen experimentiert und bin nun erfolgreich auf diese Lösung gekommen:
#TempHumidityToLoxone
#device:
#1 temperatur
#2 humidity
#3 battery (0,1)
sub TempHumidityToLoxone($)
{
my ($device) = @_;
my $temperature=ReadingsVal(“$device”,”temperature”,”-1″);
my $humidity=ReadingsVal(“$device”,”humidity”,”-1″);
my $battery = ReadingsVal(“$device”,”battery”,”-1″);
if ($battery eq “ok”) {
$battery = “1”;
}
if ($battery eq “low”) {
$battery = “0”;
}
UDP_Msg(“192.168.178.xx” , “port” , “$device: $temperature $humidity $battery”);
}
Anmerkung: Die korrekte IP-Adresse muss natürlich lokal angepasst und statt “port” muss die entsprechende Portadresse eingesetzt werden.
Das Auslesen von Temperatur und Batteriestatus aus den fhem Readings klappt also soweit.
Wie kann ich jetzt aus den fhem Internals
CUL_0_TIME 2017-08-18 16:19:45
den Zeitstempel der Temperaturmessung (Messwertübertragung) abgreifen und von fhem nach Loxone im entsprechenden Format mit oder ohne Datum übertragen. Denn das wäre ja noch das Sahnehäubchen zu wissen, wann denn die Temperatur tatsächlich auch gemessen wurde?
Beste Grüße
Rosco
Hallo Rosco,
wie man Internals ausliest steht in der FHEM-Commandref unter der Kategorie “Perl Specials”. Link: https://fhem.de/commandref.html#perl
VG
Christoph
Wie bekomme ich den Status Wert eines Bewegungsmelders über UDP in die Loxone.
Bewegungsmelder:Bew01_K1
Status: on-for-timer 128
Wenn der Bewegungsmelder mit dem Button ausgeschaltet wird, kommt das off daher.
Aber ich schaff es einfach nicht den Ein Befehl zu übermitteln.
In der fhem.cfg hätte ich folgendes reingeschrieben:
define OnForTimerToLoxone notify .*:state.* {OnForTimerToLoxone(“$NAME”)}
und in der 99_myUtils.pm:
#OnForTimerToLoxone
#device:
#1 state(0,1)
#2 pct(0-100)
sub OnForTimerToLoxone($)
{
my ($device) = @_;
my $state = ReadingsVal(“$device”,”state”,”-1″);
my $pct = ReadingsVal(“$device”,”pct”,”-1″);
#fhem(“set $device: $state $pct”);
UDP_Msg(“10.0.0.200” , “7000” , “$device: $state $pct”);
}
Ich hab das einfach abgeschrieben – hab leider keinen Tau von Perl etc.
Ich bitte um hilfe.
Andere Frage: Was kann schuld sein, wenn der Bewegungsmelder von sich aus keinen AUS Befehl liefert.
Einstellungen (FS20PIRA):
Einschaltdauer: 6.3: 128 sec.
Sendeabstand: 6.4: 120 sec,
Hi,
ich habe wie beschrieben, alles angelegt, die Daten kommen auch an. Jetzt würde ich gerne die Darstellung für Fenster auf/zu Darstellen.
Muss ich dazu einen Baustein anlegen, oder wie hast du das gemacht?
gruß
Hallo Zusammen,
ich habe es auch nach der Anleitung angelegt. Allerdings erhalte ich von dem “OnOffToLoxone”-notify in Loxone immer den Zustand 0 (NULL) und nicht den Zustand 1 bei engschalteter Lampe.
Woran kann das liegen?
Danke im Voraus
2017.11.22 20:23:34 2: IT set Lichterkette off
2017.11.22 20:23:35 3: OnOffToLoxone return value: send Lichterkette: 0 -1
2017.11.22 20:23:35 2: IT set Lichterkette on
2017.11.22 20:23:36 3: OnOffToLoxone return value: send Lichterkette: 0 -1
Loxone Schaltuhr an FS20 über FHEM
Hallo liebe Blog-Gestalter und -leser,
ich kann mir nicht erklären, warum diese Schaltung (Link zum Screenshot: https://www.dropbox.com/s/jmszqq8pum30n0m/x-mas_light.PNG?dl=0) nicht funktionieren will.
Wenn ich die notify´s manuell an den Eingängen `On´ bzw. ´Off`des 2-Tasten Bausteins trigger wird der FS20 Schaltaktor auch geschaltet. Auch über die Loxone Visu kann ich den FS20 Schalter bedienen. Alles gut soweit.
Füge ich jetzt die Loxone Schaltuhr (als Digitalausgang) mit ihren Ausgängen ´Qon´ bzw. ´Qoff´ parallel auf die Impulseingänge des Tasters dazu, aktiviert zwar die Schaltuhr wie gewünscht ihre Ausgänge – aber der FS20 Schaltaktor reagiert nicht darauf. So wird´s nix mit der Weihnachtsbeleuchtung…
Ich bin für jeden Tipp dankbar, der die Lichterkette hell macht. 😉
Allen eine schöne Vorweihnachtszeit
Gruß Rosco
Ich hab´s dank freundlicher Hinweise aus den einschlägigen Foren gelöst bekommen und möchte dies hier natürlich noch mitteilen:
In der Vergangenheit habe ich einfache Schaltungen, wie ursprünglich auch hier im Blog an anderer Stelle empfohlen, mit einem 2-TASTEN-Baustein und dem EIB-TASTER realisiert.
Den EIB-TASTER, und nur diesen, habe ich für die Visualisierung hergenommen. Somit wurden auch Schaltänderungen, welche direkt am Aktor selbst oder über andere externe Services ausgelöst wurden, über FHEM an Loxone und den entsprechenden “EIB-Taster” weitergereicht und dessen Status in der Visu nachgezogen. Die Schaltungen innerhalb Loxone klappten auch über die Visu mit dem EIB-TASTER. Alles soweit ok.
Aber eben nicht in Verbindung mit dem Loxone SCHALTUHR-Baustein. Sofern der EIB-TASTER dazwischen sitzt, wird trotz korrekter Darstellung in der Liveview kein HTTP-Befehl an FHEM weitergegeben. Warum auch immer…
Die Lösung ist tatsächlich der Einbau eines SCHALTER-Bausteins statt des 2-TASTEN- und des EIB-TASTER-Bausteins, denn dieser stellt die Änderungen in FHEM auch korrekt in der Loxone Visu dar.
Hallo an Alle,
Ich habe bereits die Thermostate von Max! erfolgreich in Loxone eingerichtet und kann sie auch aus Loxone heraus steuern.
Was mich aber stört ist die Tatsache dass wenn ich auch mal die Temperatur an einem Thermostat direkt ändere dieses aber nicht in der Loxone App angezeigt wird, sondern nur immer die Temperatur die zuletzt in der App eingestellt wurde.
Gibt es eine Möglichkeit dass Loxone die am Thermostat eingestellte Temperatur in der App übernimmt?
Beste Grüße,
Daniel
HI.
Danke für die tolle Anleitung.
Ich habe Bewegungsmelder in FHEM, welche auch noch einen Helligkeitswert mitgeben.
Leider bekomme ich den nicht übertragen.
Des weiteren löst auf motion aus, aber es kommt immer eine -1.
Was kann hier das Problem sein?
Danke
Hi!
Wie kann ich das ganze mit den Rauchmelder von Xiaomi realisieren?
ISt das dann auch die ONOFF UDP Message?
Hatte ich so eingerichtet – aber es wird nichts gesendet?
Die Readings in FHEM sehen so aus:
Readings
alarm
0
2018-11-24 11:21:03
batteryState
ok
2018-11-24 11:21:03
batteryVoltage
3.3
2018-11-24 11:21:03
density
0
2018-11-24 11:21:03
heartbeat
158d0002824aab
2018-11-24 11:21:03