Homematic wired

[Jojo11]

Hallo,

kurze Frage: Gibt es eine einfache Möglichkeit, die im frontend angezeigte Lampe z.B. bei den Schaltausgängen des HMW_IO_12_Sw7_DR klickbar zu machen (für on/off)?

Code Auswählen Erweitern

webCmd on:off hilft nicht.

schöne Grüße
Jo

[RoBra81]

Ja, mit devStateIcon:

Code Auswählen Erweitern

attr xxx devStateIcon on:on:off off:off:on

Ronny

[Jojo11]

Danke, hat geklappt 

schöne Grüße
Jo

[hglaser]

Hallo Gevoo

Wie ich ja schon hier http://forum.fhem.de/index.php/topic,10607.msg266700.html#msg266700 vor einiger Zeit geschrieben hatte, Du daß aber wohl falsch verstanden hattest, habe ich mir das ganze noch einmal genauer angeschaut. Wenn ein EEprom Wert über zwei Zeilen im DeviceHash gespeichert wird, stimmt das Auslesen der Werte im "sub getRawEEpromData($;$$$$)" nicht. (spätestens beim Peering-Werte auslesen im IO12Sw7 kommt das vor: Addr 0x2d ein size 4 Wert).

Code Auswählen Erweitern

my $retVal = '';
for ($blockCount = $blockStart; $blockCount < (ceil($addrMax / $blockLen)); $blockCount++) { # von 0 bis 64
my $blockId = sprintf ('.eeprom_%04X' , ($blockCount * $blockLen));
# HM485::Util::HM485_Log( 'Device:getRawEEpromData blockId = ' . $blockId);
if ($devHash->{READINGS}{$blockId}{VAL}) {
$retVal.= $devHash->{READINGS}{$blockId}{VAL};
# HM485::Util::HM485_Log( 'Device:getRawEEpromData Reading = ' . $devHash->{READINGS}{$blockId}{VAL});
} else {
$retVal = 'FF' x $blockLen;
# HM485::Util::HM485_Log( 'Device:getRawEEpromData Reading = nicht vorh.');
}

if (length($retVal) / 2 >= $len) {
last;
}
}
Hier stimmt die untere if Zeile nicht, da die Länge des $retVal bei einer Zeile 32 ist und $len höchstens 4 ist (bei Addressen), wird nie die nächste Zeile angehängt.

Ich habe es nun So gelöst:

Code Auswählen Erweitern

if (length($retVal) / 2 >= $start - $blockStart * $blockLen + $len) {
last;
}
Auch das "ceil" in der for Schleife finde ich nutzlos, da "$addrMax / $blockLen" immer 64 ist.

Grüße Harald

[gevoo]

Hallo Harald,

danke für Deinen Vorschlag. Habe ich übernommen und noch einige Verbesserungen beigefügt. Möchtest Du die Version einmal mit dem IO12Sw7 testen?

Gruß gevoo

[Jojo11]

Hallo,

nachdem der HMW_Sen_SC_12_DR jetzt gut funktioniert, verzweifle ich gerade an einem watchdog zu dessen Abfrage. Im event-Monitor erscheint Folgendes:

Code Auswählen Erweitern


2015-04-12 19:30:52.079 HM485 HMW_SC_12_01 SENSOR: on

Mein watchdog (bzw. die regexp) funktioniert aber leider nicht. Getestet habe ich folgende Kombinationen:

Code Auswählen Erweitern


HMW_SC_12_01.*:on
HMW_SC_12_01.STATE:on
HMW_SC_12_01.SENSOR:on
HM485.HMW_SC_12_01.*:on


Hat jemand evtl. den entscheidenden Hinweis für mich? Danke!

schöne Grüße
Jo

[hglaser]

Hallo Gevoo

Ich wollte es gerade probieren und sehe, daß der hm485d wieder einmal nicht startet. Auch diesen Fehler hatte ich bereits Hier http://forum.fhem.de/index.php/topic,10607.msg277293.html#msg277293 gepostet. Also erst einmal wieder das Komma gegen einen Doppelpunkt geändert und schon Startet der hm485d mit dem eingestellten Port.
Auf der Konsole erscheint ein

Code Auswählen Erweitern

root@testfhem:/home/pi# dUsing a hash as a reference is deprecated at FHEM/lib/HM485/ConfigurationManager.pm line 118, <$fh> line 40.
Using a hash as a reference is deprecated at FHEM/lib/HM485/ConfigurationManager.pm line 123, <$fh> line 40.
Nun zum Test: Beim IO12SW7 stimmen die Schaltzustände und auch switch, puschbutton und logging in der Configuration. Ich habe bisher keine Fehler finden können.
Beim Dimmer stimmt soweit auch alles bis auf das logging in der Configuration. Zeigt off an, sollte aber on sein. Es gibt  "in sub getValueFromEepromData($$$$;$)"

Code Auswählen Erweitern

$retVal = dataConversion($eepromValue, $configHash->{conversion}, 'from_device');. Wird das berücksichtigt ? (Es funktioniert übrigens nicht, wenn $wholeByte = 1 gesetzt ist)  Ich glaube mich zu erinnern, daß ich das auch einmal gesucht habe. Bin mir aber nicht mehr sicher.

Ich würde sagen, Dimmer und IO12SW7 funktionieren soweit ganz gut.

Viele Grüße Harald

[hglaser]

Code Auswählen Erweitern


HMW_SC_12_01.*:on
HMW_SC_12_01.STATE:on
HMW_SC_12_01.SENSOR:on
HM485.HMW_SC_12_01.*:on


Code Auswählen Erweitern

HMW_SC_12_01.SENSOR:.on?
gehört aber wohl eher nicht hierher.
lg harald

[Thorsten Pferdekaemper]

Hi,
die Version von heute ist jetzt auch im git (https://github.com/kc-GitHub/FHEM-HM485/tree/dev).

Ich habe inzwischen gelernt, dass anscheinend einige Devices z.B. in der 10_HM485.pm hardcodiert sind. Das macht uns natürlich Probleme beim Entwickeln der Homebrew-Geräte. Wäre es möglich, das langsam so umzustellen, dass nur die Informationen aus dem XMLs (bzw. den daraus generierten pm-Dateien) benutzt werden?
Mir ist klar, dass das gar nicht so einfach ist, insbesondere wenn man nicht das schon funktionierende stören will. Ich denke aber, dass es längerfristig viel besser wäre.

Gruß,
   Thorsten

[Jojo11]

Code Auswählen Erweitern

HMW_SC_12_01.SENSOR:.on?
gehört aber wohl eher nicht hierher.
lg harald

Danke, hat funktioniert.
Da sich das room-Atttribut nicht wie gewohnt setzen lässt (s.o.) hatte ich vermutet, dass es hierbei evtl. auch eine Besonderheit geben könnte. Daher mein post in diesem Unterforum.

schöne Grüße
Jo

[gevoo]

Hallo Harald,

Beim Dimmer stimmt soweit auch alles bis auf das logging in der Configuration. Zeigt off an, sollte aber on sein.

Hast Du auch die Datei optionref.pm eingespielt?

Also erst einmal wieder das Komma gegen einen Doppelpunkt geändert und schon Startet der hm485d mit dem eingestellten Port.

Ist mir durch die Lappen gegangen. Kommt bei der nächsten Version mit.

Es funktioniert übrigens nicht, wenn $wholeByte = 1 gesetzt ist

Ich habe den Fall noch nicht gefunden, bei dem size < 1 ist und wholebyte = 1. Im Übrigen wird dann auch ein Byte gelesen.

Grüße gevoo

[gevoo]

Hallo Thorsten,

Wäre es möglich, das langsam so umzustellen, dass nur die Informationen aus dem XMLs (bzw. den daraus generierten pm-Dateien) benutzt werden?

Ja auf jeden Fall. Einige Rudimente werden aber bleiben, da Informationen in der Config fehlen.

Gruß gevoo

[Thorsten Pferdekaemper]

Ja auf jeden Fall. Einige Rudimente werden aber bleiben, da Informationen in der Config fehlen.

Ich dachte, dass mit den XMLs alles gesagt wäre. Zumindest scheint das die CCU so zu sehen.
Welche Informationen, die nicht in den XMLs sind, brauchst Du denn?
Gruß,
   Thorsten

[hglaser]

hallo gevoo

Ich habe den Fall noch nicht gefunden, bei dem size < 1 ist und wholebyte = 1. Im Übrigen wird dann auch ein Byte gelesen.

stimmt , nur ein byte. Ich dachte halt nur, da das ganze beim zurückschreiben ins eeprom von solchen bits wie "logging" oder "input_type" zum tragen, kommt und wenn man z.B 0xFE oder 0xFD zurück schreiben muss, dann macht dieses "dataConversion" im  "sub getValueFromEepromData" Müll" daraus. Wenn also die "sub convertSettingsToEepromData" diese Daten aus dem eeprom ausliest (hier ist wholebyte gesetzt), dann liest es hier "0x0" aus anstatt z.b. "0xFD". somit funktioniert das bitgeschupse nicht richtig. Du hast es so gelöst, daß Du alles noch einmal in der sub convertSettingsToEepromData neu berechnest, anstatt nur das bit zu setzten. Ist natürlich auch eine Möglichkeit. Einfacher wäre es jedoch, wenn Du in "getValueFromEepromData" einfach ein:

Code Auswählen Erweitern


if ($wholeByte == 0) {
$retVal = dataConversion($eepromValue, $configHash->{'conversion'}, 'from_device');
$default = $configHash->{'logical'}{'default'};
} else { #dataConversion bei mehreren gesetzten bits ist wohl sinnlos kommt null raus
#auch ein default Value bringt teilweise nur unsinn in solchen fällen Richtig ???
$retVal = $eepromValue;
}
einfügst.

Hast Du auch die Datei optionref.pm eingespielt?

Ja habe ich. Das ist übrigens auch so ein Fall, der mir persönlich überhaupt nicht gefällt. Das ganze könnte man aus dem devicexml.pm auslesen: Hier steht ja schon welche der Option "true" ist.

Code Auswählen Erweitern

<parameter id="LOGGING"><logical type="option"><option id="OFF"/><option id="ON" default="true"/></logical>
Interessant wirds erst wenn es mehr als zwei Optionen gibt. Hier müsste man sich wohl überlegen, wie man das in einem Hash sortiert. Das wäre dann wohl was für den xmlHelper.

lg Harald

[gevoo]

Hallo Harald,

danke für Deine Mühe. Werde ich überprüfen und einarbeiten.

Ja habe ich. Das ist übrigens auch so ein Fall, der mir persönlich überhaupt nicht gefällt. Das ganze könnte man aus dem devicexml.pm auslesen: Hier steht ja schon welche der Option "true" ist.

Ja dachte ich auch. Das stimmt aber nicht. Manche Eigenschaften sind mit true hinterlegt aber entsprechen trotzdem einer 0x0. Genau da liegt das Problem.
Wenn Du einen Lösungsvorschlag hast, dann immer her damit.

Grüße gevoo