Eins von zwei HM-Dis-WM55 paired nicht, RESPONSE TIMEOUT:RegisterRead

[martinp876]

Chef de Mission und zusätzlich owner der 00_cul ist Rudi.
Mittlerweile ist 00_cul für hm schon weit fortgeschritten so dass Rudi tatsächlich Probleme haben wird, die Änderungen abzusehen. Die Versuche ihn bereits auf dem Weg mitzunehmen sind gescheitert.
Somit sehe ich keine Chance dass es über Rudi noch etwas wird. Dein Problem verstehe ich ebenfalls.
Aktuell hast du die beschriebene Wahl. Ich denke einmal über eine gütliche Einigung zwischen den beiden Entwicklern nach

[dog_martin]

Ahaa: "Moderator" und "Hero Member"


Viel Erfolg!
Ich kann Rudi nach Deiner Beschreibung aber ebenfalls gut verstehen...

[martinp876]

Mei Vorschlag ist ein io cul-hm bereitzustellen. Das kann man in fhem einbinden. Rudi hat weiterhin sei universal culio was hm nicht sauber unterstützt und für welches ich keinen Support liefere.
Der User kann die cul für hm nutzen ODER fuer eine andere Familie.
Er muss das Perl Modul (also den Typ bei der Definition) wählen. Auch der fwupdate sollte entsprechend implementiert werden.

Damit sollte Rudi, Ansgar, ich, du und alle anderen Leben koennen.

[dog_martin]

Das hört sich für mich praktikabel an.
Vielleicht habt Ihr eine Möglichkeit das so um zu setzen.

[dog_martin]

Kurze Rückmeldung zum reklamierten Display:
Der neue Bausatz erreichte mich eben - habe also einen Kompletttausch bekommen.

Leider KEINE Besserung, auch das neue Display kann nicht vollständig gepaired werden.
Dieselbe Firmware 1.0 und derselbe Bausatz.

Nach Überprüfung des ersten funktionstüchtigen Displays und einem erneuten getConfig bekomme ich auch dort einen RESPONSE TIMEOUT.
Ich nehme an, dass zwischen dem Anlernen des ersten und des zweiten Displays eine Änderung des Code zu diesem Verhalten führte.

Ich muss mir jetzt überlegen wie ich weiter machen werde, so kann das nicht bleiben...

[martinp876]

Im Log einige Zeit zurück sehe ich ein Pairen und AES gesendet von einer CUL ohne "HW-FW".

Es ist immer noch sehr kritisch eine CUL mit der "standart-FW" mit HM zu nutzen - insbesondere bei Kommunikation mit Timing Anforderungen wie AES und aktionen die mehrere Message austauschen.
Ein Debuggen lohnt sich nicht - haben wir vor ~2 Jahren aufgegeben.
Es git eine FW die Timing korrekturen ermöglicht. Wer die nicht nutzt muss seine (selbst verschuldeten) Probleme selbst lösen - es geht halt nicht.
Es liegt nicht am HM device.

[dog_martin]

Es git eine FW die Timing korrekturen ermöglicht. Wer die nicht nutzt muss seine (selbst verschuldeten) Probleme selbst lösen - es geht halt nicht.

Ich würde ja gerne, wenn's denn funktionierte.
Ich teste gerade mit Ansgars FW und bekomme nur Probleme: Cannot init /dev/ttyACM0, ignoring it (CUL_0)

Da kann ICH doch eigentlich nicht viel verbocken - das Flashen der FW und der anschliessende Verify liefen problemlos durch.
Die 00_CUL.pm ersetzen fertig - ODER?

[martinp876]

so ist es.
da meine CUL verstorben ist kann ich es nicht mehr probieren. Also sie noch lief ging es ohne Probleme.
Ansgar wird sicher antworten.

[dog_martin]

Ansgar hat mir den entscheidenden Tipp gegeben!

Nach dem Flashen haben meine beiden USB Devices mal eben die /dev/ttyAMA* getauscht.
Da konnte nicht mehr viel kommen.

Lustigerweise haben sie nach Flashen der ursprünglichen Version wieder zurück getauscht.
Dann funktionierte wieder alles und ich dachte natürlich es läge an der FW...

[MadMax-FHEM]

Hi,

wenn die beim/nach dem Booten mal tauschen, dann besser einbinden per /dev/serial/by-id bzw. (wie ich, da selbe ID) /dev/serial/by-path (dann halt nicht unstecken, eh klar)...

Mit der alternativen/optimierten FW und den angepassten Modulen habe ich jetzt auch keine Probleme mehr.

Gebe dir Recht: blöd, dass es nicht im Standard ist...

Aber bei mir tragbar, da es "nur" ein Testsystem ist...

Bei meinen "richtigen" Systemen habe ich HM-CFG-USB bzw. neuerdings HM-UART...

Gruß, Joachim

[noansi]

Hallo Joachim,

kannst Du bitte mal ein Pairing und getConfig mit HM-CFG-USB mit

Code Auswählen Erweitern

attr global mseclog 1 und verbose 4 mit loggen, falls Su so ein Display hast. Oder jemand anderes?

Es könnte sein, dass Martins letzte Änderung bezüglich Pairing in 10_CUL_HM.pm wegen des Klingelsensors bei dem Display jetzt Probleme bereitet, da nun auf wiederholtes Request nicht mehr neu gesendet wird (wie auch im Log zu getConfig zu sehen).

Ohne eine offizielle Übernahme dieser Firmware und der angepassten Module wäre das für mich eine Sackgasse bzgl. zukünftiger Updates.

Ich denke einmal über eine gütliche Einigung zwischen den beiden Entwicklern nach

Rudi hat leider nicht genügend Zeit und Energie, um alle aufgelaufenen Änderungen meinerseits zu prüfen und zu testen. Dazu habe ich zu weit ausgeholt und teilweise ausholen müssen.

Mein Vorschlag ist ein io cul-hm bereitzustellen.

Die Sackgasse hat zu weiteren unabhängigen Entwicklungen meinerseits geführt, die ich nicht mehr missen möchte und vom "Standard" 00_CUL.pm usw. nicht unterstützt werden.
Ich arbeite derzeit an einem 00_TSCUL.pm, 16_TSSTACKED.pm, plus weiterer Sondermodule. Damit kann man dann die Timestamp Firmware für HM nutzen und 00_CUL.pm etc. kann Updates erfahren ohne dass es zu Konflikten kommen sollte.
Da auch meine Zeit und Energie sehr begrenzt ist, ist das auch erst mal der schnellste Weg.
Ein jeweils "geringer" Eingriff seitens Rudi und Martin wird aber nicht zu vermeiden sein, da z.B. der {TYPE} an einigen Code Stellen abgefragt/benötigt wird und ein (ggf. suboptimaler) Mischbetrieb mit mehrenen CUL Devices, insbesondere bei STACKABLE_CC möglich bleiben muss.

Gruß, Ansgar.

[MadMax-FHEM]

Hi Ansgar,

gerne.
Habe beide Displays...
Bin allerdings grad nicht zuhause bis Mitte der Woche...

Wenn sich bis dahin niemand gefunden hat reiche ich es nach...

Kann ja auch mal mit dem "Spezial-CUL" am Testsystem testen...

Und auch mal HM-UART...

Gruß, Joachim

P.S.: ist auch eine gute Gelegenheit die "aufgeräumten" Module einzuspielen... Hatte dazu bislang keine Zeit/Anlass...

[MadMax-FHEM]

Hi Ansgar,

also ich hab mal mein Hauptsystem (HM-CFG-USB) auf den neuesten Stand gebracht und die Einstellungen vorgenommen.

Allerdings verbose 4 bei global spuckt sehr viel (unnützes) Zeugs raus...
...und mit verbose 4 nur beim hmusb steht nicht wirklich viel im Log...

Code Auswählen Erweitern


2016.09.09 11:51:04.897 3: CUL_HM set vccu hmPairForSec 60
2016.09.09 11:51:13.858 2: CUL_HM Unknown device HM_3515DA is now defined
2016.09.09 11:51:13.877 2: autocreate: define HM_3515DA CUL_HM 3515DA
2016.09.09 11:51:13.882 2: autocreate: define FileLog_HM_3515DA FileLog ./log/HM_3515DA-%Y.log HM_3515DA
2016.09.09 11:51:14.518 3: CUL_HM pair: HM_3515DA pushButton, model HM-Dis-WM55 serialNr
2016.09.09 11:51:25.621 4: HMLAN_ack: timeout - clear queue
2016.09.09 11:51:39.542 3: CUL_HM set HM_3515DA getConfig
2016.09.09 11:51:48.578 1: my_StoreBatteryStatus      ignoring Device: HM_3515DA
2016.09.09 11:51:58.659 4: HMLAN_ack: timeout - clear queue


Was würde dir helfen?

Gruß, Joachim

[MadMax-FHEM]

Hi Ansgar,

hab nun doch noch mal mit global verbose 4 versucht möglichst wenig "Schrott" zu loggen...

Code Auswählen Erweitern


2016.09.09 12:20:01.876 3: CUL_HM set vccu hmPairForSec 60
2016.09.09 12:20:01.909 4: WEB_192.168.1.72_43588 GET /fhem?detail=vccu&fw_id=; BUFLEN:0
2016.09.09 12:20:01.962 4: name: /fhem?detail=vccu&fw_id= / RL:5326 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.09.09 12:20:02.645 4: WEB_192.168.1.72_43588 GET /fhem?cmd={ReadingsVal(%22vccu%22,%22virtual%22,%22%22)}&XHR=1; BUFLEN:0
2016.09.09 12:20:02.652 4: name: /fhem?cmd={ReadingsVal(%22vccu%22,%22virtual%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.09.09 12:20:02.662 4: WEB_192.168.1.72_43588 GET /fhem?cmd={AttrVal(%22vccu%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2016.09.09 12:20:02.668 4: name: /fhem?cmd={AttrVal(%22vccu%22,%22room%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.09.09 12:20:02.789 4: WEB_192.168.1.72_43588 GET /fhem?XHR=1&inform=type=status;filter=vccu;since=1473416400;fmt=JSON&fw_id=976×tamp=1473416402754; BUFLEN:0
2016.09.09 12:20:08.287 2: CUL_HM Unknown device HM_3515DA is now defined
2016.09.09 12:20:08.325 2: autocreate: define HM_3515DA CUL_HM 3515DA
2016.09.09 12:20:08.329 2: autocreate: define FileLog_HM_3515DA FileLog ./log/HM_3515DA-%Y.log HM_3515DA
2016.09.09 12:20:08.963 3: CUL_HM pair: HM_3515DA pushButton, model HM-Dis-WM55 serialNr
2016.09.09 12:20:20.755 4: HMLAN_ack: timeout - clear queue
2016.09.09 12:20:22.311 4: WEB_192.168.1.72_43592 POST /fhem?cmd=save&XHR=1&fw_id=976; BUFLEN:0
2016.09.09 12:20:22.347 4: WriteStatefile HM_3515DA_Dis_01 peerList: Missing TIME, using current time
2016.09.09 12:20:22.456 4: name: /fhem?cmd=save&XHR=1&fw_id=976 / RL:52 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.09.09 12:20:30.192 4: Connection closed for WEB_192.168.1.72_43588: EOF
2016.09.09 12:20:30.206 4: WEB_192.168.1.72_43592 GET /fhem?room=CUL%5fHM; BUFLEN:0
2016.09.09 12:20:30.268 4: name: /fhem?room=CUL%5fHM / RL:1644 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.09.09 12:20:30.977 4: WEB_192.168.1.72_43592 GET /fhem?XHR=1&inform=type=status;filter=room=CUL%5fHM;since=1473416429;fmt=JSON&fw_id=978×tamp=1473416430941; BUFLEN:0
2016.09.09 12:20:31.552 4: SetSavedDesTemp exec {my_StoreDesTemp($NAME, $EVENT)}
2016.09.09 12:20:35.049 4: WEB_192.168.1.72_43590 POST /fhem?cmd.HM_3515DA=set%20HM_3515DA%20getConfig&room=CUL_HM&XHR=1&fw_id=978; BUFLEN:0
2016.09.09 12:20:35.490 3: CUL_HM set HM_3515DA getConfig
2016.09.09 12:20:35.495 4: name: /fhem?cmd.HM_3515DA=set%20HM_3515DA%20getConfig&room=CUL_HM&XHR=1&fw_id=978 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.09.09 12:20:36.821 4: SetBatteryStatus exec {my_StoreBatteryStatus($NAME, $EVENT)}
2016.09.09 12:20:36.822 1: my_StoreBatteryStatus      ignoring Device: HM_3515DA
2016.09.09 12:20:37.206 4: SetBatteryStatus exec {my_StoreBatteryStatus($NAME, $EVENT)}
2016.09.09 12:20:37.208 4: SetBatteryStatus exec {my_StoreBatteryStatus($NAME, $EVENT)}
2016.09.09 12:20:42.856 4: WEB_192.168.1.72_43590 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2016-09.log; BUFLEN:0


Wenn du noch was brauchst einfach melden...

Macht es Sinn das Display bei mir auf meinem Testsystem ("Spezial-CUL") anzumelden?
Oder auf dem HMUART-System?

Gruß, Joachim

[KillVirus]

Hallo Dog_Martin,

ich habe ein ähnliches/gleiches? Problem.
https://forum.fhem.de/index.php/topic,43022.0.html

Woran lag es jetzt bei dir?
Leider habe ich deine Aussage jetzt nicht so genau verstanden. Das tauschen der /dev/ttyAMA* kam ja erst durchs flashen oder?

Dank & Gruß Marcus