Vorstellung + Projekt CCU - >FHEM + kleine Frage
unimatrix
ich bin seit heute hier angemeldet und hoffe, einiges beitragen zu können. Für mich ist FHEM noch relativ neu, aber das wird sich hoffentlich bald ändern :)
Ich benutze seit über 1 Jahr ein Homematic-System mit einer CCU. Davon möchte ich weg. Nicht von Homematic, aber von der CCU. Die Möglichkeiten sind mir zu eingeschränkt bzw. meine Ziele sind mir zu kompliziert zu erreichen und nach und nach wird alles unübersichtlicher. Ich erhoffe mir von dem FHEM / Perl Ansatz mehr Möglichkeiten.
Ich habe im FHZ-Forum (das soll KEINE Werbung sein) angefangen, einen umfangreichen Thread zu posten, in dem ich über meine Projektfortschritte und Probleme und deren Lösungen berichten möchte. Falls da jemand interesse daran hat, kann ich das hier entweder verlinken oder auch hier nochmal posten. Wie ist es gewünscht?
Auf eine Frage bin ich schon gestossen. UNd zwar gibt es bei der CCU sogenannte virtualle Kanäle (50 Stück). Diese kann man als virtuelle Taster in Direktverknüpfungen nutzen. Ich wüsste gerne, und das ist offenbar schwer rauszufinden, ob das auch mit dem HMLAN oder gar dem CUL gehen kann (bzw. von der Firmware des CULs unterstützt wird). Wichtig ist mir das, weil nur mit virtuellen Tastern kann ich z.B. bei einem Dimmaktor von Homematic durch die Konfiguration des Link-Profils ein Blinken des Dimmers hervorrufen (z.B: 1 sekunde an, 5 sekunden aus). Dies nutze ich bei mir z.b. für einen LED-Lichtschlauch, damit signalisiere ich dass die Waschmaschine fertig ist.
Kann das jemand beantworten? Es muss nicht der CUL sein, ich würd wohl sowieso eher den LAN Konfigurator nehmen, weil ich den frei im Haus platzieren kann.
Das ganze FHEM werde ich auf einer Dockstar laufen lassen, denn die verbraucht fast keinen Strom und hat mit PERL und CPAN keine probleme (von der Fritzbox die ich auch laufen habe hab ich mich daher eher verabschiedet, also was FHEM angeht)
VG!
Rudolf Koenig
> dem HMLAN oder gar dem CUL gehen kann (bzw. von der Firmware des CULs
Virtuelle Kanaele gibt es im fhem nicht, aber das ist auch nicht notwendig.
Dein Problem loest man wahrscheinlich mit einem Notify:
define blinkNtfy notify dimmaktor:on\
set led on-for-timer 1;;\
define blinkAt at +*{2}00:00:05 set led on-for-timer 1
Erklaerung: falls fhem vom dimmaktor ein on Nachricht empfaengt, dann wird erst
das led fuer eine Sekunde eingeschaltet, und danach ein at Instanz definiert,
um das LED 2-mal in 5 Sekunden Abstand nochmal einzuschalten. Wie man sieht,
ist Blinken in fhem auch noch nicht optimal geloest.
Andererseits kann man in fhem auch "dummy" oder "ignored" Geraete anlegen, um
diese zu etwas zu missbrauchen. Evtl. lohnt sich das Studium des
fhem-fuer-Einsteiger Dokumentes.
unimatrix
danke für die Antwort. Dein Beispiel ist mir völlig klar. Ich habe mir auch das Einsteiger-PDF und vieles andere durchgelesen.
Der Vorteil der virtuellen Kanäle ist z.B. dass man hier ja auch sehr schnell blinken kann, das macht dann der Aktor von ganz alleine. Außerdem ist das Profil der Dimm-Kurve schärfer. Beim internen blinken blinkt der Dimmer wirklich "scharf" zwischen zwei Helligkeitsstufen, beim setzen eines neuen Dimmwertes per Funk, wird dieser "sanft" in ca. 0,2 Sekunden angefahren.
Das ist für mich jetzt aber auch kein No-Go. Nur um den Fertigzustand der Master-Slaves anzuzeigen reicht ja auch sehr langsames und ungenaues Signalisieren.
Die virtuellen kanäle haben aber neben dem o.g. auch den Vorteil, dass ich damit z.B. völlig gleichzeitig ALLE Lichter ausschalten kann, in dem ein virtueller Taster "1" mit ALLEn Aktoren als "Ausschalten" direkt verknüpft ist. Schaltet man diese direkt über FHEM ab, gibt es ja eine Latenz, bis alles über Funk durch ist.
Danke erstmal - wenn ich doch noch etwas herausfinde (und den HMLAN erstmal habe) werde ich es hier kund tun.
Am Dienstag, 28. Februar 2012 15:32:20 UTC+1 schrieb Rudolf Koenig:
> Ich w�sste gerne, und das ist offenbar schwer rauszufinden, ob das auch mit
> dem HMLAN oder gar dem CUL gehen kann (bzw. von der Firmware des CULs
> unterst�tzt wird).
unimatrix
komme ich zu der Vermutung/Hoffnung dass es doch irgendwie geht. Ich werde mich da baldmöglichst genau mit beschäftigen. Vll gibt es ja eine brauchbare Lösung, die in der Breite genutzt werden kann.
Das ist halt eine Besonderheit der Homematic-Komponenten. Viele Features der Aktoren lassen sich direkt von einer Zentrale gar nicht steuern sondern nur durch eine (virtuelle) Fernbedienung. Z.b auch sehr langsames runterdimmen, ohne jetzt von der Zentrale aus regelmässig dekrementierte Dimmwerte zu schicken...
Rudolf Koenig
> damit z.B. v�llig gleichzeitig ALLE Lichter ausschalten kann, in dem ein
> virtueller Taster "1" mit ALLEn Aktoren als "Ausschalten" direkt verkn�pft
> ist. Schaltet man diese direkt �ber FHEM ab, gibt es ja eine Latenz, bis
> alles �ber Funk durch ist.
Das ist mir neu, und daraus folgt, dass das HM-fhem Modul das nicht beherrscht.
Bevor Du dich wg. dem Umstieg aergerst: HM Support in fhem beruht auf
Beobachtung von Funkverkehr, und ist weit von perfekt entfernt. Das Modul
wuerde von erfahrenen HM Benutzer profitieren, kann aber fuer Dich erstmal auch
bedeuten, dass manches was selbstverstaendlich erscheint, nicht funktioniert.
Kann man mit dem HMLAN Konfigurator auch virtuelle Kanaele definieren?
unimatrix
Ob das der Adapter kann da bin ich mir noch nicht ganz sicher, das werde ich wissen, wenn ich ihn morgen habe :)
Am Dienstag, 28. Februar 2012 16:31:33 UTC+1 schrieb Rudolf Koenig:
> Die virtuellen kan�le haben aber neben dem o.g. auch den Vorteil, dass ich
> damit z.B. v�llig gleichzeitig ALLE Lichter ausschalten kann, in dem ein
> virtueller Taster "1" mit ALLEn Aktoren als "Ausschalten" direkt verkn�pft
> ist. Schaltet man diese direkt �ber FHEM ab, gibt es ja eine Latenz, bis
> alles �ber Funk durch ist.
unimatrix
Rudolf Koenig
> http://fhz-forum.de/viewtopic.php?f=26&t=8489&p=60026#p60026 dokumentiert.
Interessantes Monolog :) Mein Eindruck ist, dass das Hauptspeicher der FB7270
fuer deine umfangreichen Programme zu eng gewesen waere. Ich kann mir jetzt
lebhaft vorstellen, warum Du auf fhem umstellen willst, und empfehle waermstens
das Erstellen von Funktionen in einem (oder mehreren?) eigenen Modulen wie
99_MyUtils.pm (z.Bsp als Kopie von 99_Utils.pm)
> Was allerdings nicht funktioniert und ich habe meinen Fehler noch nicht
> gefunden, ist, dass, wenn heute ein Feiertag ist (ich habe das mal in der Datei
> so eingegeben) dann auch die $we-Variable eine 1 zur�ckliefert.
unimatrix
Die Commandref zu holiday2we hab ich natürlich beachtet, jedoch klappt es nicht. Hier ein Schnippsel aus meiner Telnet-Session auf 7072. Ich habe für heute einen Feiertag "test" im feiertage.holiday File angelegt.
get feiertage 02-27
none
get feiertage 02-28
test
attr global holiday2we feiertage
{$we}
0
> so eingegeben) dann auch die $we-Variable eine 1 zur�ckliefert.
unimatrix
Komme ich trotzdem noch an diese "globalen" Variablen wie $hour, $min, $we, usw ?
Ein Ansatz mit
use vars qw($hour);
use vars qw($min);
use vars qw($sec);
sub
Neptun_Initialize($$)
{
my ($hash) = @_;
}
bringt nicht den Erfolg, ich komme einen uninitialized value Error.
unimatrix
Eine AKtion in der CCU (z.B. Dimmwert setzen, ich teste erstmal nur mit einem Gerät, einem UP-Dimmer 1 Kanal) führt dann auch dazu, dass die Antwort vom Dimmer auch bei FHEM "ankommt" und korrekt ausgewertet wird, der Dimmwert wird angezeigt. Nun möchte ich nach und nach weiter analysieren. Gibt es dazu noch irgendwelche Anhaltspunkte/Quellen/Dokumente die ihr verwendet habt, als ihr den CUL_HM - Kram implementiert habt? Ich habe versuche aus dem CUL_HM.pm-Modul zu lernen. Für die bisher unterstützten Geräte/Features müsst ihr ja irgendwie rausbekommen haben, was die Bytes in den Payloads bedeuten. Ist das noch irgendwo aufgeschrieben oder nur implizit im Code dokumentiert?
Mir fällt auf, dass ein Aktor eine Nachricht mehr antwortet, wenn er per CCU ausgeschaltet wird im Vergleich zum Ausschalten per FHEM.
Danke und VG!
Rudolf Koenig
> die ihr verwendet habt, als ihr den CUL_HM - Kram implementiert habt?
Nein, nur Protokoll belauschen, und aus dem Trace versuchen irgendwelche
Hypothesen zu erstellen. Doku habe ich nicht geschrieben, unter anderem weil
ich nicht gleich zwei Dateien anpassen wollte, wenn ich diese Hypothesen
verwerfen musste. Vieles ist auch noch hardcoded, weil ich die Bedeutung
mancher Bytes nicht wirklich verstehe.
Rudolf Koenig
> Habe ein Modul 99_Neptun.pm auf Basis von 99_Utils.pm erstellt.
Wenn es NeptunUtils.pm heissen wuerde, dann koennte man es auch im FHEMWEB
editieren.
> Komme ich trotzdem noch an diese "globalen" Variablen wie $hour, $min, $we,
> usw ?
Wuesste im Moment nicht wie, es sei denn ich mache diese Variablen in fhem.pl
global. Solange kann man die paar Zeilen aus AnalyzePerlCommand duplizieren.
Rudolf Koenig
> test
> attr global holiday2we feiertage
> {$we}
> 0
Liegt wohl daran, dass der Status von feiertage nur beim define oder am
naechsten Tag aktualisiert wird, nicht aber beim "get".
Workarounds:
- fhem neustarten
- delete feiertage; define feiertage holiday
- modify feiertage none
unimatrix
Danke für den Tip mit dem Umbenennen. Wenn ich mit meiner gesamten KOnfiguration durch bin kann ich sie ja im Wiki als kommentiertes Projekt einstellen, vll hift das dem ein oder anderen.
Aber das ist gerade pausiert weil ich fanatisch am Tracen mit dem CUL und HM bin...habe schon erfolgreich den CUL stick so tun lassen als würde er virtuelle Tastendrücke senden. Schwieriger wird es für mich sicher, das in FHEM so zu abstrahieren dass man das richtig nutzen kann, da ich noch nie Perlscripte geschrieben habe die länger als eine Bildschirmseite sind...
unimatrix
Lipo
ich habe auch eine CCU und nutze aber eher meine FHEM Installation auf einer Fritzbox.
Wie hast Du das mit der gleichen HmId gemacht?
Wie hast Du die ID der CCU herausbekommen/gesetzt?
Was hast Du genau in FHEM definiert?
Ich möchte auch die Geräte nur einmal an der CCU anlernen und dann auch durch FHEM steuern können.
Danke schon mal
Lipo
unimatrix
die ID der CCU bekommst du raus, indem du mit FHEM oder dem Tool in der CULFW die Raw-Daten mitliest und dir die Adressen ansiehst. Löse z.B. in der CCU eine Aktion aus, dann schickt die CCU Daten an ein Gerät und dieses sendet was zurück.
Diese ID trägst du dann in der fhem.cfg ein (siehe commandref FHEM). Wenn du die Geräte an der CCU angelernt lassen willst musst du auf Autoconfig verzichten. Du musst dann auch die 3-Byte Adressen der ganzen Geräte dadurch rausbekommen dass du den Datenverkehr mitliest und manuell in die fhem.cfg eintragen. Das ist je nach Anzahl Geräte halt ein wenig Handarbeit.
VG
Rudolf Koenig
> CULFW die Raw-Daten mitliest und dir die Adressen ansiehst.
Z.Bsp. im telnet mit
fhem> inform timer
fhem> attr CUL/HMLAN hmProtocolEvents
> Diese ID tr�gst du dann in der fhem.cfg ein (siehe commandref FHEM). Wenn
> du die Ger�te an der CCU angelernt lassen willst musst du auf Autoconfig
> verzichten.
Nicht unbedingt: fhem legt ein Geraet an, wenn vom Geraet ein Anlern-Sequenz
eintrifft, Dazu muss man in fhem das Anlernen per hmPairForSec nicht
aktivieren. Also am Geraet Knopf druecken oder im CCU das Paaren via ID
bestellen.
Ich waere aber vorsichtig fhem und CCU mit dem gleichen ID parallel zu
betreiben, da dann 2 Zentralen (fhem+CCU) versuchen die Statusmeldungen der
Geraete zu quittieren. Evtl. hilft CUL/HMLAN mit dem dummy Attribut auf
Read-Only zu setzen.
fhem-hm-knecht
und habe ihr die Hmld F12222 vepasst :)
und läuft somit parallel zu Fhem
und beide quittieren :) , scheint bis jetzt noch keine negativen
Auswirkungen zu haben
sieht aber lustig aus im telnet
und ja, das Teil hat ja wieder ne ganz eigene logik, ich sag jetzt nix
dazu, :(
Hary
unimatrix
"eigene Logik?"
unimatrix
mit FHEM wäre es aber trivial einfach. Ein virtueller Kanal ist nichts anderes als dass man mit der FHEM-HM-ID so tut als wäre man ein Switch mit bis zu 50 Kanälen. Man schickt genau das gleiche Telegramm was auch ein echter Switch schickt aber eben mit der Source der Zentrale also der HmId.
Am Dienstag, 28. Februar 2012 16:31:33 UTC+1 schrieb Rudolf Koenig:
> Die virtuellen kan�le haben aber neben dem o.g. auch den Vorteil, dass ich
> damit z.B. v�llig gleichzeitig ALLE Lichter ausschalten kann, in dem ein
> virtueller Taster "1" mit ALLEn Aktoren als "Ausschalten" direkt verkn�pft
> ist. Schaltet man diese direkt �ber FHEM ab, gibt es ja eine Latenz, bis
> alles �ber Funk durch ist.