Neueste Beiträge

#1

Forum-Software / VERSCHOBEN: Datum uhrzeit setz...

Letzter Beitrag von Otto123 - 05 November 2026, 12:58:56

Dieses Thema wurde nach Anfängerfragen verschoben.

https://forum.fhem.de/index.php?topic=145849.0

#2

Anfängerfragen / Aw: Mercedes CLA 250+

Letzter Beitrag von betateilchen - 05 November 2026, 12:49:14

Das gehört nicht in die Anfängerfragen, für Fragen zu E-Autos gibt es ein eigenes Unterforum.

Den Button zum Verschieben findest Du unten links auf der Seite.

#3

Anfängerfragen / Mercedes CLA 250+

Letzter Beitrag von wolliballa73 - 05 November 2026, 12:36:09

Hallo allerseits,

ich darf demnächst von meinem CLA 250e zum neuen CLA 250+ wechseln und würde den gerne wieder in FHEM integrieren.
Mein bisheriges Fahrzeug habe ich über BYOCAR (?) verbunden, zumindest bis das Abo für Fernzugriff ausgelaufen ist. Jetzt habe ich mal ein bisschen die KI befragt, wie der Stand der Dinge denn so ist. Die ist sich ziemlich sicher, dass ich den Umweg über HomeAssistant und MQTT gehen muss, da eine direkte Integration mit FHEM nicht möglich ist.
Kann das hier bestätigt werden, oder gibt's nen anderen (Königs-)Weg?

Was ich brauche bzw. möchte:
- SoC und/oder Reichweite lesen
- Vorklimatisierung programmieren (oder zumindest einschalten)

Das sollte reichen, dass ich mein DOIF zur Überschuss-Ladung entsprechend anpassen kann.

Vielen Dank für sachdienliche Hinweise 

VG
Mathias

#4

Anfängerfragen / Aw: Datum uhrzeit setzen

Letzter Beitrag von Prof. Dr. Peter Henning - 05 November 2026, 12:24:56

Erstens gehört dieser Post nicht hierher, sondern in die Anfängerfragen.

Zweitens: Da die SD-Karte komplett voll ist, gar nicht. Offenbar läuft FHEM seit 2019 _eben nicht_. So wie es aussieht, hat irgendeine Datenbank die Karte komplett vollgemüllt.

Der sicherste Weg ist, mit einer neuen Karte und neuem Betriebssystem zu starten und die alte FHEM-Konfiguration von der alten Karte zu holen.

LG

pah

#5

Anfängerfragen / Datum uhrzeit setzen

Letzter Beitrag von reimundko - 05 November 2026, 12:16:45

Hallo habe mehrere jahre fhem auf einem Rspberry am laufen.-

Habe nun gemerkt dass datum und uhrzeit verkehrt sind.
wie kann ich das bitte ändern ?

Vielen Dank

2019-02-15 08:13:55
desired
20
2019-02-15 07:25:38
e_ESPEasy_ESP_Easy_ds18b20k_Temperature
20.35
2019-02-15 08:26:16
e_Kellersteckdose_desired
20
2019-02-15 07:25:38
e_Kellersteckdose_hysterese
3
2019-02-15 08:22:43
hysterese
3
2019-02-15 08:22:43
state
off
2019-02-15 08:13:55
timer_01_c01
15.02.2019 20:00:00
2019-02-15 07:24:51

in der shell wird angezeigt
sudo dpkg-reconfigure tzdata

Current default time zone: 'Europe/Berlin'
Local time is now:      Fri Feb 15 07:33:14 CET 2019.
Universal Time is now:  Fri Feb 15 06:33:14 UTC 2019.

debconf: DbDriver "config": could not write /var/cache/debconf/config.dat-new: No space left on device
Warning: unable to close filehandle $fh properly: No space left on device at /usr/share/perl5/Debconf/DbDriver.pm line 55.

#6

Heizungssteuerung/Raumklima / Aw: THZ Tecalor (LWZ Stiebel E...

Letzter Beitrag von willybauss - 05 November 2026, 11:30:09

Danke, Trumpeter. Da muss ich nicht mehr viel ergänzen. Original war eine Stabelektrode verbaut, ersetzt durch eine Kettenanode, die in anodenshop.com aber nur 79,30€ gekostet hatte. Es erschließt sich mir nicht, weshalb ich den Druckschalter austauschen sollte, solange er nicht fehlerhaft ist; aber das kann Jeder halten wie er meint.

Auch ich habe eine Entkalkungsanlage, die die Härte von 18 auf 6 reduziert. Dennoch keine so kurze Lebensdauer wie die genannten 2 Jahre.

#7

Sonstige Systeme / Aw: Netatmo Modul - 38_netatmo...

Letzter Beitrag von BroPi - 05 November 2026, 11:29:22

Moin.

Ich sehe das eher als Chance, das Polling von Netatmo nervt ohnehin. Ich würde mich rechtzeitig darum kümmern. Nachdem ich die letzten Wochen damit verbracht habe, FHEM in meiner Installation KI-unterstützt für die nächsten Jahre fit zu machen (zertifikatbasierter HTTPS-Login, hübscheres CSS, Readings-Datenbank und schneller Graph-Viewer...), würde ich sogar mittlerweile die Maintainerschaft des Netatmo-Moduls anbieten, falls das noch gewünscht ist. An wen müsste ich mich dazu wenden? VG flydd

Das hört sich ja gut an!
An Rudolf Koenig müsstest du dich dann wenden, um Maintainer zu werden, was ich sehr begrüßen würde.
Übrigens läuft das Modul, seit den letzten Änderungen wirklich sehr stabil. Neustarts von FHEM überlebt es immer problemlos und es gibt keinerlei Abstürze. Auch die letzte Änderung "extendedRainPeriods 3,7,30" konnte ich erfolgreich  mit "7" sehr zufriedenstellend testen.

#8

Frontends / Aw: fhem-cms – Die Smart-Home-...

Letzter Beitrag von Prof. Dr. Peter Henning - 05 November 2026, 11:27:01

Interessant - aber was ist der Use Case?

LG

pah

#9

MQTT / Aw: MQTT to Home assistant

Letzter Beitrag von Beta-User - 05 November 2026, 11:23:28

especially first get the fhem<=>MQTT part working.

So let's start with some remarks to the FHEM=>MQTT part. Means: how to publish reading values towards the server.

Many "solutions" out there recommend using (more or less) "global publish of any information". My very personal point of view: this isn't really state of the art, even if you use the "devspec" option to restrict at least the number of devices to send.

Let's start, my example - just as shown via "Copy for forum" with one dummy device configured to interact "somehow" with the MQTT_GENERIC_BRIDGE:

Code Auswählen Erweitern

define mgb3 MQTT_GENERIC_BRIDGE mgb3 TYPE=dummy
#   DEF        mgb3 TYPE=dummy
#   FUUID      6aec49d7-f33f-d171-3512-4d1df8c29d30b951
#   IODev      mqtt_io
#   NAME       mgb3
#   NR         664
#   NTFY_ORDER 70-mgb3
#   STATE      ???
#   TYPE       MQTT_GENERIC_BRIDGE
#   devspec    TYPE=dummy
#   eventCount 5
#   prefix     mgb3
#   READINGS:
#     2026-11-05 10:19:48   IODev           mqtt_io
#     2026-11-05 10:25:04   device-count    1
#     2026-11-05 10:19:48   incoming-count  0
#     2026-11-05 10:19:48   outgoing-count  0
#     2026-11-05 10:19:48   transmission-state IO device initialized (mqtt2)
#     2026-11-05 10:19:48   updated-reading-count 0
#     2026-11-05 10:19:48   updated-set-count 0
#   devices:
#     devStrich0:
#   globalDeviceExcludes:
#   globalReadingExcludes:
#   globalTypeExcludes:
#     pub:
#       FHEMWEB    *
#       Global     *
#       MQTT       transmission-state
#       MQTT_BRIDGE transmission-state
#       MQTT_DEVICE transmission-state
#       MQTT_GENERIC_BRIDGE *
#       telnet     *
#     sub:
#       FHEMWEB    *
#       Global     *
#       MQTT       transmission-state
#       MQTT_BRIDGE transmission-state
#       MQTT_DEVICE transmission-state
#       MQTT_GENERIC_BRIDGE *
#       telnet     *
#
setstate mgb3 2026-11-05 10:19:48 IODev mqtt_io
setstate mgb3 2026-11-05 10:25:04 device-count 1
setstate mgb3 2026-11-05 10:19:48 incoming-count 0
setstate mgb3 2026-11-05 10:19:48 outgoing-count 0
setstate mgb3 2026-11-05 10:19:48 transmission-state IO device initialized (mqtt2)
setstate mgb3 2026-11-05 10:19:48 updated-reading-count 0
setstate mgb3 2026-11-05 10:19:48 updated-set-count 0
 

So what's that:

Code Auswählen Erweitern

define mgb3 MQTT_GENERIC_BRIDGE mgb3 TYPE=dummydefine <name> <TYPE> should be obvious, "mgb3" is the "prefix", "TYPE=dummy" is the regex to limit the possible devices (I'd prefered "TYPE=MAX", so just change that ).
"prefix" is just the first letters of the attributes (in your case available in all the MAX-devices) that might be set for interaction of these devices with this MQTT_GENERIC_BRIDGE. (Maybe there are better options, but imo less confusing than generic "mqtt", especially as I have configured more than one MQTT_GENERIC_BRIDGE here).

Next step would be to do some more testing with just one device (my "dustbin"):

Code Auswählen Erweitern

defmod devStrich0 dummy
attr devStrich0 icon dustbin
attr devStrich0 mgb3Publish temperature:mgb3/$device/$reading
So whatever might be send towards my dustbin, only any event referring to the reading "temperature" will finally be visible via MQTT.
As topic, only "mgb3" is hardcoded. We could do better, so let us turn to the "solution" you found:

Code Auswählen Erweitern

attr mqttGenericBridge globalDefaults base="homeassistant" qos=2 retain=1


Just forget about the last to "recommendations" and DELETE them:
Afaik, "qos" is not needed nor supported by the MQTT2_(SERVER|CLIENT) modules, and if you really need the "last known value" of any gadget in HomeAssistant, there's afaik more efficient ways possible than abusing any MQTT-Server as data storage. You might better provide some "get the latest fhem values" request option, if you really suffer from relevant downtimes in HomeAssistant

Wrt. to "base", in the commandref there's an (at least in the german version somehow missing the attribute name) example:

Code Auswählen Erweitern

attr <dev> globalDefaults sub:base={"FHEM/set/$device"} pub:base={"FHEM/$device"}
Adopting this to

Code Auswählen Erweitern

attr mgb3 globalDefaults sub:base={"mgb3/set/$device"} pub:base={"mgb3/$device"} and

Code Auswählen Erweitern

attr devStrich0 mgb3Publish temperature:$base/$readingwill finally publish all new temperature values (generating events!) to the same topic as the hardcoded version.

Apart from some remarks wrt. to the differentiation between publish ("pub:...") and "supscription" (sub:...") the explanation of the relevant modules and attributes might be more or less complete. Additionally just make sure MQTT_GENERIC_BRIDGE points to the desired IODev and set the appropriate attribute value if needed.

Once you got your MAX thermostat values published as wanted, we could turn to the "subscription" side (MQTT=>FHEM). Be warned: this is a little more complex than what we've discussed until now (but might already be a peace of cake in case you tried the configuration the attrTemplate way ).

#10

MQTT / Aw: MQTT to Home assistant

Letzter Beitrag von Beta-User - 05 November 2026, 10:14:19

Forget about autodiscovery in HASS... Do yaml config manually

Some additional remarks on this provoking wording:
- As already remarked, I'm not using HomeAssistant, so my sight on this might not be aptly in all aspects
- To my understanding, (MQTT-) autodiscovery allows using whatever gadget without any deeper insight, which topics the gadget uses and expects, how the payload is built and so on. Very helpfull, if you really don't know nothing about the gadget, and/or the firmware etc. might change and bring some braking changes in the MQTT communication
- fiddling around with yaml language seems to be special (I personally absolutely dislike it...), so providing all the configuration info via MQTT may somehow be the "easier way". There ares some users in FHEM trying to support this, see e.g. https://forum.fhem.de/index.php?topic=138354.0 (there might even exist a working solition somewhere...)
- the "basic problem" imo is the non persistive design: As long as there's no config message, the gadget doesn't exist. So one could either abuse the MQTT server (via retain) as "configuration storage", or send all the configution stuff more or less regularly.

All together: Not the best option for any interaction to be fully configured on both ends (FHEM and HomeAssistant) in cases the configuration itself, once established (more or less) never changes...