Neueste Beiträge

#91

FRITZ!Box / Aw: 72_FRITZBOX.pm ab Version...

Letzter Beitrag von neobiker - 19 November 2025, 18:46:09

Hi Jörg,
Danke!
Also die Readings kommen schonmal, hab keinen Fehler im Logfile bisher.

Wenn Du irgendwann noch die 'boost' Werte finden könntest, und den 'boost-Befehl' ergänzt, könnte zumindest ich schonmal den FBDECT Modul loswerden.

Tolle Sache - Danke !

Gruss neobiker

#92

Server - Linux / Aw: Cluster mit mehreren Nodes...

Letzter Beitrag von MadMax-FHEM - 19 November 2025, 18:31:03

Single point of failure bleibt aber, zumindest bei ZWave (, EnOcean soweit ich weiß, Zigbee?) und ähnlichen Systemen, wo Endgeräte/Sensoren fest mit einem bestimmten "Controller" (HW) verbunden sind, eben dieser...

Bei anderen, wie Homematic (zumindest direkt an fhem über vccu) besteht das Problem nicht, noch dazu, wenn redundant (eben per vccu) und Netzwerk angebunden...

Gruß, Joachim

#93

FRITZ!Box / Aw: 72_FRITZBOX.pm ab Version...

Letzter Beitrag von neobiker - 19 November 2025, 18:28:34

Hi Jörg,

Hallo,

ich habe jetzt einen Teil der Daten identifizieren können. Zum Teil ist die Namensgebung im JSON eher als kreativ zu bezeichnen, andere habe ich bisher einfach nicht berücksichtigt.

Grüße Jörg

super, das habe ich vermutet.

Ich denke dass AVM auch diese Daten mehr und mehr über die API (Ziel ist vermutlich alles über die API zu machen) intern verarbeiten wird. Wir haben ja mit Versionen wie 7.50 oder 8.x schon gesehen, dass da Namen angepasst werden.

Ich denke dass da auch die komischen Namen sich von Version zu Version anpassen könnten: standardisierte, logische, bessere Namen die logisch aufgebaut sind -> bessere Wartbarkeit für AVM.

Gruss
Neobiker

#94

FRITZ!Box / Aw: 72_FRITZBOX.pm ab Version...

Letzter Beitrag von neobiker - 19 November 2025, 18:14:12

Hi,

Die Frage ist vermutlich auch, wie komplex und umfangreich die Funktionen des Moduls sinnvoll werden können und bei SW Updates wartbar bleiben.
Es muss am Ende für den Modulautor und auch den Anwender handhabbar bleiben.

Netzwerkzentrale und SmatHomezentrale sind ja logisch durchaus getrennte Sachverhalte.

das sehe ich auch so. Aber die Box ist halt eine für beide Themen: FritzBox! -> FritzBox-API
Die bietet eine API, die Daten liefert, für verschiedene Themen...

Die allgemeine Funktionalität zur Kommunikation mit der Box (API) müssen ja nicht zwei Module doppelt machen!
Auch reicht ein Login von FHEM auf die FritzBox, anstatt 2 parallele Login auf die Fritzbox die minütlich Daten laden.

Das spart Aufwände in beiden Modulen, die Themen können sich mehrere Entwickler teilen.
Ich sehe hier Jörg unglaublich tolle Arbeit machen: was die API betrifft, und alle unsere Wünsche und Problemchen die er so schnell bearbeitet!

Alleine die Möglichkeit den Temperaturwert der FritzThemostate auf einen externen Temperatursensor zu synchronisieren durch den Temperatur-OffSet ist für mich enorm nützlich, ja notwendig!
Da wird um bis zu -4,5°C korrigiert, weil der Thermostat z.B. hinter dem Sofa steckt, da gibt es HitzeStau.
Oder der Heizkörper im DG, der ist so klein, dass der die ganze Zeit voll aufdrehen muss, sodass der Thermomstat obwohl er nicht unter Hitzestau leidet bis zu -3,5°C OffSet hat, ohne den denkt der es ist warm und er würde schon das Ventil zudrehen, obwohl der Raum noch nicht die Temperatur erreicht hat, er bliebe zu kalt, oder ich müsste mehr Vorlauftemperatur einstellen.

Ergo: nur damit regeln die Thermostatte die Raumtemperatur vernünftig wie man es gewohnt ist.

#95

Zigbee / Aw: HueBridge Pro mit FHEM - A...

Letzter Beitrag von Klaus.A - 19 November 2025, 18:09:27

@Brause:

Frage: Hue Bridge Pro mit FHEM? Alleine funktioniert sie, das ist klar. Aber mit FHEM? Wenn problemlos, welches Betriebssystem?

@alle:

Es gibt in der Hue Bridge Pro ein inzwischen bekanntes Problem mit Zertifikaten bzw. deren Implementierung. Da scheitert in der Regel die Validierung, d.h. eine externe Anwendung kann keine HTTPS-Verbindung erhalten. Dann gibt es Folgefehler wie z.B. den angeblichen JSON-Fehler in FHEM. Auf ein paar System scheint es zu laufen - warum ist noch unklar. Die Hue Bridge Pro verlangt unbedingt HTTPS und API Version 2. Das kann auch das FHEM-HueBridge-Modul, macht es auch richtig mit der bisherigen Bridge v2.

Ich werde für meine Installation abwarten bis Signify das Zertifikatproblem behoben hat. Work Arounds sind eine mögliche Schwachstelle für die Zukunft.

Es gibt für mich noch einen weiteren Grund abzuwarten: Für die Verbindung zu Apple Home kennt die Hue Bridge Pro kein Homekit-Protokoll mehr, nur noch Matter. Das ist zwar verständlich weil Apple Homekit nicht mehr weiter entwickelt und voll auf Matter setzt. Aber in Matter fehlen noch Funktionen. Der Aktuelle Stand kennt keine Gruppensteuerung, d.h. Hue Lampen können nicht gemeinsam (z.B. pro Raum) geschaltet werden, sondern nur einzeln. Das kann je nach Komplexität der Installation zu unschönen Effekten führen. Matter 1.3 soll Gruppensteuerung enthalten. Das muss dann erst von Apple noch implementiert werden und danach ist wieder Signify dran. Das kann Monate dauern.

Gruß Klaus

#96

Sprachsteuerung / Aw: [37_echodevice] Amazon Ech...

Letzter Beitrag von locodriver - 19 November 2025, 17:43:17

Hallo, seit dem letzten update durch Michael, läuft Alexa bzw. echodevice wieder.

Allerdings habe ich gerade folgende Einträge im log (reverse) entdeckt, die schon seit 10.11. (letztes fhem-update) auftreten.

Code Auswählen Erweitern

Node.js v18.20.4

}
  syscall: 'write'
  code: 'EPIPE',
  errno: -32,
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
    at emitErrorCloseNT (node:internal/streams/destroy:116:3)
    at emitErrorNT (node:internal/streams/destroy:151:8)
Emitted 'error' event on Socket instance at:
    at /opt/fhem/cache/alexa-cookie/node_modules/alexa-cookie2/alexa-cookie.js:499:41
    at console.log (node:internal/console/constructor:380:26)
    at console.value (node:internal/console/constructor:305:16)
    at Writable.write (node:internal/streams/writable:337:10)
    at _write (node:internal/streams/writable:333:10)
    at writeOrBuffer (node:internal/streams/writable:392:12)
    at Socket._write (node:net:975:8)
    at Socket._writeGeneric (node:net:963:11)
    at writeGeneric (node:internal/stream_base_commons:151:3)
    at afterWriteDispatched (node:internal/stream_base_commons:160:15)
Error: write EPIPE

      ^
      throw er; // Unhandled 'error' event
node:events:495
Zeitweise sind mehr solche Einträge vorhanden als normale Logzeilen.

Die Funktion scheint aber nicht beeinträchtigt zu sein.
Sowohl das account device als auch die Echos sind connected.

Was ist da "los" und wie bekomme ich das weg?

Dankeschön.

Uwe

#97

Homematic / Aw: Busware CUL CC1101 an eine...

Letzter Beitrag von Beta-User - 19 November 2025, 17:33:05

Hm, zu den Aufsteckmodulen sollte was allgemeines im Wiki (von Otto) zu finden sein. Hast du da alle Schritte durch?
(Meine, dazu hätte es auch den einen oder anderen Thread in den letzten Monaten gegeben).

#98

Homematic / Aw: Busware CUL CC1101 an eine...

Letzter Beitrag von popperchris - 19 November 2025, 17:15:53

Hey,
danke für die schnelle Antwort.
Habe schon alles kontrolliert usw.
So sieht das ttyAMA0 aus
crw-rw---- 1 root dialout 204, 64 Nov 19 16:45 /dev/ttyAMA0

in der config.txt steht:
dtparam=uart0=on
dtoverlay=miniuart-bt
enable_uart=1

Aber der CUL_HM bleibt auf opened

#99

DOIF / Aw: DOIF, dass nicht auf Winte...

Letzter Beitrag von Per - 19 November 2025, 16:43:59

Der letzte Case ist zu weit gefasst *), deshalb löst er zu oft aus, kein DOIF-, sondern ein Logik-Problem.

Und die Zeitumstellung kannst du mittels Variablen (oder Userreadings) machen, DOIF kann Zeittrigger berechnen.

*) z.B.
[OLED:presence] -> "present"
Wetterstation:luminosity = 7000
HM_rolloWohnzimmer:control = 28

#100

FRITZ!Box / Aw: 72_FRITZBOX.pm ab Version...

Letzter Beitrag von JoWiemann - 19 November 2025, 16:35:36

Hier scheint der Dateianhang zu fehlen, zumindest kann ich keinen sehen.

Ups.

Grüße Jörg