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

[Pfriemler]

Huh ... das ist spaßig! 
Meinen HM-LC-Sw2-FM als Sw1 zu redefinieren hat funktioniert. Ein Kanal weg, es schaltet weiterhin die 1.
Dann habe ich mal einen HM-LC-Sw4-DR draus gemacht. Vier Kanäle, bei drei und vier erwartungsgemäß MISSING_ACK.
Dann wieder einen HM-LC-Sw2-FM ...
Und nun habe ich ein Gerät mit model HM-LC-Sw2-FM, einen 1. Kanal mit model HM-LC-Sw2-FM und einen zweiten Kanal mit model HM-LC-Sw4-DR

Problem also: Das Model in den Kanälen wird nur aktualisiert, wenn der betreffende Kanal automatisch hinzugefügt wurde, aber nicht bei bestehenden. Kreuztest nach Restart: Ändert man den HM-LC-Sw2-FM in einen HM-LC-Sw1-FM, bleibt in seinem nun noch einzigen Kanal ein HM-LC-Sw2-FM als model stehen.

Und im übrigen halte ich modelForce in den Kanälen für überflüssig. Oder was spricht dafür, es dort zu lassen?

Ansonsten aber: KLASSE!

[Pfriemler]

Uuuh ... doch eine Nebenwirkung. Im so umgebauten/rekonfigurierten HM-LC-Sw2-FM wirft das Ausschalten des zweiten Kanals (und nur dieses) einen Fehler im Log:

Code Auswählen Erweitern

2019.01.04 13:50:05 3: CUL_HM set HM_42A296_Sw_02 off
2019.01.04 13:50:09 1: PERL WARNING: Use of uninitialized value $cmd in concatenation (.) or string at ./FHEM/10_CUL_HM.pm line 4127.
2019.01.04 13:50:09 1: stacktrace:
2019.01.04 13:50:09 1:     main::__ANON__                      called by ./FHEM/10_CUL_HM.pm (4127)
2019.01.04 13:50:09 1:     main::CUL_HM_Set                    called by fhem.pl (3605)
2019.01.04 13:50:09 1:     main::CallFn                        called by fhem.pl (1811)
2019.01.04 13:50:09 1:     main::DoSet                         called by fhem.pl (1844)
2019.01.04 13:50:09 1:     main::CommandSet                    called by fhem.pl (1218)
2019.01.04 13:50:09 1:     main::AnalyzeCommand                called by fhem.pl (1064)
2019.01.04 13:50:09 1:     main::AnalyzeCommandChain           called by ./FHEM/90_at.pm (181)
2019.01.04 13:50:09 1:     main::at_Exec                       called by fhem.pl (3153)
2019.01.04 13:50:09 1:     main::HandleTimeout                 called by fhem.pl

Das scheint jetzt auch noch andere Geräte zu verwirren ... Bin erst mal auf die alte 10_CUL_HM zurück...

[martinp876]

Die re-definition und das Anlegen der Kanäle wird mit jeder Config Message geprüft. Schon immer.
Bestehende Kanäle werden nicht gelöscht. Es wird das Model geändert und die SubType Info kommt eh aus den Device.
=> der Kanal behält den Namen und die Attribute (auser model)
=> Auch gelesene Registerwerte würden erst einmal bleiben. Bis man ein getConfig macht (was bei autoReadReg automatisch, Zeitversetzt passieren sollte).

Der Kanal 1 bleibt immer erhalten, so er existiert. Ein formaler Anwender spaltet auch ein-Kanal Devices in Kanal 1 und Device. Somit darf ich diesen nicht löschen.

Der Fehler bei dir ist Seltsam. kannst du ein
set  HM_42A296_Sw_02 ?
ausführen und mir schicken? Und sicherheitshalber ein List des Device und Kanal.

[Pfriemler]

... Bestehende Kanäle werden nicht gelöscht.

Doch ... nach dem Setzen von modelForce auf HM-LC-Sw1-FM hatte der Sw2 seinen zweiten Kanal verloren.

Es wird das Model geändert

Wurde eben gerade nicht. Blieb auf HM-LC-Sw2-FM. Ich habe allerdings kein getConfig gemacht. In den Kanälen, wohlgemerkt. Im Device ändert sich die model-Bezeichnung.

Der Kanal 1 bleibt immer erhalten, so er existiert. Ein formaler Anwender spaltet auch ein-Kanal Devices in Kanal 1 und Device. Somit darf ich diesen nicht löschen.

Finde ich auch gut so. Ich bin allerdings auch nicht formal, habe noch nie Einkanaler in Gerät und Kanal gespalten.

Der Fehler bei dir ist Seltsam. kannst du ein
set  HM_42A296_Sw_02 ?
ausführen und mir schicken? Und sicherheitshalber ein List des Device und Kanal.

Nicht sofort. Ich bin ja erst mal wieder zurück auf die offizielle Version, weil das hier mein Produktivsystem ist (habe keine anderen) und vor dem Wochenende ist ein logmüllendes System kontraproduktiv 

[martinp876]

Ok, schlecht ausgedrückt. Besteht ein Kanal und wird er im neuen Model benötigt wird er nicht gelöscht.
Oder: überzählige werden gelöscht, fehlende kreiert.

Das attr model aller entities muss geändert werden. Alle haben dann das gleiche. Prüfe ich gleich. Nicht mit dem namen verwechseln. Namen gehören dem Anwender. Ich trage nur einen default ein.

Ich bin auch nicht konsequent. Habe allerdings gerade erst 2 einkanäler gesplittet. Auf der Webseite sehe ich dann eine Gruppe devices und eine Gruppe Kanäle.

Ok, dann schaue ich, was ich so sehen kann. Bei meinem Versuch hat sich nichts verhädert

[martinp876]

da hast du mich doch erwischt. Das Kommando war eine Zeile zu hoch

Was ich allerdings nicht verstehe: welche Probleme hat es sonst gegeben? In welchem Bereich? Ich nehmen an, dass du mit modelForce nur an einem Device gespielt hast. Waren auch andere betroffen?

[Pfriemler]

da hast du mich doch erwischt. Das Kommando war eine Zeile zu hoch

Genau, nicht nur neu angelegte Kanäle eines Gerätes be_model_n, sondern alle.

Was ich allerdings nicht verstehe: welche Probleme hat es sonst gegeben? In welchem Bereich?
Ich nehmen an, dass du mit modelForce nur an einem Device gespielt hast. Waren auch andere betroffen?

Soweit ich gesehen habe, waren keine anderen betroffen. mit $cmd hast Du ja auch was geändert, also sehen wir mal.
Aktuell, nach reload, schaltet alles fehlerfrei.

modelForce wird auch in den Kanälen angeboten - aber der Versuch es zu setzen, wird mit "only valid for devices" zurückgewiesen. Gut.

1. Sw2-Fm wird zum Sw1-FM. Es wird Kanal 2 gelöscht. Kanal 1 behält model HM-LC-SW2-FM.
2. Sw2-Fm wird zum Sw4-DR. Es werden alle Kanäle umbenannt.
3. Sw4-DR wird zum Sw1-FM. Drei Kanäle werden gelöscht, Kanal 1 model heißt immer noch HM-LC-Sw4-DR.
4. Sw1-FM wird zum Sw2-FM. Die Kanalmodels stimmen wieder alle.
Ergo: Werden nur Kanäle gelöscht, bleibt es beim alten. Werden neue hinzugefügt, dann werden auch alle umbe_model_t.
Ich blick's nicht, warum.

Dann: nach dieser Aktion liefert "set <Aktorchannel> ?"

Code Auswählen Erweitern


...Sw_01: Unknown argument ?, choose one of clear getConfig getRegRaw inhibit off on-for-timer on-till on peerBulk peerIODev press regBulk regSet sign statusRequest templateDel toggle
...Sw_02: Unknown argument ?, choose one of clear getConfig getRegRaw inhibit off on-for-timer on-till on peerBulk peerIODev regBulk regSet statusRequest templateDel toggle

Im zweiten Kanal fehlt "press" und "sign".

Richtig spooky wird es, wenn man jetzt modelForce löscht. Das schmeißt wieder alles bis auf den ersten Kanal raus, das model und subtype sind gelöscht und auch der erste Schaltkanal unbedienbar, weil on und off etc. fehlen. Überhaupt wird es jetzt zum HM-Dummy, inkl. dessen Menü-dropdowns.
model händisch zu setzen gibt einen Hinweistext - sehr gut.
Setzt man modelForce wieder, wird es wieder und alles funktioniert.
Ansonsten muss man das Gerät löschen und neu anlernen, damit es von autocreate angelegt wird.

Viel Stoff, ich weiß... aber es muss ja nicht alles heute sein...   

[martinp876]

modelForce wird auch in den Kanälen angeboten

Ziemlich nervig. Leider gibt es keine wirklich gute möglichkeit attribute auf relevante entities zu begrenzen (analog Command)

2. Sw2-Fm wird zum Sw4-DR. Es werden alle Kanäle umbenannt.

nein. Umbenannt wird nie ein Kanal. Die Namen sind zufällig gleich.

3. Sw4-DR wird zum Sw1-FM. Drei Kanäle werden gelöscht, Kanal 1 model heißt immer noch HM-LC-Sw4-DR.

Bei mir heist er y_Sw_01. Vorher wie nachher

Code Auswählen Erweitern

HM-LC-SW4-DR angelegt
NAME y
channel_01 y_Sw_01
channel_02 y_Sw_02
channel_03 y_Sw_03
channel_04 y_Sw_04


geändert nach HM-CC-RT-DN
channel_01 y_Sw_01
channel_02 y_Sw_02
channel_03 y_Sw_03
channel_04 y_Sw_04
channel_05 y_ClimaTeam
channel_06 y_remote

namen NICHT geändert

Code Auswählen Erweitern

Geändert nach HM-LC-SW1-FM und Kanal 1 gelöscht
- kein Kanal

geändert nach HM-CC-RT-DN
channel_01 y_Weather
channel_02 y_Climate
channel_03 y_WindowRec
channel_04 y_Clima
channel_05 y_ClimaTeam
channel_06 y_remote

neue Namen

Code Auswählen Erweitern

geändert nach HM-LC-SW2-FM
channel_01 y_Weather
channel_02 y_Climate
namen stabil

Code Auswählen Erweitern

geändert nach HM-RC-19-B
channel_01 y_Weather
channel_02 y_Climate
channel_03 y_Btn_03
channel_04 y_Btn_04
channel_05 y_Btn_05
channel_06 y_Btn_06
channel_07 y_Btn_07
channel_08 y_Btn_08
channel_09 y_Btn_09
channel_0A y_Btn_10
channel_0B y_Btn_11
channel_0C y_Btn_12
channel_0D y_Btn_13
channel_0E y_Btn_14
channel_0F y_Btn_15
channel_10 y_Btn_16
channel_11 y_Btn_17
channel_12 y_Disp
keine Namensänderung existierender Kanäle.

Richtig spooky wird es, wenn man jetzt modelForce löscht.

nun - sollte nicht sein. Aber hast du einmal restartet? Das ist notwendig. Dann wird für jedes Device das hidden Attribut ".mId" angelegt. Löschst du modelForce wird auf das orginal zurückgeschaltet.

Man sollte also dazu sagen, dass man einen Reboot durchführen sollte. Und dann ein Save.
Mache ein Backup deiner .cfg files vorab.

Viel Stoff, ich weiß... aber es muss ja nicht alles heute sein..

eigentlich nicht. Nur das mit dem Fehlenden Kommando muss ich noch suchen. Aber danke fürs testen.

Du kannst mit

{$attr{<devName}{".mId"}="0009"}

die mId setzen (ohne netz und doppelten Boden).
Wenn du nun modelForce löschst ist alles gut. Du wirst den 2-kanaler erhalten.

[Pfriemler]

Moinmoin,
ich war etwas unpräzise und Du hast es anders verstanden. Es ging nie um die Namen, sondern um das Attribut model in den Kanälen. Die Kanäle werden richtig benannt wenn sie hinzugefügt werden, aber model ändert sich eben nur beim Zufügen von Kanälen, die zurechtgerückte Zeile hat das Problem nur halb gelöst...

Der .mId-Mechanismus klingt gut. Habe ich nicht gesehen, die aber beim list zu sehen sein.
Habe ich es richtig verstanden: das .mId wird bei jedem HM-Gerät bei einem Neustart angelegt? Dann sollte das ja ausreichen, ich hatte gestern beim zweiten Versuch nur reloaded. Nach (!) dem Löschen von modelForce half ein Neustart jedenfalls nichts mehr.
In jedem Fall sollte aber sichergestellt sein,  dass ein User in einer Sitzung modelForce anlegen und wieder löschen kann, daher muss es auch beim (auto)create angelegt werden (ich habe noch nicht geprüft ob das so ist.
Ich hätte. mId an das Zufügen von modelForce geknüpft: ist es noch nicht vorhanden, wird model nach .mId gerettet...

Wenn man Attribute bei den Kanälen nicht ausblenden kann ... das ist kein Beinbruch. Das Popup erklärt ja den Fehlversuch und hilft beim Lernen.

[martinp876]

das mit dem fehlenden Kommando kann ich nicht erkennen. Siehe Ablauf.

Code Auswählen Erweitern

delete Tasse
define Tasse CUL_HM C0FFEE
attr Tasse modelForce HM-LC-SW2-FM
attr Tasse modelForce HM-LC-SW4-DR
attr Tasse modelForce HM-LC-SW2-FM
attr Tasse modelForce HM-LC-SW2-FM

set Tasse_Sw_01 ?
Unknown argument ?, choose one of clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all getConfig:noArg getRegRaw inhibit:on,off off:noArg
on-for-timer on-till on:noArg peerBulk peerIODev press regBulk regSet sign:on,off statusRequest:noArg templateDel toggle:noArg
set Tasse_Sw_02 ?
Unknown argument ?, choose one of clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all getConfig:noArg getRegRaw inhibit:on,off off:noArg
on-for-timer on-till on:noArg peerBulk peerIODev press regBulk regSet sign:on,off statusRequest:noArg templateDel toggle:noArg


ja, beim ein-kanaler hatte ich model vergessen. Ist korrigiert.

Habe ich nicht gesehen, die aber beim list zu sehen sein.

Code Auswählen Erweitern

attr global schoInternalValues 1
muss gesetzt sein. Sonst wird es nicht angezeigt. Leider auch nicht bei list. 

das .mId wird bei jedem HM-Gerät bei einem Neustart angelegt?

nein, wäre kontraproduktiv. Es ist erst einmal ein Attribut welches gespeichert wird. Ist nach dem Laden das Attribut nicht zu sehen, wird es aus model zurückgerechnet und gesetzt.
.mId wird ggf beim Empfang einer configmessage auf den dort empfangenen Wert gesetzt.

Nach (!) dem Löschen von modelForce half ein Neustart jedenfalls nichts mehr.

zu wenig details. Wenn du reloaded hattest und das Device existierte sollt .mId existent gewesen sein.

Der Ablauf:
- du legst device an, setzt modelForce => model wird gesetzt
- du löschst modelForce => rückbau auf basis von .mId. Da es  nicht vorhanden ist bleibt model leer. Ein virtuelles Device
- du setzt modelForce, speicherst und reloadest => .mId wird auf basis model gesetzt.
- du löschst modelForce => model wird auf Basis .mId neu berechnet - bleibt also unverändert

In jedem Fall sollte aber sichergestellt sein,  dass ein User in einer Sitzung modelForce anlegen und wieder löschen kann

kann er doch. Beachte, was das Ziel ist. Man kann den eQ3 Bug umgehen. Oder ein Dummy erstellen welches die Register und Kommandos wiedergibt. Das sollte alles prima abgedekt sein. Es geht nichts kaputt.

Wenn ein User einen ordentlichen Update macht erfolgt ein Reboot. Ein Reload des cul_hm ist nicht ausreichend, da .mId nicht angelegt wird.

[sensorle]

Hallo,
habe die neue Version mal mit dem Schalter der sich falsch meldet getestet. Sorry, dass ich mich erst jetzt melde...

Wenn ich mit modelForce aus dem HM-LC-SW2-FM einen HM-LC-SW1-FM mache (was er ja tatsächlich ist), dann wird er angezeigt wie vorher, mit dem Unterschied, dass Kanal 2 entfernt wurde (siehe Screenshot 1).
Das ist ähnlich wie ich es vorher hatte, als ich den Kanal 2 mit DeletDevice glöscht hatte.

Im verbleibenden Kanal 1 steht dann immer noch HM-LC-SW2-FM als Attribut (siehe Screenshot 2).

Grundsätzlich sieht der mit modelForce geänderte Schalter aus wie ein Mehrfach Schalter mit einem Kanal. Damit unterscheidet er sich von einem "normalen" HM-LC-SW1-FM, bei dem keine Kanäle in den Internals angezeigt werden.

Fazit: Die Änderung funktioniert. FHEM verhält sich damit ähnlich wie die HM Konfigurations-SW meines USB-Sticks.

Danke Martin!


Nachtrag:
musste bei allen anderen Devices ebenfalls modelForce ausführen.
Habe ich leider zu spät bemerkt - Sorry.
Siehe auch hier:
https://forum.fhem.de/index.php/topic,95409.msg882568.html#msg882568

[Pfriemler]

Ouu... Martin, da hat was noch nicht funktioniert.

Den allerletzten Zwischenstand kann ich jetzt nicht mehr nennen, aber in der vor dem heuten reboot gespeicherten fhem.cfg stand (in Auszügen):

Code Auswählen Erweitern

define HM_42A296 CUL_HM 42A296
attr HM_42A296 .mId 0009
attr HM_42A296 IODev HMUART
attr HM_42A296 IOgrp vccu:HMUART
...
attr HM_42A296 model HM-LC-SW2-FM
...
attr HM_42A296 subType switch
...
define HM_42A296_Sw_01 CUL_HM 42A29601
...
attr HM_42A296_Sw_01 model HM-LC-SW2-FM
...
define HM_42A296_Sw_02 CUL_HM 42A29602
attr HM_42A296_Sw_02 model HM-LC-SW2-FM


Bis hierhin alles korrekt und funktionierend. Aber:

Nach dem Neustart finde ich ein rotes Fragezeichen: "structural changes: delete HM_42A296_Sw_02 CUL_HM 42A29602" - der zweite Kanal ist weg.

Gerätelist: model und subtype fehlen.

Code Auswählen Erweitern

Internals:
   DEF        42A296
   IODev      HMUART
   NAME       HM_42A296
   NOTIFYDEV  global
   NR         908
   NTFY_ORDER 50-HM_42A296
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HM_42A296_Sw_01
   READINGS:
...
     2019-01-05 12:42:04   .protLastRcv    2019-01-05 12:42:04
     2019-01-04 17:56:08   D-firmware      2.8
...
     2019-01-04 17:55:57   RegL_00.        00:00 02:01 0A:14 0B:11 0C:AB 15:FF 18:00
     2019-01-05 12:41:18   powerOn         2019-01-05 12:41:18
     2019-01-05 12:42:04   state           CMDs_done
   helper:
     HM_CMDNR   65
     mId       
     subType   
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +42A296,00,01,00
       rxt        0
       vccu       vccu
       p:
         42A296
         00
         01
         00
       prefIO:
         HMUART
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
     tmpl:
Attributes:
   .mId       0009
   IODev      HMUART
   IOgrp      vccu:HMUART
   alias      HM_42A296 (2fach Switch UP, Fundus)
...
   subType   
   webCmd     getConfig:clear msgEvents
   model:

beachte vor allem die letzte Zeile: Der Doppelpunkt steht im list, im Web-Def fehlt das Attribut komplett.

Im (einzigen) Kanal befindet sich noch das korrekte model-Attribut.

Ich mach erst mal nix weiter...

[Pfriemler]

Ach du dicke Scheiße ... hier gab es nach einem weiteren Neustart gerade massiven Kahlschlag, alle models meiner HM-Geräte sind weg.
Ich muss jetzt einen shutdown fahren, das official 10_CUL_HM.pm einspielen und die Config restoren.

Alle die ihr das hier bisher verwendet - schaut mal wie es Euch ergeht ...

[Christoph Morrison]

Ach du dicke Scheiße ... hier gab es nach einem weiteren Neustart gerade massiven Kahlschlag, alle models meiner HM-Geräte sind weg.
Ich muss jetzt einen shutdown fahren, das official 10_CUL_HM.pm einspielen und die Config restoren.

Alle die ihr das hier bisher verwendet - schaut mal wie es Euch ergeht ...

So wie ich das Forum lese: Das Problem gibt es auch mit der Version aus dem SVN. Du solltest dir also eher eine aus dem Restore/Backup holen ...

[LuckyDay]

@ Pfriemler
https://forum.fhem.de/index.php/topic,95409.0.html