[HM-Wired] Vereinigung der Versionen "honk" und "gevoo/thorsten"

[Thorsten Pferdekaemper]

Ich habe gerade ein HBW Device aktiviert und natürlich vergessen die dazugehörige device.pm ins Devices Verzeichniß zu kopieren. (ich würde vorschlagen, Deine HBW_device.pms aus dem github zu löschen).

Das war ein Versehen, ich habe sie inzwischen gelöscht.

Nun legt FHEM ein "HMW_Generic_HBW4073471" an. Das gefällt mir . Das Problem ist, daß nun scheinbar auf irgendetwas gewartet wird.

Code Auswählen Erweitern

2015.08.03 19:08:50 3: HM485: Warte auf Initialisierung Gateway
2015.08.03 19:08:55 3: HM485: Warte auf Initialisierung Gateway
2015.08.03 19:09:00 3: HM485: Warte auf Initialisierung Gateway
2015.08.03 19:09:05 3: HM485: Warte auf Initialisierung Gateway
2015.08.03 19:09:10 3: HM485: Warte auf Initialisierung Gateway
2015.08.03 19:09:15 3: HM485: Warte auf Initialisierung Gateway
......

Ich musste das "HMW_Generic_HBW4073471" löschen und neu starten. Dann war Ruhe.

Ich habe das gerade mal selbst ausprobiert und konnte das Problem nicht nachvollziehen. Bei mir wird sauber ein "generic" Device angelegt und es erscheint nichts verdächtiges im Log. Kannst Du das reproduzieren?

Was hat es denn mit diesem Generic Device auf sich? Was könnte ich den damit anstellen wenn es geht ?

Du kannst im Wesentlichen raw-Kommandos schicken. Das ist ganz nützlich, wenn man ein Homebrew-Device entwickelt und sich erstmal nicht mit dem XML/device.pm befassen will. Man kann damit sogar Devices steuern, die sich als HMW-Devices ausgeben, aber sich nicht an die normale Semantik halten.
Man kann inzwischen übrigens auch raw-Kommandos vom Device aus schicken. Also sowas wie

Code Auswählen Erweitern


set HMW_Generic_HBW4073471 raw 7802A0

...würde Kanal 03 (in FHEM-Zählung) auf 0xA0 setzen.
Ich habe das eingebaut, weil der bisher existierende RAW-Befehl etwas unhandlich war. Insbesondere kennt man ja die Sende-/Empfangsfolgenummer nicht.
Gruß,
   Thorsten

[Ralf9]

Hi,
ich bin nicht ganz Deiner Meinung, aber ich denke, dass das Thema tatsächlich noch etwas Aufmerksamkeit verdient. Mal sehen, ob wir zu einer Lösung kommen können, die für alle gut ist.

Ja, das wird wahrscheinlich nicht einfach eine Lösung zu finden, die für alle passt. Dies wird nur durch einstell möglichkeiten bei der getconfig und Response timeout Behandlung möglich sein.

   1 - ATSTARTUP, d.h. nur beim Start von FHEM. Wenn es einmal erfolgreich war, dann nie wieder. Das ist für Geräte, die planmäßig nicht immer am Bus sind.

Diese Option würde mir erst mal reichen. Es muß nicht pro Modul einstellbar sein, allgemein für alle Module reicht auch. Dies bedeuted dann, dass nach einem erfolgreichen Start auf Response Timeout nicht mehr reagiert wird.
Wie kann ich erkennen, daß beim Start alle Module erfolgreich geladen wurden?

3. Ein Fehler in der Software (FHEM). In dem Fall sollten wir den Fehler beheben. Kannst Du das Problem sicher reproduzieren? Wenn ja, dann würde ich es gerne analysieren.

Das Response timeout ist durch einen Programmierfehler in meinem Modul enstanden. Bei einem Kommando wurde kein Response zurückgeschickt.

Gruß Ralf

[stephan-221]

Hallo Ralf,

Wie kann ich erkennen, daß beim Start alle Module erfolgreich geladen wurden?

Durch einen Blick aufs Device:

Code Auswählen Erweitern

CONFIG_STATUS     OK

Viele Grüße
Stephan

[Ralf9]

mir ist aufgefallen, daß durch die übernahme der "sub getFrameInfos" von der Version von honk, meine änderung der sub getFrameInfos nicht mehr drin ist
http://forum.fhem.de/index.php/topic,39235.msg316164.html#msg316164

Gruß Ralf

[Thorsten Pferdekaemper]

mir ist aufgefallen, daß durch die übernahme der "sub getFrameInfos" von der Version von honk, meine änderung der sub getFrameInfos nicht mehr drin ist
http://forum.fhem.de/index.php/topic,39235.msg316164.html#msg316164

Hi,
ich habe mir das gerade angeschaut. Soweit ich das Coding verstehe, ist das auch nicht mehr nötig. Das Coding sucht sich den Frame Type, der zum gesendeten Frame passt. Hast Du es ausprobiert?
(Möglicherweise fehlt da etwas bezüglich const_value, aber das ist eine andere Geschichte.)
Gruß,
  Thorsten

[Thorsten Pferdekaemper]

Hi,
nach einem Peering musste man get config all machen, um das Peering korrekt zu sehen bzw. es bearbeiten zu können. Das ist mit Version 0.7.7 korrigiert.
Möglicherweise gab es ähnliche Effekte auch bei anderen Konfigurationen, die damit auch gelöst werden.
Gruß,
   Thorsten

[Ralf9]

ich habe mir das gerade angeschaut. Soweit ich das Coding verstehe, ist das auch nicht mehr nötig. Das Coding sucht sich den Frame Type, der zum gesendeten Frame passt. Hast Du es ausprobiert?

Ich habe es ausprobiert, wie zu erwarten funktioniert es damit nicht, wenn es mehrere Info_level mit verschiedenen sizes gibt.
In meinem Fall gibt es einen normalen Info_level mit size = 1.0 und einen weiteren Info_level2 mit size = 2.0

Ich habe die "sub getFrameInfos" umgeschrieben, damit funktioniert es bei mir.
Info_level 0x69 und key 0x4b werden getrennt behandelt.
Ich habe es so erweitert, daß beim Info_level der "frameTypeName" ermittelt und dann mit $frames verglichen wird.

Mir ist dabei nicht klar zu was diese beiden Codeteile gut sind:

Code Auswählen Erweitern

# Todo we rewrite the new configuration to the old one
my $replace = convertFrameIndexToHash( $frames->{$frame}{'parameter'});
delete ($frames->{$frame}{'parameter'});
$frames->{$frame}{'parameter'} = $replace;

Code Auswählen Erweitern


foreach my $pindex (keys %{$parameter}) { #Daten umstrukturieren
my $replace = $parameter->{$pindex}{'param'};
if (defined($replace)) {
$parameter->{$replace} = delete $parameter->{$pindex};
delete $parameter->{$replace}{'param'};
}
}
}


Die Änderung der state Behandlung in der "sub HM485_ChannelDoUpdate" hat bei mir nicht funktioniert. Ich habe die Änderung wieder zurückgenommen. Nun funktioniert es wieder.

Gruß Ralf

[Thorsten Pferdekaemper]

Ich habe es ausprobiert, wie zu erwarten funktioniert es damit nicht, wenn es mehrere Info_level mit verschiedenen sizes gibt.
In meinem Fall gibt es einen normalen Info_level mit size = 1.0 und einen weiteren Info_level2 mit size = 2.0

Ok, das sollte nicht sein.

Ich habe die "sub getFrameInfos" umgeschrieben, damit funktioniert es bei mir.

Ich wundere mich nur, warum das so ist. Worin unterscheiden sich denn die beiden Frames? Ich meine damit: Woran erkennt das System, welches der richtige ist? Könntest Du mal das zugehörige <device>.pm schicken, damit ich mir mal ein Bild machen kann?

Info_level 0x69 und key 0x4b werden getrennt behandelt.

Warum?

Ich habe es so erweitert, daß beim Info_level der "frameTypeName" ermittelt und dann mit $frames verglichen wird.

Es sieht mir aber so aus, als ob der frameTypeName nur aus dem Devicefile ermittelt wird und nicht wirklich aus den Daten des Frames. Funktioniert das wirklich auch für short press, long press und so?

Mir ist dabei nicht klar zu was diese beiden Codeteile gut sind:

Das ist zum Umwandeln der "alten" <device>.pm-Struktur in die neue. Wahrscheinlich könnte man das inzwischen weglassen.

Die Änderung der state Behandlung in der "sub HM485_ChannelDoUpdate" hat bei mir nicht funktioniert. Ich habe die Änderung wieder zurückgenommen. Nun funktioniert es wieder.

Seltsam. Bei honk und mir funktioniert das. Könntest Du mal genauer sagen, was nicht funktioniert?

Gruß,
   Thorsten

[Ralf9]

Worin unterscheiden sich denn die beiden Frames? Ich meine damit: Woran erkennt das System, welches der richtige ist?

Hier ist ein Auszug meines devicefiles

Code Auswählen Erweitern

'frames' => {
"info_level" => {
"channel_field" => 10,
"direction" => "from_device",
"event" => true,
"parameter" => {
"11.0" => {
"param" => "state",
"size" => 1.0,
"type" => "integer"
},
"12.4" => {
"param" => "state_flags",
"size" => 0.3,
"type" => "integer"
}
},
"type" => 0x69
},
"info_level2" => {
"channel_field" => 10,
"direction" => "from_device",
"event" => true,
"parameter" => {
"index" => 11.0,
"param" => "state",
"size" => 2.0,
"type" => "integer"
},
"type" => 0x69
},

In meinem Fall wird über den ermittelten $chTyp=analog unter "response" der "info_level2" ermittelt.
Die Info ob es sich um info_level oder info_level2 handelt, steckt nur im devicefile.

Code Auswählen Erweitern

"analog" => {
"count" => 4,
"index" => 21,
"paramset" => {
"link" => {},
"master" => {
"address_start" => 0x3B,
"address_step" => 2,
"parameter" => {
...
},
"type" => "master"
},
"values" => {
"parameter" => {
"value" => {
"conversion" => {
"factor" => 10,
"type" => "float_integer_scale"
},
"id" => "value",
"logical" => {
"max" => "200.0",
"min" => "0.0",
"type" => "float",
},
"operations" => "read,event",
"physical" => {
"event" => {
"frame" => "info_level2"
},
"get" => {
"request" => "level_get",
"response" => "info_level2"
},
"interface" => "command",
"type" => "integer",
"value_id" => "state"
}
}
},
"type" => "values"

Es sieht mir aber so aus, als ob der frameTypeName nur aus dem Devicefile ermittelt wird und nicht wirklich aus den Daten des Frames. Funktioniert das wirklich auch für short press, long press und so?

Die Info_level 0x69 und key 0x4b werden getrennt behandelt damit es auch mit dem short press, long press und so funktioniert.

Seltsam. Bei honk und mir funktioniert das. Könntest Du mal genauer sagen, was nicht funktioniert?

Im Event monitor wurden die short press, long press doppelt angezeigt und bei dem 'door_sensor.state' wurde der state nicht aktualisiert.

Gruß Ralf

[Thorsten Pferdekaemper]

In meinem Fall wird über den ermittelten $chTyp=analog unter "response" der "info_level2" ermittelt.
Die Info ob es sich um info_level oder info_level2 handelt, steckt nur im devicefile.

Jetzt habe ich's kapiert. Du hast einfach verschiedene Kanäle. Manche liefern info_level, andere liefern info_level2.
Ich würde das einbauen, habe aber dazu noch Fragen:
1. Warum benutzt Du physical/get/Response und nicht physical/event/Frame ? Du weißt ja nicht, ob das Device die 0x69-Nachricht als Antwort schickt oder einfach so. Müsste man da nicht unterscheiden?
2. Bei einigen Devices stehen unter channels/<channeltype>/paramset/values/parameter/ mehrere Einträge. Theoretisch könnte man das auch für Kanäle machen, die kein 0x4B, sodern 0x69 liefern. Dann müsste man wieder nach const_value unterscheiden. Hast Du das absichtlich ignoriert?
3. Das mit dem behaviour könnte auch noch dazwischen funken. Beim HMW_IO12_SW14_DR steht für manche Kanäle als Frame Type "infi_frequency". Je nach "behaviour" scheint aber trotzdem info_level gesendet zu werden. Deine Version beachtet das nicht, oder?

Im Event monitor wurden die short press, long press doppelt angezeigt

Ich nehme mal an, dass Du so etwas siehst:

Code Auswählen Erweitern


2015-08-06 22:15:39 HM485 HMW_LC_Sw2_DR_KEQ1056682_01 press_short: 56
2015-08-06 22:15:39 HM485 HMW_LC_Sw2_DR_KEQ1056682_01 press_short_56

Wenn Du genau hinsiehst, dann sollte Dir auffallen, dass die Zeilen unterschiedlich sind. Die erste Zeile ist das Event, das vom Reading "press_short" ausgelöst wird. Die zweite Zeile ist das Event, das vom Reading "state" ausgelöst wird.
Ich dachte auch erst, dass "state" keine Events auslösen sollte, aber ich glaube, dass das andere Module auch so machen.

und bei dem 'door_sensor.state' wurde der state nicht aktualisiert.

Das ist seltsam. Ich kann das selbst nicht testen, da ich kein solches Device habe. Wenn ich mir das ganze im Coding betrachte, dann scheint das aber sehr ähnlich zu switch.state zu sein und da funktioniert es bei mir.
...oder meinst Du vielleicht STATE (und nicht state) auf dem Frontend?

Gruß,
   Thorsten

[Ralf9]

1. Warum benutzt Du physical/get/Response und nicht physical/event/Frame ? Du weißt ja nicht, ob das Device die 0x69-Nachricht als Antwort schickt oder einfach so. Müsste man da nicht unterscheiden?

das mit dem response habe ich aus der Routine von gevoo übernommen und habe es verallgemeinert. event und response haben normalerweise immer den selben info_level, oder ist Dir ein Modul bekannt wo dies nicht der Fall ist.

Code Auswählen Erweitern


my $frameTypeName  = getValueFromDefinitions( $deviceKey . '/channels/' . $chTyp . '/paramset/values/parameter/frequency/physical/get/response');


2. Bei einigen Devices stehen unter channels/<channeltype>/paramset/values/parameter/ mehrere Einträge. Theoretisch könnte man das auch für Kanäle machen, die kein 0x4B, sodern 0x69 liefern. Dann müsste man wieder nach const_value unterscheiden. Hast Du das absichtlich ignoriert?

Mir ist nicht ganz klar was Du damit meinst?

3. Das mit dem behaviour könnte auch noch dazwischen funken. Beim HMW_IO12_SW14_DR steht für manche Kanäle als Frame Type "infi_frequency". Je nach "behaviour" scheint aber trotzdem info_level gesendet zu werden. Deine Version beachtet das nicht, oder?

Bei HMW_IO12_SW14_DR gibt es eine Ausnahme wo es nicht passt, dafür gibt es die folgende Abfrage.

Code Auswählen Erweitern

if ( $frameTypeName eq "info_frequency" && $behaviour eq "digital_input") {
$frameTypeName = "info_level";
}

Ich nehme mal an, dass Du so etwas siehst:

Code Auswählen Erweitern


2015-08-06 22:15:39 HM485 HMW_LC_Sw2_DR_KEQ1056682_01 press_short: 56
2015-08-06 22:15:39 HM485 HMW_LC_Sw2_DR_KEQ1056682_01 press_short_56

Wenn Du genau hinsiehst, dann sollte Dir auffallen, dass die Zeilen unterschiedlich sind. Die erste Zeile ist das Event, das vom Reading "press_short" ausgelöst wird. Die zweite Zeile ist das Event, das vom Reading "state" ausgelöst wird.

Wozu wird beim "press_short/long" ein state benötigt, hat dies irgendwelche Vorteile?

Gruß Ralf

[Ralf9]

In der sub HM485_ProcessEepromData gibt es ein "{'.helper'}{'firsttime'}" ich habe Probleme mit dem Nachvollziehen wie dies funktionieren soll. Ich habe das {'.helper'}{'firsttime'} sonst nirgends gefunden.

Code Auswählen Erweitern

sub HM485_ProcessEepromData($$$) {
my ($hash, $requestData, $eepromData) = @_;
my $name = $hash->{NAME};
my $adr = substr($requestData, 0, 4);
if (ref $hash->{'.helper'}{'firsttime'} eq 'HASH') {
if (keys %{$hash->{'.helper'}{'firsttime'}} == 0) {
Log3 ($name, 3, "Request Eeprom data finished");
delete $hash->{'.helper'}{'firsttime'};
} else {
delete $hash->{'.helper'}{'firsttime'}{$adr};
}
}

Gruß Ralf

[Ralf9]

Ich habe auch mal kurz mein HMW_IO_12_FM getestet, dabei ist mir aufgefallen, daß bei den Kanälen die Config Option "logging" fehlt.
Kann es sein, daß bei der "sub getConfigSettings" dieser Spezialfall nicht berücksichtigt ist?

Code Auswählen Erweitern

"subconfig" => {
"link_roles" => {
"target" => {
"name" => "switch"
}
},
"paramset" => {
"hmw_io_ch_master" => {
"address_start" => 33,
"address_step" => 2,
"parameter" => {
"behaviour" => {
"logical" => {
"option" => [
{
"default" => true,
"id" => "input"
},
{
"id" => "output"
}
],
"type" => "option"
},
"physical" => {
"interface" => "internal",
"type" => "integer",
"value_id" => "behaviour"
},
"ui_flags" => "transform"
},
"logging" => {
"logical" => {
"option" => [
{
"id" => "off"
},
{
"default" => true,
"id" => "on"
}
],
"type" => "option"
},
"physical" => {
"address" => {
"index" => 0
},
"interface" => "eeprom",
"size" => 0.1,
"type" => "integer"
}
}
},
"type" => "master"
},
"hmw_switch_ch_link" => {
"address_start" => 0x39,
"address_step" => 28,

Gruß Ralf

[hglaser]

Hallo Ralf

Ich habe auch mal kurz mein HMW_IO_12_FM getestet, dabei ist mir aufgefallen, daß bei den Kanälen die Config Option "logging" fehlt.

Ich habe auch einen HMW_IO_12_FM. logging gibts tatsächlich nicht. Habe ich glatt übersehen. Jetzt wird mir auch klar warum ich manchmal eine Rückmeldung bekomme und manchmal nicht. Wenn ih es richtig verstehe, gibts dieses logging nur, wenn der Kanal auf output gesetzt ist.

lg Harald

[Thorsten Pferdekaemper]

Hi,

In meinem Fall wird über den ermittelten $chTyp=analog unter "response" der "info_level2" ermittelt.
Die Info ob es sich um info_level oder info_level2 handelt, steckt nur im devicefile.

Das ist mit der aktuellen Version (0.7.9) unterstützt. Ich habe es allerdings etwas anders implementiert, in der Hoffnung damit noch ein paar weitere Eventualitäten abgedeckt zu haben. Kannst Du es mal ausprobieren?

Wozu wird beim "press_short/long" ein state benötigt, hat dies irgendwelche Vorteile?

Ich dachte, dass es "FHEM-Standard" ist, dass jeder Kanal ein Reading "state" hat.

In der sub HM485_ProcessEepromData gibt es ein "{'.helper'}{'firsttime'}" ich habe Probleme mit dem Nachvollziehen wie dies funktionieren soll. Ich habe das {'.helper'}{'firsttime'} sonst nirgends gefunden.

Das ist wohl ein Artefakt aus der Zeit vor meinen Queues. Ich hab's gelöscht (Version 0.7.10).

Ich habe auch einen HMW_IO_12_FM. logging gibts tatsächlich nicht. Habe ich glatt übersehen. Jetzt wird mir auch klar warum ich manchmal eine Rückmeldung bekomme und manchmal nicht. Wenn ih es richtig verstehe, gibts dieses logging nur, wenn der Kanal auf output gesetzt ist.

@honk: Könntest Du Dich damit befassen? Ich habe kein solches Device und mir ist nicht ganz klar, wie das mit dem behaviour zusammenhängt.

Noch was @Ralf9: Hat sich das mit dem 'door_sensor.state' erledigt?

Gruß,
   Thorsten