HomeMatic Wired - HMW-LAN-Gateway

[gevoo]

Hallo Jürgen,

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.

Hast Du eventuell "Save config" auf der Weboberfläche angeklickt?

Gruß gevoo

[Thorsten Pferdekaemper]

die Erklärung für ist eigentlich was für Informatiker.

Ok. Irgendwo habe ich einen Zettel rumfliegen, auf dem mein Name steht und irgendwas von "Diplom". Auch das Wort "Informatik" ist drauf...

Ich versuche es einmal als Praktiker:

Auch gut. Obiger Zettel ist relativ alt, seitdem habe ich das ganze fast nur in der Praxis ausgeübt.
SCNR...

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

Wenn das so ist, dann müsste folgendes stimmen:

Wert in Realität	Wert im EEPROM
0.01s	10
0.1s	6
0.17s	10
5s	5
10s	10
50000s	5000

Ist das so gemeint? Wenn ja: Wie kann man unterscheiden zwischen 0.01s, 0.17s und 10s, wenn der interne Wert 10 ist?

In device.pm wird im Moment mit einer praktikablen Wertegröße gerechnet. Es wird davon ausgegangen, daß SHORT_ONDELAY_TIME >= 1 s ist

Warum funktioniert es dann, wenn ich 0.2s eingebe? Das dürfte doch dann gar nicht gehen, oder?

Gruß,
   Thorsten

[Thorsten Pferdekaemper]

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.

Dafür gibt es inzwischen ein Reading: configStatus. Erst wenn das auf "OK" steht kann man davon ausgehen, dass die EEPROM-Daten vom Device von FHEM gelesen wurden. (FHEM lädt den Kram beim Start jedesmal neu vom Device. Wie haben bei Wired ja kein Problem mit Sendekontingenten und so.)
configStatus kann noch folgende Werte annehmen:
PENDING: Das ist am Anfang, bevor das Interface initialisiert ist
READING: Währen die Daten gelesen werden
FAILED: Das kann man sich denken...
Letzteres bleibt nicht ewig stehen. Wenn etwas schief geht, dann pendelt es immer zwischen READING und FAILED, bis es irgendwann hoffentlich dann doch auf OK geht.
Das Reading wird auch geändert, wenn man "get ... config all" macht. Dann geht es auf READING und danach auf OK, wenn alles gut läuft.

Weil noch keiner die Schnittstelle programmiert hat.

Deswegen ja meine Frage, ob das gewünscht ist. Die Darstellung wird dadurch ggf. etwas unübersichtlicher, aber man kann die Werte halt einfacher lesen.

Gruß,
   Thorsten

[gevoo]

Hallo Thorsten,

Wenn das so ist, dann müsste folgendes stimmen:
Wert in Realität   Wert im EEPROM
0.01s   10
0.1s   6
0.17s   10
5s   5
10s   10
50000s   5000
Ist das so gemeint? Wenn ja: Wie kann man unterscheiden zwischen 0.01s, 0.17s und 10s, wenn der interne Wert 10 ist?

In etwa. Das wurde in device.pm Zeilen 1098- 1118 schon wunderbar gelöst.

Gruß gevoo

[Thorsten Pferdekaemper]

In etwa. Das wurde in device.pm Zeilen 1098- 1118 schon wunderbar gelöst.

Hi,
die Logik mit den Vergleichen kann ich nicht finden. Mir sieht das so aus, als ob das immer mit einem festen Wert multipliziert wird, egal
welcher Wert am Frontend eingegeben wird.
Ich glaube, dass ich da mal noch ein bisschen experimentieren muss.
Gruß,
   Thorsten

[bmwfan]

@gevoo:
Nach einigen Versuchen bin ich auf diese Methode gekommen, wie mir Änderungen in untergeordneten cfg-Dateien nicht mehr nach dem speichern verschwinden:
Zuerst die *.cfg speichern, dann fhem.cfg öffnen und speichern. Nach restart gibt es ein rotes Fragezeichen bei Save config auf der Weboberfläche. Dann das geklickt. So waren bisher meine Änderungen immer noch nach dem restart vorhanden.

Bis auf dieses Mal. Da war, wie geschrieben, die definition der testjal plötzlich in fhem.cfg, obwohl in Jlousie.cfg eingegeben. Hatte ich noch nie.

@Thorsten:
Als Beginner, zu denen ich mich noch zähle, wäre es einfacher, wenn man die konfigurierten Werte wie Fahrzeit ab... einfach über ein reading auslesen könnte. Was dann unübersichtlicher wird kann ich nicht beurteilen.

Als readings vom Rolloaktor

FW_VERSION 3.06
   IODev
   MODEL      HMW_LC_Bl1_DR
   NAME       Jal_KU_Ost_03

habe ich allerdings nur:

Readings:
     2015-11-28 07:50:41   direction       none
     2015-11-28 07:50:41   level           100
     2015-11-28 07:50:41   state           level_100
     2015-11-27 22:45:59   winkel          90
     2015-11-28 07:50:41   working         off

[Thorsten Pferdekaemper]

@Thorsten:
Als Beginner, zu denen ich mich noch zähle, wäre es einfacher, wenn man die konfigurierten Werte wie Fahrzeit ab... einfach über ein reading auslesen könnte.

Hi,
mit der aktuellen dev-Version (0.7.33) geht das jetzt. Siehe auch hier: http://forum.fhem.de/index.php/topic,10607.msg367039.html#msg367039
In der Regel sollten die Readings auch im fhem.save gespeichert werden. D.h. sie müssten von Anfang an verfügbar sein. (Nur halt nicht beim ersten Mal.) Allerdings ist es besser, wenn man auf configStatus = "OK" wartet.
Es müsste also z.B. beim Jalousieaktor ein Reading "R-reference_running_time_top_bottom" geben.
Gruß,
   Thorsten

[RobertD]

Hallo,

Kann ich bestätigen mit der 0.7.33 siehts so aus:
Readings vom HMW_LC_Bl1_DR:

R-change_over_delay   0.50      2015-11-30 00:49:40
R-logging            on      2015-11-30 00:49:40
R-reference_run_counter   0      2015-11-30 00:49:40
R-reference_running_time_bottom_top   10.00   2015-11-30 00:49:40
R-reference_running_time_top_bottom   10.00   2015-11-30 00:49:40
direction            none   2015-11-30 01:01:19
level               0      2015-11-30 01:01:19
state            level_0   2015-11-30 01:01:19
working         off      2015-11-30 01:01:19

Gruß Robert

[gevoo]

Hallo Jürgen,

damit vereinfacht sich das Jalousiee- Modul etwas 

Gruß gevoo

[bmwfan]

Hallo Thorsten und Gevoo,

an beide ein dickes DANKE.

@Thorsten: Was gibt denn das reading Winkel genau an? Es kann ja nicht der tatsächliche Lamellenwinkel sein, da das device ja die Drehzeit und den ganzen Drehwinkel gar nicht kennt.

@gevoo: In Zeile 93 ist ein Klammerfehler. Muss korrekt so heißen:

Code Auswählen Erweitern

if ( defined( ReadingsVal( $aktor, "R-reference_running_time_bottom_top", undef)) && ReadingsVal( $aktor, "R-reference_running_time_bottom_top", undef)) {

Werde morgen weiter testen.

Gruß Jürgen

[Thorsten Pferdekaemper]

@Thorsten: Was gibt denn das reading Winkel genau an? Es kann ja nicht der tatsächliche Lamellenwinkel sein, da das device ja die Drehzeit und den ganzen Drehwinkel gar nicht kennt.

Keine Ahnung. Normale HMW-Rolloaktoren haben das nicht. ...und wenn sie es hätten, dann wär's auf Englisch.
Gruß,
   Thorsten

[gevoo]

Hallo Jürgen,

wenn das Modul einmal richtig läuft, soll der Winkel den tatsächlichen Winkel angeben. Er wird aus der Zeit, die sich die Lamellen drehen berechnet.

Gruß gevoo

[bmwfan]

Hallo gevoo,

da kommt wieder meine Unkenntnis durch. Ich war der Meinung, das die readings gerätespezifisch sind und in der Firmware vom Hersteller bereits festgelegt sind. Die Werte hinter den readings können dann auf einem EEPROM oder anderes Speichermedium im device geschrieben bzw. von dort ausgelesen werden.
Deiner Antwort nach, kommen die aber aus deinem Modul??? Da verstehe ich den Zusammenhang nicht, da ja über die verschiedenen 485er Module (10_HM485 ...) auf das device zugegriffen wird.
Kannst Du mir erläutern, was genau das 90_Jalousie.pm macht, das 10_HM485.pm, das 00_HM485_LAN.pm, communication.pm, configurationManager.pm ....?

Gruß Jürgen

[gevoo]

Hallo Jürgen,

allgemein gesagt: ein Programmmodul macht das was man ihm beibringt.
In unserm speziellen Fall von 90_Jalousie.pm werden die Originaldaten des RolloAktors eingelesen und als Kopie im Hauptspeicher gehalten. Es werden weiterhin berechnete Werte hinzugefügt, als Readings angelegt und auch im Hauptspeicher gehalten. Weiterhin werden Daten zum RolloAktor übertragen und dessen Readings gespeichert, wie z.B. level. Da die Jalousie als Hardware körperlich nicht existiert, wird sie als Software nachgebildet, damit Du irgendwann einmal den Öffnungsgrad der Jalousie und den Drehwinkel direkt eingeben kannst.
Die Programmmodule 10_HM485.pm, das 00_HM485_LAN.pm, communication.pm, configurationManager.pm ... beziehen sich auf hardwareseitig wirklich, körperlich existierende  Geräte. Deshalb können diese auch in den Eeprom der Geräte schreiben oder von dort lesen.
Ich hoffe das hilft Dir?

Gruß gevoo

[Thorsten Pferdekaemper]

Hi,
ich vermute mal, dass 90_Jalousie.pm sowas macht wie "setreading <rolloaktor-kanal> Winkel <winkel>".
Man kann in FHEM praktisch von überall Readings in praktisch jedem Device setzen.
Gruß,
  Thorsten