Neueste Beiträge

#1

MQTT / Aw: LWT offline und State anpa...

Letzter Beitrag von riker1 - 03 Oktober 2025, 13:18:30

hatte ich falsch verstanden, ich dachte du meinst fhem server nicht mqtt server.

#2

MQTT / Aw: attrTemplate welches ist z...

Letzter Beitrag von TomLee - 03 Oktober 2025, 13:02:33

In eigentlich fast jedem attrTemplate wird ein model-Attribut gesetzt.

https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template

#3

MQTT / Aw: LWT offline und State anpa...

Letzter Beitrag von TomLee - 03 Oktober 2025, 12:59:38

danke, ah, dachte der mqtt server sendet offline

Macht er doch?

#4

MQTT / attrTemplate welches ist zugeo...

Letzter Beitrag von riker1 - 03 Oktober 2025, 12:44:22

Hallo,

hätte eine Frage, wie erkenne ich am MQTT Device , welche attrTemplate per set zugeordnet wurde?




Danke

#5

MQTT / Aw: LWT offline und State anpa...

Letzter Beitrag von riker1 - 03 Oktober 2025, 12:41:54

danke, ah, dachte der mqtt server sendet offline

[Was suche ich?]

#6

Beleuchtung / LED Strahler Außenbereich - WL...

Letzter Beitrag von Take-Off - 03 Oktober 2025, 12:41:03

Werte FHEM Gemeinde,

da mich diese Aufgabe nun schon längere Zeit erfolglos beschäftigt, benötige ich eure Hilfe.

Bisher beleuchte ich den Außenbereich mit mehreren 20W RGBWW WiFi Stahlern von Novostella. Damals mit Tuya-Convert problemlos in FHEM einsetzbar. Den Link platziere ich ganz unten.
Leider gibt es dieses Produkt nicht mehr, die neuere Version lies sich ohnehin nicht mehr flashen.

Was suche ich?
- Außenstrahler mit mindestens 15W - 20W. Mindestens weiß dimmbar, wünschenswert RGBWW
- Vollumfänglich steuerbar über FHEM
- Keine Cloud / App zur Einrichtung nötig

Idealerweise kann das Gerät also per WiFi / MQTT mit FHEM kommunizieren.
Bei meiner Suche bin ich öfter auf ZigBee gestoßen, aber noch nicht vollumfänglich davon überzeugt, da ich ein neues Gateway dafür brauche.

Ich bin für jeden Tipp dankbar.



Link zum bisherigen Produkt:
https://www.amazon.de/Novostella-Kompatibel-Flutlichtstrahler-Wasserdicht-Stimmungslichter/dp/B09FK182RJ

#7

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

Letzter Beitrag von JoWiemann - 03 Oktober 2025, 12:36:36

Hallo Björn,

anbei die "08.20.06c Beta". Habe ich korrigiert. Nach dem Einspielen bitte Fhem neu starten.

Grüße Jörg

#8

Frontends / Aw: eCharts in FHEM (Version 0...

Letzter Beitrag von schwatter - 03 Oktober 2025, 12:08:22

Mahlzeit,

im Anhang die Version 0.0.13.6

• Umbau, damit die Buttons auf Mobile und Desktop per X- und Y-Koordinaten frei platziert werden können.
• Dadurch wurde der Fehler in attr zu option_legend_m_buttons behoben. Jetzt: option_buttons_visible_mobile:on,off.
• Dokumentation hinzugefügt.
• Fehler in Zeile 570 (Use of uninitialized value $_) behoben.
• Kompletter Code auf Leerzeichen umgestellt – hier und da waren noch Tabs.
• Dokumentation mit HTML-Formatter formatiert, sodass alles sauber im Modul formatiert ist.

Vorher mit Bug:

Code Auswählen Erweitern

option_legend_desktop
option_legend_mobile:on,off  <-- falsch, eine Position zu tief
option_legend_m_buttons

Jetzt nach dem Umbau:

Code Auswählen Erweitern

option_buttons_offset_desktop
option_buttons_offset_mobile
option_buttons_visible_mobile:on,off
option_legend_desktop
option_legend_mobile


#9

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

Letzter Beitrag von Wastegate - 03 Oktober 2025, 11:47:33

Hallo,

ich kann meinen Anrufbeantworter mit "set tam 0 on" nicht mehr einschalten. Auch das ausschalten geht nicht mehr.


2025.10.03 11:37:41 4:[Fritzbox | 5590 | 272.08.02 | call_TR064_Cmd.14313] - EXPANDED:TR064 error 713:SpecifiedArrayIndexInvalid (service='X_AVM-DE_TAM:1', control='x_tam', action='SetEnable', parameter1='NewEnable' => '1', parameter2='NewIndex' => '-1')

Grüße Björn

#10

DOIF / Aw: obwohl die erste Bedingung...

Letzter Beitrag von Damian - 03 Oktober 2025, 11:36:53

DOELSEIF realisiert eben seit 10 Jahren nicht das ELSE, das das Schlüsselwort DOELSEIF suggeriert.

Das ist korrekt.

...solange die IF-Bedingung TRUE ist, darf niemals der ELSE-Zweig betreten werden.

Für die Logik einer IF/ELSEIF/ELSE ist es unerheblich, ob sich bei der IF-Bedinigung ein Eingangsparameter ändert.

Das ist auch korrekt.

Wenn in der Commandref ein Hinweis stünde, dass "ein DOELSEIF nur mit checkall-Attribut ein DOELSEIF sei und ansonsten DOELSEIFs gleichberechtigte Statements zum DOIF sind" wäre FHEM evtl. auch schon geholfen wenn der Code nicht verändert werden sollte.

Den Hinweis auf checkall kann ich beim nächsten Update einbauen.

Hätte ein "default checkall all" für neue Objekte denn technische Nachteile? Eine Abwärtskompatibilität mit bestehenden Objekten wäre ja gegeben.

Nach zehn Jahren schon. Ich müsste jedes mal erklären, warum sich zig-tausend definierte DOIF-Devices anders verhalten als zig-tausend neu definierte.

Nur zur Info, das Modul hat sich in meinem ersten Entwurf genauso Verhalten, wie du es dir vorstellst, wurde aber bewusst geändert, weil viele DOIF-Definitionen sich anders Verhalten haben, als ich wollte. Es wurde oft ein falscher Zweig ausgeführt, der weiter vorne definiert war, an den ich nicht mehr gedacht hatte. Das hat damit zutun, dass man bei DOIF Ereignisse und Zustände in einer Abfrage definiert.

Beispiel:

Code Auswählen Erweitern

DOIF ([device1:state] eq "on") (set bla...
...
DOELSEIF ([device2:state] eq "on") (set bla ...
Wenn ein Event von device2 mit "on" kommt, erwartet man, dass dieser Zweig ausgeführt wird. Mit checkall passiert das dann nur manchmal

Das ist die Alternative ohne checkall mit dem Verhalten on IF/ELSEIF/ELSE

DOIF {if ([device1:state] eq "on") (fhem_set" bla...
...
elsif ([device2:state] eq "on") (fhem_set" bla...

PS Es gibt auch den IF-Befehl der sich genauso verhält.