Neueste Beiträge

#1

Automatisierung / Aw: GUEST nach timerablauf auf...

Letzter Beitrag von DeeSPe - 11 Dezember 2025, 13:48:15

Soweit ich weiß ist dieses Verhalten so gewünscht. Jedenfalls benutze ich dieses Konstrukt bereits seit vielen Jahren genau so.
Ein Gast steht ja für einen generischen Benutzer der dann und wann mal da sein könnte, also ist der logische Schluss, dass er nach "abwesend/absent" halt auf "none/nicht vorhanden" wechselt. Wer weiß ob der jemals zurückkommt!?
Im Gegensatz dazu sind ROOMMATE eben Benutzer die irgendwann auch mal wiederkommen.

Gruß
Dan

#2

Sonstige Systeme / Aw: fhempy: tuya (lokal)

Letzter Beitrag von satprofi - 11 Dezember 2025, 13:42:07

wie stellst du das an ? bei mir geht nichts mehr über lokale anbindung. nur mehr mit tuya-connector.

Das ist jetzt schon länger her, ca. 2.5 ~ 3 Jahre.  Das funktioniert bis jetzt reibungslos.

Viele Grüße Gisbert

also seitdem ich zugang zur cloud verloren hatte, klappts nur mehr über smartlife. alle befehle zu tuya_local werden nicht ausgeführt, weil "initialing"

#3

Sonstige Systeme / Aw: Neues Modul: Tado Heizungs...

Letzter Beitrag von Bernhard - 11 Dezember 2025, 13:25:55

aus meiner Sicht sind die Abo-Gebühren eine Unverschämtheit. Morgen kommen sie auf die Idee, die Nutzung von Tado insgesamt Abo-pflichtig zu machen.

Zur Frage.
Ich habe meinen Zeitplan innerhalb der App eingerichtet.

• Auto-Assist (Tado-Einstellung) deaktiviert
• Ortsabhängige Steuerung aktiviert
• - Home-WLAN-Erkennung überprüfe ich gelegentlich
• - Home-Bereich eingestellt, Standard (Umkreis 400 m) dürfte meist ausreichend sein
• Wetteranpassung (derzeit noch im Standard)
• Fenster-Offen-Erkennung für alle Räume deaktiviert.
       - Mit Home-Assist (Tado-Einstellung, nicht das HA-System)  wird relativ schnell reagiert, ohne träge, wird oft nicht bemerkt
• Intelligenter Zeitplan aktiviert

So, was nutze ich von TadoAPI:
- die Readings GeoLocation_.*  - also present/away und setze entsprechend HOME/AWAY
- externe Fenstersensoren setzen die Solltemperatur hoch oder runter.
- ein AT um 23:55 mit "setAllOverlays remove" um evtl. Fehlsteuerungen
  zu korrigieren
- Attribut oldreadings , derzeit jedoch nicht aktiv genutzt
- Attribut updateintervall 120   um temporäre Signalausfälle (Fenstersensoren, Handy) abzufangen

Viel mehr brauchts aus meiner Sicht nicht
(Einschränkung, gelegentlich übersieht Tado eine Rückmeldung der Handies, also zumindest für längere Abwesenheit schon mal kontrollieren und ggf. händisch auf AWAY stellen)

Ob diese Funktionen das Budget belasten, weiss ich nicht.

#4

Kalendermodule / Aw: [bug] 57_Calendar.pm: cuto...

Letzter Beitrag von betateilchen - 11 Dezember 2025, 13:01:52

Hallo Boris,
mit dem Event im ersten Beitrag habe ich heute getestet und das Verhalten scheint sich grundsätzlich verändert zu haben. Mit gesetztem Attribut cutoffOlderThan 60s wird mir von "get ... vevents" kein Event mehr zurückgeliefert.

Aber ich habe neue perl Warnungen im Log:

Code Auswählen Erweitern

2025.12.11 12:58:11 1: PERL WARNING: Argument "20250618T194000" isn't numeric in addition (+) at ./FHEM/57_Calendar.pm line 3088.
2025.12.11 12:58:11 1: stacktrace:
2025.12.11 12:58:11 1:     main::__ANON__                      called by ./FHEM/57_Calendar.pm (3088)
2025.12.11 12:58:11 1:     main::Calendar_UpdateCalendar       called by ./FHEM/57_Calendar.pm (2913)
2025.12.11 12:58:11 1:     main::Calendar_PollChild            called by fhem.pl (3514)
2025.12.11 12:58:11 1:     main::HandleTimeout                 called by fhem.pl (710)

2025.12.11 12:58:14 1: PERL WARNING: Use of uninitialized value in addition (+) at fhem.pl line 5266.
2025.12.11 12:58:14 1: stacktrace:
2025.12.11 12:58:14 1:     main::__ANON__                      called by fhem.pl (5266)
2025.12.11 12:58:14 1:     main::fhemTimeGm                    called by fhem.pl (5272)
2025.12.11 12:58:14 1:     main::fhemTimeLocal                 called by ./FHEM/57_Calendar.pm (1186)
2025.12.11 12:58:14 1:     ICal::Entry::tm                     called by ./FHEM/57_Calendar.pm (1198)
2025.12.11 12:58:14 1:     ICal::Entry::before                 called by ./FHEM/57_Calendar.pm (3088)
2025.12.11 12:58:14 1:     main::Calendar_UpdateCalendar       called by ./FHEM/57_Calendar.pm (2913)
2025.12.11 12:58:14 1:     main::Calendar_PollChild            called by fhem.pl (3514)
2025.12.11 12:58:14 1:     main::HandleTimeout                 called by fhem.pl (710)


#5

Anfängerfragen / Aw: (GELÖST) Fhem-Log periodis...

Letzter Beitrag von rabehd - 11 Dezember 2025, 12:56:14

Hmm, wer ein statistisch arbeitendes System mit einem Kosenamen belegt, sollte das mal mit einem Arzt seines Vertrauens erörtern.

Das würde ich nicht pauschalisieren!
Ein "Kose"-Name kann auch sagen, dass man mit Herzblut an der Sache arbeitet.
Es gibt genug Menschen ohne solche Kose-Namen-Themen, die einen Arzt brauchen.

#6

Anfängerfragen / Aw: (GELÖST) Fhem-Log periodis...

Letzter Beitrag von Prof. Dr. Peter Henning - 11 Dezember 2025, 11:58:35

Chaty

Hmm, wer ein statistisch arbeitendes System mit einem Kosenamen belegt, sollte das mal mit einem Arzt seines Vertrauens erörtern.

LG

pah

#7

Marktplatz - Güter / Aw: [S] 8GB Speicher für think...

Letzter Beitrag von betateilchen - 11 Dezember 2025, 11:10:03

(offtopic)
Ich suche für die gleiche Geräteserie gerade 2*16GB aber die Speicherpreise für diese kleinen Kisten sind inzwischen echt gruslig geworden.

#8

FHEMWEB / Aw: Anzeige plötzlich mit Fehl...

Letzter Beitrag von betateilchen - 11 Dezember 2025, 11:03:03

Bei mir Perl Version 5.28 auf einem Debian 10 System.

Debian 10 ist ja nun auch nicht wirklich aktuell.
Dafür gibt es doch schon seit 2024 nicht einmal mehr den LTS, nachdem schon 2022 das End-of-Life erreicht war.

[gone:verreist]

#9

Automatisierung / GUEST nach timerablauf auf non...

Letzter Beitrag von ch.eick - 11 Dezember 2025, 11:00:44

Hallo zusammen,
ich habe mir eine neuen Gast eingerichtet und nach der Abreise den Status absent gesetzt. Später ist dann der Timer abgelaufen und GUEST hat den Status "none" anstatt "gone" gesetzt.

Im rg_WO_Gast habe ich dann etwas gesehen, was mich etwas verunsichert.

- attr rg_WO_Gast eventMap  home:zuhause absent:abwesend gone:verreist gotosleep:bettfertig asleep:schläft awoken:aufgestanden
- Dadurch wurde dann mit stat none => zuhause angezeigt
- Wenn ich dann gone in none ändere scheint alles wieder richtig zu laufen.

Ich denke da ist irgendwo im GUEST, oder beim Anlegen von rg_WO_Gast ein Tippfehler.
In der Doku finde ich z.B. diesen Satz "Please note that individuals with current state 'gone' or 'none' (in case of guests) will not be touched.", aus dem ich dann ableite, dass beim Anlegen eines Gastes das Attribut eventMap mit none definiert werden müsste.

Aus dem Log

Code Auswählen Erweitern

2025.12.10 14:21:00.001 3: GUEST rg_WO_Gast: AutoGone timer changed state to 'gone'

List

Code Auswählen Erweitern

Internals:
   DEF        Bewohner
   DURATIONTIMER 1765446984.02892
   FUUID      692c2449-f33f-61a8-6f6f-a844c7b0146dba5e
   FVERSION   20_GUEST.pm:0.195330/2019-06-02
   NAME       rg_WO_Gast
   NOTIFYDEV  global,
   NR         894
   NTFY_ORDER 50-rg_WO_Gast
   READY      1
   RESIDENTGROUPS Bewohner
   STATE      verreist
   SUBTYPE    generic
   TYPE       GUEST
   eventCount 11537
   Helper:
     DBLOG:
       durTimerAbsence:
         LogDB:
           TIME       1765446924.03149
           VALUE      36:34:24
       durTimerAbsence_cr:
         LogDB:
           TIME       1765446924.03149
           VALUE      2194
       durTimerPresence:
         LogDB:
           TIME       1765315260.20787
           VALUE      00:00:00
       durTimerPresence_cr:
         LogDB:
           TIME       1765315260.20787
           VALUE      0
       durTimerSleep:
         LogDB:
           TIME       1765263966.40924
           VALUE      00:00:00
       durTimerSleep_cr:
         LogDB:
           TIME       1765263966.40924
           VALUE      0
       lastArrival:
         LogDB:
           TIME       1765372860.01255
           VALUE      -
       lastAwake:
         LogDB:
           TIME       1765372860.01255
           VALUE      -
       lastDeparture:
         LogDB:
           TIME       1765315260.20787
           VALUE      2025-12-09 22:21:00
       lastDurAbsence:
         LogDB:
           TIME       1765372860.01255
           VALUE      -
       lastDurAbsence_cr:
         LogDB:
           TIME       1765004403.83159
           VALUE      974
       lastDurPresence:
         LogDB:
           TIME       1765315260.20787
           VALUE      86:20:57
       lastDurPresence_cr:
         LogDB:
           TIME       1765315260.20787
           VALUE      5181
       lastDurSleep:
         LogDB:
           TIME       1765372860.01255
           VALUE      -
       lastDurSleep_cr:
         LogDB:
           TIME       1765263966.40924
           VALUE      470
       lastLocation:
         LogDB:
           TIME       1765372860.01255
           VALUE      -
       lastMood:
         LogDB:
           TIME       1765372860.01255
           VALUE      -
       lastSleep:
         LogDB:
           TIME       1765372860.01255
           VALUE      -
       lastState:
         LogDB:
           TIME       1765387162.81947
           VALUE      abwesend
       location:
         LogDB:
           TIME       1765372860.01255
           VALUE      -
       mood:
         LogDB:
           TIME       1765315260.20787
           VALUE      -
       presence:
         LogDB:
           TIME       1765315260.20787
           VALUE      abwesend
       state:
         LogDB:
           TIME       1765387162.81947
           VALUE      none
   READINGS:
     2025-12-11 10:55:24   durTimerAbsence 36:34:24
     2025-12-11 10:55:24   durTimerAbsence_cr 2194
     2025-12-09 22:21:00   durTimerPresence 00:00:00
     2025-12-09 22:21:00   durTimerPresence_cr 0
     2025-12-09 08:06:06   durTimerSleep   00:00:00
     2025-12-09 08:06:06   durTimerSleep_cr 0
     2025-12-10 14:21:00   lastArrival     -
     2025-12-10 14:21:00   lastAwake       -
     2025-12-09 22:21:00   lastDeparture   2025-12-09 22:21:00
     2025-12-10 14:21:00   lastDurAbsence  -
     2025-12-06 08:00:03   lastDurAbsence_cr 974
     2025-12-09 22:21:00   lastDurPresence 86:20:57
     2025-12-09 22:21:00   lastDurPresence_cr 5181
     2025-12-10 14:21:00   lastDurSleep    -
     2025-12-09 08:06:06   lastDurSleep_cr 470
     2025-12-10 14:21:00   lastLocation    -
     2025-12-10 14:21:00   lastMood        -
     2025-12-10 14:21:00   lastSleep       -
     2025-12-10 18:19:22   lastState       absent
     2025-12-10 14:21:00   location        -
     2025-12-09 22:21:00   mood            -
     2025-12-09 22:21:00   presence        absent
     2025-12-10 18:19:22   state           none
     2025-11-30 12:02:34   wayhome         0
   TIMER:
     rg_WO_Gast_DurationTimer:
       HASH       rg_WO_Gast
       MODIFIER   DurationTimer
       NAME       rg_WO_Gast_DurationTimer
Attributes:
   alias      WO_Gast
   comment    Auto-created by Bewohner
   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
   eventMap   home:zuhause absent:abwesend none:verreist gotosleep:bettfertig asleep:schläft awoken:aufgestanden
   group      Guests
   icon       scene_visit_guests
   rg_realname alias
   room       Residents
   sortby     3
   verbose    5
   webCmd     state
   widgetOverride state:zuhause,bettfertig,schläft,aufgestanden,abwesend,verreist

VG  Christian

#10

Sonstige Systeme / Aw: Neues Modul: Tado Heizungs...

Letzter Beitrag von blommaep - 11 Dezember 2025, 10:59:08

Hallo,

Was macht ihr mit Tado's neue Limit:
    Without Auto-Assist: 100 requests/day
    A small daily quota, which should still support basic use cases that are not available via tado's local APIs: HomeKit for V3/V3+ devices or Matter for tado° X devices. We have updated the documentation on how to access the REST API to reflect these changes.

    With Auto-Assist: 20.000 requests/day
    This should cover even more demanding use cases, and the subscription fees enable us to offset the increased costs associated with additional server calls.

Ihr hat Auto-Assist zahlt? Oder einfach Tado fur etwas anderes erwechseld?