Neueste Beiträge

[Revision 31237: 76_SolarForecast: Version 2.6.9]

#1

FHEM Code changes / Revision 31237: 76_SolarForeca...

Letzter Beitrag von System - 17 Mai 2026, 00:30:45

Revision 31237: 76_SolarForecast: Version 2.6.9

76_SolarForecast: Version 2.6.9

Source: Revision 31237: 76_SolarForecast: Version 2.6.9

#2

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 16 Mai 2026, 23:41:16

Neue Version ist eingecheckt, vor allem auch wegen dem wichtigen Fix in der Flowgrafik.
Morgen früh wie üblich...

#3

Sonstige Systeme / Aw: Neues Modul: INDEGO

Letzter Beitrag von Basti-K - 16 Mai 2026, 23:40:25

Moin zusammen! 👋
Kurzes Statusupdate für alle, deren Indego-Anbindung seit Anfang 2023 im Dornröschenschlaf liegt:

Das Problem:

Bosch hat die Indego-Cloud auf SingleKey ID (Azure AD B2C) umgestellt. Das alte 70_INDEGO.pm-Modul versucht es immer noch per HTTP-Basic-Auth an der abgeschalteten API – da läuft natürlich jeder ins Leere, egal mit welcher FHEM-Version. Das ist also kein Bug im Modul, Bosch hat einfach den Stecker gezogen.

An der Stelle aber mal ein fettes Danke an VuffiRaa für das ursprüngliche Modul – das Teil hat hier jahrelang einen Spitzenjob gemacht! 😎

Die Lösung (am echten Indego 350 getestet):

Statt die tote Basic-Auth-Leiche wiederzubeleben, läuft jetzt ein kleiner Python-Sidecar als lokaler Helfer auf dem FHEM-Host. Der schnackt mit der neuen OAuth-API und stellt intern (127.0.0.1) eine schlanke JSON-API bereit. FHEM holt sich das Ganze dann einfach über ein HTTPMOD-Device ab. Status auslesen und die Grundbefehle (Mähen, Pause, zurück zur Ladestation) laufen damit wieder eins a.

Den gleichen Umweg nutzen übrigens auch openHAB und Home Assistant, und zwar aus einem nervigen Grund: Der SingleKey-Login ist mit hCaptcha geschützt. Ein komplett automatischer Login im Hintergrund fliegt da direkt auf die Nase. Man muss sich also einmalig über einen echten Browser einloggen. Danach reicht der Refresh-Token, und das Erneuern im Hintergrund läuft ohne Captcha. Ein reines Perl-Modul ohne diesen Browser-Zwischenschritt fällt deshalb leider flach.

Der Haken an der Sache (Butter bei die Fische):

Inoffiziell & Reverse-Engineered: Wir nutzen die bekannte Bosch-App-Client-ID. Wenn Bosch da was ändert, stehen wir wieder im Regen.

User-Agent: Ohne passenden App-User-Agent blockt die Azure-WAF sofort mit einem 403er-Fehler.

Token-Ablauf: Bosch schmeißt den Refresh-Token ab und zu (oder bei Passwortänderung) raus. Dann heißt es: noch mal kurz im Browser anmelden.

Sicherheit: Der Token ist so sensibel wie euer Passwort. Also: Dateirechte auf 600 und den Sidecar streng auf 127.0.0.1 festnageln.

Echtzeit: Die Steuerbefehle gehen natürlich eins zu eins an euren echten Mäher – also Vorsicht beim Testen. 😉

Lizenz & Credits:

Bleibt alles wie beim Original: GPL-2.0-or-later. Danke an VuffiRaa und die Vorarbeit von openHAB, Home Assistant und pyIndego.

Wie geht's weiter?

Ich habe das Ganze fix und fertig verpackt (Sidecar, eine kleine GUI fürs einmalige Token-Holen ohne Passwort-Gefahr, systemd-Unit, fertiges FHEM-Snippet und ein passendes README).

Ich würde das Paket bei GitHub hochladen, ein Wiki dazu schreiben und mich auch um die Pflege kümmern. Besteht überhaupt Bedarf bei euch oder bastelt parallel schon jemand an was Ähnlichem? Gebt mal kurz Laut!

Viele Grüße
Basti

[Revision 31236: 76_SolarForecast: Version 2.6.9]

#4

FHEM Code changes / Revision 31236: 76_SolarForeca...

Letzter Beitrag von System - 16 Mai 2026, 22:20:41

Revision 31236: 76_SolarForecast: Version 2.6.9

76_SolarForecast: Version 2.6.9

Source: Revision 31236: 76_SolarForecast: Version 2.6.9

#5

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 16 Mai 2026, 22:11:51

Zur Erhöhung der Übersichtlichkeit hat da AI Statuspopup nun auf/zuklappbare Abschnitte.
-> im Contrib.

[python3 blink_bridge.py]

#6

Sonstige Systeme / Aw: blink-mqtt-bridge

Letzter Beitrag von rabehd - 16 Mai 2026, 22:09:31

Ich habe FHEM in einem Docker-Container auf einem Pi5.

Schon python3 blink_bridge.py meldet Probleme.

Code Auswählen Erweitern

SUCCESS: 2FA verification completed!

============================================================
TESTING BASIC FUNCTIONALITY
============================================================

[4/5] Refreshing camera data...

📹 Cameras found:
  - Th: Armed=False, Battery=ok%
  - Ter : Armed=False, Battery=ok%
  - Zu: Armed=False, Battery=ok%
  - Wo: Armed=True, Battery=None%
  - Ka : Armed=True, Battery=None%
  - Tk : Armed=False, Battery=ok%

🔌 Sync modules found:
  - Systename: Armed=True

[5/5] Saving credentials to blink_credentials.json...
Credentials saved!

============================================================
ALL TESTS PASSED!
============================================================
blinkpy is working correctly with your Blink account.
You can now use this for FHEM integration.

SUCCESS! You can proceed with blinkpy integration.
Unclosed client session
client_session: <aiohttp.client.ClientSession object at 0x7ffed169cfa0>
Unclosed connector
connections: ['deque([(<aiohttp.client_proto.ResponseHandler object at 0x7ffed16be8e0>, 946914.738256688), (<aiohttp.client_proto.ResponseHandler object at 0x7ffed16a0e20>, 946915.000574291)])', 'deque([(<aiohttp.client_proto.ResponseHandler object at 0x7ffed0e284c0>, 946915.165886772)])', 'deque([(<aiohttp.client_proto.ResponseHandler object at 0x7ffed0e28ee0>, 946920.742729671)])']
connector: <aiohttp.connector.TCPConnector object at 0x7ffed169cfd0>
Fatal error on SSL transport
protocol: <asyncio.sslproto.SSLProtocol object at 0x7ffed169cc70>
transport: <_SelectorSocketTransport closing fd=6>
Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/selector_events.py", line 918, in write
    n = self._sock.send(data)
OSError: [Errno 9] Bad file descriptor

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/sslproto.py", line 684, in _process_write_backlog
    self._transport.write(chunk)
  File "/usr/lib/python3.9/asyncio/selector_events.py", line 924, in write
    self._fatal_error(exc, 'Fatal write error on socket transport')
  File "/usr/lib/python3.9/asyncio/selector_events.py", line 719, in _fatal_error
    self._force_close(exc)
  File "/usr/lib/python3.9/asyncio/selector_events.py", line 731, in _force_close
    self._loop.call_soon(self._call_connection_lost, exc)
  File "/usr/lib/python3.9/asyncio/base_events.py", line 746, in call_soon
    self._check_closed()
  File "/usr/lib/python3.9/asyncio/base_events.py", line 510, in _check_closed
    raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
Fatal error on SSL transport
protocol: <asyncio.sslproto.SSLProtocol object at 0x7ffed16b6370>
transport: <_SelectorSocketTransport closing fd=7>
Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/selector_events.py", line 918, in write
    n = self._sock.send(data)
OSError: [Errno 9] Bad file descriptor

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/sslproto.py", line 684, in _process_write_backlog
    self._transport.write(chunk)
  File "/usr/lib/python3.9/asyncio/selector_events.py", line 924, in write
    self._fatal_error(exc, 'Fatal write error on socket transport')
  File "/usr/lib/python3.9/asyncio/selector_events.py", line 719, in _fatal_error
    self._force_close(exc)
  File "/usr/lib/python3.9/asyncio/selector_events.py", line 731, in _force_close
    self._loop.call_soon(self._call_connection_lost, exc)
  File "/usr/lib/python3.9/asyncio/base_events.py", line 746, in call_soon
    self._check_closed()
  File "/usr/lib/python3.9/asyncio/base_events.py", line 510, in _check_closed
    raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
Fatal error on SSL transport
protocol: <asyncio.sslproto.SSLProtocol object at 0x7ffed0e16700>
transport: <_SelectorSocketTransport closing fd=8>
Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/selector_events.py", line 918, in write
    n = self._sock.send(data)
OSError: [Errno 9] Bad file descriptor

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/sslproto.py", line 684, in _process_write_backlog
    self._transport.write(chunk)
  File "/usr/lib/python3.9/asyncio/selector_events.py", line 924, in write
    self._fatal_error(exc, 'Fatal write error on socket transport')
  File "/usr/lib/python3.9/asyncio/selector_events.py", line 719, in _fatal_error
    self._force_close(exc)
  File "/usr/lib/python3.9/asyncio/selector_events.py", line 731, in _force_close
    self._loop.call_soon(self._call_connection_lost, exc)
  File "/usr/lib/python3.9/asyncio/base_events.py", line 746, in call_soon
    self._check_closed()
  File "/usr/lib/python3.9/asyncio/base_events.py", line 510, in _check_closed
    raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
Fatal error on SSL transport
protocol: <asyncio.sslproto.SSLProtocol object at 0x7ffed0e167f0>
transport: <_SelectorSocketTransport closing fd=9>
Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/selector_events.py", line 918, in write
    n = self._sock.send(data)
OSError: [Errno 9] Bad file descriptor

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/sslproto.py", line 684, in _process_write_backlog
    self._transport.write(chunk)
  File "/usr/lib/python3.9/asyncio/selector_events.py", line 924, in write
    self._fatal_error(exc, 'Fatal write error on socket transport')
  File "/usr/lib/python3.9/asyncio/selector_events.py", line 719, in _fatal_error
    self._force_close(exc)
  File "/usr/lib/python3.9/asyncio/selector_events.py", line 731, in _force_close
    self._loop.call_soon(self._call_connection_lost, exc)
  File "/usr/lib/python3.9/asyncio/base_events.py", line 746, in call_soon
    self._check_closed()
  File "/usr/lib/python3.9/asyncio/base_events.py", line 510, in _check_closed
    raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed


#7

Solaranlagen / Aw: Zendure HEMS Modul

Letzter Beitrag von Tueftler1983 - 16 Mai 2026, 21:27:02

Kann ich es auf einem raspberry pi parallel nutzen ohne docker container oder wie das heißt?

#8

Solaranlagen / Aw: Zendure HEMS Modul

Letzter Beitrag von Mitch - 16 Mai 2026, 21:14:26

Hat alles seine Vor- un Nachteile. Ich nutze beides.
HA hat extrem viele Integrationen und eine riesige hilfsbereite Community.
fhem hat mit DOIF für ich die besten Automationsmöglichkeiten und breiteste Unterstützung für verschiedene Standards. Vor allem HM, was ich noch viel habe.

#9

Solaranlagen / Aw: Zendure HEMS Modul

Letzter Beitrag von Tueftler1983 - 16 Mai 2026, 21:09:39

Das ist sehr nett und das kannte ich auch bereits Aberdings denke ich übersteigt das meine Fähigkeiten. So langsam habe ich aber das Gefühl das ein Umstieg von FHEM auf HA lohnt.
Tibber ist da sauberer integriert, der wirlpool von mir, einige zigbee Geräte und auch Zendure.

Leider integrieren fiele Hersteller HA aber nicht FHEM was ich schade finde.

LG Holger

#10

Sonstige Systeme / Aw: blink-mqtt-bridge

Letzter Beitrag von rabehd - 16 Mai 2026, 21:07:08

attr blink readingList blink/sync/[^/]+/status:.*    { my $t=$TOPIC;; $t=~s#^blink/sync/##;; $t=~s#/status$##;;json2nameValue($EVENT, $t."_");; }\
blink/cameras/[^/]+/status:.* { my $t=$TOPIC;; $t=~s#^blink/cameras/##;; $t=~s#/status$##;;json2nameValue($EVENT, $t."_");; }\

Also das Attribut möchte mein FHEM nicht übernehmen.
Da ich es auch nicht verstehe....

blink: bad reading name { my $t=$TOPIC;; $t=~s#^blink/sync/##;; $t=~s#/status$##;;json2nameValue($EVENT, $t."_");; }\ (contains not A-Za-z/\d_\.- or is too long)