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
> 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
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
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
> 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
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
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
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
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
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
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
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
> 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
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
> 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
Originally posted by: <email address deleted>
Hi,
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
Am Donnerstag, 1. März 2012 11:40:02 UTC+1 schrieb unimatrix:
>
> 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.
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo,
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
Am Samstag, 3. März 2012 15:02:08 UTC+1 schrieb Lipo:
>
> Hi,
> 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
>
> Am Donnerstag, 1. März 2012 11:40:02 UTC+1 schrieb unimatrix:
>>
>> 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.
>>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> 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.
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.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
ich habe eine Homematic fast geschenkt bekommen :)
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
On 3 Mrz., 20:42, Rudolf Koenig wrote:
> > 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.
>
> 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.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
du hast eine CCU geschenkt bekommtn? Ich will meine ja ersetzen weil ich
sie nicht mag. Das Problem ist nicht auf der Bid-Cos-Service-Ebene, die XML
Bedienung ist eigentlich ganz gut, sondern auf der Ebene darüber, die
RegaHSS ist langsam und umständlich und die dazugehörige Weboberfläche eine
Katastrophe.
"eigene Logik?"
Am Sonntag, 4. März 2012 00:49:41 UTC+1 schrieb fhem-hm-knecht:
>
> ich habe eine Homematic fast geschenkt bekommen :)
> 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
>
> On 3 Mrz., 20:42, Rudolf Koenig wrote:
> > > 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.
> >
> > 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.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Die Frage nach dem HMLAN-Konfigurator steht ja noch aus -> Nein, damit kann
man das nicht (virtuelle Kanäle)
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.
>
> 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
Originally posted by: <email address deleted>
Danke, da ich nun weiss, dass ich es nicht falsch gemacht habe, kann ich
auch ohne die Variablen leben.
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...
Am Freitag, 2. März 2012 17:37:41 UTC+1 schrieb Rudolf Koenig:
>
> 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
Originally posted by: <email address deleted>
ok, wieder was gelernt. insofern alles WAD. danke
Am Freitag, 2. März 2012 17:50:02 UTC+1 schrieb Rudolf Koenig:
>
> > 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