- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#11
DOIF / Aw: aktuelle Zeit in dummy sch...
Letzter Beitrag von RalfRog - 27 November 2025, 15:56:46https://wiki.fhem.de/wiki/Notify (dort nach "Zeitverzögert schalten" suchen)
ok, die Anforderung war umfangreicher als nur verzögert das Radio einschalten
#12
DOIF / Aw: aktuelle Zeit in dummy sch...
Letzter Beitrag von matkoh - 27 November 2025, 15:56:08Ich habe nur einen Ausschnitt meiner DOIFs und Konfigurationen gepostet. Z. B. steuert das Drücken des Tasters auch Rolladeneinstellungen. Dann gibt es mehrere Räume und je nach Einstellung des Dummy Fruehstueck soll ein anderes Radio eingeschaltet werden.
Mir erschien die Steuerung über ein Dummy als sinnvollste Lösung.
Mir erschien die Steuerung über ein Dummy als sinnvollste Lösung.
#13
DOIF / Aw: aktuelle Zeit in dummy sch...
Letzter Beitrag von rabehd - 27 November 2025, 15:47:57Zitat von: matkoh am 27 November 2025, 15:39:07nach einer festgelegten Zeit nach Drücken des Tasters eine Aktion (Radio einschalten) auszuführen.Wenn das die eigentliche Aufgabe ist, dann erscheint mir die Lösung etwas zu groß. Außer Du willst Rechenzeit verbrauchen.
Warum reagierst Du nicht mit einem notify (von mir aus auch DOIF) auf den Schalter? Sleep (und wait) verzögern das einfach.
#14
DOIF / aktuelle Zeit in dummy schreib...
Letzter Beitrag von matkoh - 27 November 2025, 15:39:07Hallo,
ich möchte (mit einem Homematic-Taster) die aktuelle Zeit in ein Dummy schreiben und das Reading des Dummy in einem anderen DOIF auswerten, das gelingt mir aber nicht. Der Sinn ist, nach einer festgelegten Zeit nach Drücken des Tasters eine Aktion (Radio einschalten) auszuführen.
Hier ein Ausschnitt des ersten DOIF, das den Dummy setzen soll mit verschiedenen Versuchen:
setreading Matthias_Aufgestanden timestamp {(time)} ergibt einen Unix-Zeitstempel, der aber auch nicht als Zeit auswertbar ist.
setreading Matthias_Aufgestanden time {(hms)} ergibt den Fehler "Bareword "hms" not allowed while "strict subs" in use at..."
Hier ein Ausschnitt des 2. DOIF, der das vorher gesetzte Dummy auswerten soll:
Das gleiche passiert bei [([Matthias_Aufgestanden] + 900)].
Im 1. DOIF habe ich auch versucht,
Wie kann ich also mit Drücken des Tasters eine aktuelle Zeit in ein Dummy schreiben, in einem 2. DOIF eine Zeit addieren und dann eine Aktion ausführen?
Vielen Dank für Eure Hinweise
Matthias
ich möchte (mit einem Homematic-Taster) die aktuelle Zeit in ein Dummy schreiben und das Reading des Dummy in einem anderen DOIF auswerten, das gelingt mir aber nicht. Der Sinn ist, nach einer festgelegten Zeit nach Drücken des Tasters eine Aktion (Radio einschalten) auszuführen.
Hier ein Ausschnitt des ersten DOIF, das den Dummy setzen soll mit verschiedenen Versuchen:
Code Auswählen
## 3
DOELSEIF ([Matthias.Status_2:?SHORT])
(set RolloStatus on, set Matthias_Aufgestanden {(TimeNow)}, setreading Matthias_Aufgestanden timestamp {(time)}, setreading Matthias_Aufgestanden time {(hms)}set Matthias_Aufgestanden {(TimeNow)} ergibt eine formatierte Zeichenkette, z. B. 2025-11-27 14:38:46, das ist aber nicht als Zeit auswertbar.setreading Matthias_Aufgestanden timestamp {(time)} ergibt einen Unix-Zeitstempel, der aber auch nicht als Zeit auswertbar ist.
setreading Matthias_Aufgestanden time {(hms)} ergibt den Fehler "Bareword "hms" not allowed while "strict subs" in use at..."
Hier ein Ausschnitt des 2. DOIF, der das vorher gesetzte Dummy auswerten soll:
Code Auswählen
## 5
DOELSEIF ([Fruehstueck] eq "Kueche" and [([Matthias_Aufgestanden:timestamp] + 900)])
(set Sonos_Kueche Volume 13, set Sonos_Kueche PlayURI ...)Das ergibt den FehlerCode Auswählen
error: Wrong timespec 1764250726.70788: either HH:MM:SS or {perlcode}Das gleiche passiert bei [([Matthias_Aufgestanden] + 900)].
Im 1. DOIF habe ich auch versucht,
Code Auswählen
setreading Matthias_Aufgestanden time {$hms}zu setzen, dann wird einfach "{$hms}" in das Reading geschrieben.Wie kann ich also mit Drücken des Tasters eine aktuelle Zeit in ein Dummy schreiben, in einem 2. DOIF eine Zeit addieren und dann eine Aktion ausführen?
Vielen Dank für Eure Hinweise
Matthias
#15
Homematic / Aw: HM-CFG-LAN ersetzen
Letzter Beitrag von grappa24 - 27 November 2025, 15:37:42Zitat von: Otto123 am 27 November 2025, 12:14:14Der Aufwand ist immer relativ gleich: hast Du VCCU - dann einfach IOlist erweitern, hast Du keine VCCU dann mache Eine - und dann IOlist erweiternEine VCCU hab ich, Anleitung für IOList erweitern hab ich auch gefunden - check
ZitatBeide Geräte sind älter als alt - hol Dir besser ein HM-MOD-RPI-PCB bei elv und einen USB Serialwandler. Wenn Du nicht löten kannst / willst gibt es die Kombi mW auch fertig in der Bucht.- Der HM-MOD-RPI-PCB wird "normalerweise" auf das GPIO vom RasPi aufgesteckt?
- Alternativ kann man ihn mit einem USB Serialwandler an die USB-Schnittstelle des Raspi anschließen?
- Nach dem Anstecken muss er in FHEM konfiguriert werden?
- Für sowas gibts doch sicher dann auch ein kleines "Gehäuse"
- Das Foto zeigt wohl einen fertigen HM-MOD-RPI-PCB mit Antenne(nadapter)?
#16
Wallboxen und E-Fahrzeuge / Aw: VW ID.7, ID.5, ID.4, ... ...
Letzter Beitrag von Prof. Dr. Peter Henning - 27 November 2025, 15:35:47So, da mein weconnect-mqtt nicht mehr so richtig wollte und zum Jahresende auch abgekündigt wurde, habe ich jetzt auf CarConnectivity umgestellt.
Zunächst einmal Lob: Da ist jetzt eine ganze Menge Arbeit hineingeflossen, Installation und Start haben problemlos funktioniert. Das Ding hat (auf Wunsch) auch ein nettes Web-Interface.
Wermutstropfen: Im Zuge der Verallgemeinerung haben die Maintainer, im Wesentlichen also Till Steinbach, die ganzen Topics geändert. Dabei sind durchaus sinnvolle Vereinfachungen herausgekommen, beispielsweise der Ersatz von
/vehicles/.../domains/charging/plugStatus/plugConnectionState durch /garage/.../charging/connector/connection_state
Aber man muss eben alles neu setzen, und natürlich auch erst wieder herausfinden, was denn wo steckt. Ich habe vor, in den nächsten Tagen noch den Wiki-Artikel anzupassen.
Doppelter Wermutstropfen: Daten zu Türen und Fenstern fehlen noch, auch die Überwachung des 12V-Batterielevels geht (noch) nicht.
LG
pah
Edit: Ich habe das gerade mit Till Steinbach diskutiert. Wenn man in der Konfiguration des Volkswagen-Connectors setzt
Zunächst einmal Lob: Da ist jetzt eine ganze Menge Arbeit hineingeflossen, Installation und Start haben problemlos funktioniert. Das Ding hat (auf Wunsch) auch ein nettes Web-Interface.
Wermutstropfen: Im Zuge der Verallgemeinerung haben die Maintainer, im Wesentlichen also Till Steinbach, die ganzen Topics geändert. Dabei sind durchaus sinnvolle Vereinfachungen herausgekommen, beispielsweise der Ersatz von
/vehicles/.../domains/charging/plugStatus/plugConnectionState durch /garage/.../charging/connector/connection_state
Aber man muss eben alles neu setzen, und natürlich auch erst wieder herausfinden, was denn wo steckt. Ich habe vor, in den nächsten Tagen noch den Wiki-Artikel anzupassen.
Doppelter Wermutstropfen: Daten zu Türen und Fenstern fehlen noch, auch die Überwachung des 12V-Batterielevels geht (noch) nicht.
LG
pah
Edit: Ich habe das gerade mit Till Steinbach diskutiert. Wenn man in der Konfiguration des Volkswagen-Connectors setzt
Zitat"force_enable_access": false // To allow for door/window statekommen wieder die alten "domains"-Daten. Allerdings _alle_ - was für einen Sinn sollte es dann machen, die neuen Topics zu verwenden? Irgendwie noch nicht ganz konsistent, vor allem, weil zwar der ganze alte "domains"-Kram dann gesendet wird, aber ohne Inhalt.
#17
Automatisierung / Aw: ASC Auto Shutter Control -...
Letzter Beitrag von ch.eick - 27 November 2025, 15:27:44Welcher state wird denn vom ASC in diesem Fall verwendet?
#18
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von ch.eick - 27 November 2025, 15:26:16Hallo zusammen,
um den angesprochenen WAF zu optimieren läuft meine WP bereits ohne FHEM ziemlich optimal in einem Fenster von 10-16 Uhr mit der angesprochenen Tagesanhebung/Nachtabsenkung.
Das Haus ist sehr gut gedämmt und zusätzlich eine KWL (ohne Heizung). Die letzten Prozente der Optimierung habe ich dann noch mit FHEM herausgeholt, indem ich die nächtlichen WP Einschaltungen durch abschalten der Heizung in der WP erreiche. nur wenn es sehr kalt wird schalte ich bereits früh am Morgen die Heizung ein, dann ist der Wärmepuffer auch so gerade eben bei der Nachtabsenkung und muss wieder geladen werden.
Damit spart man sich die ganze Energiekalkulation und den Abgleich mit SF. Die Trefferquote für PV ist sehr hoch.
Der PV-Modus mit dem Überheizen und WW mit 60°C wird nur verwendet, wenn es heute Überschuss gibt und es morgen zuwenig PV gibt. Über eine Fernbedienung (von den Schweden) kann meine Frau den PV-Modus mit 45 Minuten Vorlauf selber noch starten um heißes Putzwasser zu bekommen. Wenn die Kiddies kommen ist das auch praktisch für die Dauerduscher.
Ohne SF lief die WP heute mit WW von 10-13 Uhr und von 13:30-14:30 Uhr, da die Außentemperatur bei 7° liegt.
VG Christian
um den angesprochenen WAF zu optimieren läuft meine WP bereits ohne FHEM ziemlich optimal in einem Fenster von 10-16 Uhr mit der angesprochenen Tagesanhebung/Nachtabsenkung.
Das Haus ist sehr gut gedämmt und zusätzlich eine KWL (ohne Heizung). Die letzten Prozente der Optimierung habe ich dann noch mit FHEM herausgeholt, indem ich die nächtlichen WP Einschaltungen durch abschalten der Heizung in der WP erreiche. nur wenn es sehr kalt wird schalte ich bereits früh am Morgen die Heizung ein, dann ist der Wärmepuffer auch so gerade eben bei der Nachtabsenkung und muss wieder geladen werden.
Damit spart man sich die ganze Energiekalkulation und den Abgleich mit SF. Die Trefferquote für PV ist sehr hoch.
Der PV-Modus mit dem Überheizen und WW mit 60°C wird nur verwendet, wenn es heute Überschuss gibt und es morgen zuwenig PV gibt. Über eine Fernbedienung (von den Schweden) kann meine Frau den PV-Modus mit 45 Minuten Vorlauf selber noch starten um heißes Putzwasser zu bekommen. Wenn die Kiddies kommen ist das auch praktisch für die Dauerduscher.
Ohne SF lief die WP heute mit WW von 10-13 Uhr und von 13:30-14:30 Uhr, da die Außentemperatur bei 7° liegt.
VG Christian
#19
Automatisierung / Aw: ASC Auto Shutter Control -...
Letzter Beitrag von ch.eick - 27 November 2025, 14:58:23Ich habe jetzt mal so angefangen
Code Auswählen
defmod WO_Gast dummy
attr WO_Gast devStateIcon .*zuhause:user_available:absent .*anwesend:user_available:absent .*abwesend:user_away:home .*verreist:user_ext_away:home .*bettfertig:scene_toilet:asleep .*schlaeft:scene_sleeping:awoken .*schläft:scene_sleeping:awoken .*aufgestanden:scene_sleeping_alternat:home .*:user_unknown:home
attr WO_Gast eventMap home:zuhause absent:abwesend gone:verreist gotosleep:bettfertig asleep:schläft awoken:aufgestanden
attr WO_Gast group Gaeste
attr WO_Gast icon scene_visit_guests
attr WO_Gast room Residents,Rollos
attr WO_Gast webCmd state
attr WO_Gast widgetOverride state:zuhause,bettfertig,schläft,aufgestanden,abwesend,verreist
#20
Automatisierung / Aw: ASC Auto Shutter Control -...
Letzter Beitrag von ch.eick - 27 November 2025, 14:52:20Zitat von: CoolTux am 27 November 2025, 14:46:49Bei diesem Attribut gibt man nicht das Residenz Device sondern ein oder mehrere roomate devices ein welche in diesem Raum schlafenOkay und wie könnte ich das z.B. mit einem Dummy Device An/Aus im FHEMWEB simmulieren? An/Aus sollen nur die Zustände andeuten, es könnte auch schläft/abwesend, oder was auch immer notwendig ist, sein.