Hallo Alle,
ich will eine zentral gesteuerte Outdoor-Heizungsregelung für ein Gewächshaus aufbauen, in der ich wegen Staub/Spritzwasser keinen HM-CC-TC einsetzen kann. Außerdem muss die Steuerung einen Ein-/Ausschalter ansprechen und kein Ventil.
Um auf dem FLOORPLAN ein ansprechendes look-and-feel zu bekommen habe ich folgenden Hack angewendet:
Ich habe kurzerhand den benutzten HM-WDS30-T-O (h_Temp) in FHEM das attribut model HM-CC-TT verpasst und damit die Nutzung des entsprechenden FLOORPLAN inputs freigeschaltet.
Zusätzlich habe ich einen notify definiert der die Eingabe der Solltemperatur abzapft und in eine Dummy Variable h_sollTemp schiebt:
define h_setSoll notify h_Temp:set_desired-temp.* {\
my @@val = split(' ',"%");;\
fhem(" set h_sollTemp $val[1]");;\
}
Frage an die Experten:
kann der Hack an anderer Stelle ein Problem auslösen oder kann man das so lassen?
Danke,
Uwe
Hi,
aus Sicht der frontends (FHEMWEB und FLOORPLAN) passiert ja genau das, was Du willst.
notify und at werten m.W. das Attribut model nicht aus.
Soweit also keine Probleme.
Ob damit in HMLAN.pm oder HM.pm model-abhängig was Besonderes passiert, weiß ich nicht. Das müsste am besten HM-Martin oder Rudi beantworten. Zumindest Ersterer liest m.W. nur den Ordner Homematic, evtl solltest Du Deine Frage dort (noch einmal) stellen. Oder soll ich diesen Fred dorthin verschieben?
Gruß, Uli
Hallo Uli,
wenn du ihn verschieben könntest wäre das nicht schlecht....
Danke,
Uwe.
Hallo,
ich bin kein Experte und den Sensor habe ich auch nicht in Betrieb, aber ich könnte mir schon vorstellen, dass da ein paar Probleme auftreten können.
Wenn du bei einem TC die Soll-Temperatur ( oder sonst etwas ) änderst, wird dafür ja normalerweise ein Befehl generiert und in der Command-Queue geparkt, bis der TC das nächste Mal ein Wakemeup schickt. Als ich mich das letzte Mal intensiv mit dem HM-Quelltext beschäftigt habe, war imho das Model genau dafür das Kriterium. Jetzt weiß ich nicht, welchen Funkmodus der Sensor verwendet. Wenn er im Burst arbeitet werden die Befehle möglicherweise nie abgeschickt und sammeln sich an, wenn er auch ein Wakemeup schickt, bekommt er möglicherweise einen Befehl, mit dem er nichts anfangen kann und du kriegst ein Missing-ACK oder ähnliches.
Wenn der Sensor Befehle empfangen kann, funktioniert das möglicherweise auch nicht mehr richtig, wenn das Model nicht stimmt
Außerdem kann es sein, dass das Model jedesmal wenn du den Anlernknopf drückst überschrieben wird.
Eine Alternative könnte sein, den Sensor Sensor sein zu lassen und für die Steuerung und Visualisierung einen TC als Dummy anzulegen. Wenn der Sensor Werte sendet, könntest du die per notify in den Dummy durchreichen und wenn die Soll-Temp am Dummy verändert wird, könntest du sie wie derzeit in deine Variable schreiben. Je nachdem, wofür du die Variable verwendest könntest du aber eigentlich auch direkt die Desired-Temp des Dummy-TC als Variable abgreifen.
Hallo Carsten,
guter Punkt...
Zitat von: Carsten schrieb am Fr, 01 März 2013 09:48Eine Alternative könnte sein, den Sensor Sensor sein zu lassen und für die Steuerung und Visualisierung einen TC als Dummy anzulegen. Wenn der Sensor Werte sendet, könntest du die per notify in den Dummy durchreichen und wenn die Soll-Temp am Dummy verändert wird, könntest du sie wie derzeit in deine Variable schreiben. Je nachdem, wofür du die Variable verwendest könntest du aber eigentlich auch direkt die Desired-Temp des Dummy-TC als Variable abgreifen.
mit Dummy meinst Du nicht als dummy variable sondern als HM Device das ins "leere" zeigt?
Viele Grüße,
Uwe
Zitat von: thunder schrieb am Fr, 01 März 2013 10:02mit Dummy meinst Du nicht als dummy variable sondern als HM Device das ins "leere" zeigt?
Ja, genau. Du kannst für das Gerät dann das Attribut dummy setzen. Dann sollte es auch nicht mehr versuchen, zu senden.
Aus der Commandref:
Zitatdummy
Set the device attribute dummy to define devices which should not output any radio signals. Associated notifys will be executed if the signal is received. Used e.g. to react to a code from a sender, but it will not emit radio signal if triggered in the web frontend.
Das hat allerdings mal für HM nicht funktioniert, aber soweit ich weiß, hat Martin das mittlerweile implementiert.
Also das model zu aendern ist keine gute idee.
fuer hacker: nur das 'model' attribut im device ist relevant. Das kanaele auch ein attribut "model" haben kommt nur daher, weil ich gezwungen wurde ;-)
Andere Applikationen kennen nur entities und keine channels/devices. Sie basieren ihre Auswertung auf diesem Attribut.
Daher ist es HM egal, was du mit dem Attribut model in channels anstellst.
Das im Device solltest du in ruhe lassen. Das message-parsing, register setzen und lesen geht alles ueber dieses Attribut - da ist die Garantie dann abgelaufen ;-)
Die Idee mit einem dummy ist nicht schlecht. Virtuelle Aktoren sind eine Alternative, aber dummy sollte besser geeignet sein. In beiden faellen musst du die Werte quasi manuell reinkopieren
Gruss
Martin
Gruss
Martin
ACK danke für die Info. war dann kein bösersonder ein dummer Hack ;-)