GELÖST Temperatur HM-CC-RT-DN lässt sich nur mit LAN-Verbindung ändern

bdy · 21 Januar 2016, 00:04:12

Guten Tag,

meine im Profil beschriebene Konfiguration hatte ich vor ca. 1 Jahr dank der vielen Wikis und Forenartikel relativ schnell aufgebaut. Alles lief 1 Jahr völlig störungsfrei, bis plötzlich (ohne dass am System etwas gemacht wurde) die per FHEMWEB eingestellten Temperaturen für die Homematic HM-CC-RT-DN nicht umgesetzt wurden. Im "State" stand dauerhaft "set desired-temp xy,zz". Da 1 Tag zuvor ein Stromausfall war, hatte ich Bedenken bezgl. Inkonsistenzen und beschloss, das System kpl. (also auch mit akuellem Debian) neu aufzubauen.

Der Aufbau erfolgte zunächst mit LAN-Anschluss. Nach 2 Stunden lief alles wie zuvor. Nun kam das WLAN (Edimax-Adapter) dran. Als Laie orientierte ich mich am Beitrag in https://www.elektronik-kompendium.de/sites/raspberry-pi/1912221.htm. Schließlich stoppte ich FHEM, fuhr den RPI runter und startete alles neu.
Der Webaufruf erfolgte jetzt unter der WLAN IP-Adresse. Die Temperatur des HMS wurde angezeigt, alle Schalter funktionierten einwandfrei, auch die von den Thermostaten gelieferten Infos wie Temperatur und Valve waren plausibel. Was wieder nicht klappte, war die Temperatureinstellung an den HM-CC-RT-DN. Die gewünschten neuen Temperaturen wurden nicht weitergegeben, der State blieb auf "desired-temp xx,zz". Das Zurückgehen auf den LAN-Anschluss änderte hieran nichts.
Ein weiterer Neuiaufbau führt zum gleichen Ergebnis, im LAN klappt alles, nachdem auf WLAN umgestellt wird, werden Temperaturänderungen bei den Homematic nicht akzeptiert.

Auf den ersten Blick sieht alles nach einem Problem des WLAN Adapters aus, auf den zweiten Blick ist dies jedoch sehr fraglich, da ja alle Schalter angesteuert werden können und auch das HMS100 TF funktioniert.

Nach vielen Tagen des Probierens bin ich hier als ziemlicher Laie am Ende und hoffe, dass jemand das Problem irgendwie kennt oder zumindest kanalisieren kann.
Ferner würde mich interessieren, wie ich meine eingestellten Änderungsanforderungen bei den Thermostaten zurücksetzen kann, um zumindest wieder auf den LAN-Betrieb zurückzugehen. Das Rückspielen des Backups ändert den Zustand leider nicht. Den State einfach zu überschreiben, ist ja sicherlich auch nicht sinnvoll, da ich dem "getstate" entnommen habe, dass da ja viele Werte drinstehen.

Ich hoffe, dass mir hier jemand bei den beiden Fragen weiterhelfen kann. Für mögliche Ideen vielen Dank im Voraus.

bdy

Hollo · 21 Januar 2016, 09:31:00

Zitat von: bdy am 21 Januar 2016, 00:04:12
...Da 1 Tag zuvor ein Stromausfall war, hatte ich Bedenken bezgl. Inkonsistenzen und beschloss, das System kpl. (also auch mit akuellem Debian) neu aufzubauen...

Warum? Funktionierte/lief Dein Debian nicht mehr... dann hättest Du auch nicht drauf zugreifen können.
Woher kommt diese Meinung, dass 1x Netzausfall das System lahm legt?

Zitat...Was wieder nicht klappte, war die Temperatureinstellung an den HM-CC-RT-DN...
Das Zurückgehen auf den LAN-Anschluss änderte hieran nichts.
Ein weiterer Neuiaufbau führt zum gleichen Ergebnis, im LAN klappt alles, nachdem auf WLAN umgestellt wird...

Irgendwie widerspricht sich das etwas.
Warum wundert mich das nicht?

Laut Deiner config übermittelst Du die Befehle doch per USB an die Homematic-Geräte (und NICHT per LAN).
Dementsprechend hat das LAN nach dem Ändern der Temp im WebIF nichts mehr damit zu tun.

sinngemäßer Ablauf:

Änderung im WEBIF <---> LAN <---> Raspi <---> HM-CFG-USB <---> HM-CC-RT-DN

Zitat...Auf den ersten Blick sieht alles nach einem Problem des WLAN Adapters aus...

Wenn Du per entsprechender IP auf das Webfrontend zugreifen kannst, muss Dein jeweiliger Netzwerkadapter funktionieren.
Es sieht eher so aus, als ob Du Homematic nur empfangen aber nicht mehr senden kannst.
- Kann es sein, dass Du bei der Einrichtung des WLAN-Adapters etwas falsch machst und sich USB-WLAN und USB-HM gegenseitig in die Quere kommen?
- Werden beide USB-Devices beim Neustart korrekt erkannt und initialisiert?
- werden nach der Umstellung auf WLAN die Homematic-Werte wirklich aktualisert oder stehen da nur die alten von vor dem Reboot?

Zitat...Ferner würde mich interessieren, wie ich meine eingestellten Änderungsanforderungen bei den Thermostaten zurücksetzen kann...

Guck mal bei Deinen Thermostaten nach, da sollte dann jetzt "CMDs pending" stehen. Dann findest Du auch ein "clear msgEvents", um die gesammelten Befehle "wegzulöschen".

Ohne genauere Infos (Konfiguration, Fehlermeldungen, was steht im LOG) ist das schwierig.
Im LOG sollten z.B. Infos stehen, wenn der HM-USB öfter disconnected, weil es da ein Konfig-Problem am USB gibt.

isy · 21 Januar 2016, 18:48:58

Ist denn vom Fhem Server aus die 127.0.0.1 per ping erreichbar?
Ich habe keinen HM USB eingebunden, aber im Wiki ist diese IP hinterlegt. Vielleicht in dieser Richtung suchen?
Gruß Helmut

bdy · 24 Januar 2016, 22:58:12

Danke für die Hinweise.
Das Attr "clear msgEvents" hat mich ein Stück weiter gebracht.
Entscheidend war jedoch, dass der hmcfgusb häufig auf "disconnect" stand, obwohl er 10 Minuten zuvor noch "open" war.
Im LOG zeigt sich dies bei Neustart als "Can't connect to 127.0.0.1:1000: Connection refused".
Ich denke also, dass der hmcfgusb1 defekt ist, zumindest einen Wackelkontakt hat. Bei meinem originär geschilderten Problem habe ich vermutlich beim Reinstecken des WLAN-Adapters jeweils den hmcfgusb mit bewegt und er kam in eine andere Position.
Ich probiere es mit einem neuen hmcfgusb 2 aus.

Gruß, bdy

isy · 24 Januar 2016, 23:01:17

Der Port 1000 - ist das richtig?
Denke, eher kein Port, oder?

bdy · 24 Januar 2016, 23:58:16

Hallo pv_is,
der Port ist richtig, das hatte ich "http://paradies.aufdemdach.net/index.php/hausautomation/92-7-homematic-usb-adapter" entnommen.
Der Beweis ist der, dass es im Moment wieder läuft. Da ich den hmcfgusb problemlos in Windows konfiguriert bekam (Wackel- und Erschütterungsversuchen), ist dieser Stick wohl nicht schuld. Jetzt muss ich mir die USB-Stecker des RPI mal genauer ansehen.
Gruß, Bdy

Nachtrag: Tatsächlich habe ich an den RPI USB-Steckern Kontaktprobleme. Die habe ich inzwischen gelöst, jetzt kommt wieder die Untersuchung meines ursprünglichen Problems dran (WLAN-Adapter und hmcfgusb kommen sich in die Quere)

Deudi · 25 Januar 2016, 07:25:36

Beim Pi geht bei zwei angesteckten USB Geräten öfters die Stromversorgung in die Knie. Hast du einen USB Hub da, dann hänge den mal dazwischen.

Prof. Dr. Peter Henning · 25 Januar 2016, 08:31:08

1. NIEMALS ein Linux-System "komplett neu aufsetzen", nur weil ein paar Dinge nicht funktionieren. "Inkonsistenzen" wie bei Windows können da nur sehr selten auftreten und sind gut erkennbar.

2. Es ist in der Tat nicht ausgeschlossen, dass WLAN und USB sich auf einem Raspberry ins Gehege kommen - die hängen nämlich an derselben Hardware. Es ist auch durchaus möglich, dass dies nach einem Wechsel des Betriebssystems passiert, weil dessen Konfiguration leicht anders ist.

3. Im vorliegenden Fall zweifele ich erst einmal an, dass tatsächlich keine weitere Änderung durchgeführt wurde. Irgendetwas umgesteckt , so dass die Nummerierung des USB-Adapters sich geändert hat ?

LG

pah

rr725 · 25 Januar 2016, 13:33:26

Zitat von: Prof. Dr. Peter Henning am 25 Januar 2016, 08:31:08
2. Es ist in der Tat nicht ausgeschlossen, dass WLAN und USB sich auf einem Raspberry ins Gehege kommen - die hängen nämlich an derselben Hardware.

das ist unfug. ich habe mittlerweile zig raspis (gut und gerne 20 an der Zahl) voll bestückt, teilweise mit voll bestückten usb hubs (bluetooth und wlan). an nicht einem gab es wlan probleme weil "sich etwas ins gehege kam".

Prof. Dr. Peter Henning · 25 Januar 2016, 14:19:58

Unfug ist, von 20 funktionierenden Konfigurationen auf eine unbekannte Konfiguration zu schließen.

Google liefert lediglich 550.000 Hits bei der Suche nach "raspberry pi wlan usb problem" - und etliche davon haben mit der Unzulänglichkeit des USB-Stack zu tun.

pah

rr725 · 25 Januar 2016, 15:13:42

Zitat von: Prof. Dr. Peter Henning am 25 Januar 2016, 14:19:58
Unfug ist, von 20 funktionierenden Konfigurationen auf eine unbekannte Konfiguration zu schließen.

Unfug ist, von einer unbekannten Konfiguration, welche funktionsfähig war, von einem grundsätzlichen USB Problem auszugehen.
Ist die gleiche Diskussion wie mit dem cross over kabel.

Prof. Dr. Peter Henning · 25 Januar 2016, 17:07:11

Vlt. mal den Ausgangspost genauer lesen:

Zitatdas System kpl. (also auch mit akuellem Debian) neu aufzubauen

Soviel zu "funktionsfähiger Konfiguration". Im Übrigen: Immer schön bei der Sache bleiben.

pah

Hollo · 25 Januar 2016, 22:44:58

Es schweift "etwas" vom eigentlichen Problem ab.

Zitat von: rr725 am 25 Januar 2016, 15:13:42
...von einem grundsätzlichen USB Problem auszugehen...

Grundsätzlich hat meines Wissens niemand gesagt; es ging um die Möglichkeit, dass es etwas damit zu tun haben könnte.

Stril · 25 Januar 2016, 22:54:06

Hallo! Ich würde damit beginnen, einen aktiven USB Hub dazwischen zu hängen, um Probleme mit der Leistungsaufnahme auszuschließen.

bdy · 26 Januar 2016, 23:26:39

Das Problem ist gelöst, es läuft alles wieder, auch mit WLAN.
Ich habe alles neu installiert. Da ich nicht sonderlich tief drinstecke, schreibe ich letztlich Vorschläge weitgehend ab.
Diesmal habe ich mich bei der WLAN Einrichtung nach einem anderen Vorschlag gerichtet.
Bisher:
auto wlan0
allow-hotplug wlan0
iface wlan0 inet manual
......
Neu:
auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
.....
Ehrlich gesagt, kann ich die Parameter nicht interpretieren, aber es klappt.

Zwischendrin bin ich auch noch in eine Beispielfalle getappt. Beim Start von hnmlan mit
/opt/hmcfgusb/hmland -d -p 1000
entspricht die "1000" vermutlich einem Port. Hier hatte ich aus Beispielen die 1234 gedankenlos übernommen.

Eien Erklärung für mein Erstproblem (nach 1 jahr störungsfreiem Betrieb -garantiert ohne Änderungen- klappte Temperatureinstellung Hoemmatic nicht mehr) habe ich zwar nicht mehr bekommen, aber das lässt sich nach meiner anfänglichen Neuinstallationseuphorie jetzt auch nicht mehr rekonstruieren.

Danke für die Diskussion, aus der ich interessnate Anregungen entnehmen konnte.

Bdy