Wie ergibt sich die Begrenzung der maximalen Regexp Einträge der FHEM2FHEM Konfiguration?
ZB:
define F2F_Rasp01 FHEM2FHEM 192.xxx.xxx.xxx:7072:SSL LOG:AB_P_DSFRD.*|AB_P_ST_DT09T04D.*|AB_P_ZPFSD.*|AB_P_ZPHZD.*|AB_P_ZPPSD.*|AB_SSP_ST_DT07T08D.*|AB_SSP_ST_DT12T08D.*|AB_SSP_ST_FHVA3D.*|AB_SSP_ST_HVV3D.*|AB_SSP_ST_FKVA5D.*|AB_ST_FGHZFRD.*|OG2_HZR_ST_PPPFA2D.*|OG2_HZR_ST_PSSPD.*|OG2_HZR_ST_PSWWZPD.*|OG2_HZR_ST_V1D.*|OG2_HZR_ST_V2D.* Passwort
Wird nicht mehr ausgeführt.
Nehme ich drei der LOG Einträge wieder heraus funktioniert die FHEM2FHEM Schnittstelle wieder.
Weiss nicht genau, was mit "Begrenzung der maximalen LOG Einträge" gemeint ist, aber das was du zeigst, wird als Regexp ausgewertet, und wie ueblich gegen name bzw. name:event geprueft. Mir sind keine harten Grenzen beim regexp bekannt. Ich gehe davon aus, dass die Ursache des Problems anderswo zu suchen ist.
Ich habe das schon alles durchgetestet.
Es liegt definitiv eine Begrenzung vor wo auch immer diese herrührt.
Sowie ich zwei Definitionen entferne (zb. OG2_HZR_ST_V1D.*|OG2_HZR_ST_V2D.*) werden alle andern via Remote übertragen.
Ich habe mich derweilen so beholfen das ich eine zweite FHEM2FHEM Remoteschnittstelle konfiguriert habe um alle benötigten Regexp Auswertungen zu übertragen.
Fehler ist jedenfalls von meiner Seite nicht vorhanden. Das habe ich mehrfach geprüft.
Es wäre nur irgendein Hinweis hilfreich, denn bei zu vielen Einträgen werden plötzlich gar keine Daten mehr übertragen und im ersten Moment weiß man nicht wo der Fehler liegt, da die Schnittstelle sich als funktionsfähig zeigt.
Ich kann doch nicht auf was hinweisen, was mAn nicht gibt.
Kannst du bitte in telnet/FHEMWEB, was mit dem Slave (also da, wo die FHEM2FHEM Instanz hinzeigt, nicht da, wo sie definiert ist) folgendes ausfuehren:
{ join("\n", map { $inform{$_}{regexp} } keys %inform) }
und den Rueckgabewert mit deinem Regexp vergleichen?
Soll der gesamte Inhalt vorher wieder in der FHEM2FHEM Konfiguration eingefügt werden?
Originale Remoteanforderung
define F2F_Rasp01 FHEM2FHEM 192.xxx.xxx.xxx:7072:SSL LOG:AB_P_DSFRD.*|AB_P_ST_DT09T04D.*|AB_P_ZPFSD.*|AB_P_ZPHZD.*|AB_P_ZPPSD.*|AB_SSP_ST_DT07T08D.*|AB_SSP_ST_DT12T08D.*|AB_SSP_ST_FHVA3D.*|AB_SSP_ST_HVV3D.*|AB_SSP_ST_FKVA5D.*|AB_ST_FGHZFRD.*|OG2_HZR_ST_PPPFA2D.*|OG2_HZR_ST_PSSPD.*|OG2_HZR_ST_PSWWZPD.*|OG2_HZR_ST_V1D.*|OG2_HZR_ST_V2D.* Passwort
{ join("\n", map { $inform{$_}{regexp} } keys %inform) }
DL2_T04.*|OG2HHSD.*|PHSD.*|PBLSD.*|PSTWD.*
AB_P_PP_STSD.*|AB_P_ZP_S1D.*|OG2_HZR_H_HSD.*|OG2_HZR_P_APSD.*|PBLSD.*
Und aufgeteilte Remoteanforderung
define F2F_Rasp01_1 FHEM2FHEM 192.xxx.xxx.xxx:7072:SSL LOG:AB_P_(DSFRD|ST_DT09T04D|ZPFSD|ZPHZD|ZPPSD).* Passwort
define F2F_Rasp01_2 FHEM2FHEM 192.xxx.xxx.xxx:7072:SSL LOG:AB_SSP_ST_(DT07T08D|DT12T08D|FHVA3D|HVV3D|FKVA5D).*|AB_ST_FGHZFRD.*|OG2_HZR_ST_(PPPFA2D|PSSPD|PSWWZPD|V1D|V2D).* Passwort
{ join("\n", map { $inform{$_}{regexp} } keys %inform) }
AB_P_PP_STSD.*|AB_P_ZP_S1D.*|OG2_HZR_H_HSD.*|OG2_HZR_P_APSD.*|PBLSD.*
DL2_T04.*|OG2HHSD.*|PHSD.*|PBLSD.*|PSTWD.*
FHEM2FHEM uebertraegt im LOG-Mode den im define spezifizierten Regexp an die Gegenstelle, die diesen Regexp unveraendert in %inform eintraegt.
Bei Dir sehe ich in beiden Faellen keine Korrelation zwischen FHEM2FHEM-Definition und inform Inhalt.
Ich gehe davon aus, dass die falsche FHEM-Instanz abgefragt wurde.
ZitatBei Dir sehe ich in beiden Faellen keine Korrelation zwischen FHEM2FHEM-Definition und inform Inhalt.
Verstehe nicht wie du das meinst?
Es kommen doch alle Daten im LOG Mode an die ich benötige, zumindest wenn ich diese aufteile.
Ich muss leider dieses Thema wieder aufgreifen da ich immer wieder über diesen Fehlerfall stolpere.
Folgende Test habe ich durchgeführt.
ccs-ht-rasp01 FHEM2FHEM Konfiguration mit ungekürzten Bezeichnungen
192.168.17.182:7182:SSL LOG:AB_P_DSFRD.*|AB_P_SSSSD.*|AB_P_PP_STSD.*|AB_P_ST_DT09T04D.*|AB_P_ST_PPPA2.*|AB_P_ST_PPPFA2D.*|AB_P_ZPHZD.*|AB_P_ZPPSD.*|DL2.*|HTZ_SDM630M_1.*|NGZ_SDM630M_2.*|OG2_HZR_H_HSD.*|OG2_HZR_P_APSD.*|OG2_HZR_STSP5_HTD.*|OG2_HZR_STSP5_RYD.*|OG2_HZR_NS_APCUEWD.* Passwort
Es erfolgt keine Datenübertragung!
Überprüfung am ccs-ht-rasp02 mit
{ join("\n", map { $inform{$_}{regexp} } keys %inform) }
Ergebnis
AB_P_ZPFSD.*|AB_P_ZPHZD.*|AB_P_ZPPSD.*
ccs-ht-rasp01 FHEM2FHEM Konfiguration mit gekürzten Bezeichnungen
192.168.17.182:7182:SSL LOG:AB_P_(DSFRD|SSSSD).*|AB_P_PP_STSD.*|AB_P_ST_DT09T04D.*|AB_P_ST_PPP(A2|FA2D).*|AB_P_ZPHZD.*|AB_P_ZPPSD.*|DL2.*|(HTZ|NGZ)_SDM630M_(1|2).*|OG2_HZR_(H_HS|P_APS)D.*|OG2_HZR_STSP5_(HT|RY)D.*|OG2_HZR_NS_APCUEWD.* Passwort
Es erfolgt eine Datenübertragung!
Überprüfung am ccs-ht-rasp02 mit
{ join("\n", map { $inform{$_}{regexp} } keys %inform) }
Ergebnis
AB_P_(DSFRD|SSSSD).*|AB_P_PP_STSD.*|AB_P_ST_DT09T04D.*|AB_P_ST_PPP(A2|FA2D).*|AB_P_ZPHZD.*|AB_P_ZPPSD.*|DL2.*|(HTZ|NGZ)_SDM630M_(1|2).*|OG2_HZR_(H_HS|P_APS)D.*|OG2_HZR_STSP5_(HT|RY)D.*|OG2_HZR_NS_APCUEWD.*
AB_P_ZPFSD.*|AB_P_ZPHZD.*|AB_P_ZPPSD.*
So wie sich dieser Fehlerfall darstellt, liegt der Fehler an der Zeichenlänge für die regexp Einträge der FHEM2FHEM Konfiguration, und nicht an der Anzahl der regexp Einträge.
Ich habe leider keine andere Lösung für die Datenübermittlungen zwischen den einzelnen Raspberrys gefunden.
Es wird wahrscheinlich auch bei der zusammen gekürzten Schreibweise der regexp Einträge irgendwann eine Überschreitung der Zeichenlänge erfolgt sein wo es auch hier zu keiner Datenübertragung mehr kommen wird obwohl alles richtig konfiguriert wurde.
Hier wäre zumindest bei der Konfiguration von FHEM2FHEM ein Hinweis bei der Überschreitung der Zeichenlänge hilfreich um nicht den Fehler an der falschen Seite zu suchen.
Es gibt keine absichtliche Begrenzung der Zeichenlaenge in FHEM2FHEM.
Das Problem hier war das Zusammenspiel von SSL, FHEM2FHEM und select in fhem.pl: Die SSL Routinen puffern die nicht abgeholten Daten, deswegen merkt select nicht, dass noch nicht alles gelesen wurde und benachrichtigt deswegen nicht FHEM2FHEM wieder, der in deinem Fall nicht alles auf einmal abgeholt hat. Ohne SSL hat es auch vorher funktioniert.
Ich habe fhem.pl angepasst, damit SSL-Verbindungen zusaetzlich mit pending() geprueft werden. Die Aenderung in fhem.pl ist zwar klein aber grundlegend, und ich hoffe, dass es keine Nebeneffekte hat. FHEM update ist (wie uebich) ab morgen um 8 verfuegbar.
@rudolfkoenig
Da muss man auch erst drauf kommen was da alles einem in die Suppe spukt.
Danke Rudi.
Zitat von: rudolfkoenig am 31 Mai 2018, 13:34:39
Ich habe fhem.pl angepasst, damit SSL-Verbindungen zusaetzlich mit pending() geprueft werden. Die Aenderung in fhem.pl ist zwar klein aber grundlegend, und ich hoffe, dass es keine Nebeneffekte hat. FHEM update ist (wie uebich) ab morgen um 8 verfuegbar.
Hallo Rudi,
es scheint in der Tat Nebeneffekte mit dieser Änderung zu geben.
https://forum.fhem.de/index.php/topic,88357.0.html
https://forum.fhem.de/index.php/topic,88340.0.html
Der erste Thread hat definitiv etwas mit Deiner Änderung zu tun, der zweite klingt zumindest so ähnlich.
Ich habe auch Probleme:
https://forum.fhem.de/index.php/topic,88357.0.html (https://forum.fhem.de/index.php/topic,88357.0.html)
Auch wenn ich die Ursache nicht verstehe, habe gerade in fhem.pl eine zusaetzliche Pruefung via can('pending') eingefuehrt. Kann sein dass es hilft.
Ich waere dankbar, wenn jemand mit einem Absturz in fhem.pl, vor der Zeile mit 'pending' Folgendes einfuegt, und das Ergebnis hier postet:
Log 1, "*** check pending for $hash->{NAME}" if($hash->{SSL});
habe ich eben gemacht und warte auf den nächsten Absturz. :-)
Hallo Rudi,
das erzeugt sehr viele log-Einträge. Ist es so gedacht?
Die log-Datei wird sehr groß werden.
2018.06.04 06:43:19 1: *** check pending for WEB
2018.06.04 06:43:19 1: *** check pending for WEBtablet
2018.06.04 06:43:19 1: *** check pending for WEBtablet_192.168.178.203_52902
2018.06.04 06:43:19 1: *** check pending for WEBphone
2018.06.04 06:43:19 1: *** check pending for WEBhook
2018.06.04 06:43:19 1: *** check pending for WEB
2018.06.04 06:43:19 1: *** check pending for WEBtablet
2018.06.04 06:43:19 1: *** check pending for WEBtablet_192.168.178.203_52902
2018.06.04 06:43:19 1: *** check pending for WEBphone
2018.06.04 06:43:19 1: *** check pending for WEBhook
2018.06.04 06:43:19 1: *** check pending for WEB
2018.06.04 06:43:19 1: *** check pending for WEBtablet
2018.06.04 06:43:19 1: *** check pending for WEBtablet_192.168.178.203_52902
2018.06.04 06:43:19 1: *** check pending for WEBphone
2018.06.04 06:43:19 1: *** check pending for WEBhook
2018.06.04 06:43:19 1: *** check pending for WEB
2018.06.04 06:43:19 1: *** check pending for WEBtablet
2018.06.04 06:43:19 1: *** check pending for WEBtablet_192.168.178.203_52902
2018.06.04 06:43:19 1: *** check pending for WEBphone
2018.06.04 06:43:20 1: *** check pending for WEBhook
2018.06.04 06:43:20 1: *** check pending for WEB
2018.06.04 06:43:20 1: *** check pending for WEBtablet
2018.06.04 06:43:20 1: *** check pending for WEBtablet_192.168.178.203_52902
2018.06.04 06:43:20 1: *** check pending for WEBphone
2018.06.04 06:43:21 1: *** check pending for WEBhook
2018.06.04 06:43:21 1: *** check pending for WEB
2018.06.04 06:43:21 1: *** check pending for WEBtablet
2018.06.04 06:43:21 1: *** check pending for WEBtablet_192.168.178.203_52902
2018.06.04 06:43:21 1: *** check pending for WEBphone
2018.06.04 06:43:22 1: *** check pending for WEBhook
2018.06.04 06:43:22 1: *** check pending for WEB
2018.06.04 06:43:22 1: *** check pending for WEBtablet
2018.06.04 06:43:22 1: *** check pending for WEBtablet_192.168.178.203_52902
2018.06.04 06:43:22 1: *** check pending for WEBphone
2018.06.04 06:43:23 1: *** check pending for WEBhook
2018.06.04 06:43:23 1: *** check pending for WEB
2018.06.04 06:43:23 1: *** check pending for WEBtablet
2018.06.04 06:43:23 1: *** check pending for WEBtablet_192.168.178.203_52902
2018.06.04 06:43:23 1: *** check pending for WEBphone
2018.06.04 06:43:24 1: *** check pending for WEBhook
2018.06.04 06:43:24 1: *** check pending for WEB
2018.06.04 06:43:24 1: *** check pending for WEBtablet
2018.06.04 06:43:24 1: *** check pending for WEBtablet_192.168.178.203_52902
2018.06.04 06:43:24 1: *** check pending for WEBphone
2018.06.04 06:43:25 1: *** check pending for WEBhook
2018.06.04 06:43:25 1: *** check pending for WEB
2018.06.04 06:43:25 1: *** check pending for WEBtablet
2018.06.04 06:43:25 1: *** check pending for WEBtablet_192.168.178.203_52902
2018.06.04 06:43:25 1: *** check pending for WEBphone
2018.06.04 06:43:25 1: *** check pending for WEBhook
2018.06.04 06:43:25 1: *** check pending for WEB
2018.06.04 06:43:25 1: *** check pending for WEBtablet
2018.06.04 06:43:25 1: *** check pending for WEBtablet_192.168.178.203_52902
2018.06.04 06:43:25 1: *** check pending for WEBphone
2018.06.04 06:43:25 1: *** check pending for WEBhook
2018.06.04 06:43:25 1: *** check pending for WEB
2018.06.04 06:43:25 1: *** check pending for WEBtablet
2018.06.04 06:43:25 1: *** check pending for WEBtablet_192.168.178.203_52902
2018.06.04 06:43:25 1: *** check pending for WEBphone
2018.06.04 06:43:26 1: *** check pending for WEBhook
2018.06.04 06:43:26 1: *** check pending for WEB
2018.06.04 06:43:26 1: *** check pending for WEBtablet
2018.06.04 06:43:26 1: *** check pending for WEBtablet_192.168.178.203_52902
2018.06.04 06:43:26 1: *** check pending for WEBphone
2018.06.04 06:43:26 1: *** check pending for WEBhook
2018.06.04 06:43:26 1: *** check pending for WEB
2018.06.04 06:43:26 1: *** check pending for WEBtablet
2018.06.04 06:43:26 1: *** check pending for WEBtablet_192.168.178.203_52902
2018.06.04 06:43:26 1: *** check pending for WEBphone
2018.06.04 06:43:27 1: *** check pending for WEBhook
2018.06.04 06:43:27 1: *** check pending for WEB
2018.06.04 06:43:27 1: *** check pending for WEBtablet
2018.06.04 06:43:27 1: *** check pending for WEBtablet_192.168.178.203_52902
2018.06.04 06:43:27 1: *** check pending for WEBphone
2018.06.04 06:43:28 1: *** check pending for WEBhook
2018.06.04 06:43:28 1: *** check pending for WEB
2018.06.04 06:43:28 1: *** check pending for WEBtablet
2018.06.04 06:43:28 1: *** check pending for WEBtablet_192.168.178.203_52902
2018.06.04 06:43:28 1: *** check pending for WEBphone
2018.06.04 06:43:29 1: *** check pending for WEBhook
2018.06.04 06:43:29 1: *** check pending for WEB
2018.06.04 06:43:29 1: *** check pending for WEBtablet
2018.06.04 06:43:29 1: *** check pending for WEBtablet_192.168.178.203_52902
2018.06.04 06:43:29 1: *** check pending for WEBphone
2018.06.04 06:43:30 1: *** check pending for WEBhook
2018.06.04 06:43:30 1: *** check pending for WEB
2018.06.04 06:43:30 1: *** check pending for WEBtablet
2018.06.04 06:43:30 1: *** check pending for WEBtablet_192.168.178.203_52902
2018.06.04 06:43:30 1: *** check pending for WEBphone
2018.06.04 06:43:30 1: *** check pending for WEBhook
2018.06.04 06:43:30 1: *** check pending for WEB
2018.06.04 06:43:30 1: *** check pending for WEBtablet
2018.06.04 06:43:30 1: *** check pending for WEBtablet_192.168.178.203_52902
2018.06.04 06:43:30 1: *** check pending for WEBphone
2018.06.04 06:43:30 1: *** check pending for WEBhook
2018.06.04 06:43:30 1: *** check pending for WEB
2018.06.04 06:43:30 1: *** check pending for WEBtablet
2018.06.04 06:43:30 1: *** check pending for WEBtablet_192.168.178.203_52902
2018.06.04 06:43:30 1: *** check pending for WEBphone
2018.06.04 06:43:31 1: *** check pending for WEBhook
2018.06.04 06:43:31 1: *** check pending for WEB
2018.06.04 06:43:31 1: *** check pending for WEBtablet
2018.06.04 06:43:31 1: *** check pending for WEBphone
2018.06.04 06:43:31 1: *** check pending for WEBtablet_192.168.178.203_52908
2018.06.04 06:43:31 1: *** check pending for WEBphone
2018.06.04 06:43:31 1: *** check pending for WEBtablet
2018.06.04 06:43:31 1: *** check pending for WEB
2018.06.04 06:43:31 1: *** check pending for WEBhook
2018.06.04 06:43:31 1: *** check pending for WEBtablet_192.168.178.203_52908
2018.06.04 06:43:31 1: *** check pending for WEBphone
2018.06.04 06:43:31 1: *** check pending for WEBtablet
2018.06.04 06:43:31 1: *** check pending for WEB
2018.06.04 06:43:31 1: *** check pending for WEBhook
Ich dachte eigentlich, dass es sofort abstuerzt.
Wenn nicht, dann bitte folgende Zeile statt den vorherigen verwenden:Log 1, "*** MISSING pending for $hash->{NAME}" if($hash->{SSL} && $hash->{CD} && !$hash->{CD}->can('pending'));
Der Absturz war mindestens einmal am Tag.
Ich habe nun die Log-Zeile ausgetauscht. Sobald sich fhem wieder verabschiedet, poste ich den Eintrag.
2018.06.04 12:33:16 1: *** MISSING pending for WEBphone_80.187.122.51_4605
Can't locate object method "pending" via package "IO::Socket::INET" at fhem.pl line 661.
Hat WEBphone das HTTPS Attribut?Gibt es irgendwelche SSL Meldungen im log?Hast du auf FHEM ueber WEBphone gerade zugegriffen?
WEBphone hat attr HTTPS=1
Der letzte Eintrag vor dem Absturz ist interessant:
2018.06.04 09:53:08 1: FHEMWEB SSL/HTTPS error: SSL connect accept failed because of handshake problems (peer: 192.xxx.xxx.xxx)
2018.06.04 12:33:12 1: FHEMWEB SSL/HTTPS error: SSL connect accept failed because of handshake problems (peer: 80.187.122.51)
weil, die Automatisierungsaktivitäten von HUE seit dem fhem-Update auch nicht mehr gehen. Ich hatte aber bisher keine Zeit mich darum zu kümmern, weil ich erstmal nur fhem wieder am Laufen haben wollte. Die IP-Adresse gehört wohl zu HUE, wenn ich das richtig sehe.
Die erste IP-Adresse habe ich mit xxx anonymisiert.
Ob ich zu dem Zeitpunkt mit dem WEBPhone gerade zugegriffen habe, kann ich nicht mit Sicherheit sagen. Aber die Wahrscheinlichkeit ist nach der Mittagspause immer sehr groß. :-)
sorry, etwas ist mir eben aufgefallen, weil Du nach den attr gefragt hast.
Bei WEBPhone fehlt bei mir sslVersion = TLSv12:!SSLv3
Die "SSL/HTTPS error" Meldung 4 Sekunden vor dem Absturz duerfte es nicht sein, und die Andere um 9:53 erst recht nicht.
Fuer sslVersion ist die Voreinstellung TLSv12:!SSLv3.
Das Problem: HTTPS Verbindungen werden normalerweise vom Perl-Modul IO::Socket::SSL behandelt, die eine 'pending' Funktion hat. In deinem Fall kommt die Meldung aber vom IO::Socket::INET, d.h. dass trotz SSL Flag ist das SSL-Modul nicht aktiviert. Bin erstmal ratlos, wieso nicht, und hoffe dass mit der zusaetzlichen Pruefung von gestern das Problem nicht mehr auftritt.
d.h. ich installiere jetzt das neue Update darüber, oder?
Ja, das ist mein Vorschlag.
Hallo,
bei mir steigt Fhem nach folgendem Logeintrag aus:
2018.06.04 21:13:05 1: *** MISSING pending for WEB_::ffff:192.168.178.52_38377
Can't locate object method "pending" via package "IO::Socket::INET6" at fhem.pl line 661.
Die ergänzende Zeile in fhem.pl hatte ich vorher schon geändert.
Viele Grüße Gisbert
Danke, ist wohl das gleiche Problem, nur mit IPV6.Hilft mir leider nicht, ich habe keine Idee, warum trotz gesetzten SSL das Perl-SSL Modul nicht uebernommen hat.
Hallo Rudi,
mein Problem tritt jetzt mindestens täglich einmal auf:
2018.06.06 08:10:34 1: *** MISSING pending for WEBphone_::ffff:192.168.178.52_48695
Can't locate object method "pending" via package "IO::Socket::INET6" at fhem.pl line 661.
2018.06.06 08:17:23 1: Including fhem.cfg
Da ich die heartbeat-Methode von betateilchen zur Überwachung von Fhem nutze, hat sich das System nach geraumer Zeit neu gestartet.
Das ist immerhin schon schön, ein Neustart vom Fhem sollte aber die Ausnahme sein. Ein Neustart scheint aber auch noch andere Probleme zu machen, wie z.B. falsche Pushnachrichten, aber da bin ich eher die Ursache, es ist ein notify betroffen.
Ich bin vermutlich keine gute Hilfe, das Problem einzugrenzen, werde es aber versuchen, falls Vorschläge vorhanden sind.
Viele Grüße Gisbert
Ich gehe davon aus, dass das Problem mit der aktuellen Version von fhem.pl nicht auftritt.Und neue Ideen fuers Lokalisieren des Problems habe ich auch keine.
Wie geht die heartbeat-Methode von Betateilchen?
Ich habe eine ps -Abfage gestrickt, aber bin mit Unix nicht mehr so vertraut, dass ich ein cron-job, oder ähnliches etablieren könnte. Zumindest nicht so schnell.
so sieht mein Mini-Skript aus:
#!/bin/sh
# Prüfenob fhem läuf
mycheck=`ps -ef | grep fhem.cfg | awk '{ print $9 }'`
if [ "$mycheck" != "fhem.cfg" ]; then
# /etc/init.d/fhem stop
sleep 5
# /etc/init.d/fhem start
fi
Ich weiß nur nicht, wie ich es als "heartbeat" implementiere. Bzw. Vielleicht gibt es viel elegantere Möglichkeiten für das gleiche Ziel.
Mit den jetzt gemachten Erfahrungen, finde ich sowas sehr nützlich.
Zitat von: rudolfkoenig am 06 Juni 2018, 10:34:38
Und neue Ideen fuers Lokalisieren des Problems habe ich auch keine.
Mein Bauchgefühl (und Bauch habe ich mehr als genug) sagt mir, dass es vielleicht irgendwas mit der grundlegenden Überarbeitung von IO::Socket::SSL zu tun haben könnte, die in 2017/2018 passiert ist und die sich vermutlich erst jetzt in den distributionsabhängigen perl-Modulen niederschlägt.
https://noxxi.de/pws/2007/io-socket-ssl.pdf
Zitat von: Alcamar am 06 Juni 2018, 11:14:09
Wie geht die heartbeat-Methode von Betateilchen?
Wenn man hier im Forum in die Suche als Text "heartbeat" und als Benutzer "betateilchen" eingibt, kommen ca. 10-12 Ergebnisse, die man problemlos auf einer Bildschirmseite angezeigt bekommt und überfliegen kann, um das passende Ergebnisse zu erkennen...
Danke!
"heartbeat" als Suchbegriff hatte ich eingegeben. Da kam nur der Thread, der mich auf den Betriff erstmalig geführt hat. Die Kombinaton von Suchbegriff und Benutzer weiß ich (noch) nicht einzusetzen. Aber Deiner Antwort zu Folge, muss es einen Weg geben, den ich rausfinde. :-) Muss mich ein wenig mit den Funktionen im Forum beschäftigen, merke ich gerade.
Zitat von: Alcamar am 06 Juni 2018, 14:39:02
Die Kombinaton von Suchbegriff und Benutzer weiß ich (noch) nicht einzusetzen.
Schicke eine leere Suche ab, dann kommst Du auf die Seite, in der Du die "Erweiterte Suche" findest.
Zitat von: betateilchen am 06 Juni 2018, 15:05:31
Schicke eine leere Suche ab, dann kommst Du auf die Seite, in der Du die "Erweiterte Suche" findest.
das geht auch, wenn man auf Suche klickt (oberhalb der ganzen Thread-Anzeige) --> https://forum.fhem.de/index.php?action=search
kann aber auch sein, das das in manchen forenstyles ausgeblendet ist ::) :o 8)
ich habe es ja schon. Geduld.... ;D
Zitat von: rudolfkoenig am 04 Juni 2018, 14:00:39
Hat WEBphone das HTTPS Attribut? Gibt es irgendwelche SSL Meldungen im log? Hast du auf FHEM ueber WEBphone gerade zugegriffen?
Bei mir sieht es so aus, der Logfile enthält noch ne Menge mehr solcher Einträge, HTTPS-Attribute sind gesetzt:
2018.06.06 08:06:27 1: telnet SSL/HTTPS error: SSL accept attempt failed error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number (peer: 127.0.0.1)
2018.06.06 08:41:28 1: FHEMWEB SSL/HTTPS error: SSL accept attempt failed error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number (peer: ::ffff:192.168.178.26)
2018.06.06 08:41:28 1: FHEMWEB SSL/HTTPS error: SSL accept attempt failed error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number (peer: ::ffff:192.168.178.26)
Zitat1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
Laut Internet konnten sich Server (FHEM) und Client (Browser) nicht auf eine Verschluesselung einigen. In FHEM kann man die akzeptierten Verschluesselungen mit sslVersion beeinflussen, die Voreinstellug ist z.Zt. TLSv12:!SSLv3
Hallo Rudi,
nur eine Rückmeldung. Mein FHEM ist seit deiner letzten Änderung nicht mehr abgestürzt. Vielen Dank
Viele Grüße
Achim
Auch bei mir läuft es problemlos.