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
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.
Hallo,
Zitatdank 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 ;D
Grüße
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
Hallo,
ZitatAber braucht man das in der Praxis wirklich?
Nein.
ZitatBrauche 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 ;D ).
Ich will hier aber jetzt keine Werbetrommel für FHEM rühren.
Entscheiden musst im Endeffekt du dich was du nimmst.
Grüße
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.
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
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:
ZitatBei 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 8)
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
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/ (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... :P).
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
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
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
Hallo,
ZitatHabt ihr einen Tipp für mich?
Lesen ;D
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
attr global motd none mal eingeben ;)
Zu den rot markierten Punkten kann ich dir leider nichts sagen.
Grüße
Ergibt sich dadurch dann ein Sicherheitsrisiko?
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
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 (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? :'(
Hallo,
per putty die fhem.cfg editieren und die Zeile löschen.
Grüße
Edith:
Hier http://www.meintechblog.de/2013/05/fhem-server-auf-dem-raspberry-pi-in-einer-stunde-einrichten/ (http://www.meintechblog.de/2013/05/fhem-server-auf-dem-raspberry-pi-in-einer-stunde-einrichten/) findest du ab
ZitatDa der sichere Zugriff per Benutzer/Passwort von unterwegs per Smartphone-Browser möglich
eine gute Anleitung zum absichern der Zugänge.
Damit hab sogar ich das geschafft 8)
Hi,
du sagst das so einfach. Wo liegt denn die fhem.cfg in der Dateistruktur des Raspberry und wie sind die Befehle um diese zu öffnen?
Vielen Dank für deine Hilfe!
Gruß,
Fabian
Ah ich hab's gefunden. Liegt unter
cd /opt/fhem
und editieren kann man sie dann mit
sudo nano fhem.cfg
Hallo,
genau.
Grüße
Die Anleitung von meintechblog.de scheint für mich aber nicht ganz anwendbar zu sein, da zum einen fhem nicht auf der Fritzbox läuft und zum anderen ich einen Airport Extreme habe, der bei Portweiterleitungen irgendwie seinen eigenen Kopf hat. Habe mir jetzt einen Account bei selfhost.de registriert, aber noch keinen Plan, wie ich die Daten im Router hinterlege.
Aber ich bleibe dran...
Hallo,
in dieser Anleitung wird auch erklärt wie man seine FHEM-Installation auf dem RasPi absichern kann ;)
Grüße
Hallo allerseits,
ich muss euch nochmals mit einem kleinen Problem nerven. Ich habe jetzt alle Heizungen mit Schaltern automatisiert und prinzipiell tut die Heizung auch das, was ich will. Allerdings bekomme ich häufig den Fehler:
2013.12.12 06:24:45 2: HMLAN_Parse: HMLAN1 new condition Warning-HighLoad
2013.12.12 06:35:54 2: HMLAN_Parse: HMLAN1 new condition ERROR-Overload
Prinzipiell nutze ich für jede Heizung folgende Logik:
##############################################################
# Heizungsregelung Arbeitszimmer
define AzHeizungsregelungNotify notify Az_Thermostat {if ((ReadingsVal("Az_Thermostat","desired-temp","")> ReadingsVal("Az_Thermostat","measured-temp","")) && (Value("Az_Schaltaktor") eq "off")) { fhem("set Az_Schaltaktor on")} elsif (ReadingsVal("Az_Thermostat","desired-temp","")< ReadingsVal("Az_Thermostat","measured-temp","") && (Value("Az_Schaltaktor") eq "on")) {fhem("set Az_Schaltaktor off") }\
}
Ich verstehe notify so, dass ich jedes Mal, wenn das Thermostat neue Werte schickt, die if-else Anweisung prüfe und falls eine Bedingung zutrifft, die Heizung an oder abschalte. Das heißt aber doch auch, dass nur dann Funkverkehr entsteht, wenn ich auch einen Statuswechsel anfordern will. Wieso kommt es dann trotzdem zu dem Overload?
Ein zweites Problem ist, dass ich im Wohnzimmer mit einem Thermostat drei Heizungen schalten will. Folgendes funktioniert in FHEM:
##############################################################
# Heizungsregelung Wohnzimmer
# HeizungUG groß
define WzUGGrHeizungsregelungNotify notify Wz_Thermostat {if ((ReadingsVal("Wz_Thermostat","desired-temp","")> ReadingsVal("Wz_Thermostat","measured-temp","")) && (Value("Wz_SchaltaktorGr") eq "off")) { fhem("set Wz_SchaltaktorGr on")} elsif (ReadingsVal("Wz_Thermostat","desired-temp","")< ReadingsVal("Wz_Thermostat","measured-temp","") && (Value("Wz_SchaltaktorGr") eq "on")) {fhem("set Wz_SchaltaktorGr off") }\
}
# HeizungUG klein
define WzUGKlHeizungsregelungNotify notify Wz_Thermostat {if ((ReadingsVal("Wz_Thermostat","desired-temp","")> ReadingsVal("Wz_Thermostat","measured-temp","")) && (Value("Wz_SchaltaktorKl") eq "off")) { fhem("set Wz_SchaltaktorKl on")} elsif (ReadingsVal("Wz_Thermostat","desired-temp","")< ReadingsVal("Wz_Thermostat","measured-temp","") && (Value("Wz_SchaltaktorKl") eq "on")) {fhem("set Wz_SchaltaktorKl off") }\
}
# HeizungOG
define WzOGHeizungsregelungNotify notify Wz_Thermostat {if ((ReadingsVal("Wz_Thermostat","desired-temp","")> ReadingsVal("Wz_Thermostat","measured-temp","")) && (Value("Wz_SchaltaktorOG") eq "off")) { fhem("set Wz_SchaltaktorOG on")} elsif (ReadingsVal("Wz_Thermostat","desired-temp","")< ReadingsVal("Wz_Thermostat","measured-temp","") && (Value("Wz_SchaltaktorOG") eq "on")) {fhem("set Wz_SchaltaktorOG off") }\
}
Das erscheint mir jedoch unsauber, da ich ja drei Mal notify auf das gleiche Thermostat abfrage. Da wäre es doch sicher sauberer, wenn ich folgenden Code implementieren würde:
##############################################################
# Heizungsregelung Wohnzimmer
define WzUGGrHeizungsregelungNotify notify Wz_Thermostat {
# HeizungUG groß
if ((ReadingsVal("Wz_Thermostat","desired-temp","")> ReadingsVal("Wz_Thermostat","measured-temp","")) && (Value("Wz_SchaltaktorGr") eq "off")) { fhem("set Wz_SchaltaktorGr on")}
elsif (ReadingsVal("Wz_Thermostat","desired-temp","")< ReadingsVal("Wz_Thermostat","measured-temp","") && (Value("Wz_SchaltaktorGr") eq "on")) {fhem("set Wz_SchaltaktorGr off") }
# HeizungUG klein
elsif ((ReadingsVal("Wz_Thermostat","desired-temp","")> ReadingsVal("Wz_Thermostat","measured-temp","")) && (Value("Wz_SchaltaktorKl") eq "off")) { fhem("set Wz_SchaltaktorKl on")}
elsif (ReadingsVal("Wz_Thermostat","desired-temp","")< ReadingsVal("Wz_Thermostat","measured-temp","") && (Value("Wz_SchaltaktorKl") eq "on")) {fhem("set Wz_SchaltaktorKl off") }
# HeizungOG
elsif ((ReadingsVal("Wz_Thermostat","desired-temp","")> ReadingsVal("Wz_Thermostat","measured-temp","")) && (Value("Wz_SchaltaktorOG") eq "off")) { fhem("set Wz_SchaltaktorOG on")}
elsif (ReadingsVal("Wz_Thermostat","desired-temp","")< ReadingsVal("Wz_Thermostat","measured-temp","") && (Value("Wz_SchaltaktorOG") eq "on")) {fhem("set Wz_SchaltaktorOG off") }\
}
Der bringt jedoch im Logfile immer Fehler, wie z.B. folgenden:
2013.12.12 07:06:19 3: WzUGGrHeizungsregelungNotify return value: syntax error at (eval 7257) line 1, at EOF
Danke für eure Hilfe schonmal im Voraus!! :)
Gruß,
Fabian
Hallo,
bitte deinen Beitrag nochmal bearbeiten und verwende die Code-Tags (# oben).
So les ich mir den Code nicht durch - auch wenn alles sauber getrennt aussieht.
Aber was anderes - warum prüfst du auf desired-temp und measured-temp nicht auf actuator?
Ich weiß allerdings nicht ob HM das kann.
actuator ist die Ventilstellung und damit liese sich mit wenig Aufwand auch eine Hysterese einbauen.
Hat die Fehlermeldung nicht noch eine zweite Zeile??
Grüße
Hi,
hoffe so passt es. Auf den Actuator-Status abfragen, darüber habe ich noch nicht nachgedacht. Letztendlich kann ich den Lüfter ja nicht regeln, daher der Gedanke mit der Soll- und Isttemperatur. Eine Hysterese war bislang nicht nötig, da die Thermostate von Homematic so stark bedämpft sind, dass man ohnehin schon Überschwinger von 0,1-0,3°C macht. Damit ist ja quasi eine Hysterese gegeben.
Gruß,
Fabian
Hallo,
danke für Code-Tags. Sieht doch schon um einiges Besser aus ;)
Ok. Da ich kein "Einzeiler-Fan" bin muss ich deine Abfragen erstmal - für mich - passend aufbereiten.
Das wird nun ein bischen dauern.
Zu den Overload-Warnings kann ich dir nichts sagen.
Ich verwende zwar einen HM-Lan aber da hängen nur ein paar Funkschalter und -dimmer dran.
Die Idee mit dem actuator würde dann in etwa so aussehen:
if ((ReadingsVal("Wz_Thermostat","actuator","")> 40)...
Wobei du die 40 natürlich an deine gewünschte Ventilstellung anpassen kannst.
Grüße
Hallo,
grad schnell über deinen Code drüber geschaut.
Sieht soweit nicht schlecht aus aber ...
FHEM ist pingelig was Leerzeichen am Ende von Zeilen anbelangt.
z.B.:
hier steht der Code {
und hier gehts weiter
sieht für uns in Ordnung aus - nach der { habe ich aber ein Leerzeichen versteckt 8)
Das mag FHEM nicht.
# im Code musste ich gestern erst feststellen mag FHEM auch nicht.
Entweder hinter den Code stellen (wenn das klappt) oder ganz weg lassen.
Und - wie schon erwähnt.
Ich bearbeite ausschliesslich das DEF eines notify.
1:1 Kopien von meinen Vorschlägen werden sowieso nie fehlerfrei laufen da bei mir einfach die \ und ;; fehlen.
Ich würde dir auch ans Herz legen die fhem.cfg in Ruhe zu lassen und über die Gefehlszeile bzw. das DEF eines notify (oder at) gehen.
So. Nun schauen wir mal was du mit diesen Erkenntnissen anfangen kannst und welche Fehlermeldung
dein nächster Code auspuckt ;)
Grüße
Edith: Ich vergas - ganze Leerzeilen sind auch nicht so gut.
der Code wird zwar uU für Menschen lesbarer aber im Endeffekt soll der Code durch einen Interpreter ausgeführt werden - und die haben in aller Regel einen genauen Syntax.
Und da sind diese Interpreter kompromisslos ;)
Hi,
vielen Dank für deine ausführliche Antwort. Das werde ich morgen mal ausprobieren! Heute hat sich übrigens noch ein weiteres Problem ergeben. Ich frage im Code (siehe oben) ab, ob der Status des Aktors eq "off" oder eq "on" ist, um die Schaltanweisung zu schicken. Das ist prinzipiell auch so nicht schlecht, denn damit wird vermieden, dass eine Schaltanweisung geschickt wird, obschon sich der Aktor bereits im Zielzustand befindet.
Leider ergibt sich folgendes Problem: Meine Aktoren sind in der Nachtspeicherheizung verbaut (Metallgehäuse), was funktechnisch wohl nicht so optimal ist (will daher die Schalter nach außen legen, wovon das Problem zwar weniger häufig auftritt, aber nach wie vor bestehen bleibt). Setze ich den Schaltaktor auf "on" oder "off" und dieser verpasst meinen Schaltbefehl, so schaltet FHEM irgendwann auf "MISSING ACK" um. Lese ich dann den Value des Schaltaktors aus, gibt dieser "set_on" oder "set_off" zurück. Da dies jedoch nicht mit der Abfrage übereinstimmt, wird diese nie wieder ausgeführt. Das heißt, dass die Heizung endlos weiterläuft. Nicht so gut. Bin vor ein paar Tagen schon schweißgebadet aufgewacht... ;)
Jetzt habe ich gedacht, alles klar, fragst du eben als ODER-Verknüpfung beide Stati ("off" oder "set_off") und ("on" oder "set_on") ab:
define AzHeizungsregelungNotify notify Wz_Thermostat {if ((ReadingsVal("Wz_Thermostat","desired-temp","")> ReadingsVal("Wz_Thermostat","measured-temp","")) && ((Value("Wz_SchaltaktorOG") eq "off") || (Value("Wz_SchaltaktorOG") eq "set_on"))) { fhem("set Wz_SchaltaktorOG on")} elsif (ReadingsVal("Wz_Thermostat","desired-temp","")< ReadingsVal("Wz_Thermostat","measured-temp","") && ((Value("Wz_SchaltaktorOG") eq "on") || (Value("Wz_SchaltaktorOG") eq "set_off"))) {fhem("set Wz_SchaltaktorOG off") }\
}
Das führt jedoch dazu, dass trotz notify mehrere Schaltanweisungen innerhalb von wenigen Sekunden an den Schaltaktor rausgeschickt werden:
2013.12.14 17:47:16 2: CUL_HM set Az_Schaltaktor off
2013.12.14 17:47:16 2: CUL_HM set Az_Schaltaktor off
2013.12.14 17:47:16 2: CUL_HM set Az_Schaltaktor off
2013.12.14 17:47:16 2: CUL_HM set Az_Schaltaktor off
2013.12.14 17:47:16 2: CUL_HM set Az_Schaltaktor off
2013.12.14 17:47:16 2: CUL_HM set Az_Schaltaktor off
2013.12.14 17:47:22 2: CUL_HM set Az_Schaltaktor on
2013.12.14 17:47:22 2: CUL_HM set Az_Schaltaktor on
2013.12.14 17:47:22 2: CUL_HM set Az_Schaltaktor on
2013.12.14 17:47:22 2: CUL_HM set Az_Schaltaktor on
Habe schon überlegt, mit einem "at" und alle fünf Minuten oder so alle Aktoren auf "set_on" oder "set_off" zu überprüfen. Aber auch das scheint mir etwas unsauber, da ja das "at" dann zu ungünstigen Zeitpunkten mitten in einem Schaltvorgang aufgerufen werden könnte.
Habt ihr eine Idee, wie das klappen könnte? Vielen Dank schonmal im Voraus!
Gruß,
Fabian
Hallo,
hat zwar mit der Anfangsfrage nichtsmehr zu tun (nächstes mal bitte neuen Beitrag aufmachen) aber ...
das
define AzHeizungsregelungNotify notify Wz_Thermostat {if
von dir gepostete macht genau das was es soll.
Wenn ein Ereigniss von Wz_Thermostat eintritt wird das notify geprüft.
Naja - WzThermostat sendet mehr als ein! Ereigniss wie du schön im Event Monitor erkennen kannst.
Einfach mal öffnen und warten - nicht nochmal klicken!! - warten.
Sobald die ersten Device ihr Nachrichten schicken werden sie im Event Monitor angezeigt.
Also einfach nur warten - es kommt schon was.
Da siehst du das Wz_Thermostat mehrere Readings hat und auf alle trifft ja dein regepx zu.
Wz_Thermostat (mit ohne nix oder allem was kommt).
Genauso könntest du schreiben
Wz_Thermostat.*
Das trifft auch auf alles zu was von Wz_Thermostat kommt.
Und was soll das notify machen?
Genau.
Bei jedem Treffer des regexp wird es geprüft.
Die Bedingungen werden abgefragt und die Aktionen ausgelöst.
Du willst aber eigentlich nur auf "desired-temp" prüfen - RSSI und alles was der sonst noch sendet ist dir ja in diesem notify egal.
Also erweitern wir mal das regexp und schauen was passiert.
Wz_Thermostat.desired.* (sollte hoffentlich richtig sein - der Punkt . steht für ein beliebiges Zeichen und ein Leerzeichen müsste eigentlich als beliebiges Zeichen durchgehen).
also das es so aussieht:
define AzHeizungsregelungNotify notify Wz_Thermostat.desired.* {if ((ReadingsVal("Wz_Thermostat","desired-temp
und schauen was jetzt passiert.
Grüße
Das klingt jetzt erstmal plausibel. Allerdings muss ich doch sowohl bei Ankuft des "desired-temp", als auch bei Ankunft des "measured-temp" das notify ausführen. Sonst würde sich bei Änderung der Ist-Temperatur oder bei Änderung der Solltemperatur die Heizung nicht anschalten, korrekt?
Hallo,
ZitatAllerdings muss ich doch sowohl bei Ankuft des "desired-temp", als auch bei Ankunft des "measured-temp" das notify ausführen.
Wenn das so sein muss brauchst du doch nur das regexp entsprechend umbauen das es auf "desired-temp" und "measured-temp" reagiert.
Such dir eine Gemeinsamkeit der beiden "Daten" und bau dir ein passendes regexp ;)
Grüße
Also das funktioniert leider so nicht:
define AzHeizungsregelungNotify notify Az_Thermostat.desired-temp.* {if ((ReadingsVal
Habe auch sämtliche Varianten wie Az_Thermostat.desired-temp oder Az_Thermostat*desired-temp ausprobiert. Keine Chance.
Eigentlich sollte es so aussehen:
define AzHeizungsregelungNotify notify (Az_Thermostat.desired-temp.* | Az_Thermostat.measured-temp.*) {if ((ReadingsVal
Dann müsste er doch sobald sich Soll- oder Istwert ändern das Notify aufrufen, korrekt?
Hier der Ausschnitt aus der Logdatei:
2013.12.15 14:44:37 5: Triggering Az_Thermostat (2 changes)
2013.12.15 14:44:37 5: Notify loop for Az_Thermostat desired-temp: 17.0
2013.12.15 14:44:37 5: Triggering AzHeizungsregelungNotify
2013.12.15 14:44:37 5: Cmd: >{if ((ReadingsVal("Az_Thermostat","desired-temp","")> ReadingsVal("Az_Thermostat","measured-temp","")) && (Value("Az_Schaltaktor") eq "off")) { fhem("set Az_Schaltaktor on")} elsif (ReadingsVal("Az_Thermostat","desired-temp","")< ReadingsVal("Az_Thermostat","measured-temp","") && (Value("Az_Schaltaktor") eq "on")) {fhem("set Az_Schaltaktor off") }\\
}<
2013.12.15 14:44:37 3: AzHeizungsregelungNotify return value: syntax error at (eval 62772) line 1, at EOF
Hallo,
ZitatDann müsste er doch sobald sich Soll- oder Istwert ändern das Notify aufrufen, korrekt?
Das sollte wohl so sein, ja.
Ich hab aber grad gesehen das meine FHT regelmäßig actuator senden.
Das kansntdu mit dem Event Monitor prüfen.
define AzHeizungsregelungNotify notify Az_Thermostat:(desired-temp.*|measured-temp.*) {if ((ReadingsValwürde auf beides reagieren.
ZitatAzHeizungsregelungNotify return value: syntax error at (eval 62772) line 1, at EOF
EOF heisst End Of File - da hast du wohl noch einen Fehler in deinem notify.
Speziell mal die Klammern durchzählen und schauen ob auch an den richtigen Stellen die " stehen.
Grüße
Das Notify sieht jetzt so aus und tut prinzipiell mal das, was es soll (jetzt auch mit dem set_on bzw. set_off um ein Deadlock bei "Missing Ack" zu vermeiden):
define AzHeizungsregelungNotify notify Az_Thermostat:(desired-temp.*|measured-temp.*) {if ((ReadingsVal("Az_Thermostat","desired-temp","")> ReadingsVal("Az_Thermostat","measured-temp","")) && ((Value("Az_Schaltaktor") eq "off") || (Value("Az_Schaltaktor") eq "set_on"))) {fhem("set Az_Schaltaktor on")} elsif (ReadingsVal("Az_Thermostat","desired-temp","")< ReadingsVal("Az_Thermostat","measured-temp","") && ((Value("Az_Schaltaktor") eq "on") || (Value("Az_Schaltaktor") eq "set_off"))) {fhem("set Az_Schaltaktor off")}\
}
Was ich jedoch einfach nicht verstehe ist, warum der Schalter nach wie vor mehrfach angesprochen wird. Im Logfile findet sich nämlich folgendes:
2013.12.15 17:36:43 2: CUL_HM set Az_Schaltaktor on
2013.12.15 17:36:43 2: CUL_HM set Az_Schaltaktor on
2013.12.15 17:36:50 2: CUL_HM set Az_Schaltaktor off
2013.12.15 17:36:50 2: CUL_HM set Az_Schaltaktor off
Ich dachte, dass "desired-temp" und "measured-temp" in einer Botschaft ankommen und zur einmaligen Ausführung des Notifys führen. Allerdings scheint das Notify ja zweimal ausgeführt zu werden.
Hast du diesbezüglich noch eine schlaue Idee?
Vielen Dank jedenfalls schonmal für deine geduldige Hilfe! :)
Hallo,
auch jetzt macht das notify das was es soll 8)
mach mal den Event Monitor auf und warten - warten - nicht nochmal klicken - es kommt schon was
und du wirst sehen das desired-temp und measured-temp zwei "Botschaften" Readings sind die vom Thermostat übertragen werden und
da du ja auf beide Temperaturen im regexp prüfst wird das notify auch zweimal auslösen.
Warum du aber auf die Temperaturen prüfst und nicht auf actuator ist mir immer noch ein Rätsel.
Ich meine ich habe ganz am Anfang mal actuator in den Raum geworfen ;)
Grüße
Ich muss zugeben, dass ich den Event-Monitor zuerst gar nicht für voll genommen habe. Aber das ist ja sehr praktisch. Ja, man sieht zweifelsohne, dass desired-temp und measured-temp zwei Botschaften sind. Habe jetzt aber noch ein bisschen recherchiert und habe festgestellt, dass die Aktoren nach einem Timeout tatsächlich den Zustand "MISSING ACK" einnehmen.
D.h.: "off" -> "set_on" -> "on" oder "MISSING ACK" nach Timeout bzw. "on" -> set_off -> "off" oder "MISSING ACK" nach Timeout. Folglich habe ich mein Notify nun so angepasst:
define BzOGHeizungsregelungNotify notify BzOG_Thermostat {if ((ReadingsVal("BzOG_Thermostat","desired-temp","")> ReadingsVal("BzOG_Thermostat","measured-temp","")) && ((Value("BzOG_Schaltaktor") eq "off") || (Value("BzOG_Schaltaktor") eq "MISSING ACK"))) {fhem("set BzOG_Schaltaktor on")} elsif (ReadingsVal("BzOG_Thermostat","desired-temp","")< ReadingsVal("BzOG_Thermostat","measured-temp","") && ((Value("BzOG_Schaltaktor") eq "on") || (Value("BzOG_Schaltaktor") eq "MISSING ACK"))) {fhem("set BzOG_Schaltaktor off")}\
}
Es gibt jetzt war trotzdem noch häufig "MISSING ACK"-Zustände, die ich aber eher auf den Empfang der Schalter im Metallgehäuse der Heizung zurückführen würde. Die Schaltsteckdose im Bad hat damit jedenfalls bisher keine Probleme gehabt. Insgesamt ist es jedoch dadurch deutlich robuster geworden, denn selbst wenn ein Schalter eine Schaltanweisung verpasst, wird die Heizung noch "gerettet".
Noch ein Satz, wieso ich nicht auf "actuator" abfrage. Zum Einen brauche ich praktisch keine Hysterese in der Temperaturregelung, da die Thermostate sehr stark bedämpft sind und die Temperatur ohnehin über- und unterschwingt, sodass die Lüfter bei Regelung auf einen konstanten Sollwert trotzdem ca. 15 Minuten an sind und dann auch 15 Minuten wieder aus. Außerdem ist es - finde ich - mit einer Soll- und Isttemperatur deutlich besser nachvollziehbar, wann die Heizung an- und ausgeht.
Gruß,
Fabian