Originally posted by: <email address deleted>
Hallo, ich bin ja recht neu in Sachen Hausautomation und fhem. Nachdem ich
einiges schon hinbekommen habe, hab ich jetzt aber ab und an mal wieder ein
kleines Problemchen.
Wenn ich per at einen Aktor schalten möchte, klappt das nicht immer. Also
hab ich mir ein Perl-Routine geschrieben, die nach dem set den Status überprüft:
sub SetCheck($$)
{
my ($device,$state2Set) = @_;
my $currentValue = ReadingsVal($device,"state","?");
my $i = 0;
Log 1, "SetCheck ----------------------";
Log 1, "Device=".$device.": currentState=".$currentValue;
Log 1, "state2Set=".$state2Set;
while(($state2Set ne $currentValue) && ($i < 5))
{
fhem("set ".$device." ".$state2Set);
sleep(1);
$currentValue = ReadingsVal($device,"state","?");
Log 1, $i.": currentValue=".$currentValue;
Log 1, "CmdAccepted=".ReadingsVal($device, "CommandAccepted", "nA");
$i++;
}
}
Jetzt sieht es so aus, dass der neue Status auch dem gesetzten entspricht,
der Aktor aber nicht geschalten hat. Das ganze passiert mit beiden Aktoren
sporadisch, gefühlt etwa 2 Mal pro Woche..
Hier die Log-Ausgabe meiner Routine:
2012.09.23 19:15:32 1: Device=OG.Bad.Lampe: currentState=off
2012.09.23 19:15:32 1: state2Set=on
2012.09.23 19:15:32 2: CUL_HM set OG.Bad.Lampe on
2012.09.23 19:15:33 1: 0: currentValue=on
2012.09.23 19:15:33 1: CmdAccepted=yes
Und hier die Log-Ausgabe des Aktors:
2012-09-23_19:15:32 OG.Bad.Lampe on
2012-09-23_19:15:33 OG.Bad.Lampe deviceMsg: off
2012-09-23_19:15:33 OG.Bad.Lampe off
Was ich nicht wirklich verstehe, vor dem Befehl set OG.Bad.Lampe on wird
der Status ,,off" ausgegeben, nach dem Befehl dann ,,on". Das Log des Aktors
zeigt aber, dass der Aktor nicht wirklich geschalten hat. Ich hatte die
Routine zum Setzen so geschrieben, dass der set-Befehl mehrfach ausgeführt
wird, wenn der neue Status nicht dem zu setzenden entspricht, aber wenn der
neue Status nicht korrekt ist, kann das ja nicht funktionieren.
Ich frag mich, was mach ich falsch ? Für eine Hilfe wäre ich sehr dankbar.
Viele Grüße,
Arndt
P.S. Ich verwende einen HomeMatic LAN-Konfigurations-Adapter und zwei
Funk-Zwischenstecker
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hi,
ich kenne leider keine Lösung für Dein Problem, habe vorgestern ebenfalls
über die merkwürdige Nachrichtenreihenfolge in den Logfiles geschrieben.
Bei mir sieht ein "on:oben" auch erst so aus:
2012-09-21 13:08:05 CUL_HM TuerTerasseRoll oben
2012-09-21 13:08:05 CUL_HM TuerTerasseRoll deviceMsg: unten
2012-09-21 13:08:05 CUL_HM TuerTerasseRoll unten
Wie groß ist die Entfernung zu den Aktorem vom HMLAN? Niederspannungstrafos
in der Nähe?
Gruß Eike
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Eike,
die Entfernungen des einen Aktors zum HMLAN ist ca 4 Meter mit einer Wand
dazwischen, die Entfernung zum anderen liegt bei ca. 7 Meter mit 3 Wänden.
Ich denke, die Entfernung ist nicht zu groß.
Mein Eindruck ist, dass bei der Status-Abfrage das Signal des Aktors zurück
an den HMLAN und fhem noch nicht "angekommen ist" und fhem den "neuen
Soll-Status" solange als gültig führt.
Niederspannungstrafos haben wir nur einen, der ist etwa 1,5 Meter von dem
einen Aktor entfernt. Allerdings steht der HMLAN schräg oberhalb unseres
Fernsehers.
Ich habe jetzt in die Routine ein Sleep von 2 Sekunden eingestellt, mal
schauen was passiert. Weiß jemand, ob das sleep das fhem anderweitig
blockiert bzw. aufhält ?
Grüße,
Arndt
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Wenn fhem nicht threaded programmiert wurde, steht der Daemon für 2
Sekunden würde ich meinen,
dann wird auch nichts vom hmlan ausgewertet.
Das ist eine Vermutung.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
>Weiß jemand, ob das sleep das fhem anderweitig
blockiert bzw. aufhält ?
ja, ja.
ansonsten: sufu
(sleep und wann es fhem blockiert und wann nicht wurde hier schon
bestimmt 5 x behandelt.)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Danke für den Zaunpfahl. :)
Zitat von Zrrronggg!:
"Man könnte ausserdem mit sleep arbeiten.
Muss man aber aufpassen, dass das sleep nicht in perl ausgeführt wird,
weil dann FHEM solange blockiert ist. FHEM Sleep ist aber okay, wenn
ich das richtig verstanden habe.
Gehen müsste also folgendes
define aktion notify aktion {fhem("set a on ;; sleep 5 ;; set b on ;;
sleep 5 ;; set c on ;; sleep 5 ;; set d on")}
"
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Es kommt eben drauf an, wo man sleep verwendet. Ich persönlich würde
das immer versuchen anders zu lösen.
On 24 Sep., 11:47, elo wrote:
> Danke für den Zaunpfahl. :)
>
> Zitat von Zrrronggg!:
> "Man könnte ausserdem mit sleep arbeiten.
> Muss man aber aufpassen, dass das sleep nicht in perl ausgeführt wird,
> weil dann FHEM solange blockiert ist. FHEM Sleep ist aber okay, wenn
> ich das richtig verstanden habe.
>
> Gehen müsste also folgendes
>
> define aktion notify aktion {fhem("set a on ;; sleep 5 ;; set b on ;;
> sleep 5 ;; set c on ;; sleep 5 ;; set d on")}
> "
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
>
> die Lösung ist im Nachbar-Thread:
https://groups.google.com/forum/?fromgroups=#!topic/fhem-users/-G7lh874-NM
Gruß
Damian
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Damian,
danke für den Querverweis, ich habe das bei mir den Parameter entsprechend
geändert.
Werde jetzt mal abwarten, wie's in Zukunft läuft.
Nachdem ich heute nochmals mit diversen Schlagwörtern gesucht habe, habe
ich dann auch den Thread gefunden, in dem
das Verhalten des Sleeps erläutert wird. Ist in den vielen Posts echt nicht
leicht zu finden. Deshalb der Vollständigkeit hier
noch der Link zu dem Beitrag von Rudolf König:
https://groups.google.com/d/msg/fhem-users/3XVPU_V6nQ4/7Cq_-pjYoIUJ
Grüße,
Arndt
On Monday, September 24, 2012 8:07:04 PM UTC+2, Damian wrote:
>
> die Lösung ist im Nachbar-Thread:
>
>
> https://groups.google.com/forum/?fromgroups=#!topic/fhem-users/-G7lh874-NM
>
> Gruß
>
> Damian
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo Arndt,
ich weiß nicht, ob wir uns verstanden haben.
Ich meinte nicht den Sleep-Wert auf 0,3 Sekunden setzen (geht natürlich
auch), sondern viel eleganter in der Source 00_HMLAN.pm nach "select(undef"
suchen und den Wert 0.03 auf 0.3 setzen.
siehe Sourcecode:
HMLAN_Write($$$)
{
my ($hash,$fn,$msg) = @_;
my $dst = substr($msg, 16, 6);
if(!$lhash{$dst} && $dst ne "000000") { # Don't think I grok the
logic
HMLAN_SimpleWrite($hash, "+$dst,00,00,");
HMLAN_SimpleWrite($hash, "+$dst,00,00,");
HMLAN_SimpleWrite($hash, "+$dst,00,00,");
HMLAN_SimpleWrite($hash, "-$dst");
HMLAN_SimpleWrite($hash, "+$dst,00,00,");
HMLAN_SimpleWrite($hash, "+$dst,00,00,");
HMLAN_SimpleWrite($hash, "+$dst,00,00,");
HMLAN_SimpleWrite($hash, "+$dst,00,00,");
$lhash{$dst} = 1;
}
my $tm = int(gettimeofday()*1000) % 0xffffffff;
$msg = sprintf("S%08X,00,00000000,01,%08X,%s",
$tm, $tm, substr($msg, 4));
HMLAN_SimpleWrite($hash, $msg);
# Avoid problems with structure set
# TODO: rewrite it to use a queue+internaltimer like the CUL
select(undef, undef, undef, *0.3*);
}
Gruß
Damian
Am Montag, 24. September 2012 20:36:51 UTC+2 schrieb Arndt:
>
> Hallo Damian,
>
> danke für den Querverweis, ich habe das bei mir den Parameter entsprechend
> geändert.
> Werde jetzt mal abwarten, wie's in Zukunft läuft.
>
> Nachdem ich heute nochmals mit diversen Schlagwörtern gesucht habe, habe
> ich dann auch den Thread gefunden, in dem
> das Verhalten des Sleeps erläutert wird. Ist in den vielen Posts echt
> nicht leicht zu finden. Deshalb der Vollständigkeit hier
> noch der Link zu dem Beitrag von Rudolf König:
> https://groups.google.com/d/msg/fhem-users/3XVPU_V6nQ4/7Cq_-pjYoIUJ
>
> Grüße,
> Arndt
>
> On Monday, September 24, 2012 8:07:04 PM UTC+2, Damian wrote:
>>
>> die Lösung ist im Nachbar-Thread:
>>
>>
>> https://groups.google.com/forum/?fromgroups=#!topic/fhem-users/-G7lh874-NM
>>
>> Gruß
>>
>> Damian
>>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Damian,
ist schon klar, ich hab Dich richtig verstanden und es genau so abgeändert.
Das Sleep in meiner eigenen Routine ist inzwischen auskommentiert.
Grüße,
Arndt
Am Montag, 24. September 2012 22:33:35 UTC+2 schrieb Damian:
>
> Hallo Arndt,
>
> ich weiß nicht, ob wir uns verstanden haben.
>
> Ich meinte nicht den Sleep-Wert auf 0,3 Sekunden setzen (geht natürlich
> auch), sondern viel eleganter in der Source 00_HMLAN.pm nach "select(undef"
> suchen und den Wert 0.03 auf 0.3 setzen.
>
> siehe Sourcecode:
>
> HMLAN_Write($$$)
> {
> my ($hash,$fn,$msg) = @_;
>
> my $dst = substr($msg, 16, 6);
> if(!$lhash{$dst} && $dst ne "000000") { # Don't think I grok the
> logic
> HMLAN_SimpleWrite($hash, "+$dst,00,00,");
> HMLAN_SimpleWrite($hash, "+$dst,00,00,");
> HMLAN_SimpleWrite($hash, "+$dst,00,00,");
> HMLAN_SimpleWrite($hash, "-$dst");
> HMLAN_SimpleWrite($hash, "+$dst,00,00,");
> HMLAN_SimpleWrite($hash, "+$dst,00,00,");
> HMLAN_SimpleWrite($hash, "+$dst,00,00,");
> HMLAN_SimpleWrite($hash, "+$dst,00,00,");
> $lhash{$dst} = 1;
> }
> my $tm = int(gettimeofday()*1000) % 0xffffffff;
> $msg = sprintf("S%08X,00,00000000,01,%08X,%s",
> $tm, $tm, substr($msg, 4));
> HMLAN_SimpleWrite($hash, $msg);
>
> # Avoid problems with structure set
> # TODO: rewrite it to use a queue+internaltimer like the CUL
> select(undef, undef, undef, *0.3*);
> }
>
> Gruß
>
> Damian
>
>
> Am Montag, 24. September 2012 20:36:51 UTC+2 schrieb Arndt:
>>
>> Hallo Damian,
>>
>> danke für den Querverweis, ich habe das bei mir den Parameter
>> entsprechend geändert.
>> Werde jetzt mal abwarten, wie's in Zukunft läuft.
>>
>> Nachdem ich heute nochmals mit diversen Schlagwörtern gesucht habe, habe
>> ich dann auch den Thread gefunden, in dem
>> das Verhalten des Sleeps erläutert wird. Ist in den vielen Posts echt
>> nicht leicht zu finden. Deshalb der Vollständigkeit hier
>> noch der Link zu dem Beitrag von Rudolf König:
>> https://groups.google.com/d/msg/fhem-users/3XVPU_V6nQ4/7Cq_-pjYoIUJ
>>
>> Grüße,
>> Arndt
>>
>> On Monday, September 24, 2012 8:07:04 PM UTC+2, Damian wrote:
>>>
>>> die Lösung ist im Nachbar-Thread:
>>>
>>>
>>>
>>> https://groups.google.com/forum/?fromgroups=#!topic/fhem-users/-G7lh874-NM
>>>
>>> Gruß
>>>
>>> Damian
>>>
>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Bin gespannt auf Deine Resultate, bekomme gelegentlich auch ein MISSING ACK.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
soweit ich den Status sehe wird dieser nicht nur von den Antworten des
device gesetzt sondern auch von den Befehlen an den Aktor. Dies macht Sinn
bei Geraetefamilien, die eine Ruckmeldung liefern. Bei HM eigentlich nicht.
Ohne messages kann ich es nicht genau sagen, aber ich denke dass die
merkwuerdige Folge der States mit dem verarbeiten der trigger sowie der
Statusmessages zu tun hat.
Evtl mal die Messages aufzeichnen
Gruss
Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo zusammen,
hier ein kurzer Update: Bis jetzt haben alle Aktoren nach der Änderung, wie
von Damian vorgeschlagen, einwandfrei geschaltet.
Ich bin jetzt ein paar Tage offline, werde aber später nochmal kurz über
den Status berichten.
> Evtl mal die Messages aufzeichnen
>
Messages habe ich bisher noch keine aufgezeichnet, bin momentan etwas knapp
an Zeit.
Grüße,
Arndt
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo,
nachdem ich nun aus dem Urlaub zurück bin und das fhem ohne meine
Einwirkung seine Aufgaben erledigen konnte, hier ein Update:
Nach der Änderung, wie von Damian in diesem Thread vorsgeschlagen, haben
nun die Schaltvorgänge der Aktoren in den vergangenen
2 1/2 Wochen einwandfrei funktioniert.
Vielen Dank für den hilfreichen Hinweis und natürlich auch an alle anderen,
die hier eifrig mitwirken.
Grüße,
Arndt
Am Freitag, 28. September 2012 11:48:40 UTC+2 schrieb Arndt:
>
> Hallo zusammen,
>
> hier ein kurzer Update: Bis jetzt haben alle Aktoren nach der Änderung,
> wie von Damian vorgeschlagen, einwandfrei geschaltet.
> Ich bin jetzt ein paar Tage offline, werde aber später nochmal kurz über
> den Status berichten.
>
>
>> Evtl mal die Messages aufzeichnen
>>
> Messages habe ich bisher noch keine aufgezeichnet, bin momentan etwas
> knapp an Zeit.
>
> Grüße,
> Arndt
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo Arndt,
du hast während deiner Abwesenheit offenbar nicht mitbekommen, dass das
CUL_HM-Modul ein größeres Redesign-Update von Martin erfahren hat.
Die Kommunikation mit den HM-Aktoren sollte, nach einem Update der
aktuellen FHEM-Entwickler-Version, jetzt auch bei dir mit einem kleinen
Wert, also 0,03 funktionieren. Ich habe den Wert schon seit längerer Zeit
zurückgesetzt und habe keine Probleme mit meinen HM-Komponenten.
Das Hochsetzen des Wertes war eher ein Workaround für das alte CUL_HM-Modul.
Gruß
Damian
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com