Vorstellung + Projekt CCU - >FHEM + kleine Frage

[Guest]

Originally posted by: <email address deleted>

Hallo,

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!

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> 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).

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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo,

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).
>
> 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.
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Nach einem Studium von diesem Thread:
http://groups.google.com/group/fhem-users/browse_thread/thread/9c07d7a141a0d000/a165d9a662107400

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...

Am Dienstag, 28. Februar 2012 16:11:54 UTC+1 schrieb unimatrix:
>
> Hallo,
>
> 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).
>>
>> 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.
>>
>>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> 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.

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?

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Dein Projekt ist ja sehr interessant. Danke für die Schilderungen.

Ich setze zwar schon länger FHEM ein, möchte von aber von FHT80b-
Heizungsreglern auf Homematic umsteigen und habe mir für den ersten
Test einen HMLAN sowie HM-CC-TC (Funk-Wandthermostat + Funk-
Stellantrieb) bestellt. Einen ungenutzten alten CUL habe ich für die
Tests auch noch.

Ziel ist aber der Einsatz von HMLAN, da ich gerne meine
Funkkommunikation signiert per AES absichern will (abhören ist mir
egal, aber ich mag keine Replay-Angriffe = Scherzbold, der auf der
Strasse meine Geräte abhört und dann schaltet). Das geht ja wohl
leider mit CUL (noch) nicht.

Wenn ich Deine Schilderung richtig verstehe, setzt Du derzeit FHEM mit
HMRPC und der CCU ein. Das hört sich nach einer interessanten
Kombination an, da man dann auch die HomeMatic RS-485-Geräte nutzen
könnte.

Gibt es für Dich einen Grund zukünftig nicht mehr HMRPC mit der CCU,
sondern HMLAN direkt an FHEM einzusetzen? Oder ist das gar nicht Dein
Ziel?

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Das macht gar nix. Ich glaub ich bin halbwegs HM-erfahren und ich beteilige
mich gerne am Reverse-Engineering.

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.
>
> 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?
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Falls ich das hier posten darf, meine genauen Arbeitsschritte sind hier:
http://fhz-forum.de/viewtopic.php?f=26&t=8489&p=60026#p60026 dokumentiert.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

On Tue, Feb 28, 2012 at 08:03:09AM -0800, unimatrix wrote:
> 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.

http://fhem.de/commandref.html#holiday2we

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Dass das ganze Perl ausgelatert werden muss ist klar. Wollte nur ein
schnelles Erfolgserlebnis daher hatte ich es so eingebaut.

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


Am Dienstag, 28. Februar 2012 20:32:33 UTC+1 schrieb Rudolf Koenig:
>
> On Tue, Feb 28, 2012 at 08:03:09AM -0800, unimatrix wrote:
> > http://fhz-forum.de/viewtopic.php?f=26&t=8489&p=60026#p60026dokumentiert.
>
> 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.
>
> http://fhem.de/commandref.html#holiday2we
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Habe ein Modul 99_Neptun.pm auf Basis von 99_Utils.pm erstellt.

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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

ich habe mir meine Testumgebung jetzt so eingerichtet, dass ich FHEM mit
der gleichen 3-Byte HmId fahre wie die CCU. So kann ich die Geräte in der
CCU angelernt habe und gleichzeitig mit FHEM benutzen.

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!

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Gibt es dazu noch irgendwelche Anhaltspunkte/Quellen/Dokumente
> 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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

On Tue, Feb 28, 2012 at 12:33:15PM -0800, unimatrix wrote:
> 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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> get feiertage 02-28
> 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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com