Ich befürchte.... das einzige was da wirklich komisch ist... das ist die Photovoltaik-Kiste.
Softwaretechnisch ein pures Disaster... an vielen Ecken und Enden... auch in Sachen dieser Log-Dateien haben da schon viele, die viel mehr Ahnung über diese Themen haben als ich, brüllend gelacht oder den Kopf geschüttelt...
NoPlayBack Das ist ein Fehler in requests, der in Version 2.34.x behoben ist: https://github.com/psf/requests/issues/6711
Wo muss ich hin um dich zu knutschen ???
Alter... das ist nicht wahr... es läuft wieder nach einem Upgrade von requests und urllib3 
Ich hatte das Zertifikat in meiner mySENEC-Seite geladen... das war ein SenecGui-Root.pem... hat nichts geholfen.
Rasp-Berlin meinst du diese Zertifikate sind besser?
Der Code
response = requests.get(url, cert="SenecGui-Root.pem", verify=False) # SSL-Verifikation deaktivierenwürde dann richtig sein ?
Rasp-Berlin Das ist doch letztlich egal, es funktioniert doch mit curl. Und der Unterschied zwischen curl und dem Python-Programm ist ein fehlender / in der URL. Man könnte da noch mal die Gegenprobe machen was bei curl mit dem fehlendem / als Antwort kommt, dann wüsste man sicher(er), dass das die Ursache für die Antwort des Servers ist.
Ja es sieht so aus als ob es fehlt... aber im Debugger sieht man dass in der Variable URL die Slashes alle da sind.
Daher nur zur Sicherheit meine Frage: Welches // glaubst du fehlt? Du meinst vermutlich dass hinter der IP-Adresse?
Ich glaube rpi444 hat in #3 die richtige Frage gestellt. Wurde leider nicht beantwortet.
Beantwortet in #6 
Debug-Ausgabe von request.get:
InsecureRequestWarning: Unverified HTTPS request is being made to host '192.168.178.28'. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#tls-warnings
warnings.warn(
DEBUG:urllib3.connectionpool:https://192.168.178.28:443 "GET /Log/2026/06/06.log HTTP/1.1" 401 None
send: b'GET /Log/2026/06/06.log HTTP/1.1\r\nHost: 192.168.178.28\r\nUser-Agent: python-requests/2.32.3\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nConnection: keep-alive\r\n\r\n'
reply: 'HTTP/1.1 401 Unauthorized\r\n'
header: Server: nginx/1.17.7
header: Date: Wed, 10 Jun 2026 09:04:20 GMT
header: Transfer-Encoding: chunked
header: Connection: keep-aliveUnd ja... das ist alles nicht mein Hoheitsgebiet... ich vermute das übersteigt meinen Horizont...
http://ip-der-pv//Log/2026/06/06.logist genau das was ich anfrage... mit einer SW die unverändert auf Bookworm läuft.
curl https://192.168.178.28//Log/2026/06/06.log --verbose --insecuregetestet, Antwort ist im Header
* Trying 192.168.178.28:443...
* schannel: disabled automatic use of client certificate
* schannel: using IP address, SNI is not supported by OS.
* ALPN: curl offers http/1.1
* ALPN: server accepted http/1.1
* Established connection to 192.168.178.28 (192.168.178.28 port 443) from 192.168.178.37 port 52539
* using HTTP/1.x
> GET //Log/2026/06/06.log HTTP/1.1
> Host: 192.168.178.28
> User-Agent: curl/8.19.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< Server: nginx/1.17.7
< Date: Wed, 10 Jun 2026 08:55:47 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 54142
< Connection: keep-alive
<und danach kommen genau die Daten die ich haben will... in Windows, im Dos-Prompt.
Auf dem Raspi kommt als Header (vor den Daten):
* Trying 192.168.178.28:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 / x25519 / RSASSA-PSS
* ALPN: server accepted http/1.1
* Server certificate:
* subject: C=DE; ST=Saxony; L=Leipzig; O=SENEC GmbH; CN=senecGuiSelf
* start date: Apr 20 09:29:51 2026 GMT
* expire date: Apr 17 09:29:51 2036 GMT
* issuer: C=DE; ST=Saxony; L=Leipzig; O=SENEC GmbH; CN=SenecGui-Root
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* Connected to 192.168.178.28 (192.168.178.28) port 443
* using HTTP/1.x
> GET //Log/2026/06/06.log HTTP/1.1
> Host: 192.168.178.28
> User-Agent: curl/8.14.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< Server: nginx/1.17.7
< Date: Wed, 10 Jun 2026 08:58:32 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 54142
< Connection: keep-alive
<und danach dann die Daten die ich sehen will.....
Ein jungfräulicher Rechner zeigt mit bei Firefox
Dann muss ich da auf erweitert, und dann auf den nicht empfohlenen Knopf zum Anzeigen der Seite. Dann wird mir die Seite angezeigt.
Keinerlei Name oder Passwort. So war das auch schon immer nachdem für diese Seite vom Hersteller https eingeführt wurde.
Das ist das einzige was man einmal machen muss, dann wird diese Seite auch immer im Internetexplorer geöffnet, weil Firefox sich das merkt.
Deswegen wurde vor vielen Monden der "verify=false" in den Code benutzt um die SSL Versicherung zu umgehen.
Aus diesem Grunde war ich halt der Meinung dass nun aus irgendeinem Grunde das verify=false nicht mehr so wirkt wie vorher.... ich kann zwar Netzwerk-Gequatsche mitschneiden, aber vermutlich nicht analysieren und verstehen, von daher wird das wohl eher nix... und da ich nicht sicher sein kann private Daten zu zeigen wenn ich das Ergebnis hier posten würde dann muss ich es wohl eher sein lassen 
Rückmeldung ist Code 401 und der Text kommt als Inhalt, als Content.
<Response [401]>
b'<html><head><title>Unauthorized</title></head><body><h1>Unauthorized</h1><p>Please authorize before accessing `Log/2026/06/06.log`.</p></body></html>'Ich autorisiere mich gar nicht, das Teil steht hier im Haus-Netzwerk und wird schlicht mit der Internetadresse angesprochen.
Wenn ich diese Internetadresse in den Internetexplorer gebe dann bekomme ich die Seite angezeigt, ebenfalls ohne Name und Passwort.
Nur mit dem Python request.get klappt es nicht mehr... seit dem die neuen Versionen auf den Geräten ist.
rpi444 : in Trixie geguckt, Datei gefunden, aber keine Section mit dem Namen. Lohnt es sich in Bookworm zu gucken? Dafür müsste ich halt neu booten...
Edit: nachgeguckt, auch in Bookworm keine solche Section.
__blackjack__ : Ich debugge durch den Python Code. Ich nutze die SW die auf Bookwork geht und auch einmal auf Windows ging. Der Befehl ist:
response = requests.get(url, verify=False)...und dann gibt es einen Fehler mit der o.g. Bezeichnung.
Rasp-Berlin : Befehl siehe 2 Zeilen hier drüber. Es geht um eine SENEC V3, dort kann man Log-Dateien einsehen...also eher blanke Ascii-Folgen.
Ich habe hier eine Photovoltaik-Kiste von der ich https-Seiten einlesen möchte.
Früher war es eine http Seite, dann änderte der Hersteller das auf https, aber mit request get und dem Parameter verify=false konnte man die Seite trotzdem lesen.
Das funktionierte auf Windows und auf dem Raspi... irgendwann kam dann die Fehlermeldung "Please authorize before accessing" in Windows... Raspi funktionierte weiter.
Dann kam Trixie auf einem Raspi5... dann auch dort die gleiche Meldung.
Dann kam Trixie auch auf den alten Raspi4... jetzt auch da die gleiche Meldung.
Da ist also offensichtlich irgendwas mit neuen Versionen von genutzten Routinen geändert worden, und damit funktioniert das Einlesen nicht mehr.
Weiß jemand was sich da geändert hat? Was ich tun muss um wieder die Seite zu lesen? Im Moment nutze ich eine SD-Karte zum Booten in Bookworm... damit klappt es immer noch.
Habe zum ersten Male einen Raspi mit iobroker am laufen, der per "SQL-Protokollierung" in eine mysql schreiben soll, die nicht von ihm selber gehostet wird sondern von einem anderen raspi.
Deswegen habe ich den server nicht mit "localhost" sondern mit dem Netzwerknamen des anderen Raspi versehen.
Er hat auch sofort Verbindung gehabt, und trägt brav die Werte ein.
Blöd ist nur, dass im Journal seit dem immer wieder Fehlermeldungen auftauchen:
Nov 22 14:24:35 raspberrypixx sudo[498064]: pam_unix(sudo:auth): conversation failed
Nov 22 14:24:35 raspberrypixx sudo[498064]: pam_unix(sudo:auth): auth could not identify password for [iobroker]
Nov 22 14:24:35 raspberrypixx bash[988]: sudo: Zum Lesen des Passworts ist ein Terminal erforderlich; verwenden Sie entweder die Option -S, um aus der Standardeingabe zu lesen oder richten Sie das Askpass-Hilfsprogramm ein
Nov 22 14:24:35 raspberrypixx bash[988]: sudo: Ein Passwort ist notwendigDatenbankname und Benutzername sind beides "iobroker".......
Warum ist das so ????
nu gut... habe ich wieder was zum checken ...
Aber die Geschwindigkeitsunterschiede waren ja für beide SSD ohne diese Umstellung... also ist ja wohl die Patriot trotzdem schneller, oder nicht ?
wie aktiviere ich PCI Gen 3 ? Ich habe gehört der Raspi macht nur Gen 2 mit einer Lane ?????
Eine einzige Schraube (unter dem USB-C Stromanschluss) locker rein reicht schon aus. Die anderen 3 Schrauben sind nicht gar so empfindlich, aber können es auch auslösen.
Bin inzwischen sicher dass es an der SSD liegt... weil alles andere ist jetzt wie vorher. Wenn ich da alle 4 Schrauben anziehe ist das wurscht.
Damit höre ich jetzt auf.... schade, ich hätte gerne etwas eindeutiges gefunden... irgendwie kann ich nicht ganz glauben dass die SSD was hat... vor allen Schade weil die definitiv schneller war als meine neue.
Alte SSD: Patriot P300P256GM28
Neue SSD: Transcend TS256GMTE400S
PS: Ich glaube ich habe den Board-Hersteller gefunden... auf meinem steht nix drauf aber es sieht exakt so aus wie der Geekworm X1001 PCIe to M.2 NVMe Key-M SSD Shield.
In dem Link hier ist auch ein Video in dem auch das gleiche Gehäuse genutzt wird.....
Naja, wenn es keinen Kurzschluss mit dem Gehäuse gibt, dann bleibt eigentlich nur noch ein Fehler dieser Art übrig. Passiert das auch, wenn die Schrauben nur soweit greifen, dass sich der RPi nicht verschieben kann, aber die Schrauben nicht angezogen werden?
Getestet.... Schrauben 1 Umdrehung gelöst, stürzt immer noch ab.
Es ist wohl die SSD.... läuft und läuft und läuft...
Naja... aber ausschalten wollte ich es jetzt deswegen nicht, hab wieder eingeschaltet.
Hätte mich nur interessiert woher die falsche Angabe kommt... und ja, sonst sehe ich überall 8GB.
Naja... wenn ich das richtig verstehe... und jetzt auch richtig sehe... wird jetzt schlicht die Anzeige nicht mehr gezeigt ?
Irgendjemand wollte doch auch einen Screenshot....
