HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi

Begonnen von chipmunk, 18 September 2015, 13:32:39

Vorheriges Thema - Nächstes Thema

hauwech

Zitat von: hauwech am 17 März 2023, 10:39:51Hallo zusammen,
ich hatte am Wochenende einen kurzen Stromausfall, seitdem war einer meiner HM-MOD-RPI-PCB UARTs auf Raspi nicht mehr erreichbar. Mein erster Verdacht am Raspi richtet sich immer auf die SD-Karte. ...
Hallo nochmal,
ich wollte meinen Beitrag ergänzen. Seit dem erwähnten Stromausfall ärgert mich der UART. Nachdem er wieder ein paar Tage lief, konnte fhem wieder nicht mehr verbinden (... did not respond...). Der Service läuft, der Raspi ist erreichbar. Ich habe den Raspi jetzt mal an einen anderen Switch gesteckt. Da hat fhem sofort connecten können, vielleicht auch wegen des Neustarts. Ich hatte vor einiger Zeit mal einen (Consumer-)Switch, der nach einigen Jahren sporadisch immer wieder mal schwer nachvollziehbare Probleme gemacht hat.
Ich werde das ein paar Tage beobachten. Falls es wieder zuverlässig funktionieren sollte, würde ich empfehlen, bei sporadischen Problemen auch mal das Netz drumherum in den Kreis der Verdächtigen aufzunehmen. Falls ich auf dem Holzweg war, werde ich auch das berichten.

Gruß Roland
Fhem auf Intel NUC11TNKi5+M2 NVMe+32GB RAM mit Ubuntu 22.04 LTS

hauwech

Update:
Der UART-Raspi hängt jetzt seit 9 Tagen an einem anderen Switch. Seither ist er noch nicht wieder ausgestiegen. Damit steigt die Wahrscheinlichkeit, daß der Switch, wo er vorher dran war, seit dem Stromausfall doch eine Macke hat, zumindest an diesem Port, wo der Raspi vorher angeschlossen war. Ich werde den Raspi zum Gegencheck jetzt auch nicht mehr zurück stecken. Funktechnisch ist der neue Standort auch gut und ich bin froh, daß alles wieder sauber läuft.
Wie schon festgestellt, schadet es also nicht, bei solchen Problemen auch das LAN mit in Betracht zu ziehen.

Gruß Roland
Fhem auf Intel NUC11TNKi5+M2 NVMe+32GB RAM mit Ubuntu 22.04 LTS

hauwech

#227
Mist. Ich habe mich zu früh gefreut. Seit heute pendelt der UART in fhem wieder zwischen init und disconnected mit "... did not respond" im Log. Raspi rebootet, fhem neu gestartet, fhem-NUC rebootet, keine Chance. Der socat service am Raspi läuft, aber fhem kriegt keinen connect mehr hin. So langsam gehen mir die Ideen aus - und heute habe ich auch keinen Bock mehr. Ich habe zum Glück noch drei weitere UARTS laufen mit etwas schlechterem RSSI, aber es geht. Den vierten habe ich erst kürzlich aufgebaut, als wenn ich's geahnt hätte.  ;D

Morgen kuck' ich mal genauer hin. Wie könnte man denn von der fhem-Maschine aus manuell testen, ob der Port am Raspi Verbindungen annimmt? Blöde Frage, es war wohl stressig heute...

Gruß Roland
Fhem auf Intel NUC11TNKi5+M2 NVMe+32GB RAM mit Ubuntu 22.04 LTS

hauwech

Ich habe den socat Port tcp/4000 mal in mein checkmk mit aufgenommen. Der ist kontinuierlich erreichbar. Am Raspi/UART selbst scheint es nicht zu liegen. Ich kann auch vom NUC aus (auf dem fhem läuft) mit "telnet <remotehost> 4000" eine Verbindung aufbauen.

Service auf raspiuart2 vor der telnet Verbindung:
roland@raspiuart2:~ $ sudo systemctl status hmlangw
● hmlangw.service
  Loaded: loaded (/etc/systemd/system/hmlangw.service; enabled; vendor preset: enabled)
  Active: active (running) since Thu 2023-04-13 08:59:10 CEST; 4s ago
 Main PID: 16675 (socat)
    Tasks: 1 (limit: 2200)
  Memory: 312.0K
  CGroup: /system.slice/hmlangw.service
          └─16675 /usr/bin/socat TCP4-LISTEN:4000,fork,reuseaddr /dev/ttyAMA0,raw,echo=0,b115200

Apr 13 08:59:10 raspiuart2 systemd[1]: Started hmlangw.service.

Dann telnet auf fhem-NUC:
roland@fhem:~$ telnet raspiuart2 4000
Trying 192.168.1.87...
Connected to raspiuart2.zero.local.
Escape character is '^]'.
▒s*▒.f▒
▒▒@▒▒$tW▒l▒▒▒▒▒:▒7▒p▒8▒_2▒▒n▒
                            ▒PM&▒▒uH▒▒▒▒l▒▒sUL▒'▒▒O}▒▒▒v>▒▒^,▒▒▒▒}▒▒▒w"▒<▒
▒▒
  @▒▒▒x2▒V▒f
▒▒@▒=▒yR▒▒"▒▒
▒▒@▒▒PuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTY▒z<`▒,R!'PuTTY-▒▒▒▒▒{=▒▒Z'▒PuTTY▒▒Bϋ

Daß da nur wilder ASCII Salat zurückkommt, ist normal, denke ich.

Service auf raspiuart2 während der telnet session:
roland@raspiuart2:~ $ sudo systemctl status hmlangw
● hmlangw.service
  Loaded: loaded (/etc/systemd/system/hmlangw.service; enabled; vendor preset: enabled)
  Active: active (running) since Thu 2023-04-13 08:59:10 CEST; 5min ago
 Main PID: 16675 (socat)
    Tasks: 2 (limit: 2200)
  Memory: 520.0K
  CGroup: /system.slice/hmlangw.service
          ├─16675 /usr/bin/socat TCP4-LISTEN:4000,fork,reuseaddr /dev/ttyAMA0,raw,echo=0,b115200
          └─17348 /usr/bin/socat TCP4-LISTEN:4000,fork,reuseaddr /dev/ttyAMA0,raw,echo=0,b115200

Apr 13 08:59:10 raspiuart2 systemd[1]: Started hmlangw.service.

Technisch scheint es also zu funktionieren, nur fhem kriegt keine Connection hin, pendelt permanent zwischen init und disconnected. Im fhem Log sehe ich nur:
2023.04.13 09:10:45.953 3: Opening HmUART2 device 192.168.1.87:4000
2023.04.13 09:10:45.971 3: HmUART2 device opened
2023.04.13 09:10:49.978 1: HMUARTLGW HmUART2 did not respond for the 1. time, resending
2023.04.13 09:10:53.012 1: HMUARTLGW HmUART2 did not respond for the 2. time, resending
2023.04.13 09:10:56.018 1: HMUARTLGW HmUART2 did not respond for the 3. time, resending
2023.04.13 09:10:59.026 1: HMUARTLGW HmUART2 did not respond after all, reopening
2023.04.13 09:10:59.029 3: HmUART2 device closed
2023.04.13 09:10:59.078 1: 192.168.1.87:4000 reappeared (HmUART2)
2023.04.13 09:11:03.083 1: HMUARTLGW HmUART2 did not respond for the 1. time, resending
2023.04.13 09:11:06.521 1: HMUARTLGW HmUART2 did not respond for the 2. time, resending
2023.04.13 09:11:09.611 1: HMUARTLGW HmUART2 did not respond for the 3. time, resending
2023.04.13 09:11:12.707 1: HMUARTLGW HmUART2 did not respond after all, reopening
2023.04.13 09:11:12.711 3: HmUART2 device closed
2023.04.13 09:11:13.087 1: 192.168.1.87:4000 reappeared (HmUART2)
2023.04.13 09:11:17.090 1: HMUARTLGW HmUART2 did not respond for the 1. time, resending
2023.04.13 09:11:20.097 1: HMUARTLGW HmUART2 did not respond for the 2. time, resending
2023.04.13 09:11:23.102 1: HMUARTLGW HmUART2 did not respond for the 3. time, resending
2023.04.13 09:11:26.107 1: HMUARTLGW HmUART2 did not respond after all, reopening
2023.04.13 09:11:26.111 3: HmUART2 device closed

Hat vielleicht jemand noch eine Idee? Die anderen drei UARTS laufen problemlos, da kann auch fhem ohne Problem verbinden. Ich habe auch schon ser2net auf dem raspiuart2 getestet, bin aber wieder zurück auf socat, weil das erstens das Problem nicht behebt und zweitens, weil mir die neumodische YAML Konfiguration zu zickig ist. Da muß nur eine Zeilen-Einrückung nicht stimmen, schon haut der Dir das Ding um die Ohren.

Gruß Roland
Fhem auf Intel NUC11TNKi5+M2 NVMe+32GB RAM mit Ubuntu 22.04 LTS

hauwech

Ich werde da irgendwie nicht schlau draus  :(  ::)
Ich habe das fhem device mal gelöscht und neu angelegt - keine Änderung.
Dann habe ich den Raspi stromlos gemacht und auf einen anderen freien Port am Switch gesteckt. Das war dumm, ich hätte nur EINE Änderung machen sollen. Das kommt dann beim nächsten Mal.
Jetzt geht's wieder. Fhem Device "set HmUART2 open" - flupp "open" und alles gut, als wäre nie was gewesen.
Ich habe keine konkrete Idee, wo es klemmen könnte. Der Raspi ist im LAN verfügbar, keine Paketverluste, nix. Der Port 4000 ist von außen erreichbar und antwortet. Das Netzteil - auch ein häufiger Kandidat für Probleme - ist ein original Raspi Netzteil. Das Einzige, was ich beim nächsten Ausfall noch ergänze, ist der Ferritkern am Stromversorgungskabel, den habe ich vergessen. Wobei alle anderen UART Raspis auch ohne den Kern auskommen und keine Probleme machen.
Die SD-Karte ist auch neu. Wenn die Raspis nicht so unverschämt teuer und auch verfügbar wären, würde ich alles komplett neu aufsetzen und daneben hinstecken. Einen UART Bausatz habe ich noch liegen.

Gruß Roland
Fhem auf Intel NUC11TNKi5+M2 NVMe+32GB RAM mit Ubuntu 22.04 LTS

frank

FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

hauwech

Der nächste Versuch kam schneller als gedacht  :)
Ich mußte einmal reopen machen, weil ich bei der Neuanlage des fhem-Devices den hmKey vergessen hatte. Und schon gingen die erfolglosen reconnect Versuche wieder los. Diesmal war ich wenigstens so schlau und habe nur die Stromversorgung am Raspi abgezogen. Danach ging's wieder.
Ich werde mir also doch mal ein neues Raspi Netzteil besorgen. Die sind auch nicht gerade für Langlebigkeit bekannt und ein kurzer Stromausfall kann da wohl auch einen Schaden hinterlassen, besonders, wenn nach einer FI-Auslösung alle Geräte plötzlich wieder Strom kriegen. Vielleicht entstehen da Spannungsspitzen im Netz, die die Schaltnetzteile nicht vertragen.

Gruß Roland
Fhem auf Intel NUC11TNKi5+M2 NVMe+32GB RAM mit Ubuntu 22.04 LTS

hauwech

Zitat von: frank am 13 April 2023, 13:19:19vielleicht läuft ser2net stabiler?
Ser2net hatte ich auf diesem Raspi auch schon getestet: mit den gleichen Effekten. Ich habe auch zwei Raspis, wo der UART über ser2net mit der alten Konfiguration läuft. Mich stört aber die eingeführte zickige YAML Konfiguration. Der kleinste Fehler beim Zeilen-Einrücken wird völlig intolerant abgewiesen. Nur Leerzeichen, keine Tabs... einfach nervig.

Gruß Roland
Fhem auf Intel NUC11TNKi5+M2 NVMe+32GB RAM mit Ubuntu 22.04 LTS

MadMax-FHEM

#233
Du kannst doch mit vcgencmd get_throttled prüfen, ob es Unterspannung gibt/gab.

Und wichtig ist (auch) Spannung!
Es sollten/müssen 5,1-5,2V sein...
Ich hatte auch das Phänomen, dass ein Netzteil wohl die Spannung nicht mehr ausreichend geliefert hat.

Hab jetzt schon bei 2 PIs ein Step-Up dazwischen gehangen.
Hatte Probleme mit meinem RaspBee...
Danach/seit dem ist Ruhe :)

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)

hauwech

Das kannte ich noch nicht. Da kommt bei mir:
roland@raspiuart2:~ $ sudo vcgencmd get_throttled
throttled=0x0
roland@raspiuart2:~ $
Muß das nach einem Neustart erst noch Daten sammeln? 0x0 heißt wohl "alles gut", wie hier beschrieben.
Brauchen die Step-Up nicht mehr Spannungsdifferenz zwischen in und out? Ich bin da nicht so sattelfest.  :(

Gruß Roland
Fhem auf Intel NUC11TNKi5+M2 NVMe+32GB RAM mit Ubuntu 22.04 LTS

MadMax-FHEM

0x0 passt.

Es gibt ja 2 Dinge: "aktuelle Störung" und "Störung trat schon mal auf"

Ich frage das regelmäßig per Script ab und setze Readings...

Hmmm, den Step-up (die ich verwende) ist es (wohl) egal.
Step-down ist (wohl) anders, da muss Eingang (immer deutlich) höher sein als Ausgang...

Scheint bei dir aber wohl nicht das Problem zu sein, wenn es bei 0x0 bleibt...

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)

hauwech

So langsam nervt mich der Raspi mit dem HmUART. Der geht nach einer unbestimmten Zeitspanne immer wieder auf disconnected/init - und auch nur einer von Vieren - Es ist kein Muster erkennbar, wieviel Zeit dazwischen liegt. Ich habe jetzt erstmal einen Funkschalter dazwischen, mit dem ich den Raspi ausknipsen kann, wenn er auf cond != ok geht. Eine Lösung ist das natürlich nicht, ich werde mir aber auf keinen Fall einen Raspi3 für 120€ oder noch mehr kaufen zum Testen. Im Wiki bin ich gerade nochmal (wieder  ::) ) auf den möglichen Betrieb mit einem ESP8266 gestoßen. WLAN ist jetzt nicht meine bevorzugte Technik zum Vernetzen, zumal die 8266 gerne mal unter WLAN Schluckauf leiden. Aber zuverlässiger als ein im Minuten-/Stunden-/oder Tagestakt unterbrochener Raspi mit UART wird es allemal sein. Und ein paar Wemos Mini und D1 Boards habe ich rumliegen. Jetzt ärgere ich mich nur, daß ich nicht früher wieder drauf gekommen bin.

Gruß Roland
Fhem auf Intel NUC11TNKi5+M2 NVMe+32GB RAM mit Ubuntu 22.04 LTS

RalfRog

Hi
Die Idee den Raspi per StromAus hart auszuschalten ist vielleicht nicht so gut.
Ich hätte da die Befürchtung, dass früher oder später der Datenträger (SD Karte?) hin ist. Oder zumindest das Dateisystem Schaden nimmt.
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

hauwech

Ich habe eben mal den neuen HmUART Bausatz zusammengelötet und an ein D1 Board mit ESP8266 gesteckt. Ich habe esp-link draufgepackt und ins WLAN eingebunden. Wenn ich den jetzt nach Wiki über Port 23 anspreche, sehe ich das gleiche Theater wie mit dem anderen spinnerten UART: init/disconnected mit "... did not respond..." im Log.
Irgendwas muß ich übersehen. Vielleicht muß ich den Kram mal ein paar Tage liegen lassen.
Dummerweise kann ich seit ein paar Wochen fhem nicht mehr updaten. Nach dem Update startet fhem nicht mehr, es kommt nicht mehr über die JeeLink Initialisierung hinweg, auch wenn ich den vor dem Update disable. Die letzten drei Versuche mußte ich aus dem restoreDir wiederherstellen, daß fhem wieder hochkommt. Aber das gehört nicht hierher, ich habe das aber in dem Zusammenhang hier zu aktualisieren versucht. Die ganzen Jahre vorher hatte ich mit dem Update nie Probleme.
Irgendwann muß ich da mal ran, schon wegen Ubuntu 16.04. Aber der ganze Kram drumrum mit Mosquitto, die ganzen über die Jahre nachinstallierten Perl-Module usw. - das alles wieder hinkriegen, da brauche ich Urlaub.

Gruß Roland
Fhem auf Intel NUC11TNKi5+M2 NVMe+32GB RAM mit Ubuntu 22.04 LTS

hauwech

Zitat von: RalfRog am 14 April 2023, 14:25:01Hi
Die Idee den Raspi per StromAus hart auszuschalten ist vielleicht nicht so gut.
Ich hätte da die Befürchtung, dass früher oder später der Datenträger (SD Karte?) hin ist. Oder zumindest das Dateisystem Schaden nimmt.
Ich weiß, das ist nur ein Strohhalm, bis ich eine richtige Lösung habe. Aber die ESP8266-Geschichte ist wohl auch gestorben, siehe einen Beitrag drüber. >:(  :'(
Fhem auf Intel NUC11TNKi5+M2 NVMe+32GB RAM mit Ubuntu 22.04 LTS