Homematic wired

[hglaser]

hallo gevoo

Manche Eigenschaften sind mit true hinterlegt aber entsprechen trotzdem einer 0x0.

Hast Du da ein Beispiel ? Bei welchen Eigenschaften meinst Du kommt das vor?

lg Harald

[gevoo]

Hallo Harald,

z.B:

Code Auswählen Erweitern

"logging" => {
"logical" => {
"option" => {
"off" => {},
"on" => {
"default" => true
}
},
"type" => "option"
},
...
Hier ist on = default aber im Eeeprom ist on = 0

Code Auswählen Erweitern

"input_type" => {
"logical" => {
"option" => {
"switch" => {},
"pushbutton" => {
"default" => true
}
},
"type" => "option"
},
...
Hier ist pushbutton = default aber im Eeprom ist pushbutton = 1

Von den zahlreichen anderen Optionen bei den events ganz abgesehen. Da wird es noch komplizierter.
Das wollte ich als nächstes in Angriff nehmen, scheitere aber an genanntem Problem.

Gruß gevoo

[Ralf9]

Beim HMW_IO_12_FM scheint es beim "behaviour" auch nicht ganz zu passen.

Code Auswählen Erweitern


"behaviour" => {
"logical" => {
"option" => {
"input" => {
"default" => true
},
"output" => {}
},
"type" => "option"
},
"physical" => {
"interface" => "internal",
"type" => "integer",
"value_id" => "behaviour"
},
"ui_flags" => "transform"


Hier ist "input" => "default" => true,  aber im Eeprom ist 1 = output

Ich habe Kanal 1 - 6 als output konfiguriert und im Eeprom steht 3F00

Code Auswählen Erweitern


.eeprom_0000 FF0A00000001FE3F00030A030A030A03



Was macht eigentlich das logging? Wie kann ich erkennen ob bei einem Kanal das logging eingeschaltet ist?

Gruß Ralf

[Thorsten Pferdekaemper]

Hi,
das mit dem true ist ja eigentlich default = "true". D.h. die entsprechende Option ist der Default. Das heißt nicht, dass die Option selbst irgend einem bestimmten Wert entspricht. Es bedeutet, dass wenn kein Wert gesetzt ist, dann wird die Option angenommen, bei der das steht. Im EEPROM bedeutet das, dass dort 0xFF steht. ...oder je nach Länge eben 0xFFFF etc.
Also z.B.: 0 -> off, 200 -> on, 255 -> on oder off, je nachdem wo das default = "true" steht.
Gruß,
   Thorsten

[hglaser]

Hi Thorsten

Ja, da hast du sicher recht. Was ist nun mit

Code Auswählen Erweitern

"long_jt_off" => {
"logical" => {
    "option" => {
"no_jump_ignore_command" => {},
"off" => {},
"offdelay" => {},
"on" => {},
"ondelay" => {
"default" => true
}
},
"type" => "option"
},
"physical" => {
"address" => {
     "index" => 26.9
},
"endian" => "little",
"interface" => "eeprom",
"read_size" => 2,
"size" => 0.3,
"type" => "integer"
}
das default ondelay ist, da sind wir uns einig, die Frage ist nun, wie stelle ich mir die anderen Werte vor?, insbesondere in einem Hash, in dem ja denke ich mal, optionen nicht immer in der Selben Reihenfolge sind, keine Sortierung habe. Also wenn die Reihenfolge dahinter steckt, müsste das wohl in ein Array oder sehe ich das falsch.

[hglaser]

Hallo gevoo

Hier ist on = default aber im Eeeprom ist on = 0

bist du sicher?
wenn wir jetzt vom gleichen sprechen ist dieses logging auf index 0 und hat eine size von 0.1
Das bedeutet also es ist ein bit und es steht an 0ter also letzter Stelle. Somit wäre also
00000001 on und
00000000 off, und so stehts im eeprom:
FF = 11111111 (logging on)
FE = 11111110 (logging off)
die anderen bits zB das 2. von hinten wäre z.B input_locked also
FD = 11111101 (input_locked on)
FF = 11111111 (input_locked off) das ist übrigens ein ganz gemeines Beispiel, da hier in der conversion ein "invert => true" steht es also nochmal umgedreht werden muss

lg Harald

[Thorsten Pferdekaemper]

das default ondelay ist, da sind wir uns einig, die Frage ist nun, wie stelle ich mir die anderen Werte vor?, insbesondere in einem Hash, in dem ja denke ich mal, optionen nicht immer in der Selben Reihenfolge sind, keine Sortierung habe. Also wenn die Reihenfolge dahinter steckt, müsste das wohl in ein Array oder sehe ich das falsch.

Hi,

das Problem könnte sein, dass es glaube ich auch Fälle gibt, wo die Werte im XML explizit drinstehen. Dann klappt das mit dem Array nicht. Ich denke, man sollte da schon einen Hash benutzen und dann halt die Werte eintragen. D.h. wenn im XML keine stehen, dann halt mit 0 beginnend durchnummerieren.
Ich bin da aber auch nicht so ganz sicher.

Ich glaube auch, dass man beim Schreiben von Werten, die sich ein Byte teilen, ganz stark aufpassen muss. Wenn ein Byte 0xFF hat, dann bedeutet das erstmal "leer". Wenn man jetzt z.B. Bit 0 schreibt, dann muss man glaube ich alle anderen Bits auch setzen und zwar so, dass sie dem Default-Wert entsprechen.

Gruß,
   Thorsten

[hglaser]

Hi Thorsten

dann halt mit 0 beginnend durchnummerieren. Ich bin da aber auch nicht so ganz sicher.

Tja Ich werds wohl bei Gelegenheit durchprobieren. Aber die Idee ist mit dem Durchnummerieren find ich eine gute Lösung. dann würde sich gevoo diese blöde optionref.pm sparen können, dafür halt den xmlHelper umschreiben müssen .

dann muss man glaube ich alle anderen Bits auch setzen und zwar so, dass sie dem Default-Wert entsprechen.

Nun ich hoffe die haben sich was dabei gedacht und die default bit-Werte sind alle 1, Bisher ist mir noch kein so ein Fall aufgefallen, aber Du hast recht, das könnte noch eine Falle werden.

lg Harald

[gevoo]

Hi,

die neue Version ist auch für unbekannte Geräte geeignet. Ich habe, soweit die Tests abgeschlossen waren, die Hardcodierungen herausgenommen. In den anderen Fällen ist ein "Bypass" für unbekannte Geräte vorhanden.
Die zusätzlichen logs sind abgeschaltet, so daß diese Version für git-master geeignet wäre.

Grüße gevoo

[Thorsten Pferdekaemper]

Die zusätzlichen logs sind abgeschaltet, so daß diese Version für git-master geeignet wäre.

Hi,
ich habe jetzt die neue Version hochgeladen und dev mit master gemerged. D.h. den dev-Branch gibt es jetzt vorerst nicht mehr. Bugfixes machen wir erstmal direkt in master, denke ich. Wenn es was neues gibt, was erstmal experimentell ist, dann mache ich dev wieder auf.

@gevoo: Ich würde in Zukunft gerne die Datei HEM-HM485\FHEM\lib\HM485\readme.txt aktuell halten, von wegen Versionsangabe und History. Könntest Du die Datei auf dem neusten Stand halten oder aus Deinem .zip rauswerfen, damit sie nicht jedesmal überschrieben wird?

Gruß,
   Thorsten

[hglaser]

Hallo gevoo

Du bist ja fleissig.
Ich habs mir mal im github angesehen und mir ist natürlich sofort wieder was aufgefallen
im 10_HM485.pm unter HM_Set steht:

Code Auswählen Erweitern

} elsif ( $cmd eq 'level') {
if ( uc( $deviceKey) eq 'HMW_LC_BL1_DR' or uc( $deviceKey) eq 'HMW_LC_DIM1L_DR') {
$value = $value / 100;
#HM485::Util::logger( 'HM485_Set', 3, 'set ' . $name . ' level ' . $value);
}
$msg = HM485_SetChannelState($hash, $cmd, $value);
Wieder Blind und Dimmer. ich würde folgendes vorschlagen:

Warum entfernst Du das if nicht einfach und lässt es "HM485_SetChannelState" machen. Diese Routine ruft ja "valueToState" auf und in der sub valueToState ist ja schon alles wunderschön verfügbar. Da könnte man die 100% abfragen. Also sowas wie:

Code Auswählen Erweitern

sub valueToState($$$$) {
my ($chType, $valueHash, $valueKey, $value) = @_;

#da FHEM von 0 - 100 schickt und HMW 0-1
if (exists $valueHash->{'logical'}{'unit'} &&
$valueHash->{'logical'}{'unit'} eq '100%') {
$value = $value / 100;
}

my $factor = $valueHash->{'conversion'}{'factor'} ? int($valueHash->{'conversion'}{'factor'}) : 1;
my $state = int($value * $factor);
return $state;
}oder so ähnlich. Könnte man natürlich ausbauen, aber dann würde denke ich, auch der 4-fach Dimmer mit dem sich björn in einem anderen Thread herumschlägt zumindest schon mal den Slider richtig anzeigen. Ich finde man sollte, wenn möglich alles aus den xml-pm files rausholen wenns geht.
Edit: In umgekehrter Richtung gehts glaub ich mit ValueToControl, weiss ich jetzt nicht genau.

Grüße Harald

[gevoo]

Hallo Harald,

danke für Deinen Vorschlag, ich habe ihn entsprechend eingearbeitet, weil das echt Sinn macht.

dann würde denke ich, auch der 4-fach Dimmer mit dem sich björn in einem anderen Thread herumschlägt zumindest schon mal den Slider richtig anzeigen

Das glaube ich nicht, denn der hat bestimmt einen anderen Namen und damit nimmt er automatisch den "Bypass".

Bin noch bei weiteren Optimierungen, die dann in der nächsten Version kommen.

Grüße gevoo

[hglaser]

hallo

Ich bin gerade beim herumspielen, und versuche die Peeringadressen irgendwohin zu packen. Wo gehören die denn nun eigentlich hin? Ich hab sie mal in die Internals gepackt, aber ich hätte gerne, daß man sie anklicken kann. gibts da FHEM-intern irgend einen Funktion die das auch mit DEF Nummern kann, oder geht es nur mit dem "device" Namen?

lg Harald

[gevoo]

Hallo,

die nächste Version ist fertig. Ich habe noch einige Sachen optimiert und den Einsatz unbekannter Geräte verbessert.

@Thorsten: Die readme.txt habe ich aktuallisiert.

Damit es jetzt einen richtigen Schritt nach vorn geht, bräuchte ich mal jemanden, der den HMW_IO12_SW14_DR mit
Channel = analog_input und
Channel = frequency
testet.

Grüße gevoo

[hglaser]

hallo gevoo

Tja den hätt ich eigentlich schon fertig, ist auf meinem github. Da du aber auf meine private Mitteilung bis jetzt nicht geantwortet hast, gehe ich davon aus, daß Du ihn lieber selber entwickeln willst. Daher werde ich mich hier wohl langsam ausklinken und nur mehr ab und zu mitlesen. Ich könnte Dir allerdings einen Internet-Zugang zu meinem Eintwicklungs-Rasperry anbieten, da hängt so ein HMW_IO12_SW14 mit einem aktivierten analog_input drann, den brauch ich zur Zeit noch nicht.

lg Harald