HomeMatic Wired - HMW-LAN-Gateway

Begonnen von Dirk, 02 September 2013, 21:38:44

Vorheriges Thema - Nächstes Thema

Thorsten Pferdekaemper

Zitat von: gevoo am 24 November 2015, 20:32:16Ich lese immer mit und bin begeistert, wie Ihr die Sachen schon weiterentwickelt habt.
Danke für's Lob.
Wenn Du gerade mal was schreibst: Kannst Du erklären, wie das hier funktioniert:


<parameter id="SHORT_ONDELAY_TIME">
  <logical type="float" unit="s" default="0.0" max="982980.0" min="0.0"/>
  <physical size="2.0" type="integer" interface="eeprom" endian="little">
    <address index="+7"/>
  </physical>
  <conversion type="float_configtime" value_size="1.6" factors="0.1,1,60,1000"/>
  <conversion type="integer_integer_map">
      <value_map parameter_value="0xffff" device_value="0xc000" mask="0xc000"/>
  </conversion>
</parameter>

Ich habe mir auch das Coding dazu angesehen, aber das hilft auch nicht viel. Ich glaube, dass da irgendwo was nicht stimmt.
Gruß,
    Thorsten
FUIP

gevoo

Hallo Thorsten,

Ich kann Dir erklären, wie ich das interpretieren würde. Ob es stimmt weiß ich nicht:
Es handelt sich um den Parameter für die Wartezeit nach auslösen von press_short,
   - die Zeit ist vom Typ float, Einheit = s, Startwert = 0.0, Maximalwert = 982980.0, Minimalwert = 0.0
   - Sie wird im eeprom hinterlegt, mit einer Länge von 2 Byte, hier ist der Typ Integer --> der Wert wird mit Factors multipliziert bis ein Integerwert herauskommt
   - die Startadresse für den Wert liegt 7 Bit hinter der Startadresse für den Channel
   - intern in der Software wird der Wert als float_configtime mit einer Länge von 1Byte und 6Bit gespeichert, die Umrechnungsfaktoren sind 0.1,1,6,1000
   - zur Umrechnung von eeprom- Wert zu Softwarewert wird die Valuemap genutzt (vgl. device.pm)

Gruß gevoo

Thorsten Pferdekaemper

Hi,
soweit ist mir das auch klar. Allerdings verstehe ich das mit den Faktoren und der value_map nicht. Klar, ich kann mir das Coding betrachten, aber ich glaube, dass da was nicht stimmt. Könntest Du mal versuchen, genauer zu erklären, wie die Umrechnung geht?
Gruß,
   Thorsten
FUIP

bmwfan

Hallo gevoo,
habe es jetzt nach update der 10_HM485 nochmal getestet, allerdings mit demselben Resultat. Am 23.11. hatte ich das letzte Mal einen restart gemacht. Wenn das der ausgelesene Wert ist, ist er definitiv falsch, da diese Zeit mit 64s im GUI angezeigt wird. Anbei das Log-File:

Zitataktuelle Version ist jetzt V 0.00.09 - 22.11.2015
2015-11-23_20:51:24 Jalousie_Define: testjal reference_running_time_top_bottom = 50
2015-11-23_20:51:24 Jalousie_Define: Jal_KU_Ost_03, 50, 50
2015-11-23_20:51:24 Jalousie_Define: testjal, Jal_KU_Ost_03, 2, 2
2015-11-25_20:30:48 Jalousie_Set: testjal runter fahren auf 50
2015-11-25_20:30:48 Jalousie_SetWinkel: testjal winkel = 0
2015-11-25_20:30:48 Jalousie_SetWinkel: testjal deltaW = 0
2015-11-25_20:30:48 Jalousie_SetWinkel: testjal auf = 50 zu = 50
2015-11-25_20:30:48 Jalousie_Set: testjal level auf 50
2015-11-25_20:32:02 Jalousie_SetWinkel: testjal winkel = 90
2015-11-25_20:32:02 Jalousie_SetWinkel: testjal deltaW = 90
2015-11-25_20:32:02 Jalousie_SetWinkel: testjal auf = 50 zu = 50
2015-11-25_20:32:02 Jalousie_SetWinkel: testjal deltaZeit = 2 deltaLevel = 1
2015-11-25_20:32:02 Jalousie_SetWinkel: testjal Winkel auf 90 grad

Der Ist-Level war dann 88, der Winkel ca. 45..55.°.

Bei dem falschen Level habe ich die Vermutung, dass entweder
die in der GUI angezeigte Zeit für reference_running_time_top_bottom: 64 s. entweder gar nicht im device gespeichert ist sondern noch der Standardwert und der dann korrekt ausgelesen wird oder
das Modul den Wert nicht korrekt ausliest.
Das würde in beiden Fällen erklären, warum der Level (hängt ja von der Fahrzeit ab) nicht stimmt, nicht aber die große Abweichung von gewollt 50 auf Ist 88.

Beim falschen Winkel kann ich es mir nur aus einem Umrechnungsfehler erklären.

Hast Du einen Ansatz, was ich noch versuchen könnte?

Arbeite mich parallel in Perl ein, um Deinen Code besser verstehen zu können und selber Versuche zu machen.

Gruß Jürgen
Synology DS720+ mit Docker-Container und Haupt-FHEM, HM-LAN, Jalousienaktoren HmWired, Shelly-Devices; Raspi 3B+ mit piVCCU ohne FHEM-Instanz, CUL, JeeLink; Raspi 3B+ mit FHEM und HMUARTUSB,  Raspi 3B+ mit HMUARTGPIO, 1-wire, ebusd

bmwfan

@Thorsten,

wenn man entwicklen muss, muss das Programm ja auch Zugriff auf die device haben. Dann greife ich aber von 2 laufenden Instanzen auf die device zu. Das kann doch nicht gut gehen, denke ich.
Schaltest Du dann das laufende FHEM nab und fährst FHEM komplett auf der Entwicklungsumgebung oder schaltest Du im aktiven FHEM nur das Modul ab, an dem Du gerade entwickelst, um dieses dann auf der Entwicklungshardware laufen zu lassen? Oder noch ganz anders?

Von früher (Assemblerprogrammierung) kenne ich das so, dass ich ein komplettes Entwicklungssystem mit angeschlossenen device hatte und über Schalter / Taster die Ein/Ausgänge simuliert habe. Das geht ja hier aber nicht.

Vielleicht hast Du mir noch eine Tip, wie Du das machst.

Gruß Jürgen

Synology DS720+ mit Docker-Container und Haupt-FHEM, HM-LAN, Jalousienaktoren HmWired, Shelly-Devices; Raspi 3B+ mit piVCCU ohne FHEM-Instanz, CUL, JeeLink; Raspi 3B+ mit FHEM und HMUARTUSB,  Raspi 3B+ mit HMUARTGPIO, 1-wire, ebusd

Thorsten Pferdekaemper

Zitat von: bmwfan am 26 November 2015, 08:13:08
@Thorsten
Vielleicht hast Du mir noch eine Tip, wie Du das machst.
Ich habe einen zweiten RasPi, an dem ein komplett eigener RS485-Bus hängt. An den hänge ich dann HMW-Devices, die ich ansonsten nicht verwende. D.h. alles ist nur zum Test. Natürlich habe ich damit nicht mein komplettes System simuliert, aber zumindest die Teile, an denen ich gerade entwickle.

Zum anderen Problem mit den Fahrzeiten: Mich würde interessieren, wie das Jalousie-Modul die Fahrzeiten aus den Devices liest. Dazu gibt es nämlich kein Reading. D.h. man müsste relativ viel zu den Interna der Devices wissen und auch ausnutzen. Ich kann mir momentan nicht vorstellen, dass das so klappt.
Auch das Setzen von Werten in der Konfiguration eines Devices ist nicht ganz so einfach.
Ich habe mir mal überlegt, ob man für die Wired-Devices nicht so etwas ähnliches bauen sollte, wie für die HM-Funk Sachen. D.h. die Konfigurationen (d.h. der EEPROM-Inhalt) eines Devices würden dann als Readings bereit gestellt und könnten auch mit einem set-Befehl geändert werden.
Wird sowas gebraucht?

Gruß,
   Thorsten


Gruß,
   Thorsten
FUIP

bmwfan

@Thorsten:
Danke für die Tips. Dann muss ja wohl ein 2.ter Raspi her und für das OG brauche ich sowieso noch einen HMLAN. Jalousiedevice habe ich auch noch.

ZitatFahrzeiten
Ich benutze das Modul 90_Jalousie.pm das, soweit ich weis, von gevoo stammt. Da bin ich mir aber nicht sicher.
Ich habe mir mit meinem bisherigen Wissen (Lesen, Testen, Fragen) folgendes zusammengereimt:
Die Fahrzeiten top->bottom und bottom->top gebe ich in der GUI ein. Werte siehe Anhang.
Diese müßten ja in das device geladen werden da es ansonsten nicht weis, wann es die Jalousie auf einem bestimmten level stoppen soll. Das funktioniert auch einwandfrei, wenn die Jalosuie direkt angesprochen wird.
Befehl:
Zitatset Jal_KU_Ost_03 level 50
Diese Werte liest das Modul aus und verwendet sie zur Berechnung der Zeitdauer, die die Jalousie fahren soll, bis die gewünschte Position erreicht ist. Nach dem Befehl
Zitatset testjal level 50
fährt die Jalousie allerdings nur auf den level 88.
In der Definition des Moduls define testjal Jalousie Jal_KU_Ost_03 2 2 gebe ich die Zeitdauer der Drehbewegung an. Damit und dem Wissen, ob die letzte Bewegung ab oder auf war kann das Modul den gewünschten Winkel ausrechnen und diese Zeitdauer lang einen Fahrbefehl an die Jalousie ausgeben.

So weit meine Theorie. Wenn jemandem ein Fehler auffällt, bitte melden. Schreiben in und lesen aus einem device ist für mich noch totales Neuland.

Die Ausleseroutine aus dem Modul 90_Jalousie.pm müßte diese sein:
sub Jalousie_Define($$$) {
my ( $hash, $def ) = @_;
# in dieser Version wird vorausgesetzt, daß zu Jalousie- Ansteuerung ein Rolloaktor
# benutzt wird
# Winkel 0 = geschlossen, Winkel $DrehWinkel = offen
my @a = split( "[ \t][ \t]*", $def );
my $name = $a[0];
my $reFloat ='^([\\+,\\-]?\\d+\\.?\d*$)'; # gleitpunkt 
Log3( $name, 3, "Name = $a[0], Parameter = $a[1] $a[2] $a[3] $a[4]");

if ( @a != 5) {
return "wrong syntax: define <name> Jalousie <Rolloaktor_03> <DrehzeitAb> <DrehzeitAuf>";
}
###################
# Aktor Werte ermitteln
my $aktor = $a[2];
my $drehAb = $a[3];
my $drehAuf = $a[4];
my $drehWinkel = $DrehWinkel; # 90 Grad Drehwinkel
   
# wenn aktor nicht definiert?
if ( !$defs{ $aktor} ) {
my $msg = "Jalousie_Define: $name: Unbekannter Aktor $aktor als Device festgelegt";
Log3 ( "Jalousie", 1, $msg);
return $msg;
}

# pruefen ob die angegebenen Zeiten mit der Config des Aktors uebereinstimmen
my $dabAnteil = 0;
my $daufAnteil = 0;
my $chHash = $defs{$aktor};
my $cHash  = HM485::ConfigurationManager::getConfigFromDevice($chHash, 0);
Logger( 'Jalousie_Define: ' . $name . " reference_running_time_top_bottom = " . $cHash->{reference_running_time_top_bottom}{value});
if ( defined( $cHash->{reference_running_time_top_bottom}{value}) && $cHash->{reference_running_time_top_bottom}{value}) {
if ( abs( $cHash->{reference_running_time_top_bottom}{value} - $drehAb) < 1) {
return "Falsche Zeitangaben in Jalousie Definition $name: DrehzeitAb > reference_running_time_top_bottom";
}
} else {
Log3 ( "Jalousie", 1, "Jalousie Zeit für Abwaertsbewegung nicht definiert!");
}

if ( defined( $cHash->{reference_running_time_bottom_top}{value}) && $cHash->{reference_running_time_bottom_top}{value}) {
if ( abs( $cHash->{reference_running_time_bottom_top}{value} - $drehAuf) < 1) {
return "Falsche Zeitangaben in Jalousie Definition $name: DrehzeitAuf > reference_running_time_bottom_top";
}
$daufAnteil = 100 * $drehAuf/ $cHash->{reference_running_time_bottom_top}{value};
} else {
Log3 ( "Jalousie", 1, "Jalousie Zeit für Aufwaertsbewegung nicht definiert!");
}

$hash->{Jalousie}{aktor} = $aktor;
$hash->{Jalousie}{drehZeitAb} = $drehAb;
$hash->{Jalousie}{ab} = $cHash->{reference_running_time_top_bottom}{value};
$hash->{Jalousie}{drehZeitAuf} = $drehAuf;
$hash->{Jalousie}{auf} = $cHash->{reference_running_time_bottom_top}{value};
$hash->{Jalousie}{winkel} = 0;
$hash->{Jalousie}{lastMove} = 'ab'; # merkt sich die letzte Bewegungsrichtung

Logger( 'Jalousie_Define: ' . $aktor . ', ' . $hash->{Jalousie}{ab} . ', ' . $hash->{Jalousie}{auf});

$modules{Jalousie}{defptr}{$name} = $hash;
Log3 ( "Jalousie", 1, "Jalousie mit Rolloaktor $aktor verbunden");
Logger( 'Jalousie_Define: ' . $name . ', ' . $aktor . ', ' . $drehAb . ', ' . $drehAuf);
# Readings
# Level gibt den Stand der Jalousie an: 0 = geschlossen, 100 = voll geoeffnet

# Winkel: gibt den Drehwinkel der Lamellen an: 0 = geschlossen, $DrehWinkel = offen

return undef;
}


So weit bin ich gekommen und versuche weiter herauszufinden, wo ich etwas ändern muss damit meine Jalousien auf das gewünschte level fahren und den gewünschten Winkel einstellen.

Gruß Jürgen
Synology DS720+ mit Docker-Container und Haupt-FHEM, HM-LAN, Jalousienaktoren HmWired, Shelly-Devices; Raspi 3B+ mit piVCCU ohne FHEM-Instanz, CUL, JeeLink; Raspi 3B+ mit FHEM und HMUARTUSB,  Raspi 3B+ mit HMUARTGPIO, 1-wire, ebusd

Thorsten Pferdekaemper

Hi,
die Zeile hier ist interessant:

Logger( 'Jalousie_Define: ' . $name . " reference_running_time_top_bottom = " . $cHash->{reference_running_time_top_bottom}{value});

Was steht denn da im Log?
Gruß,
   Thorsten
FUIP

bmwfan

#293
Mache schon den ganzen Abend daran herum und zeige mir die Parameter an verschiedenen Programmpunkten in die Log-Datei.
In der Zeile steht fast immer der Wert 50, ebenso wie in dem Wert bottom-top. Ein einziges Mal standen die in der GUO sichtbaren Werte (64 s. und 65s.) darin. Ich vermute somit, dass der Auslesebefehl schon korrekt ist, aber ein Timing-Problem vorliegt.
Das log mit den korrekten fahrzeiten:
Zitataktuelle Version ist jetzt V 0.00.09 - 22.11.2015
2015-11-26_20:39:56 Jalousie_Define: testjal reference_running_time_top_bottom = 64.00
2015-11-26_20:39:56 a[0]: testjal erster Wert des hash = testjal
2015-11-26_20:39:56 a[1]: nicht verwendet zweiter Wert des hash = Jalousie
2015-11-26_20:39:56 a[2]: Jal_KU_Ost_03 dritter Wert des hash = Jal_KU_Ost_03
2015-11-26_20:39:56 a[3]: 2 vierter Wert des hash = 2
2015-11-26_20:39:56 a[4]: 2 fünfter Wert des hash = 2
2015-11-26_20:39:56 Jalousie_Define: Jal_KU_Ost_03, 64.00, 65.00
2015-11-26_20:39:56 Jalousie_Define: testjal, Jal_KU_Ost_03, 2, 2
2015-11-26_20:40:41 Jalousie_Set: testjal runter fahren auf 20
2015-11-26_20:40:41 Jalousie_SetWinkel: testjal winkel = 0
2015-11-26_20:40:41 Jalousie_SetWinkel: testjal deltaW = 0
2015-11-26_20:40:41 Jalousie_SetWinkel: testjal auf = 65.00 zu = 64.00
2015-11-26_20:40:41 Jalousie_Set: testjal level auf 20
2015-11-26_20:41:49 Jalousie_SetWinkel: testjal winkel = 90
2015-11-26_20:41:49 Jalousie_SetWinkel: testjal deltaW = 90
2015-11-26_20:41:49 Jalousie_SetWinkel: testjal auf = 65.00 zu = 64.00
2015-11-26_20:41:49 Jalousie_SetWinkel: testjal deltaZeit = 2 deltaLevel = 1.3
2015-11-26_20:41:49 Jalousie_SetWinkel: testjal Winkel auf 90 grad

Späteres log mit den "Standard"-Fahrzeiten:
Zitataktuelle Version ist jetzt V 0.00.09 - 22.11.2015
2015-11-26_21:08:42 Jalousie_Define: testjal reference_running_time_top_bottom = 50
2015-11-26_21:08:42 a[0]: testjal erster Wert des hash = testjal
2015-11-26_21:08:42 a[1]: nicht verwendet zweiter Wert des hash = Jalousie
2015-11-26_21:08:42 a[2]: Jal_KU_Ost_03 dritter Wert des hash = Jal_KU_Ost_03
2015-11-26_21:08:42 a[3]: 2 vierter Wert des hash = 2
2015-11-26_21:08:42 a[4]: 2 fünfter Wert des hash = 2
2015-11-26_21:08:42 Jalousie_Define: Jal_KU_Ost_03, 50, 50
2015-11-26_21:08:42 Jalousie_Define: testjal, Jal_KU_Ost_03, 2, 2
2015-11-26_21:10:27 Jalousie_Set: 100 ReadingsVal des Levels aus device
2015-11-26_21:10:27 Jalousie_Set: testjal runter fahren auf 50
2015-11-26_21:10:27 Jalousie_Set: testjal level auf 50
2015-11-26_21:10:57 Jalousie_SetWinkel: testjal winkel = 90
2015-11-26_21:10:57 Jalousie_SetWinkel: testjal deltaW = 90
2015-11-26_21:10:57 Jalousie_SetWinkel: testjal auf = 50 zu = 50
2015-11-26_21:10:57 Jalousie_SetWinkel: testjal deltaZeit = 2 deltaLevel = 1
2015-11-26_21:10:58 Jalousie_SetWinkel: testjal Winkel auf 90 grad

Aber auch bei den korrekten Fahrzeiten hat der level nicht gepaßt. Muss noch ein weiterer Fehler vorliegen.

Gruß Jürgen

Ergänzung:
Das ist die Routine, die das device ausliest (mit meinen log-Befehlen):
Zitatmy $chHash    = $defs{$aktor};
   Logger( '$defs{$aktor}: ' . $chHash . " nachschauen, was das ist");
   my $cHash     = HM485::ConfigurationManager::getConfigFromDevice($chHash, 0);
   Logger( 'HM485::ConfigurationManager::getConfigFromDevice($chHash, 0): ' . $cHash . " nachschauen, was das ist");
   Logger( 'Jalousie_Define: ' . $name . " reference_running_time_top_bottom = " . $cHash->{reference_running_time_top_bottom}{value});
Und das steht im Log:
Zitataktuelle Version ist jetzt V 0.00.09 - 22.11.2015
2015-11-26_21:34:25 $defs{$aktor}: HASH(0x16e1ed8) nachschauen, was das ist
2015-11-26_21:34:25 HM485::ConfigurationManager::getConfigFromDevice($chHash, 0): HASH(0x332bec8) nachschauen, was das ist
2015-11-26_21:34:25 Jalousie_Define: testjal reference_running_time_top_bottom = 50

Wieder der Falsche Wert, aber mit den Werten HASH(0x....) kann ich nichts anfangen. Ich weis schon, dass dies Hexadezimalwerte sind, aber was stellen die dar?
Synology DS720+ mit Docker-Container und Haupt-FHEM, HM-LAN, Jalousienaktoren HmWired, Shelly-Devices; Raspi 3B+ mit piVCCU ohne FHEM-Instanz, CUL, JeeLink; Raspi 3B+ mit FHEM und HMUARTUSB,  Raspi 3B+ mit HMUARTGPIO, 1-wire, ebusd

Thorsten Pferdekaemper

Hi,
für mich sieht es auch so aus, dass die Werte richtig gelesen werden. In den Rest will ich mich jetzt nicht reinarbeiten, da muss vielleicht der Autor ran.
Gruß,
   Thorsten
FUIP

gevoo

Hallo Thorsten,

die Erklärung für
Zitat <conversion type="float_configtime" value_size="1.6" factors="0.1,1,60,1000"/>
  <conversion type="integer_integer_map">
      <value_map parameter_value="0xffff" device_value="0xc000" mask="0xc000"/>
  </conversion>
ist eigentlich was für Informatiker. Ich versuche es einmal als Praktiker:
Da nur ganzzahlige positive Werte gespeichert werden können gilt folgendes:
- ist SHORT_ONDELAY_TIME < 1/60 gilt der Faktor 1000 ( das ist ziemlich klein und damit wahrscheinlich nicht unbedingt von praktischem Wert).
- ist SHORT_ONDELAY_TIME >= 1/60 und SHORT_ONDELAY_TIME < 1 gilt Faktor 60
- ist SHORT_ONDELAY_TIME >= 1 und SHORT_ONDELAY_TIME < 49152 gilt Faktor 1 ( das entspricht 49152 = #C000 = 1100 0000 0000 0000) --> daher die 14 Bit
- ist SHORT_ONDELAY_TIME >= 49152 so gilt Faktor 0.1

In device.pm wird im Moment mit einer praktikablen Wertegröße gerechnet. Es wird davon ausgegangen, daß SHORT_ONDELAY_TIME >= 1 s ist bzw. 0.0 s als Sonderfall,
wenn nichts definiert ist.

Gruß gevoo

gevoo

Hallo Jürgen,

In der Zeile:
my $cHash  = HM485::ConfigurationManager::getConfigFromDevice($chHash, 0);
wird der Channel- Hash für Channel 03 von Deiner Jalousie geholt. Solche Werte wie HASH(0x332bec8) sind nicht die Werte, die im Hash stehen, sondern das ist die Startadresse im Speicher.
Auf die Werte greiftst Du mit der nachfolgenden Zeile zu:
$cHash->{reference_running_time_top_bottom}{value}
Was soviel bedeutet wie: Gehe im Hash zur Abteilung reference_running_time_top_bottom und nimm dir das was dort im Speicher hinterlegt ist.
Der Configurationsmanager geht ( vgl. hmw_lc_bl1_dr.pm) in die Abteilung HMW_LC_BL1_DR -> channels -> blind -> paramset -> master -> parameter und ermittelt die Speicheradresse. Die wird als Hash zurückgegeben und bei uns als cHash bezeichnet.  Von der Adresse geht man Weiter im Configbaum bis zu reference_running_time_top_bottom wo im Speicher dessen Wert hinterlegt ist. Man könnte auch mit:
HMW_LC_BL1_DR -> {channels}{blind}{paramset}{master}{parameter}{reference_running_time_top_bottom}{value}
direkt auf den Wert zugreifen. Aber, da die ganze Validitätsprüfung schon im Configurationsmanager hinterlegt ist, wäre es dumm das nicht zu nutzen.
Soweit zur Theorie.
Wenn das 90_Jalousie.pm nicht die richtigen Werte ermitteln kann ( 50 ist nur ein Notbehelf, damit das Programm nicht abstürzt) könnte es folgende Ursachen haben.
- Die Definition von Deinem Rolloaktor liegt in der *.cfg hinter der Definition für die Jalousie.
- Die Intialisierung für den Rolloaktor dauert zu lange oder Deine Abfrage ist zu früh ( Ansichtssache).
- Dein Raspi ist mit anderen Sachen beschäftigt und hat keine Zeit dafür

Du könntest bitte einmal einen Auszug aus Deinem fhem-2015-11.log posten. Und zwar vom Start bis zur Definition der Jalousie.

Gruß gevoo

bmwfan

Hallo gevoo,

die Erklärung habe ich verstanden. Habe auch früher mit Referenzen gearbeitet. Diese Parameter sind doch entweder ein reading oder ein internal. Warum kann man denn nicht direkt darauf zurgreifen, wenn man den Namen des Parameters schon weis?

Anbei der Auszug aus dem log. Ist allerdings wochenweise statt monatsweise.
Zitat2015.11.26 21:34:16 0: Server shutdown
2015.11.26 21:34:16 4: CUL_send:  CUL_0X0 0     
2015.11.26 21:34:19 2: Perfmon: ready to watch out for delays greater than one second
2015.11.26 21:34:19 1: Including fhem.cfg
2015.11.26 21:34:23 1: Including ./FHEM/Sonstiges.cfg
2015.11.26 21:34:23 1: Including ./FHEM/Wohnzimmer.cfg
2015.11.26 21:34:24 1: Including ./FHEM/Jalousien.cfg
2015.11.26 21:34:24 1: Including ./FHEM/Arbeitszimmer.cfg
2015.11.26 21:34:24 1: Including ./FHEM/Flur_UG.cfg
2015.11.26 21:34:24 1: Including ./FHEM/Waschkueche.cfg
2015.11.26 21:34:24 1: Including ./FHEM/Garage.cfg
Prototype after '@' for main::Text2Speech_SplitString : @$$$$ at ./FHEM/98_Text2Speech.pm line 562, <$fh> line 387.
2015.11.26 21:34:25 1: Jalousie mit Rolloaktor Jal_KU_Ost_03 verbunden
2015.11.26 21:34:25 1: Including ./log/fhem.save
2015.11.26 21:34:27 0: Featurelevel: 5.7
2015.11.26 21:34:27 0: Server started with 149 defined entities (version $Id: fhem.pl 9993 2015-11-24 18:40:02Z rudolfkoenig $, os linux, user fhem, pid 5815)
2015.11.26 21:34:27 1: Perfmon: possible freeze starting at 21:34:20, delay is 7.493
2015.11.26 21:34:50 4: CUL_Parse: CUL_0 A 14 2F A270 27238A 31AE26 00E83A0000000004E30BB8F8 -78

und dazu das Log-File des Moduls:
Zitataktuelle Version ist jetzt V 0.00.09 - 22.11.2015
2015-11-26_21:34:25 $defs{$aktor}: HASH(0x16e1ed8) nachschauen, was das ist
2015-11-26_21:34:25 HM485::ConfigurationManager::getConfigFromDevice($chHash, 0): HASH(0x332bec8) nachschauen, was das ist
2015-11-26_21:34:25 Jalousie_Define: testjal reference_running_time_top_bottom = 50
2015-11-26_21:34:25 a[0]: testjal erster Wert des hash = testjal
2015-11-26_21:34:25 a[1]: nicht verwendet zweiter Wert des hash = Jalousie
2015-11-26_21:34:25 a[2]: Jal_KU_Ost_03 dritter Wert des hash = Jal_KU_Ost_03
2015-11-26_21:34:25 a[3]: 2 vierter Wert des hash = 2
2015-11-26_21:34:25 a[4]: 2 fünfter Wert des hash = 2
2015-11-26_21:34:25 Jalousie_Define: Jal_KU_Ost_03, 50, 50
2015-11-26_21:34:25 Jalousie_Define: testjal, Jal_KU_Ost_03, 2, 2

Da ich nur 2 verschiedene Laufzeiten für alle Jalousien habe, kann ich die Laufzeiten fest hinterlegen und muss sie nicht auslesen. Das wäre meine Notlösung, aber ein universelles Modul wäre mir lieber. Immerhin ist jetzt auch mein Entwicklerdrang erwacht und ich möchte mich mit Perl und der Hardware auseinandersetzen.  ;)

Zitat- Die Definition von Deinem Rolloaktor liegt in der *.cfg hinter der Definition für die Jalousie.
Liegt davor, da in Jalousie.cfg definiert. Ich weis, dass man das nicht macht (mehrere cfg) ist aber eine Anfängersünde meines Einstieges in FHEM. Jetzt will ich es nicht mehr ändern aus Sorge, dass dannn nichts mehr geht.

ZitatDie Intialisierung für den Rolloaktor dauert zu lange oder Deine Abfrage ist zu früh ( Ansichtssache).
Das kann ich doch nicht beeinflussen, da die Initialisierung beim Programmaufruf erfolgt oder verstehe ich das falsch?

Zitat- Dein Raspi ist mit anderen Sachen beschäftigt und hat keine Zeit dafür
Ich kann zwar die Auslastung generell überprüfen, aber wie das Monitoring des Raspi bei einer bestimmten Aktion (Rollo runterfahren) bzw. Zeitpunkt geht weis ich nicht.

Danke für Deine Hilfe und Erklärungen.
Gruß Jürgen
Synology DS720+ mit Docker-Container und Haupt-FHEM, HM-LAN, Jalousienaktoren HmWired, Shelly-Devices; Raspi 3B+ mit piVCCU ohne FHEM-Instanz, CUL, JeeLink; Raspi 3B+ mit FHEM und HMUARTUSB,  Raspi 3B+ mit HMUARTGPIO, 1-wire, ebusd

gevoo

Hallo Jürgen,

Dein Rolloaktor ist noch nicht initialisiert beim Aufruf von Define Jalousie...
Deshalb können auch die Werte nicht ermittelt werden.
Abhilfe könnte ein at in Deiner *.cfg schaffen. In etwa so:

define SetJalousie at +00:01:00 {\
fhem("define testjal Jalousie Jal_KU_Ost_03 2 2");;
}

Damit wird die Definition um 1 Minute verzögert.

ZitatDiese Parameter sind doch entweder ein reading oder ein internal. Warum kann man denn nicht direkt darauf zurgreifen
Weil noch keiner die Schnittstelle programmiert hat.

ZitatIch weis, dass man das nicht macht (mehrere cfg) ist aber eine Anfängersünde meines Einstieges in FHEM.
Mache ich auch so, ist übersichtlicher.

Gruß gevoo

bmwfan

Hallo gevoo,

habe es jetzt mehrfach versucht.
1: Eingebaut in die Jalousie.cfg hinter dem define des device. Jalousie.cfg gespeichert. Dann fhem.cfg gespeichert. Keine Fehlermeldung.
2: Neustart und logs kontrolliert.
3: Die richtigen Werte werden ausgelesen (64 und 65 sec.), aber das define testjal ... steht jetzt nicht mehr in der Jalousie.cfg sondern in der fhem.cfg.
4: Nach nächstem Neustart kommt die Meldung:
Zitat2015.11.27 23:18:56 1: Including fhem.cfg
2015.11.27 23:19:00 1: Including ./FHEM/Jalousien.cfg
2015.11.27 23:19:00 1: Including ./FHEM/Sonstiges.cfg
2015.11.27 23:19:01 1: Including ./FHEM/Wohnzimmer.cfg
2015.11.27 23:19:02 1: Including ./FHEM/Arbeitszimmer.cfg
2015.11.27 23:19:02 1: Including ./FHEM/Flur_UG.cfg
2015.11.27 23:19:02 1: Including ./FHEM/Waschkueche.cfg
2015.11.27 23:19:02 1: Including ./FHEM/Garage.cfg
Prototype after '@' for main::Text2Speech_SplitString : @$$$$ at ./FHEM/98_Text2Speech.pm line 562, <$fh> line 370.
2015.11.27 23:19:02 1: Including ./log/fhem.save
2015.11.27 23:19:03 1: statefile: SetJalousie already defined, delete it first
2015.11.27 23:19:05 0: Featurelevel: 5.7
5: Jetzt sind wieder die Standardfahrzeiten (50 sec.) im Log.
6: Schaue ich in die Jalousie.cfg ist der Eintrag define SetJalousie... gelöscht und nur noch das define testjal in der fhem.cfg vorhanden.

Seltsames Verhalten. Wieso wird von FHEM ein define nach Ausführung gelöscht? Darf so etwas sein?

Gruß Jürgen
Synology DS720+ mit Docker-Container und Haupt-FHEM, HM-LAN, Jalousienaktoren HmWired, Shelly-Devices; Raspi 3B+ mit piVCCU ohne FHEM-Instanz, CUL, JeeLink; Raspi 3B+ mit FHEM und HMUARTUSB,  Raspi 3B+ mit HMUARTGPIO, 1-wire, ebusd