Neueste Beiträge

Seiten: 1 ... 8 9 [10]
91
Hi Axel,

vielen vielen Dank erst mal vorab für die Entwicklung des HPSU-Moduls. Ich bin so ein Statistik-Monk und finde es hervorragend, dass ich durch die einfache Anleitung und dein Modul in der Lage bin, alle möglichen Werte meiner Heizung zu loggen und "zu verstehen", was die so den Tag lang macht und daran herumzuoptimieren. Ich habe eine Rotex HPSU compact 508 mit 8kW Außengerät (so ist es zumindest konfiguriert).

Da ich mein Haus größtenteils via Loxone und openHAB inkl. diverser Schnittstellen daran steuere und von FHEM wenig Ahnung habe, nutze ich das Modul derzeit nur zum Loggen der Werte (Rotex > FHEM > MQTT > openHAB > InfluxDB > Grafana, warum einfach, wenn es auch kompliziert geht ;)) und lasse die Heizung sich selbst steuern.
Ich habe die Rotex daher durchgängig im Modus Heizen laufen (also nicht Automatik oder so) und habe für WW1 einen Zeitplan hinterlegt, der jeweils morgens und abends ein 90-Minuten-Zeitfenster zur Wassererwärmung zum Duschen bestimmt.

Wenn ich außerhalb dieser Zeitfenster Warmwasser benötige (z.B. weil die Kinder baden wollen), wollte ich das nun über ForceDHW realisieren, statt an der Heizung auf den Wasserhahn zu drehen und 1x Warmwasser (mit dem Heizstab ?) bereiten zu lassen, wie ich es bisher in diesen Fällen getan habe.

Ich habe mit dem ForceDHW allerdings das Problem, dass es außerhalb der beiden WW1-Zeitfenster nicht zu funktionieren scheint. Allerdings liegt das vielleicht auch an meinem Verständnis.

Ich habe dazu schon sehnlichst die 1.14 erwartet, weil ich gehofft hatte, dass sich dadurch etwas an dem Verhalten ändert, aber nachdem ich gerade darauf aktualisiert habe, hat ein Test leider wieder nur zu einem Timeout geführt. Das Debug-Log hatte ich an (onDHW), glaube aber kaum, dass das sonderlich aufschlussreich ist.

root@loxberry:/opt/fhem/FHEM# tail -f 70_HPSU_Log.log
2021.12.05_11:36:50: HPSU 1119: ForceDHW push 69deg
2021.12.05_11:37:50: HPSU 1109: ForceDHW timeout}

Gruß Siebo

PS: Ich hänge mal exemplarisch das Grafana-Diagramm an, denn nachdem ich selber sehr viel gebastelt habe, um das wie oben beschrieben hinzubekommen, würde ich bei Interesse mal ein bisschen dazu beschreiben wollen, um dem Forum auch etwas zurückzugeben. Ist dann allerdings nicht zwingend FHEM-spezifisch, sondern eher die Kette von der Rotex als Sensor bis in die Grafana-Visualisierung.

PPS: Vielleicht noch kurz zur Erklärung: Betriebszustand "gelb" ist Abtauen, "orange" ist Heizen und "rot" ist Warmwasserbereitung. Der Temperaturabfall von ca. 10:40-11:10 bin ich beim Duschen. ForceDHW hab ich um ca. 11:35 probiert und da es nicht ging, hab ich gegen 11:50 erneut das 1x Warmwasser benutzt. Darum ist die Heizung im Diagramm halt doch am Ende in der Warmwasserbereitung, aber leider nicht wegen ForceDHW.
92
@drhirn:
Zitat
Und mit deiner Einführung von "rhasspy" hast du eine dritte Schreibweise eingeführt.
Nix da. Das war schon vorher im Wiki - aber eben nicht überall. Außerdem muss man sorgfältig zwischen dem Modul RHASSPY und der Instanz rhasspy unterscheiden.

Zitat
Der MQTT von Rhasspy läuft per default auf Port 12183. Das hat schon gepasst.
Auch nicht zielführend - denn bei Verwendung der Installations- und Startanweisung für das Docker Image auf den offiziellen Rhasspy-Seiten ist der Port 12183 nicht exposed. Damit klappt die Verbindung zwischen FHEM und Rhasspy nur über einen (Rhasspy-externen) Mosquitto. Und der läuft auf 1883.

LG

pah
93
Sonstige Systeme / Antw:[NUKI Smartlock] Neuer Thread
« Letzter Beitrag von the-vince am Heute um 11:43:33 »
;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.

Ach ja... Softwaretesting kann der zahlende Endkunde sowieso viel effizienter als die eigenen Entwickler... Entwickler sind auch so teuer. ::)
94
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?
95
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
96
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.
97
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!
98
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
99
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.
100
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
Seiten: 1 ... 8 9 [10]