[Gelöst] HMW_LC_Bl1_DR läßt sich nach RESET nicht mehr anlernen

Begonnen von bmwfan, 30 November 2021, 11:30:00

Vorheriges Thema - Nächstes Thema

bmwfan

Hallo,
bei mir laufen seit langer Zeit 7 Rolladenaktoren HmWired (HMW_LC_Bl1_DR) über ein HM485_Lan (eQ3-HMW-LGW) angesteuert. Einer davon hat gestern Abend die Jalousien nicht automatisch geschlossen. Habe heute nachgeschaut und er lies sich aus FHEM nicht mehr ansprechen. Alle anderen Aktoren gehen normal. Änderungen an der Verdrahtung oder am Netzwerk wurden nicht vorgenommen.

Habe ihn dann nach Bedienungsanleitung auf Werkseinstellungen zurückgesetzt und das Device in FHEM gelöscht, um ihn neu anzulernen. Leider wird er nicht mehr automatisch erkannt und nach manuellem Anlegen wird keine Verbindung aufgebaut. Per Tastendruck am Aktor bzw. an den Wandtastern gehen die Jalousien.
Das list des Aktors:
Internals:
   CFGFN     
   DEF        0001076C
   FUUID      61a5f140-f33f-d125-4dca-85b168c4db4f9b0c
   FailedConfigReads 0
   IODev      HM485_LAN
   NAME       HMW_LC_Bl1_DR_LEQ1321953
   NR         776
   STATE      ???
   TYPE       HM485
   READINGS:
     2021-11-30 10   IODev           HM485_LAN
     2021-11-30 11   configStatus    READING
   cache:
     sets       Unknown argument ?, choose one of  getConfig raw reset 
   hmccu:
Attributes:
   alias      Jal_KU_Ost_00
   room       HM485
   verbose    4


Nach einem
Zitat2021.11.30 11:23:30.287 3: HM485_LAN: Initialisierung von Modul 0001076C
steht nur das im Log: 2021.11.30 11:23:30.287 3: HM485_LAN: Initialisierung von Modul 0001076C

Nach einem getConfig wird das angezeigt:
{
".message":{
"input":"0",
"type":"text",
"value":"Device not completely loaded yet. Try again later."
}
}


Zum Vergleich das List eines noch funktionierenden Sensors:
Internals:
   DEF        00010B2C
   FUUID      6196a45d-f33f-d125-12dc-28171959a4ef074f
   FailedConfigReads 0
   IODev      HM485_LAN
   NAME       HMW_LC_Bl1_DR_LEQ1322802
   NR         57
   RawDeviceType 21
   RawFwVersion 774
   STATE      ACK
   TYPE       HM485
   channel_01 HMW_LC_Bl1_DR_LEQ1322802_01
   channel_02 HMW_LC_Bl1_DR_LEQ1322802_02
   channel_03 HMW_LC_Bl1_DR_LEQ1322802_03
   peer_act_0 channel_01 → HMW_LC_Bl1_DR_LEQ1322802_03
   peer_act_1 channel_02 → HMW_LC_Bl1_DR_LEQ1322802_03
   peer_sen_0 channel_03 ← HMW_LC_Bl1_DR_LEQ1322802_01
   peer_sen_1 channel_03 ← HMW_LC_Bl1_DR_LEQ1322802_02
   READINGS:
     2021-11-30 08   D-deviceKey     HMW_LC_BL1_DR
     2021-11-30 08   D-fwVersion     3.06
     2021-11-30 08   D-serialNr      LEQ1322802
     2021-11-30 08   IODev           HM485_LAN
     2021-11-30 08   R-central_address 00000001
     2021-11-30 08   R-logging_time  2.00
     2021-11-30 08   configStatus    OK
     2021-11-30 08   state           ACK
   cache:
     sets       Unknown argument ?, choose one of  config getConfig raw reset 
     03:
       allowedSets level on off up down stop inhibit install_test
       sets       Unknown argument ?, choose one of  config down inhibit install_test level off on peer href='/fhem?detail=HMW_LC_Bl1_DR_LEQ1322076_01'>HMW_LC_Bl1_DR_LEQ1322076_01,HMW_LC_Bl1_DR_LEQ1322076_02,HMW_LC_Bl1_DR_LEQ1322638_01,HMW_LC_Bl1_DR_LEQ1322638_02,Jal_KU_Fenster_00_01,Jal_KU_Fenster_00_02,Jal_WZ_Fest_Ost_01,Jal_WZ_Fest_Ost_02,Jal_WZ_Fest_West_01,Jal_WZ_Fest_West_02,Jal_WZ_Schiebetuer_01,Jal_WZ_Schiebetuer_02 peeringdetails stop unpeer href='/fhem?detail=HMW_LC_Bl1_DR_LEQ1322802_01'>HMW_LC_Bl1_DR_LEQ1322802_01,HMW_LC_Bl1_DR_LEQ1322802_02 up  off-for-timer off-till-overnight on-for-timer off-till blink on-till-overnight intervals on-till
       peeredChannels:
         HMW_LC_Bl1_DR_LEQ1322802_01
         HMW_LC_Bl1_DR_LEQ1322802_02
     linkParams:
       actuator:
         address_start 854
         address_step 6
         channel_param channel
         channels   01 02
         count      28
         peer_param actuator
         type       link
         parameter:
           HASH(0x4ecdc30)
           HASH(0x4ecdf30)
       sensor:
         address_start 18
         address_step 38
         channel_param channel
         channels   03
         count      22
         peer_param sensor
         type       link
         parameter:
           HASH(0x4e49108)
           HASH(0x4e493d8)
           HASH(0x4e495e8)
           HASH(0x4e498d0)
           HASH(0x4e49b88)
           HASH(0x4ebcd18)
           HASH(0x4ebcfd0)
           HASH(0x4ebd288)
           HASH(0x4ebd4e0)
           HASH(0x4ebd750)
           HASH(0x4ebdb28)
           HASH(0x4ebdf20)
           HASH(0x4ebe370)
           HASH(0x4ebe7c0)
           HASH(0x4ebead8)
           HASH(0x4ebf098)
           HASH(0x4ebf620)
           HASH(0x4ebfba8)
           HASH(0x4ec0150)
           HASH(0x4ec06d8)
           HASH(0x4ec1c78)
           HASH(0x4ec2200)
           HASH(0x4ec2788)
           HASH(0x4ec2a40)
           HASH(0x4ec2d18)
           HASH(0x4ec3090)
           HASH(0x4ec3348)
           HASH(0x4ec34f8)
           HASH(0x4ec37b0)
           HASH(0x4ec3a08)
           HASH(0x4ec3c98)
           HASH(0x4ec4070)
           HASH(0x4ec4448)
           HASH(0x4ec4898)
           HASH(0x4ec5d00)
           HASH(0x4ec6018)
           HASH(0x4ec65b8)
           HASH(0x4ec6b40)
           HASH(0x4ec80e0)
           HASH(0x4ec8668)
           HASH(0x4ec8c10)
           HASH(0x4ec9198)
           HASH(0x4ec9720)
           HASH(0x4ec9cc8)
     peered_act:
       0:
         channel    01
         name       00010B2C_03
       1:
         channel    02
         name       00010B2C_03
     peers:
       actuators:
         0:
           actuator   00010B2C_03
           channel    01
         1:
           actuator   00010B2C_03
           channel    02
       sensors:
         0:
           channel    03
           sensor     00010B2C_01
         1:
           channel    03
           sensor     00010B2C_02
Attributes:
   IODev      HM485_LAN
   alias      Jal_KU_Sued_00
   room       HM485


Wie bekomme ich den Aktor wieder in FHEM eingebunden?

Grüße Jürgen
Synology DS720+ mit Docker-Container und Haupt-FHEM, HW-LAN, Jalousienaktoren; Raspi 3B+ mit piVCCU ohne FHEM-Instanz, CUL, JeeLink; Raspi 3B+ mit FHEM und HMUARTUSB,  Raspi 3B+ mit HMUARTGPIO, 1-wire, ebusd

Thorsten Pferdekaemper

Hi,
das ist jetzt schwer zu sagen. Da Du das Ding über einen eQ3-HMW-LGW steuerst kann man auch nicht wirklich mehr "tracen". Möglicherweise merkt sich der eQ3-HMW-LGW auch irgendwas und blockiert das Teil jetzt.
Hast Du irgendwo einen RasPi oder sowas übrig und einen seriellen Adapter? Damit könnte man dem Ding mal ein bisschen mehr auf den Zahn fühlen.
Gruß,
   Thorsten
FUIP

bmwfan

Guten Morgen Thorsten,

habe einen raspi und einen Digitus DA-70156 noch da. Wenn der vom Raspi (USB-Anschluß) erkannt wird, könnte es gehen.

Allerdings hat sich das Problem selbst erledigt. Um 21:47, ca. 11 Stunden nach meinen Versuchen den Aktor anzusprechen, wurde er von FHEM eingelesen.
Das waren meine letzten Versuche:
2021.11.30 11:13:49.811 5: HM485_LAN: HM485_LAN_Write TX: 150
2021.11.30 11:13:49.811 5: DevIo_SimpleWrite HM485_LAN: fd02964b
2021.11.30 11:13:49.821 5: HM485_LAN: HM485_LAN_parseIncommingCommand: MsgId: 150 Cmd: 97
2021.11.30 11:13:49.822 5: HM485_LAN: HM485_LAN_parseIncommingCommand: Alive: (150) 00 AliveStatus: 00
2021.11.30 11:17:33.181 3: HM485_LAN: Initialisierung von Modul 0001076C
2021.11.30 11:23:30.287 3: HM485_LAN: Initialisierung von Modul 0001076C


und das war dann um 21:47 im Log:
2021.11.30 21:47:03.332 3: HMW_LC_Bl1_DR_LEQ1321953: Request config for device 0001076C
2021.11.30 21:47:03.344 3: HMW_LC_Bl1_DR_LEQ1321953: Lese Eeprom 0001076C
2021.11.30 21:47:03.963 3: HMW_LC_Bl1_DR_LEQ1321953: Request config for device 0001076C
2021.11.30 21:47:03.975 3: HMW_LC_Bl1_DR_LEQ1321953: Lese Eeprom 0001076C
2021.11.30 21:47:04.563 3: HMW_LC_Bl1_DR_LEQ1321953: Request config for device 0001076C
2021.11.30 21:47:04.575 3: HMW_LC_Bl1_DR_LEQ1321953: Lese Eeprom 0001076C
2021.11.30 21:47:05.451 3: HMW_LC_Bl1_DR_LEQ1321953: Request config for device 0001076C
2021.11.30 21:47:05.463 3: HMW_LC_Bl1_DR_LEQ1321953: Lese Eeprom 0001076C
2021.11.30 21:47:06.398 3: HMW_LC_Bl1_DR_LEQ1321953: Request config for device 0001076C
2021.11.30 21:47:06.410 3: HMW_LC_Bl1_DR_LEQ1321953: Lese Eeprom 0001076C
2021.11.30 21:47:07.269 3: HMW_LC_Bl1_DR_LEQ1321953: Request config for device 0001076C
2021.11.30 21:47:07.280 3: HMW_LC_Bl1_DR_LEQ1321953: Lese Eeprom 0001076C
2021.11.30 21:47:08.692 3: HMW_LC_Bl1_DR_LEQ1321953: Request config for device 0001076C
2021.11.30 21:47:08.704 3: HMW_LC_Bl1_DR_LEQ1321953: Lese Eeprom 0001076C
2021.11.30 21:47:09.371 3: HMW_LC_Bl1_DR_LEQ1321953: Request config for device 0001076C
2021.11.30 21:47:09.387 3: HMW_LC_Bl1_DR_LEQ1321953: Lese Eeprom 0001076C
2021.11.30 21:47:09.981 3: HMW_LC_Bl1_DR_LEQ1321953: Request config for device 0001076C
2021.11.30 21:47:09.993 3: HMW_LC_Bl1_DR_LEQ1321953: Lese Eeprom 0001076C
2021.11.30 21:47:18.389 4: HMW_LC_Bl1_DR_LEQ1321953: HM485_SetConfig: name = HMW_LC_Bl1_DR_LEQ1321953 Key = central_address Wert = 1 msg =
2021.11.30 21:47:18.391 3: HMW_LC_Bl1_DR_LEQ1321953: Set config HMW_LC_Bl1_DR_LEQ1321953: central_address=1
2021.11.30 21:47:18.391 4: HMW_LC_Bl1_DR_LEQ1321953: Channels initialisieren 0001076C
2021.11.30 21:47:18.392 4: HMW_LC_Bl1_DR_LEQ1321953: State der Channels ermitteln 0001076C
2021.11.30 21:47:20.448 4: HMW_LC_Bl1_DR_LEQ1321953: HM485_UpdateConfigReadings called
2021.11.30 21:47:22.907 4: HMW_LC_Bl1_DR_LEQ1321953: HM485_UpdateConfigReadings called
2021.11.30 21:47:34.616 4: HMW_LC_Bl1_DR_LEQ1321953: Channels initialisieren 0001076C
2021.11.30 21:47:34.617 4: HMW_LC_Bl1_DR_LEQ1321953: State der Channels ermitteln 0001076C
2021.11.30 21:47:34.624 4: HMW_LC_Bl1_DR_LEQ1321953: HM485_UpdateConfigReadings called
2021.11.30 21:47:42.575 4: HMW_LC_Bl1_DR_LEQ1321953: Channels initialisieren 0001076C
2021.11.30 21:47:42.577 4: HMW_LC_Bl1_DR_LEQ1321953: State der Channels ermitteln 0001076C
2021.11.30 21:47:42.588 4: HMW_LC_Bl1_DR_LEQ1321953: HM485_UpdateConfigReadings called
2021.11.30 21:47:55.852 4: HMW_LC_Bl1_DR_LEQ1321953: Channels initialisieren 0001076C
2021.11.30 21:47:55.853 4: HMW_LC_Bl1_DR_LEQ1321953: State der Channels ermitteln 0001076C
2021.11.30 21:47:55.860 4: HMW_LC_Bl1_DR_LEQ1321953: HM485_UpdateConfigReadings called
2021.11.30 21:48:04.010 4: HMW_LC_Bl1_DR_LEQ1321953: Channels initialisieren 0001076C
2021.11.30 21:48:04.011 4: HMW_LC_Bl1_DR_LEQ1321953: State der Channels ermitteln 0001076C
2021.11.30 21:48:04.018 4: HMW_LC_Bl1_DR_LEQ1321953: HM485_UpdateConfigReadings called
2021.11.30 21:48:12.346 4: HMW_LC_Bl1_DR_LEQ1321953: Channels initialisieren 0001076C
2021.11.30 21:48:12.348 4: HMW_LC_Bl1_DR_LEQ1321953: State der Channels ermitteln 0001076C
2021.11.30 21:48:12.355 4: HMW_LC_Bl1_DR_LEQ1321953: HM485_UpdateConfigReadings called
2021.11.30 21:48:21.074 4: HMW_LC_Bl1_DR_LEQ1321953: Channels initialisieren 0001076C
2021.11.30 21:48:21.075 4: HMW_LC_Bl1_DR_LEQ1321953: State der Channels ermitteln 0001076C
2021.11.30 21:48:21.082 4: HMW_LC_Bl1_DR_LEQ1321953: HM485_UpdateConfigReadings called
2021.11.30 21:48:32.539 4: HMW_LC_Bl1_DR_LEQ1321953: Channels initialisieren 0001076C
2021.11.30 21:48:32.541 4: HMW_LC_Bl1_DR_LEQ1321953: State der Channels ermitteln 0001076C
2021.11.30 21:48:32.549 4: HMW_LC_Bl1_DR_LEQ1321953: HM485_UpdateConfigReadings called
2021.11.30 21:48:39.456 4: HMW_LC_Bl1_DR_LEQ1321953: Channels initialisieren 0001076C
2021.11.30 21:48:39.458 4: HMW_LC_Bl1_DR_LEQ1321953: State der Channels ermitteln 0001076C
2021.11.30 21:48:39.464 4: HMW_LC_Bl1_DR_LEQ1321953: HM485_UpdateConfigReadings called


Warum plötzlich wieder um 21:47 der Aktor abgefragt wurde erschließt sich mir nicht. Ich habe zud er Zeit nichts am Raspi gemacht. Angesichts der Probleme und dass es jetzt wieder geht, möchte ich aber ungern Versuche machen, so sehr es mich auch interessiert, warum das so kam. Ich hatte bisher keine Probleme mit dem Bus, auch ein korrekter Busabschluß ist vorhanden und der Bus ist, vom gateway weg, lediglich ca. 1 m lang. Da dürfte es keine Probleme geben.

Ich habe allerdings vor ca. 4 Wochen 2 Shelly in den Schaltkasten gebaut. Die sind ca. 15 cm von der Busleitung weg. Könnte das WLAN der Shellys die Busübertragung beeinflussen? Zwischen den Komponenten, da direkt nebeneinander auf der Hutschiene angebracht, ist kein abgeschirmtes Kabel eingesetzt, lediglich eine 2-Drahtleitung.

Danke für Deine Hilfe.

Grüße Jürgen
Synology DS720+ mit Docker-Container und Haupt-FHEM, HW-LAN, Jalousienaktoren; Raspi 3B+ mit piVCCU ohne FHEM-Instanz, CUL, JeeLink; Raspi 3B+ mit FHEM und HMUARTUSB,  Raspi 3B+ mit HMUARTGPIO, 1-wire, ebusd

Thorsten Pferdekaemper

Hi,
das ist für mich sicherlich ok und ich kann es verstehen, dass Du da nichts ausbauen willst.

Zur Config-Abfrage: Früher war es mal so, dass bei jeder misslungenen Kommunikation (die man gar nicht mal unbedingt bemerkt) die komplette Konfiguration vom Device neu eingelesen wurde. Dafür gibt es inzwischen das Attribut autoReadConfig. Normalerweise sollte die Konfiguration nur eingelesen werden, wenn man FHEM neu startet oder das Device neu dazukommt. Kannst Du mal nachsehen, ob autoReadConfig irgendwo gesetzt ist? Das Attribut gibt es sowohl auf dem HM485-Device als auch auf dem HM485_LAN. ...oder Du hast eine so alte Verson, dass es das Attribut gar nicht gibt, aber das glaube ich nicht wirklich.

Natürlich kann es immer mal vorkommen, dass sich die Geräte gegenseitig beeinflussen. Ich habe bei mir in den Kästen alles relativ voll gepackt, aber nichts mit Funk. Ich halte es allerdings nicht für sehr wahrscheinlich, dass ein WLan-Gerät die niedrigen Frequenzen von HMW beeinflusst. ...aber wer weiß, vielleicht funken die Dinger gerade in einem so blöden Takt, dass da doch was passieren kann.

Gruß,
   Thorsten



FUIP

bmwfan

Hallo Torsten,
HM485_LAN: autoReadConfig war nicht gesetzt. Habe es jetz mal auf atstartup gesetzt. So ok?

Ich kann es mir auch nicht vorstellen, dass es durch die Shellys Probleme gibt aber dachte ich frage zur Sicherheit mal nach.

Noch eine Frage: Setze auch eine HMCCU in Verbindung mit piVCCU3 für die HmIP-Geräte ein. Habe gesehen, dass man von da aus auch HMWired-Komponenten ansprechen kann. Leider verbindet sich die HMCCU nicht mit dem Gateway. Kann es daran liegen, dass HM485_LAN auf dieselbe IP-Adresse zugreift und da schon connected, keine Verbindung mehr zu HMCCU aufgebaut wird? Ich will ungern für einen Versuch meine HM485-Konfiguration, die aktuell läuft, löschen.

Was ist denn eher zu empfehlen? Ansteuerung der Wired-Komponenten über das Modul HM485 oder HMCCU?

Ich habe schon bemerkt, dass das Modul HM485 gelegentlich, vermute wenn der Raspi schwer beschäftigt ist, die Verbindung zum gateway verliert und neu aufbaut. Vielleicht wäre dieser Effekt mit HMCCU nicht vorhanden.

Grüße Jürgen

Synology DS720+ mit Docker-Container und Haupt-FHEM, HW-LAN, Jalousienaktoren; Raspi 3B+ mit piVCCU ohne FHEM-Instanz, CUL, JeeLink; Raspi 3B+ mit FHEM und HMUARTUSB,  Raspi 3B+ mit HMUARTGPIO, 1-wire, ebusd

loetmeister

Hi Jürgen,

denke die Frage war, ob das Attribut autoReadConfig nicht mit dem Standard Wert gesetzt gewesen wäre. Wenn es nicht gesetzt ist und deine HM485 Version aktuell ist, dann würde "atStartup" gelten.
Das ist das Verhalten was ich bei mir sehe...
ZitatNormalerweise sollte die Konfiguration nur eingelesen werden, wenn man FHEM neu startet oder das Device neu dazukommt.

Ich habe den Bus per USB Dongle und HM485d (HMW-SOFT-GW) angebunden, das läuft absolut stabil (Pi 3 Model B). Weiß aber nicht ob das in deinem Setup auch geht?
Wenn dir noch mal eine Device ausfällt, kannst du das Buskabel ja mal gegen ein geschirmtes tauschen, dann kannst du das in Zukunft als Fehlerquelle ausschließen.

Gruß,
Thomas

Thorsten Pferdekaemper

Zitat von: bmwfan am 02 Dezember 2021, 15:29:10
HM485_LAN: autoReadConfig war nicht gesetzt. Habe es jetz mal auf atstartup gesetzt. So ok?
Siehe loetmeisters (aka Thomas) Antwort dazu...

Zitat
Noch eine Frage: Setze auch eine HMCCU in Verbindung mit piVCCU3 für die HmIP-Geräte ein. Habe gesehen, dass man von da aus auch HMWired-Komponenten ansprechen kann. Leider verbindet sich die HMCCU nicht mit dem Gateway. Kann es daran liegen, dass HM485_LAN auf dieselbe IP-Adresse zugreift und da schon connected, keine Verbindung mehr zu HMCCU aufgebaut wird? Ich will ungern für einen Versuch meine HM485-Konfiguration, die aktuell läuft, löschen.
Das Gateway kann meines Wissens nach nur einen Client. D.h. wenn es mit irgendwas verbunden ist, dann hört es auf nichts anderes mehr.

Zitat
Was ist denn eher zu empfehlen? Ansteuerung der Wired-Komponenten über das Modul HM485 oder HMCCU?
Also ich weiß, dass es bei mir ziemlich stabil läuft. Ich habe zurzeit 25 Devices (also Haupt-Devices, nicht die Kanäle) dranhängen. Ich verwende HM485 mit einem ziemlich primitiven USB-seriell-Gateway.

Zitat
Ich habe schon bemerkt, dass das Modul HM485 gelegentlich, vermute wenn der Raspi schwer beschäftigt ist, die Verbindung zum gateway verliert und neu aufbaut. Vielleicht wäre dieser Effekt mit HMCCU nicht vorhanden.
Es gibt da eine Keepalive-Zeit. Wenn der RasPi (standardmäßig) sich nicht etwa alle 20 Sekunden meldet, dann meldet sich das Gateway ab. Ich glaube aber, dass man diese Zeit auch anders einstellen kann.
Möglicherweise ist die HMCCU nie so überlastet, aber ich weiß es nicht.
Alternativ kann man natürlich auch die 10€ investieren und ein einfaches USB-serielles-Gateway reinstöpseln. Damit ist man in der Regel alle diese Probleme los.

Gruß,
   Thorsten
FUIP