HM-LC-SW1-FM wird als HM-LC-SW2-FM erkannt

[gromit]

SUUPPEERR! Das wars, endlich gehts, wielen Dank!!! 

[gestein]

Hallo,

ich hatte die Zeilen manuell aus der fhem.cfg gelöscht.
Damit ging es dann ohne Probleme und ohne Fehlermdlungen.
Auch bei meinem Dimmer hatte ich das Problem, dass ich auch über die fhem.cfg gelöst habe.

Hauptsache es funktioniert nun für Dich.

lg, Gerhard

[sensorle]

Hallo,

ich habe das gleiche Problem.
Der letzte HM-LC-SW1-FM (mit FW 2.8 ) den ich mir vor kurzem gekauft hatte wird als HM-LC-SW2-FM erkannt.
Das sowohl unter FHEM, als auch mit der Konfigurations-SW von Homematic und dem HM USB Konfigurations-Adapter (HM-CFG-USB2).

Im Screenshot (siehe Anhang) von der Konfig-SW ist ein HM-LC_SW2-FM gezeigt mit zwei Kanälen (so wie es sein sollte).
Der Besagte HM-LC-SW1-FM wird sls SW2 mit nur mit einem Kanal angezeigt.

Bei mir funktioniert er soweit in FHEM. Einziges Problem - welches nicht weiter stört -  ist, dass ein

Code Auswählen Erweitern

set DEVICE getConfig
immer mit:

Code Auswählen Erweitern

RESPONSE TIMEOUT:RegisterRead
endet.

Scheint ein Problem mit der FW2.8 zu sein.

Gruß,
Jürgen.

[Pfriemler]

Mich beschleicht ja direkt der Verdacht, dass eQ3 neuerdings eine vollständig einheitliche Firmware auf die Dinger bügelt und es der CCU überlässt herauszufinden, ob der Schalter dann einen oder zwei Kanäle hat. Allerdings ist ja die Bezeichnung des Aktors dann auch falsch (SW2 statt SW1).
Wenn das so weitergeht, müssen wir Martin um eine ähnliche Automatik anbetteln...

@sensorle: lösche den zweiten Kanal in FHEM...

[sensorle]

Hi Pfriemler,

habe den zweiten Kanal gelöscht.
getConfig funktioniert jetzt ohne Fehlermeldung. Danke für den Tipp!

Die falsche Anzeige des HM-LC-SW1-FM bleibt natürlich.

Gruß,
Jürgen.

[sensorle]

Hallo,

mir ist eben aufgefallen, dass ich zwei Aktoren HM-LC-SW1-FM - ebenfalls - mit FW 2.8 habe, die sich richtig anmelden. Sowohl in FHEM, als auch in der Konfigurations-SW des USB-Konfigurators.
Evtl. also doch ein HW Defekt oder eine falsch konfigurierte HW?

[martinp876]

Das Model wird von FHEM (ausschliesslich) an der ModelID erkannt welche in der Config message übertragen wird. Ich kann die MID nicht selbst auslesen.

Die ModelID 0009 ist dem HM-LC-Sw2-FM zugewiesen.
Mit
get hm models -f LC-S
bekommst du die Model Typen mit ihren IDs.
Wenn sich ein Device nicht mit der entsprechenden ID meldet könnte ich einen Fehler gemacht haben (in diesem Fall nicht) oder eq3 hat es  nicht korrekt geflasht

[Pfriemler]

Martin, es darf als erwiesen gelten, dass einige dieser Aktoren (Sw1-FM und Sw2-FM) in letzter Zeit - und zwar kreuzweise - falsche mID liefern. Deine Erkennung arbeitet vermutlich korrekt, vermutlich hat eQ3 fehlerhaft geflasht.
Der von sensorle hier gezeigten Screenshot zeigt ja sogar eine Falschanmeldung im Konfigurator, wobei dieser aus irgendeinem Grund in der Lage ist, nicht existierende Kanäle selbständig auszublenden. So ein Test im Hintergrund kann erst nach gesicherter Kommunikation erfolgen. Wenn man hier aus FHEM heraus korrigierend eingreifen wöllte, müsste man nach - etwa im Rahmen eines configChecks getConfigs von den Kanälen anfordern, bei gesicherter Kommunikation mit Kanal 1 den Kanal 2 mehrmals probieren - und dann den Kanal 2 löschen. Welche Gefahren sich daraus ergeben, dürfte klar sein. Allenfalls könnte man den User fragen, ob er einen 1- oder 2-Kanaler verbaut hat, und die Löschung so - auf sein Risiko - anbieten - bzw. das Model sauber neukonfigurieren, d.h. mit einer anderen MID und allen entsprechenden Folgen (reiner Einkanaler Device/Switch).

[martinp876]

vermutlich hat eQ3 fehlerhaft geflasht.

korrekt. Kann ich erst einmal nichts machen.

in der Lage ist, nicht existierende Kanäle selbständig auszublenden.

gut möglich. Es gibt da weitere Infos im XML über die Anzahl der Kanäle. Die kann ich nicht auslesen.

Wenn man hier aus FHEM heraus korrigierend eingreifen wöllte, müsste man nach - etwa im Rahmen eines configChecks getConfigs von den Kanälen anfordern, bei gesicherter Kommunikation mit Kanal 1 den Kanal 2 mehrmals probieren - und dann den Kanal 2 löschen.

So weit korrekt. Allerdings will ich so einen workround nicht einbauen. Das ist sehr viel gebastel.... no!

CUL_HM speichert nicht die ModelID (MID) sondern das Model (besser lesbar, kein wirklicher Grund).
FHEM wird beim Empfang jeder Config msg die Konfiguration kompletieren, also fehlende Kanäle anlegen. Das werde ich auch nicht ändern.
Die saubere Lösung ist ein neues Attribut modelForce. Der gestresste Anwender kann hier einen Model-namen eintragen worauf hin die gelesene MID ignoriert wird. Das klappt dann immer.

Ist aber einiges an Umstellung, da die Basis geändert wird. Ich werde wohl bis morgen brauchen

[Pfriemler]

Die saubere Lösung ist ein neues Attribut modelForce. Der gestresste Anwender kann hier einen Model-namen eintragen worauf hin die gelesene MID ignoriert wird. Das klappt dann immer.
Ist aber einiges an Umstellung, da die Basis geändert wird. Ich werde wohl bis morgen brauchen

Alle Daumen hoch, das ist genau die richtige Lösung. Und sie darf auch viel länger brauchen...

[martinp876]

Strukturell kämpfe ich noch mit der wilden Struktur von fhem. Ich erinnere mich, dass model "ungefragt" von unterschiedlichen Modulen genutzt wird. Jetzt muss ich also Model ändern um konsistent zu bleiben. Dabei will ich aber den original Wert nicht verlieren.
Wie einfach wäre es mit einer saubren Interface struktur. Da könnte ich den wert einfach korrekt zusammen basteln.

Genug gejammert, ich feile noch etwas.

[sensorle]

Hallo Martin,

also mit

Code Auswählen Erweitern

get hminfo models -f LC-S
bekomme ich folgendes Resultat (siehe Screenshot)

die ID 0009 kommt vor.
Ich habe aber auch tatsächlich einen HM-LC-Sw2-FM im Einsatz.

In der Datei .dev auf meinem Win7 Rechner, die von der Konfigurator-SW angelegt wird sieht die erste Zeile übrigens so aus:
<device serial="OEQ2071909" type="HM-LC-Sw2-FM" address="0x65C6E2" aes_key_index="1" firmware_version="2.8" bidcos_interface="JEQ0700648" sysinfo="00800065C6E21EBB7E2800094F45513230373139303910010100">

ich vermute mal stark, dass die fett markierten Ziffern die ModulID ist - und damit eindeutig falsch.

Vielen Dank, dass du eine Lösung für dieses Fehler von eQ3 in FHEM in Aussicht stellst!   

PS:
Angelernt habe ich den Switch übrigens über die Seriennummer - also nicht über Tastendruck

[martinp876]

0009 ist das 2kanalige. 0004 ist das 1kanalige.
Die 0009 hast du korrekt erkannt

Die config message kommt auch bei pairserial. Hm..... gute Idee - könnte man evtl nutzen. Hätte ich auch drauf kommen können.

[martinp876]

Anbei die neue Version - mal zum Testen.
Top Level: Das Attribut modelForce überschreibt das Attribut model. Liegt der Bug vor muss man hier das korrekte Model eintragen.

Low Level:
Die Reconfig greift jetzt härter durch. Unbekannte Kanäle (nicht in der Config den Models) werden gelöscht.
Attribute model, subType und .mId sind von User nicht änderbar - und sollten es auch nicht.

Kollateral-Funktionen: Man kann ein Device simulieren. Legt man ein Device leer an kann man das Model setzen. Dann werden alle Kanäle angelegt. Man kann die regList einsehen alsoauch die cmdList.

Bitte prüfen, ob es hackt.

[Christoph Morrison]

Kollateral-Funktionen: Man kann ein Device simulieren. Legt man ein Device leer an kann man das Model setzen. Dann werden alle Kanäle angelegt. Man kann die regList einsehen alsoauch die cmdList.

Das ist eine super Idee. Endlich kann ich ein Test-System mit meinen HM-Devices anlegen ohne alles in Dummies wandeln zu müssen.