Neueste Beiträge

#1

Anfängerfragen / Homekit zur Überwachung

Letzter Beitrag von stefan-dd - 28 Februar 2026, 23:34:14

Hallo, ich möchte meine Hebeanlage überwachen. Habe einen Sensor montiert, der ein einfaches on/off liefert.
Nun möchte ich, dass der Sensor im Falle einer Störung in der Home App eine Meldung ausgiebt wie es bei Türen möglich ist.
Es soll nicht mit einen einfachen Schalter dargestellt werden, sondern irgend etwas passenderes. Der würde ja wieder nur on/off darstellen.
Ich dachte irgendwie an Störung/ok.

Habe jetzt mit contactsensor experimentiert, zeigt es mir in der HomeApp aber nicht an.
Was würde für den Anwendungsfall funktionieren? Gibt es auch eine ganz individuelle Konfigurationsmöglichkeit?

Code Auswählen Erweitern

defmod Hebeanlage FRM_IN 56
attr Hebeanlage IODev MegaUG
attr Hebeanlage activeLow no
attr Hebeanlage genericDeviceType ContactSensor
attr Hebeanlage homebridgeMapping ContactSensorState=reading,values=on:CONTACT_DETECTED;;off:CONTACT_NOT_DETECTED
attr Hebeanlage internal-pullup on
attr Hebeanlage room Home,Homekit
attr Hebeanlage stateFormat reading

setstate Hebeanlage on
setstate Hebeanlage 2026-02-28 13:40:34 IODev MegaUG
setstate Hebeanlage 2026-02-28 21:06:39 reading on
setstate Hebeanlage 2026-02-28 13:40:34 state Initialized

#2

Anfängerfragen / Homebridge und WMBUS

Letzter Beitrag von hyper2910 - 28 Februar 2026, 23:05:57

Hallo,

ich würde gerne die Daten von WMBus auf Homebridge haben, jedoch bekomme ich den Wert nicht übergeben.

Der Wert im FHEM WMBUS wird in volume oder 1_VF angegeben und dieser soll nach Homebridge.

jedoch bekomme ich nur 100 angezeigt und nicht den wirklichen Wert von aktuell 154.8


Habe alles mögliche versucht bekomme das Mapping aber nicht hin.

hat jemand eine Idee?

Aktuell nutze ich folgendes Mapping, welches aber nur 100 anzeigt

Code Auswählen Erweitern

clear CurrentTemperature=volume
Danke

Code Auswählen Erweitern

Internals:
   DEF        BMT 16157095 19 7
   DeviceMedium Water
   DeviceType 7
   FUUID      5f649188-f33f-395a-930d-005b14207d994faa
   IODev      nanoCUL_WM1
   IdentNumber 16157095
   LASTInputDev nanoCUL_WM1
   MSGCNT     633
   Manufacturer BMT
   MessageEncoding CUL
   NAME       Warmwasser_Dirk
   NR         871
   STATE      no errors
   TYPE       WMBUS
   Version    19
   addr       BMT_16157095_19_7
   eventCount 633
   model      BMT_7_19
   nanoCUL_WM1_MSGCNT 633
   nanoCUL_WM1_RAWMSG b2144B409957015161307773B7A110000000C1320471500046D2321413E3C330F058E3500000071C380::-42.5
   nanoCUL_WM1_RSSI -42.5
   nanoCUL_WM1_TIME 2026-02-28 23:22:02
   READINGS:
     2026-02-28 23:22:02   1_storage_no    0
     2026-02-28 23:22:02   1_type          VIF_VOLUME
     2026-02-28 23:22:02   1_unit          m³
     2026-02-28 23:22:02   1_value         154.72
     2026-02-28 23:22:02   1_value_type    Instantaneous value
     2026-02-28 23:22:02   2_storage_no    0
     2026-02-28 23:22:02   2_type          VIF_TIME_POINT_DATE_TIME
     2026-02-28 23:22:02   2_unit         
     2026-02-28 23:22:02   2_value         2026-03-01 01:35
     2026-02-28 23:22:02   2_value_type    Instantaneous value
     2026-02-28 17:22:59   IODev           nanoCUL_WM1
     2026-02-28 23:22:02   LQI             128
     2026-02-28 23:22:02   RSSI            -42.5
     2026-02-28 23:22:02   batteryState    ok
     2026-02-28 23:22:02   decryption_ok   1
     2026-02-28 23:22:02   is_encrypted    0
     2026-02-28 23:22:02   state           no errors
     2026-02-28 23:22:02   unit            m³
     2026-02-28 23:22:02   volume          154.72
   internal:
Attributes:
   IODev      nanoCUL_WM1
   alias      Warmwasser_Dirk
   genericDeviceType thermometer
   homebridgeMapping clear CurrentTemperature=volume
   room       HASS,0.5 Zähler
   siriName   Warmwasser


OK

#3

Unterstützende Dienste / Aw: Neues Modul: Signalbot (In...

Letzter Beitrag von Adimarantis - 28 Februar 2026, 21:41:00

Kleines Update. Hab jetzt doch noch auf die schnelle versucht die 0.13.24 mit Java 25 zu installieren.

Für aarch64 (also Raspberry mit echten 64 Bit Betriebssystem) klappt das, weil ein Java 25 auf adoptium.net bereits vorhanden ist.

Für die alten 32 Bit armv7l hatte ich damals eigens ein Java 21 kompiliert. Dafür habe ich aktuell weder die Zeit noch eine geeignete Umgebung. Wer also nicht auf 64 Bit aarch64 umsteigt oder sich ein Java 25 übersetzt wird wohl auf signal-cli 0.13.23 bleiben müssen - in der Hoffnung dass die Version noch länger kompatibel bleibt.

Für die aarch64 Anwender hängt der neue Installer an diesem Post. Werde ich jetzt nicht offiziell releasen, weil sonst alle armv7l user auf der Strecke bleiben.

[Revision 30892: 50_Signalbot: Installer signal-cli 0.13.23 update]

#4

FHEM Code changes / Revision 30892: 50_Signalbot: ...

Letzter Beitrag von System - 28 Februar 2026, 21:11:22

Revision 30892: 50_Signalbot: Installer signal-cli 0.13.23 update

50_Signalbot: Installer signal-cli 0.13.23 update

Source: Revision 30892: 50_Signalbot: Installer signal-cli 0.13.23 update

#5

Unterstützende Dienste / Aw: Neues Modul: Signalbot (In...

Letzter Beitrag von Adimarantis - 28 Februar 2026, 21:02:27

Ich vermute dass es tatsächlich an "Buster" liegt.
signal-cli verwendet eine native library (genau die wird angemeckert) die ich für den Raspberry von einer Site runterlade, die diese vorgebaut anbietet.
Wahrscheinlich haben diese ihre Build Umgebungen aktualisiert, was zu dem Problem führen kann, dass eine neuere glibc vorrausgesetzt wird.

signal-cli ist generell leider gerne vorne dabei, wenn es dabei geht das neuste vom neuen zu verwenden. Mit der aktuellen Version 0.13.24 haben sie jetzt auf Java 25 umgestellt - und das gibt es für den Raspberry standardmässig noch nicht mal für Trixie geschweige denn Bookworm oder älter.

Bis zur 0.13.23 reicht Java 21 - aber auch das gibt es z.B. auf dem von mir verwendeten 64bit Bookworm nicht. Daher muss ich auch die von einer alternativen Quelle installieren. Das ist aber schon eine Weile so.

Daher wird 0.13.24 von mir aktuell nicht angeboten. Muss erst den Installer umbauen und testen - da komme ich aber aktuell nicht dazu.

Für dich heisst das wohl aktualisieren - am Besten gleich auf Trixie damit wieder eine Zeit Ruhe ist.

Jörg

#6

Solaranlagen / Aw: Modul für Ecoflow-Komponen...

Letzter Beitrag von MasterRay - 28 Februar 2026, 20:17:23

Da kann ich aus Erfahrung nur den Tipp geben: Meist muss die Reihenfolge der Parameter beachtet werden, sonst ist die Prüfsumme ("Signature") angeblich falsch, obwohl der Wert der Signature sich eigentlich nicht ändert. Nicht ärgern, nur wundern.

Siehe Ecoflow-Doku (General Information): "Step 1: request parameters must be sorted by ASCII value and concatenated with characters =, &"

#7

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 28 Februar 2026, 20:15:28

Hallo Sebasian,

das Problem bei "manchmal" auftretenden Phänomänen ist eben dass sie nicht nachvollziehbar sind und dadurch sehr schwer zu finden und zu beseitigen.
Selten habe ich das beschriebene Problem der Anzeige -01:00 verbunden mit einem nicht vorhandenen Wettersymbol bei mir auch schon beobachtet. Es ist aber immer eine unchristliche Zeit zu der ich im allgemeinen keinen Nerv mehr für eine Ursachensuche habe. Leider ist im nachhinein die Ursache nicht mehr zu ermitteln.

Deinen Hinweis bzgl. "Ist nämlich der erste Balken das Maximum, wächst das entsprechende Diagramm sehr stark in der Höhe ..." gehe ich mal nach, wobei ich mir nicht denken kann einen Wert nicht zu berücksichtigen. Aber wer weiß, vllt. ist es eine heiße Spur.

LG,
Heiko

#8

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von SebastianM83 - 28 Februar 2026, 19:15:55

Hallo Heiko,

ich habe schon ne Weile (glaube schon von Anfang an, seit ich SolarForecast nutze) das Phänomen, dass die Höhe der Balkendiagramme (ich nutze alle 3 Balkendiagramme mit je 2 Graphen) manchmal nicht richtig skaliert.

Ich glaube ich habe inzwischen herausgefunden weshalb (Annahme von mir):

Du ermittelst das Maximum der beiden Graphen für jedes Diagramm, um daraus die Höhe der einzelnen Balken zu berechnen. Dabei wird vermutlich der Wert des ersten Balken nicht berücksichtigt, was zu dem manchmal störenden Verhalten führt. Ist nämlich der erste Balken das Maximum, wächst das entsprechende Diagramm sehr stark in der Höhe, weil die Berechnung mit dem Maximum der anderen Balken rechnet. Da ich meinen Akku regelmäßig aus dem Netz lade und zu Zeiten mit teurem Strompreis (Tibber) nichts aus dem Netz entnehme, kommt es immer wieder dazu, dass ich ewig scrollen muss um den 11kWh Balken entlang zu scrollen, da alle anderen Balken nur wenige Wh hoch sind. Wächst zum Beispiel der Balken der aktuellen Stunde an, kann man zusehen, wie sich die Skalierung anpasst und wieder "normal" wird.
Meine Vermutung ist, dass evtl. ein Array mit Werten nur von Index 1 beginnend ausgewertet wird statt von Index 0 beginnend.

Des Weiteren zeigt die Zeit unter dem ersten Balken immer -01:00, wenn es eigentlich 23:00 vom Vortag anzeigen müsste. Der Balken zeigen aber die korrekten Werte. Ist der erste Balken 22:00 und der zweite Balken 23:00, dann passt alles.

Ich habe die Anzeige auf insgesammt 24 Balken mit 6h Historie eingestellt. Beide Fehler sind aber unabhängig von der Historien-Einstellung und tritt auch bei anderen Einstellungen auf, wenn die von mir geschriebenen Bedingungen erfüllt sind.

Ich hoffe die Fehlerbeschreibung hilft dir.

Gruß
Sebastian

#9

Sprachsteuerung / Aw: alexa-fhem test version mi...

Letzter Beitrag von fz55 - 28 Februar 2026, 18:29:45

Hallo ferby09,

ich habe testweise die Katzenklappe nach deinen Vorgaben definiert. Nach dem zweiten alexa-fhem reload wurde sie von Alexa erkannt.

#10

MQTT / Aw: "Der MQTT-Workshop (MQTT2-...

Letzter Beitrag von betateilchen - 28 Februar 2026, 18:04:27

Man kann doch inzwischen in aktuellen zigbee2mqtt Versionen in jedem Gerät die Gesprächigkeit reduzieren.
Hilft das nicht schon sehr viel weiter?