[gelöst] Newbie-Frage HM und AES

Begonnen von frust, 24 November 2017, 09:51:20

Vorheriges Thema - Nächstes Thema

frust

Hallo zusammen,
ich binneu bei FHEM und versuche gerade meine erste HomeMatic ans laufen zu bekommen.
Den nanoCUL <--> Heizkörperthermostat hatte ich zu pairen leicht geschafft.
Probleme macht mir der Fensterkontak HM-SEC-SCo. Er paired sich einfach nicht, sondern steht seit Tagen auf

R-pairCentral set_0xABCDEF

Was wohl bedutet, dass das pairing nicht geklappt hat.
Die Frage nun:
Der Fensterkontakt kommt ja mit eingeschaltetem AES.
  * Muss dieses zum pairen schon funktionieren?
  * Muss das Device gepaired sein, um AES abzuschalten?
  * ist der Default-AES-Key in FHEM drin, oder muss ich den irgendwo setzen?

Momentan funktioniert die Kommunikation mit den HM Geräten scheinbar gar nicht richtig,
ich bekomme nur protState CMDs_done_Errors: 1 nachdem ich lange Zeit CMDs_pending gesehen habe.
Mein HM-CC-RT-DN zeigt MISSING ACK und 250 CMDs_pending (wachsend)

Funkverbindung scheint in Ordnung:
rssi_at_nanoCUL avg:-54.5 lst:-55.5 max:-52.5 min:-60 cnt:856
rssi_nanoCUL   cnt:2 min:-48 max:-48 lst:-48 avg:-48


Ich habe folgende Hard/Software Raspberry PI,
433 MHz CUL mit SDUINO 3.3.1 (für Thermometer und so)
868 MHz CUL mit culfw-1.67 (für HomeMatic)
Software ist
Latest Revision: 15491

File                 Rev   Last Change

fhem.pl              15482 2017-11-23 10:07:05Z rudolfkoenig
90_at.pm             14995 2017-09-03 14:23:14Z rudolfkoenig
98_autocreate.pm     15377 2017-11-01 16:59:23Z rudolfkoenig
00_CUL.pm            15027 2017-09-08 09:11:43Z rudolfkoenig
10_CUL_HM.pm         15457 2017-11-19 18:18:18Z martinp876
14_CUL_TCM97001.pm   15367 2017-10-31 17:44:02Z bjoernh
98_dummy.pm          12700 2016-12-02 16:49:42Z rudolfkoenig
91_eventTypes.pm     14888 2017-08-13 12:07:12Z rudolfkoenig
01_FHEMWEB.pm        15328 2017-10-27 10:51:17Z rudolfkoenig
92_FileLog.pm        14888 2017-08-13 12:07:12Z rudolfkoenig
10_FS10.pm             331 2017-06-23 17:00:00Z v3.3-dev
10_FS20.pm           14888 2017-08-13 12:07:12Z rudolfkoenig
98_help.pm           15223 2017-10-10 10:14:24Z betateilchen
98_HMinfo.pm         15458 2017-11-19 18:20:37Z martinp876
10_IT.pm             14852 2017-08-06 08:48:24Z bjoernh
91_notify.pm         14888 2017-08-13 12:07:12Z rudolfkoenig
14_SD_WS.pm             39 2017-09-08 22:00:00Z v3.3-dev
00_SIGNALduino.pm    10488 2017-11-19 11:00:00Z v3.3.3-dev
# $Id: 90_SIGNALduino_un.pm 15479 2016-01-28 20:00:00 dev-r32 $
99_SUNRISE_EL.pm     14888 2017-08-13 12:07:12Z rudolfkoenig
98_SVG.pm            14888 2017-08-13 12:07:12Z rudolfkoenig
98_telnet.pm         15006 2017-09-05 09:37:33Z rudolfkoenig
98_update.pm         15377 2017-11-01 16:59:23Z rudolfkoenig
99_Utils.pm          13259 2017-01-28 17:39:39Z rudolfkoenig
98_version.pm        15140 2017-09-26 09:20:09Z markusbloch
98_weblink.pm        14888 2017-08-13 12:07:12Z rudolfkoenig

Blocking.pm          15412 2017-11-09 14:34:29Z rudolfkoenig
Color.pm             11159 2016-03-30 16:08:06Z justme1968
DevIo.pm             14933 2017-08-20 14:21:58Z rudolfkoenig
HMConfig.pm          15337 2017-10-29 06:43:02Z martinp876
HttpUtils.pm         15434 2017-11-15 13:21:28Z rudolfkoenig
RTypes.pm            10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm     12935 2017-01-02 19:51:46Z rudolfkoenig
TcpServerUtils.pm    14862 2017-08-07 15:16:03Z rudolfkoenig

fhemweb.js                 15228 2017-10-10 17:34:56Z rudolfkoenig

libcrypt-rijndael-perl                1.13-1+b2

Beta-User

Hallo frust,

ich hoffe, der Username ist nicht anlaßbezogen gewählt, jedenfalls willkommen hier im Forum...

Zwei Ansätze:
- Manchmal reicht es nach meiner Erfahrung, ein getConfig nachzulegen und ggf. den Kontakt 1-2x auszulösen, damit er aufwacht  (oder Knöpfchen drücken).
- Könnte auch mit dem hier zu tun haben: https://forum.fhem.de/index.php/topic,79858.0/topicseen.html

Gruß und viel Erfolg (und Freude!) mit FHEM.

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frust

Also den BUG habe ich schon ausgebaut (alte Version verwendet)

Wenn die Devices Broadcasts versenden kommen diese prima am CUL an.
Wenn der CUL Kommandos versendet stehen sie auf CMDs_pending, später auf MISSING ACK.
Der Heizkörperthermostat ist gepaired, nimmt abe keine Änderungen an,
der Fensterkontakt ist (vermutlich) nicht mal gepaired (R-pairCentral ist aus den Readings verschwunden).
Auf getConfig reagiert auch der Fensterkontakt mit CMDs_pending.

Irgendwas ist doch da faul !?
Wie kann ich das weiter eingrenzen? Gibt es eine andere Debug-Möglichkeit als "attr verbose 5" ?

darkness

#3
Nur so zur Sicherheit:

Zitatwird generell das Perl-Modul Crypt::Rijndael (Debian: libcrypt-rijndael-perl) benötigt

Das ist installiert?

wer lesen kann... Habe es eben gesehen  ::)

MadMax-FHEM

libcrypt-rijndael-perl ist installiert!?
ok, dann nehm ich das auch raus... ;)
...Rest bleibt...

Anderes Thema: warum nehmen (immer alle) viele CUL in Verbindung mit Homematic!?

Es gibt (unzählige) Threads bzgl. Problemen mit Fensterkontakt (und anderen HM-Komponenten) unter Nutzung eines CUL...

Und ja: der Standardschlüssel ist in fhem und ja eigentlich kann/sollte CUL das können (vors. siehe oben)...

Aber wie gesagt es ist generell nicht ratsam einen CUL mit Homematic zu nutzen...

Besser (gleich/bald) umsteigen auf ein Original-IODev (z.B.:  https://www.elv.de/homematic-funkmodul-fuer-raspberry-pi-bausatz.html / kann auch per USB, WLAN, ... betrieben werden / https://forum.fhem.de/index.php/topic,54511.0.html).

Evtl. auch mal einen Blick auf die "Spezial-FW" werfen: https://forum.fhem.de/index.php/topic,24436.0.html
(Erläutrung etc. am Anfang und neueste Version am Ende)

Ansonsten wie bereits geraten: getConfig und Knöpfchen drücken... Vielleicht reicht das ja (mit etwas Glück)...

Viel Erfolg, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Zitat von: darkness am 24 November 2017, 11:59:51
wer lesen kann... Habe es eben gesehen  ::)
Hatte bei der ersten Antwort auch schon angefangen zu tippen, bevor ich diese klitzekleine wichtige Bemerkung gesehen habe, das aber nur am Rande...

Zum eigentlichen:
OK, und es sieht auch so aus, als wären die IOs USB-mäßig sauber zugeordnet. Der CUL scheint ja auch zu funktionieren, sonst würde der RT-DN nicht einen RSSI-Wert melden...

hmmm..., zwei weitere Gedanken: Es gab hier jüngst zwei -möglicherweise sehr verschiedene Probleme - mit dem Modul. Evtl. solltest du die Version von mgernoth mit dem Patch von betateilchen kombinieren.

Dann würde ich nochmal das pairing versuchen, am besten mit pair-serial. Vorher aber bei allen Devices ein clear all durchführen, damit da wirklich nichts mehr in der pipeline ist. Eventuell mußt du auch sicherstellen, dass nicht die ganzen Credits flöten sind und ggf. schlicht ein wenig warten.

Wenn alles nichts hilft (wei von Joachim vorgeschlagen): Die timing-optimierte Variante der culfw verwenden (oder ein anderes Interface - mein Pi-Modul (RPI-PCB-irgendwas) hängt z.B. an einem USB-seriell-Wandler.
Aber prinzipiell sollte das auch mit einem CUL gehen, sind ja nur 2 devices...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

MadMax-FHEM

Zitat von: Beta-User am 24 November 2017, 12:05:53
Hatte bei der ersten Antwort auch schon angefangen zu tippen, bevor ich diese klitzekleine wichtige Bemerkung gesehen habe, das aber nur am Rande...

Dann sind wir ja schon (fast) zu dritt ;)


Zitat von: Beta-User am 24 November 2017, 12:05:53
Aber prinzipiell sollte das auch mit einem CUL gehen, sind ja nur 2 devices...

Ja jetzt aber wenn es dann mehr sind und es weiterhin nicht einfach bleibt mit CUL...
...ist ein früher Umstieg vielleicht nicht so schlecht...

Was sich auch empfiehlt ist das Anlegen einer vccu: https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU

Denn Sinn erkennt man mit einem CUL und 2 Devices natürlich nicht (gleich) aber es hat auch in dieser Minimalkonfiguration Vorteile (z.B. eigener AES-Schlüssel oder Nachbarn mit HM oder oder oder) und wenn später ein IODev getauscht werden soll oder wegen fehlender Funkausleuchtung erweitert werden soll ist das dann ganz einfach machbar...
...schaden tut es mal nicht...
(https://forum.fhem.de/index.php?topic=28568.0)

Aber wenn man Zeit hat und Lust zu spielen kann man auch noch eine Weile damit rumtun...
...auf jeden Fall lernt man so einiges!

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Das mit de VCCU ist schon ein guter Hinweis, nur:

Wenn etwas in der Basis nicht funktioniert (hier das pairen mit dem CUL) wird durch diese weitere Ebene nur die Komplexität erhöht. Das würde ich daher (erst mal!) lassen, und ein AES Key dürfte auch nicht davon abhängig sein.

Und: Vor meinem Umstieg auf VCCU+Pi+Modul hatte ich 12+ RT-DN's + noch mehr FK's und weiteren "Gruscht" im Einsatz zusammen mir "nur" einem CUL (incl. hakeligem Update der RT-Firmware). Jedenfalls, wenn sonst "die Luft sauber" ist, sollte das (mit den RSSI-Werten sowieso) schon klappen. Hinterher sieht man ggf. weiter (und da sind die Hinweise schon richtig).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frust

#8
SO!
Nun hat das pairen des Fensterkontakts geklappt.
Was habe ich gemacht:
  1.) neue Firmware runtergeladen (TSCUL -->https://forum.fhem.de/index.php/topic,24436.msg714173.html#msg714173)
  2.) dazugehörige *.pm Dateien installiert
  4.) fhem angehalten (service fhem stop)
  3.) fhem.cnf geändert: define nanoCUL TSCUL /dev/serial/by-path/.....
  4.) Firmware auf den nanoCUL installiert (nicht über fhem; hat nicht geklappt)
       avrdude -p atmega328p -P /dev/serial/by-path/platform-20980000.usb-usb-0:1.4:1.0-port0 -c arduino -b 57600 -U flash:w:/opt/fhem/FHEM/firmware/TSnanoCUL.hex
  5.) service fhem start
  6.) set WC_Fensterkontakt clear all
  7.) Neu gepaired mit set nanoCUL pairSerial OEQxxxxx
  8.) 2-3-mal das Knöpfchen am Fensterkontakt betätigt.

(vielleicht ist das für andere Neulinge hilfreich)

PUH! Pairing erfolgreich. Nebenbei hat der Heizkörperthermostat die geänterten Temperaturlisten akzeptiert (!)

Jedoch: nach wie vor sammeln sich massenweise CMDs_pending.

Kann ich rausfinden, ob der 868MHz Bereich bei mir gestört ist??

Nachtrag: im log sehe ich: 2017.11.24 15:20:58 3: TSCUL_ParseTsHM: nanoCUL HM repeat failed to 5F8FB4/WC_HKThermo:  468260 A F109 04760548 00 0C 61 A441 221133 5F8FB4 010200 _sfail _noAnsw
sagt das jemandem was?

MadMax-FHEM

Zitat von: frust am 24 November 2017, 15:29:44
SO!
Nun hat das pairen des Fensterkontakts geklappt.
Was habe ich gemacht:
  1.) neue Firmware runtergeladen (TSCUL -->https://forum.fhem.de/index.php/topic,24436.msg714173.html#msg714173)
  2.) dazugehörige *.pm Dateien installiert
  4.) fhem angehalten (service fhem stop)
  3.) fhem.cnf geändert: define nanoCUL TSCUL /dev/serial/by-path/.....
  4.) Firmware auf den nanoCUL installiert (nicht über fhem; hat nicht geklappt)
       avrdude -p atmega328p -P /dev/serial/by-path/platform-20980000.usb-usb-0:1.4:1.0-port0 -c arduino -b 57600 -U flash:w:/opt/fhem/FHEM/firmware/TSnanoCUL.hex
  5.) service fhem start
  6.) set WC_Fensterkontakt clear all
  7.) Neu gepaired mit set nanoCUL pairSerial OEQxxxxx
  8.) 2-3-mal das Knöpfchen am Fensterkontakt betätigt.

(vielleicht ist das für andere Neulinge hilfreich)

PUH! Pairing erfolgreich. Nebenbei hat der Heizkörperthermostat die geänterten Temperaturlisten akzeptiert (!)

Gratuliere!

Evtl. dann den Thread als gelöst kennzeichnen, umbenennen in beispielsweise: [gelöst] Newbie-Frage HM und AES



Zitat von: frust am 24 November 2017, 15:29:44
Jedoch: nach wie vor sammeln sich massenweise CMDs_pending.

Kann ich rausfinden, ob der 868MHz Bereich bei mir gestört ist??

cmds_pending ist (eine zeitlang) normal: es sind Wakeup-Devices, da findet die Abarbeitung der cmds (Templisten, getConfig, ...) wenn sie aufwachen oder aufgeweckt werden (Knöpfchen drücken) statt.

Sollte aber so nach einigen (10min) weg sein, je nachdem wie viele cmds übertragen werden sollen...


Zitat von: frust am 24 November 2017, 15:29:44
Nachtrag: im log sehe ich: 2017.11.24 15:20:58 3: TSCUL_ParseTsHM: nanoCUL HM repeat failed to 5F8FB4/WC_HKThermo:  468260 A F109 04760548 00 0C 61 A441 221133 5F8FB4 010200 _sfail _noAnsw
sagt das jemandem was?

Würde ich mal im Thread posten wo die FW her ist.
Ich denke Ansgar hat dann schnell eine Antwort...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

frust


Das FHEM ist ja derartig umfangreich, dass man erstmal den Wald vor lauter Bäumen nicht sieht.

Zitat2017.11.24 15:20:58 3: TSCUL_ParseTsHM: nanoCUL HM repeat failed to 5F8FB4/WC_HKThermo:  468260 A F109 04760548 00 0C 61 A441 221133 5F8FB4 010200 _sfail _noAnsw
Das hat sich gelöst. Ich hatte da mal ein Beispiel für einen virtuellen Fensterkontakt abgetippt. Die ID 221133 brachte mich auf die richtigr Spur :-)
Das hatte es irgendwie in die aktuelle Konfiguration geschafft.

Auf jeden Fall vielen Dank an alle Ratgeber!

MadMax-FHEM

Zitat von: frust am 24 November 2017, 16:42:03
Das FHEM ist ja derartig umfangreich, dass man erstmal den Wald vor lauter Bäumen nicht sieht.

Jep!

Das ist ja das Tolle! :)


Zitat von: frust am 24 November 2017, 16:42:03
Auf jeden Fall vielen Dank an alle Ratgeber!

Bitte gerne!

Viel Spaß noch, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Zitat von: frust am 24 November 2017, 16:42:03
Das FHEM ist ja derartig umfangreich, dass man erstmal den Wald vor lauter Bäumen nicht sieht.
Du machst das schon gut mit dem Einlesen, das sieht man (leider) selten. Der Wald wird schon noch eine Struktur bekommen, da bin ich sicher ;) . Und Fragen stellen, ist ja erlaubt (nächstes Mal wird der Hinweis auf das installierte perl-Modul sicher prominenter plaziert sein ::) )...

Jetzt dürfte es an der Zeit sein, das Thema VCCU nochmal in Erinnerung zu rufen. Du magst nicht unbedingt gleich den Nutzen erkennen, aber die allermeisten FHEMinisten dürften der Ansicht sein, dass das sinnvoll ist.

Wenig Frust weiterhin!

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files