Neueste Beiträge

Seiten: 1 ... 8 9 [10]
91
InterTechno / Antw:Icons schalten alle An wenn ich einen Schalter drücke
« Letzter Beitrag von locodriver am Heute um 11:30:44 »

Wie wärs als 1 device anlegen u. userV1setCodes einsetzen ?  Quasi die physische Fb :-\
Die Dosen als Dummy devices per notify's verknüpft ?
Grüße Markus

Guten Morgen, leider kann ich mit "als 1 device anlegen u. userV1setCodes" nichts anfangen. Kannst du mir am Beispiel zeigen, wie du das meinst?
Warum soll ich die Dosen nochmals als dummy anlegen, oder verstehe da etwas falsch?
92
DOIF / Antw:Erweitertes Treppenhauslicht
« Letzter Beitrag von Otto123 am Heute um 11:29:58 »
Hi,

weil dieser Ausdruck immer wahr ist -> [PIRI2:motion] ;)

Tipp: es macht mMn keinen Sinn für gleiche Ausführungsteile unterschiedliche DOIF Zweige zu schreiben! Fass alle diese Bedingungen in einem Ausdruck zusammen.

( (["PIRI2:^motion$"] and [TestHelligkeit] <= 25 and [06:00-10:00]) or ([12:00-22:00] and [TestHelligkeit] <= 25 ) or ([PIRI2:motion] eq 'on' and [TestHelligkeit] <= 25) )
Gruß Otto
93
TabletUI / Antw:FTUI version 3 image update
« Letzter Beitrag von Wolfgang Hochweller am Heute um 11:28:25 »
Das war schon mal im Mai ein Thema.
Bei mir funktioniert das weder mit noch ohne "" um das Intervall.
94
Automatisierung / Antw:[ASC] Lock out korrekt einrichten
« Letzter Beitrag von marvin78 am Heute um 11:25:47 »
Scheint zu funktionieren. Richtig testen mit allem drum und dran kann ich das frühestens morgen. Sorry.

Danke aber schone einmal für die Mühe!
95
DOIF / [GELÖST] Erweitertes Treppenhauslicht
« Letzter Beitrag von FFHEM am Heute um 11:19:45 »
Guten Tag,
ich möchte meine Flurlichtschaltung für eine Lampe verändern, aber es gelingt mir nicht ganz bis zum letzten Punkt. Da ich jetzt schon über 3 Stunden experimentiere: kann mir jemand einen Tipp geben?

Ausgangslage:
1. Ein HM-Bewegungsmelder "PIRI2". Dieser liefert "motion" und nach 60 s "noMotion"
2. 1 Tageshelligkeitsdummy Werte: 0 (dunkel) 25 (dämmrig), 50 (fast hell), 100 hell. 0 und 25 sind die dunklen Werte.
Gewünscht ist:
1.  Morgens von 06:00 Uhr bis 10:00 Uhr soll, nur, wenn der PIR Bewegung (einmal reicht aus) erkannt hat, das Licht solange anbleiben, bis 10:00 Uhr erreicht ist oder die Helligkeit > 25 ist, danach Lampe aus. Wenn keine Bewegung in der Zeit erkannt wurde, bleibt das Licht die ganze Zeit aus.
2. Von 12:00 - 22:00 soll das Licht unabhängig vom PIR angehen, sobald die Helligkeit <= 25 ist. Um 22:00 Uhr soll die Lampe aus gehen.
3. Zu allen anderen Zeiten soll das Licht bei Bewegung für 5 Minuten angehen, wenn die Helligkeit <= 25 ist.

Das Problem mit diesem DOIF ist, dass er in den "anderen Zeiten" (Punkt 3 oben, cmd_3) nicht mehr automatisch ausgeht, wenn eine Bewegung entdeckt wurde.

EDIT: Zu beachten ist, dass die TestHelligkeit sich natürlich ändern kann, also wenn da steht <= 25, kann es sein, dass sie zwischen 0 und 25 wechselt, was zu keinem Statuswechsel führen darf.

(["PIRI2:^motion$"] and [TestHelligkeit] <= 25 and [06:00-10:00])
   (set TestST2:FILTER=STATE!=on on)
DOELSEIF ([12:00-22:00] and [TestHelligkeit] <= 25 )
   (set TestST2:FILTER=STATE!=on on)
DOELSEIF ([PIRI2:motion] and [TestHelligkeit] <= 25)   
   (set TestST2:FILTER=STATE!=on on)
DOELSE
   (set TestST2:FILTER=STATE!=off off)   ### wird durch wait verzögert


Internals:
   DEF        (["PIRI2:^motion$"] and [TestHelligkeit] <= 25 and [06:00-10:00])
   (set TestST2:FILTER=STATE!=on on)
DOELSEIF ([12:00-22:00] and [TestHelligkeit] <= 25 )
   (set TestST2:FILTER=STATE!=on on)
DOELSEIF ([PIRI2:motion] and [TestHelligkeit] <= 25)   
   (set TestST2:FILTER=STATE!=on on)
DOELSE
   (set TestST2:FILTER=STATE!=off off)   ### wird durch wait verzögert

   DOIFDEV    ^global$|^TestHelligkeit$|^PIRI2$|PIRI2
   FUUID      5c444ff2-f33f-26cd-d07c-934b5ef2ccffc82c
   MODEL      FHEM
   NAME       di_Licht_Flur
   NR         1136
   NTFY_ORDER 50-di_Licht_Flur
   STATE      wait_timer
   TYPE       DOIF
   VERSION    24905 2021-09-01 18:35:54
   READINGS:
     2021-12-05 10:40:47   Device          TestHelligkeit
     2021-12-05 10:40:45   cmd             3
     2021-12-05 10:40:45   cmd_event       TestHelligkeit
     2021-12-05 10:40:45   cmd_nr          3
     2021-12-05 10:40:47   e_TestHelligkeit_STATE 0
     2021-12-05 10:40:39   mode            enabled
     2021-12-05 10:40:45   state           cmd_3
     2021-12-05 10:40:39   timer_01_c01    06.12.2021 06:00:00
     2021-12-05 10:40:39   timer_02_c01    06.12.2021 10:00:00
     2021-12-05 10:40:39   timer_03_c02    05.12.2021 12:00:00
     2021-12-05 10:40:39   timer_04_c02    05.12.2021 22:00:00
   Regex:
     accu:
     collect:
     cond:
       :
         0:
           "PIRI2:^motion$" PIRI2:^motion$
       PIRI2:
         2:
           motion     ^PIRI2$:^motion:
       TestHelligkeit:
         0:
           &STATE     ^TestHelligkeit$
         1:
           &STATE     ^TestHelligkeit$
         2:
           &STATE     ^TestHelligkeit$
   attr:
     cmdState:
       0:
         ein
       1:
          aus
     wait:
       0:
         0
       1:
         0
       2:
         0
       3:
         60
     waitdel:
   condition:
     0          ::EventDoIf('PIRI2',$hash,'^motion$',0) and ::InternalDoIf($hash,'TestHelligkeit','STATE') <= 25 and ::DOIF_time($hash,0,1,$wday,$hms)
     1          ::DOIF_time($hash,2,3,$wday,$hms) and ::InternalDoIf($hash,'TestHelligkeit','STATE') <= 25
     2          ::ReadingValDoIf($hash,'PIRI2','motion') and ::InternalDoIf($hash,'TestHelligkeit','STATE') <= 25
   days:
   do:
     0:
       0          set TestST2:FILTER=STATE!=on on
     1:
       0          set TestST2:FILTER=STATE!=on on
     2:
       0          set TestST2:FILTER=STATE!=on on
     3:
       0          set TestST2:FILTER=STATE!=off off
   helper:
     DEVFILTER  ^global$|^TestHelligkeit$|^PIRI2$|PIRI2
     NOTIFYDEV  global|TestHelligkeit|PIRI2|.*PIRI2.*
     event      0
     globalinit 1
     last_timer 4
     sleeptimer -1
     timerdev   TestHelligkeit
     timerevent 0
     triggerDev TestHelligkeit
     timerevents:
       0
     timereventsState:
       state: 0
     triggerEvents:
       0
     triggerEventsState:
       state: 0
   internals:
     all         TestHelligkeit:STATE
   interval:
     0          -1
     1          0
     2          -1
     3          2
   intervalfunc:
   localtime:
     0          1638766800
     1          1638781200
     2          1638702000
     3          1638738000
   readings:
     all         PIRI2:motion
   realtime:
     0          06:00:00
     1          10:00:00
     2          12:00:00
     3          22:00:00
   time:
     0          06:00:00
     1          10:00:00
     2          12:00:00
     3          22:00:00
   timeCond:
     0          0
     1          0
     2          1
     3          1
   timer:
     0          0
     1          0
     2          0
     3          0
   timers:
     0           0  1
     1           2  3
   trigger:
   triggertime:
     1638702000:
       localtime  1638702000
       hash:
     1638738000:
       localtime  1638738000
       hash:
     1638766800:
       localtime  1638766800
       hash:
     1638781200:
       localtime  1638781200
       hash:
   uiState:
   uiTable:
Attributes:
   cmdState   ein | aus
   room       DOIF,Test
   stateFormat wait_timer
   wait       0:0:0:60

Testhelligkeit (Dummy):
Internals:
   FUUID      61ab2045-f33f-26cd-7707-c438f5656f4a4a84
   NAME       TestHelligkeit
   NR         1324
   STATE      0
   TYPE       dummy
   READINGS:
     2021-12-05 10:40:47   state           0
Attributes:
   room       Test
   setList    state:0,25,50,100
   webCmd     state
96
Sonstige Systeme / Antw:[NUKI Smartlock] Neuer Thread
« Letzter Beitrag von CoolTux am Heute um 11:19:16 »
Moin CoolTux,

ich habe nach eine update all und einem restart jetzt ein Bug gefunden. Denke ich.
Das Smartlock3pro erhält jetzt immer im Wechsel das korrekte Reading (smartlock3) und dann das alte Reading (smartlock), inklusive falscher Name als Reading.
Der log sieht ein bisschen so aus als wäre ständig das auto discovery am werk.
Entsprechend lassen sich keine Befehle mehr ausführen. Ein Verbose 5 liefert einen Haufen:
2021.12.05 10:37:07 5: NUKIBridge (NukiBridge) - 2 == 2 and 2 > 0sowie:
2021.12.05 10:37:07 5: NUKIBridge (NukiBridge) - return msg: {"deviceType": 4, "nukiId": XXX, "name": "Home", "firmwareVersion": "3.0.40", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 62, "timestamp": "2021-12-05T08:40:45+00:00"}} and tail: ]
2021.12.05 10:37:07 5: NUKIBridge (NukiBridge) - Nach Sub: Laenge JSON: 272 Content: {"deviceType": 4, "nukiId": XXX, "name": "Home", "firmwareVersion": "3.0.40", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 62, "timestamp": "2021-12-05T08:40:45+00:00"}} Tail: ]
2021.12.05 10:37:07 5: NUKIBridge (NukiBridge) - Decoding JSON message. Length: 272 Content: {"deviceType": 4, "nukiId": xxx, "name": "Home", "firmwareVersion": "3.0.40", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 62, "timestamp": "2021-12-05T08:40:45+00:00"}}
2021.12.05 10:37:07 5: NUKIBridge (NukiBridge) - Vor Sub: Laenge JSON: 272 Content: {"deviceType": 4, "nukiId": xxx, "name": "Home", "firmwareVersion": "3.0.40", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 62, "timestamp": "2021-12-05T08:40:45+00:00"}} Tail: ]
2021.12.05 10:37:07 5: NukiBridge: dispatch {"deviceType": 4, "nukiId": xxx, "name": "Home", "firmwareVersion": "3.0.40", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 62, "timestamp": "2021-12-05T08:40:45+00:00"}}
2021.12.05 10:37:07 5: NUKIDevice (NukiBridge) - Parse with result: {"deviceType": 4, "nukiId": xxx, "name": "Home", "firmwareVersion": "3.0.40", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 62, "timestamp": "2021-12-05T08:40:45+00:00"}}
2021.12.05 10:37:07 5: NUKIDevice (Home) - lockAction readings set for Home
2021.12.05 10:37:07 4: NUKIDevice (Home) - find logical device: Home
und dann diese Log Einträge:
2021.12.05 10:36:37 5: NUKIBridge (NukiBridge) - return msg: {"deviceType": 0, "nukiId": xxx, "name": "Nuki_xxx", "rssi": -43, "paired": false} and tail: , {"deviceType": 2, "nukiId": xxx, "name": "Nuki_Opener_xxx", "rssi": -46, "paired": true}]}
2021.12.05 10:36:37 5: NUKIBridge (NukiBridge) - Decoding JSON message. Length: 93 Content: {"deviceType": 0, "nukiId": xxx, "name": "Nuki_xxx", "rssi": -43, "paired": false}
2021.12.05 10:36:37 5: NUKIBridge (NukiBridge) - Vor Sub: Laenge JSON: 93 Content: {"deviceType": 0, "nukiId": xxx, "name": "Nuki_xxx", "rssi": -43, "paired": false} Tail: , {"deviceType": 2, "nukiId": xxx, "name": "Nuki_Opener_xxx", "rssi": -46, "paired": true}]}
2021.12.05 10:36:37 5: NukiBridge: dispatch {"deviceType": 0, "nukiId": xxx, "name": "Nuki_xxx", "rssi": -43, "paired": false}
2021.12.05 10:36:37 5: NUKIDevice (NukiBridge) - Parse with result: {"deviceType": 0, "nukiId": xxx, "name": "Nuki_xxx", "rssi": -43, "paired": false}
2021.12.05 10:36:37 5: NUKIDevice (Home) - lockAction readings set for Home
2021.12.05 10:36:37 4: NUKIDevice (Home) - find logical device: Home
2021.12.05 10:36:37 5: NUKIBridge (NukiBridge) - Garbage character before message: ,
2021.12.05 10:36:37 5: NUKIBridge (NukiBridge) - Garbage character before message: 

Sieht also ein bisschen so aus als würde die Bridge ein zweites Gerät mit selber ID bekanntgeben?! Ich weiß mir da aber nicht so richtig zu helfen.

 ;D ;D
Du hast da ein Bug gefunden und der ist auch schon gemeldet worden. Allerdings ist das kein Bug im Modul sondern leider in der API der Nuki Bridge.
Es gibt unterschiedliche Ausgaben für die Endpunkte /list und /info bei den Smartlock 3.0 und 3.0 Pro Geräten.
97
MQTT / Antw:IP Adresse von MQTT Gerät ermitteln + dyn. setList widgets
« Letzter Beitrag von TomLee am Heute um 11:17:45 »
Sry, meine Nichten sind mir gestern dazwischengegrätscht, dann gibts nur die, da könnte FHEM auch "crashen", dann wär das in der Zeit halt so.
Und später am Abend hatte ich die aktualisierte fhemweb.js mit Filezilla hochgeladen und nicht verstanden warum diese (auch nach mehrfachem restart) nicht geladen wurde, mit der version-Abfrage stand in der Liste immer die alte Version, "ls -l ./www/pgm2/" gab mir aber die neue aus und hatte keine Lust mehr dann mich mit zu beschäftigen.

Mit dem update Heute klappt es auch in der DeviceOverview (wollt ich eigentlich die letzten zwei-drei Beiträge erwähnen das es um die geht, aber immer wieder vergessen).

Was mir jetzt auffällt ist das der erste Wert in der Liste (favRadios) als "default" genommen wird sollten setter und Reading nicht gleich sein, in dem Fall fänd ich es besser das dann kein Wert im Widget steht.

Danke
98
KNX/EIB / Antw:Beta-Test neues KNX-IO Modul
« Letzter Beitrag von Amenophis86 am Heute um 11:16:15 »
Ich wollte heute auch mal einen Test starten aber scheitere am einrichten. Ich habe das Modul über update hinzugefügt und entsprechend definiert. Das alte Device habe ich gelöscht. Aber wie erkennt FHEM nun, dass es ein neues IO Device setzen muss?

EDIT:
Ah, der Name muss wohl gleich sein. Jetzt klappt es.

Werde jetzt mal den S Mode testen.

Edit2:
Folgendes ist mir aufgefallen. Ich nutze den S-Mode, habe auf einem PI KNXD laufen und auf dem PI zwei FHEM Instanzen. Nun definiere ich KNXIO auf FHEM1 und es verbindet sich. Definiere ich KNXIO auf FHEM2, wird FHEM1 disconnected. Mit defmod bei FHEM1 kann ich die Verbindung wieder herstellen und beide sind verbunden. Startet allerdings eine der FHEM Instanzen neu und verbindet sich damit mit KNXD neu, wird die Verbindung de anderen unterbrochen und muss mittels defmod neu hergestellt werden. Lässt sich soweit reproduzieren.
99
Sonstiges / Antw:configDB und holiday-Dateien
« Letzter Beitrag von betateilchen am Heute um 11:06:34 »
Bitte klär mich auf. Was wäre denn dafür gedacht?

 :o Das habe ich doch schon geschrieben?

ics-Dateien ... Die könnte man einfach mit dem Calendar-Modul verarbeiten.

Gib mal "help calendar" in die Befehlszeile ein.
100
Hallo,

Ich würde mich für den Funk-Tasterschnittstelle 4fach, HM-PBI-4-FM, interessieren.
Schicke Dir PM.

Lg, Gerhard
Seiten: 1 ... 8 9 [10]