FHEM vs. HomeMatic Homputer CL

[fabian1987]

Guten Abend,

ich plane derzeit meine Heizungssteuerung auf eine automatisierte Temperaturregelung umzubauen. Hierzu möchte ich sechs Raumthermostate mit acht 230V Schaltaktoren und einer Schaltsteckdose verbinden.
Die Schaltaktoren sollen die Lüftermotoren (Zweipunktregelung) in meinen Nachtspeicherheizkörpern ansteuern, die Schaltsteckdose einen Elektroheizer im Bad. Später will ich die Aufladesteuerung der Speicherheizkörper ebenfalls automatisieren und ggf. weitere Projekte (man wird ja dann schnell kreativ) verwirklichen.

Im Fokus steht zunächst mal zeitnah eine funktionierende und zuverlässige Heizungstemperaturregelung aufzubauen. Das System muss auch von meiner Frau zu bedienen sein, wenn ich mal länger auf Geschäftsreise bin. Wenn die Wohnung in ferner Zukunft mal vermietet werden sollte, dann sollte das System einmal konfiguriert auch ohne Probleme weiterlaufen können. Bisschen Bastelspaß darf natürlich auch sein. Beruflich mache ich auch Softwareentwicklung, wenn auch in einem ganz anderen Gebiet. Pearl sollte daher zumindest nach entsprechendem Studium kein unüberwindbares Problem sein.

Dass ich die HomeMatic-Komponenten verwenden will ist eigentlich soweit klar, denn ich finde es wichtig, dass die Schaltaktoren mir ihren Schaltzustand zurückmelden können. Allerdings stehe ich im Moment vor der Frage, ob nun FHEM mit Raspberry PI und HMLAN-Adapter oder die originale Software von Homematic zu verwenden. Ein Kollege von mir nutzt FHEM und ist sowohl aus Kostengründen, wie auch von den Funktionen her überzeugt. Allerdings kennt er das HomeMatic-System nicht, kann mir also nichts über die funktionalen Unterschiede berichten. Er argumentiert lediglich damit, dass mit FHEM dank Pearl eigentlich alles möglich sei, was mit HomeMatic möglicherweise eher schwierig werde.

Welche Funktionalitäten kann man denn konkret in FHEM umsetzen, die man im Homeputer nicht umsetzen könnte (z.B. Wetterbericht, Plots, was auch immer)?

Hoffe ihr könnt mir auf die Sprünge helfen!

Gruß,
Fabian

[Icebear]

Hi,

ich kenne zwar homeputer nicht aber generell kann man wohl einfach behaupten das man in FHem in alles eingreifen kann was mit homeputer vermutlich nicht geht .. da hat man vorgefertigte Funktionen und ist darauf beschränkt ..
In Fhem hat man zwar auch schon eine Menge aber das was es nicht gibt baut man sich halt selbst.

(ums weiterzuspinnen, wenn ein Modul in Fhem etwas nicht so tut wie man es gern hätte könnte man theoretisch sogar das modul oder gar das ganze fhem umbauen .. geht in homeputer nicht)

Aber sowas will wohl eher keiner.

[Puschel74]

Hallo,

dank Pearl

sollte eigentlich ein Versandhändler sein - damit wirst du in FHEM nicht viel machen können ausser Geräte bestellen 

Aber ein Perl-Buch wird dir in FHEM sicher mehr helfen können wenn du ein Modul (um-)programmieren willst.

Wie Icebear schon gesagt hat.
Bei Homeputer kannst du nur! das machen was die Software kann.
Bei FHEM wird "einfach" ein Modul (neu) umgeschrieben und an deine Bedürfnisse angepasst wenn es wirklich sein muss.

Ich habe mir einen Versuchs-RasPi mit HM-Lan-Konfigurator ins "Technikzimmer" gelegt um mich mit HM ein bischen befassen zu können.
Meine FS20-Geräte werde ich langsam aber sicher verkaufen und auch auf HM umsteigen.
Aber nicht wegen den "Rückmeldungen" - dieses Thema wurde in diversen Beiträgen schon (aus-)diskutiert.

Lies dir mal das Einsteiger.pdf durch - evtl. gibt es dann ja keine Fragen mehr 

Grüße

[fabian1987]

Guten Morgen,

Pearl - auch nicht schlecht. Das ist dieser Versandhändler mit den mehr oder weniger sinnfreien Mini-Gadgets, oder? Ich meine natürlich Perl. Aber Pearl geht so natürlich von der Hand zu schreiben, das macht die fast von alleine.

Erst einmal vielen Dank für eure Antworten. Also das Einsteiger-PDF habe ich schonmal angelesen (wirklich toll übrigens geschrieben!!). Leider steigt mir das PDF schon zu sehr in die Technik ein und klärt zu wenig die Frage, was FHEM denn nun mehr kann. Soll es vermutlich auch nicht. Aber für meine Fragestellung hilft mir das demnach noch nicht ganz. 

Auch in euren Antworten ist das irgendwie bisher noch etwas unkonkret. Sicher ist es besser, wenn man ein konkretes Problem hat und das Homematic-Modul mit diesem nicht umgehen kann, dass man dann die Module in Perl für FHEM direkt umschreiben kann. Aber braucht man das in der Praxis wirklich? Brauche ich das wirklich für geläufige Problemstellungen, oder ist das nur in Detailfragen relevant? Irgendwie ist mir das noch zu abstrakt, zu wenig greifbar. Ich will damit sagen, wenn ich bspw. zugunsten einer größeren Stabilität und etwas leichterer Umsetzung auf ein kleines bisschen Funktionalität verzichten müsste, dann wäre das sicher auch okay. Nur bislang kann ich überhaupt nicht einschätzen, welches Opfer ich dann da bringen würde.

Hier gibt es doch sicher einige Leute, die vorher HomeMatic-Komponenten und Software verwendet haben bzw. beides kennen. Diejenigen sind doch sicher an einem bestimmten Punkt umgestiegen als klar wurde, dass sie bestimmte Problemstellungen mit HM nicht lösen können. Ich wüsste gerne, was das war und wieso bei denjenigen die Überzeugung kam, dass FHEM für ihre Einsatzzwecke besser geeignet sei.

Hoffe ich konnte meine Fragestellung etwas verdeutlichen! Vielen Dank für eure Antworten schon im Voraus!

Gruß,
Fabian

[Puschel74]

Hallo,

Aber braucht man das in der Praxis wirklich?

Nein.

Brauche ich das wirklich für geläufige Problemstellungen, oder ist das nur in Detailfragen relevant?

Für die ganz "normale" Anwendung wirst du sicher nicht in die Verlegenheit kommen und mal ein Modul umschreiben bzw. neu schreiben müssen.
Bei HM sowieso nicht.
Das wird dir auch bei Detailfragen sicher nie unterkommen.

Ein eigenes Modul wirst du schreiben wenn du "exotische", bisher von FHEM noch nicht abgedeckte Sachen machen willst.
Die gängigsten Module - Twilight, HeatingControl (um nur mal 2 zu nennen) - sind fertig und lassen sich mit jeder Hardware verwenden.
Als Hardware meine ich hier - Geräte die FHEM "kennt".
Sprich - die FHEM ansprechen und verarbeiten kann.

Kurz und knapp - HM kannst du definitiv verwenden ohne Module programmieren zu müssen (es sei den es sind neue Geräte die von den Funktionen her noch! nicht in FHEM integriert sind - was aber recht rasch nachgezogen wird).

Mit der Homeputer-Software bist du allerdings fest an HM gebunden da diese mWn keine andere Geräte unterstützt und auch mit einem anderen Sender/Empfänger nicht nachgerüstet werden können.
Das geht in FHEM definitiv.

FHEM auf einen RasPi, HM-Lan-Konfigurator dran und deine ersten Geräte sind bereit um in FHEM eingebunden zu werden.
Anstelle des HM-Lan kannst du auch einen CUL nehmen - dann kannst du "nebenher" noch andere Geräte bedienen (z.B. FS20).
Das geht mit einem HM-Lan nicht - dieser kann nur HM.
(Sollte ich nun Blödsinn geschrieben haben bitte ich diesen zu berichtigen).

Fazit:
Wenn du auf Homeputer setzt gibst du mit Sicherheit Flexibilität auf zugunsten von ... keine Ahnung da ich Homeputer zwar kenne aber nie verwendet habe.
Mit FHEM kannst du alles machen was du willst (und noch viel mehr    ).

Ich will hier aber jetzt keine Werbetrommel für FHEM rühren.
Entscheiden musst im Endeffekt du dich was du nimmst.

Grüße

[Icebear]

Hallo,

da du ja programmierst als beispiel:

Du kannst dir wunderbar mit access eine Datenbank zusammenklickern .. klappt auch wunderbar.. über vb kannst du in diverse sachen eingreifen. auch toll .. aber sobald du interne Verhaltensweisen ändern willst gehts nicht (oder nur sehr aufwändig).
Für solche Projekte nimmt man sich dann eine "echte" programmiersprache.

Genauso kannst du homeputer und fhem sehen ...
Ich denke jeder der mal mehr will als standard wird an die grenzen stoßen die Homeputer hergibt.
Beispiel bei mir:

Ich habe von FS20 den Infarotempfänger um mit meiner Harmony Fernbedienung aktionen Auszuführen (Sowas wie Gemütlich Fernsehen) normales licht geht aus, gemütliche beleuchtung an usw
Genau das würde mit Homeputer nicht gehen weil homeputer kein FS20 kann und es von homematic kein passendes gerät gibt. Also FHem dazwischen was per FS20 notify die Aktionen auslöst (vorher auf Intertechno/Homeeasy Geräten) mitlerweile auf Homematic geräten.
Ich habe hier also aktuell 4 verschieden Systeme laufen (alle mit vor und nachteilen) und picke mir aus allem das beste raus.
Wie z.b. einen einfachen temperatursensor von TFA (kostet 10-15 euro). Hätte ich Homeputer blieb mir nur der von Homematic (der mal ebend 50 kostet)

So das wars. Ich hoffe wir konnten dir helfen bei deiner entscheidung ..
Achja noch ein wichtiger punkt. Homeputer ist mit sicherheit einfacher zu bedienen als FHem ... Da klickste dir das zusammen was brauchst und ruhe ist ... Bei FHem haste mehr tipparbeit ... sollte der Fairnesshalber erwähnt sein.

[fiedel]

Läuft denn der heimische Puter auch auf einer 5 Watt ARM- Maschine, oder nur auf nem Windows-PC? Das wäre für mich das eigentliche No Go.

Gruß

Frank

[Puschel74]

Hallo,

ich hab mal ein bischen gegoogelt zu Homeputer.

Die Software benötigt
a) einen laufenden PC
b) Kommunikationsschnittstellen zu den Geräten

Kosten:
Software
Standardversion (unterschiede zur Studio habe ich mir nicht herausgesucht) kostet € 79,00 - die Studio € 179,00
Hardware
FHZ2000 € 99,50
oder eine CCU2 € 149,00 (inkl. Studio Software € 299,00)
oder HM-Lan-Adapter € 69,50
für grösser Objekte gibt es eine CL-Box mit 2 LAN-Schnittstellen und Software € 699,00

Möglichkeiten:
So wie ich das gelesen habe kann Homeputer HM und FS20 - passende Schnittstellen logischerweise voraus gesetzt.
"Floorplan" sprich Grundrisspläne lassen sich als Bitmap integrieren
Aktionen lassen sich "zusammen klicken" - die Device sind hinterlegt und können miteinander verknüpft werden.
Ob die Aktionen auf die Hardware übertragen werden können und auch ohne PC zur Verfügung stehen weiß ich nicht - so tief bin ich nicht hinab gestiegen.

Dem gegenüber steht FHEM.
Software € 0,00
Hardware
HM-Lan-Adapter € 69,50
RasPi € 35,20
für grössere Objekte nimmt man eben einen zweiten RasPi

Möglichkeiten:
Erschöpfen sich eigentlich nur an den Fähigkeiten oder der Ausdauer des Besitzers.
Wie Icebear schon geschrieben hat:

Bei FHem haste mehr tipparbeit ... sollte der Fairnesshalber erwähnt sein.

Bei mir persönlich ist eigentlich schon bei den preislichen Unterschieden das "Ende der Fanhnenstange" erreicht.
Die Software kostet ja schon €79,00 mehr als FHEM 

Die restliche Hardware aka CUL/CUNx/COC/HM-Lan-Adapter etc. wird ja sowieso bei beiden Varianten benötigt und wird daher von mir nicht auf den Prüfstand gestellt.
Und das bischen Tipperei übernehme ich gerne.

Alle hier zusammengetragenen Infos wie Preise, Geräte etc. wurden von mir nur überflogen und keiner Preissuchmaschine oder genaueren Kontrolle unterzogen.
Der RasPi wurde nur als Beispiel genommen - es kann natürlich jede andere FHEM-fähige Hardware benutzt werden.
Die Angaben erheben keinen Anspruch auf Vollständigkeit und sind auch nur meine persönliche Meinung.

Grüße

[fabian1987]

Hallo!

Also, ich habe es gewagt und habe mir die Tage einen Raspberry PI, den HMLAN-Adapter ein Thermostat und einen 230V-Schaltaktor gekauft. Mit folgender Installationsanleitung bin ich sehr schnell zum Ziel gekommen und hatte ein laufendes FHEM: http://www.meintechblog.de/2013/05/fhem-server-auf-dem-raspberry-pi-in-einer-stunde-einrichten/ Einen herzlichen Dank an den Autor, falls er hier mitliest. Nach einigen Anlaufschwierigkeiten habe ich es jetzt hinbekommen, dass die Heizung sich abhängig von Soll- und Isttemperatur ein- und ausschaltet (vgl. angehängten Screenshot, mächtig stolz...  ).

Allerdings habe ich noch einige Fragen bzgl. des FHEM-Frontends:

1. Wie stelle ich den Skin um? Hatte ursprünglich den Default-Skin angewählt, habe dann mal ein bisschen rumgeklickt, was jedoch nichts zur Folge hatte und irgendwann hat sich der Skin wie von Geisterhand auf grau umgestellt. Würde aber lieber wieder den Default-Skin haben. Aber egal was ich versuche (reread, shutdown), nichts hilft. Der Skin bleibt grau.

2. Wie bekomme ich Daten aus zwei Logfiles in ein Diagramm? Hätte gerne Schaltzustand des Aktors und Soll- und Isttemperatur in einem Diagramm.

3. Mit welcher Konfiguration zeige ich die Solltemperatur richtig an? Leider sendet das HM CC TC die Solltemperatur nur bei Änderung. Bei langsamen Zeitprofilen kann es also dazu kommen, dass die letzte Solltemperaturänderung außerhalb der Zeitachse liegt. Somit gibt es keine zwei Punkte im Plot zu verbinden und man sieht nichts. Gibt es vielleicht eine einfache Möglichkeit, dass das HM CC TC die Solltemperatur zusammen mit den Messdaten rausschickt?

Vielen Dank für eure Hilfe!!!

Gruß,
Fabian

[Puschel74]

Hallo,

1.) siehe Screenshot.
Select Style ist dein Freund.

2.) Suchbegriff ins Suchfeld eingeben - geschätzte 20 Treffer.
Kurz: Alle Geräte müssen! in EIN Logfile loggen dann kannst du die Werte in einem Plot darstellen.

3.) addLog - siehe Wiki Plotabriss vermeiden.

Grüße

[fabian1987]

Vielen Dank für die Antwort, das waren die entscheidenden Tipps.

Zu Punkt 1, Select Style habe ich ja versucht. Hat jetzt nach unzähligen Versuchen auch mal geklappt. Leider ist es völlig unnachvollziehbar, wann FHEM den Style ändert. Ein einfacher reload im Browser reicht jedenfalls nicht. Naja, jedenfalls das Thema mit dem Plotabriss und den Logfiles habe ich hinbekommen. Sieht jetzt schon ganz manierlich aus (siehe Screenshot).

Habt ihr noch einen Tipp, wie ich das Frontend ein bisschen übersichtlicher gestalten kann? Würde gerne alle im Screenshot rot markierten Punkte irgendwie unter einem Punkt "Einstellungen" oder so clustern. Das Attribut "hiddenroom" scheint jedenfalls nicht das zu sein, was ich suche.

Achja, und ich kriege immer einen Hinweis mit "security check", dass ich ein Passwort für Telnet o.ä. vergeben müsste. Hier stehe ich noch etwas auf dem Schlauch. Habt ihr einen Tipp für mich?

Danke schonmal!

Gruß,
Fabian

[Puschel74]

Hallo,

Habt ihr einen Tipp für mich?

Lesen 

In der Meldung müsste auch stehen - set the global attribute motd none (frei aus dem kopf raus).
Dann sollte man das auch machen und das

Code Auswählen Erweitern

attr global motd none mal eingeben 

Zu den rot markierten Punkten kann ich dir leider nichts sagen.

Grüße

[fabian1987]

Ergibt sich dadurch dann ein Sicherheitsrisiko?

[Puschel74]

Hallo,

ob mit oder ohne diesem Text.

Solange kein Passwort vergeben ist besteht immer ein gewisses Risiko.

Wenn du FHEM in deinem internen LAN betreibst musst du als "Administrator" abschätzen ob du das Risiko eingehen willst/kannst oder nicht.

Grüße

[fabian1987]

Hi,

da ich mein FHEM in absehbarer Zeit gerne per DynDNS online gehen lassen will, habe ich gemäß dieser Anleitung nun versucht ein Passwort für den Webzugriff zu vergeben. http://www.fhemwiki.de/wiki/FritzBox_Webzugriff_absichern

Das hat soweit auch ganz gut funktioniert. Danach habe ich das attr HTTPS für WEB und WEBphone gesetzt.

Jetzt habe ich mich ausgeschlossen.

Weder unter <ip_vom_raspberry>:8083, noch unter https://<ip_vom_raspberry>:8083 habe ich noch Zugriff auf FHEM. Wie kriege ich das jetzt wieder hin?