Hallo,
ich habe mich gewagt und letzes Wochenende ein update von FHEM und Raspberry gemacht. Das letzte Update war schon länger her.
Mir ist jetzt erst aufgefallen, dass ein DOIF nicht mehr richtig funktioniert.
Das DOIF habe ich für eine Kellerlüftung und soll ausgeführt werden, bestimmte Bedingungen vorliegen (Taupunktlüftung)
Wenn die Bedingungen zutreffen wird eine Lüfterklappe (HUEDevice19) erst geöffnet und wenn die geöffnet ist ein Lüfter (HUEDevice9) eingeschaltet. Der Lüfter läuft eine vorgegbene Zeit, schaltet aus und die Lüfterklappe (HUEDevice7) schließt wieder. Zwischen ein- und ausschalten des Lüfter wird ein paar Sekunden gewartet, damit die Lüfterklappen sich ganz öffnen können.
Das hat bisher funktioniert.
Jetzt ist es so, dass die Lüfterklappe öffnet, der Lüfter schaltet sich ein aber schaltet sich nach ein paar Sekunden wieder aus. Ich finde nichts, wo ich so eine kurze Lüfterzeit vorgegeben habe.
Diesen Vorgang kann ich auch manuell über ein Dummy (nicht über die o.g. Bedingungen) starten. Hier passiert das selbe.
Der Lüfter schaltet nach ein paar Sekunden aus (ca. 10 Sekunden).
Kann es sein, dass es mit dem Update zusammenhängt?
Vorher hat es funktoniert (zumindest ist mir nichts aufgefallen).
Vielen Dank
Grüße Ruggy
Hier das List vom Dummy zum Ein- und Ausschalten:
[code]Internals:
FUUID 61d08d74-f33f-f59f-6793-e39ba557dc2a8f98
NAME Kellerluefter_mit_Klappen
NR 145
STATE off
TYPE dummy
eventCount 2
Helper:
DBLOG:
state:
DbLog:
TIME 1663971133.1168
VALUE off
READINGS:
2022-09-24 00:12:13 state off
Attributes:
devStateIcon off:Ventilator_fett on:vent_ventilation_level_3@red
room Kellerlüftung
webCmd on:off
Hier das List fürs einschalten:
Internals:
DEF ([Kellerluefter_mit_Klappen:"on"]) (set HUEDevice18 on-for-timer 17) (set HUEDevice9 on)
FUUID 61d09273-f33f-f59f-ede6-1d0804cc7e2c5a3f
MODEL FHEM
NAME KELLERLUEFTER_MIT_KLAPPEN_EINSCHALTEN_doif
NOTIFYDEV Kellerluefter_mit_Klappen,global
NR 146
NTFY_ORDER 50-KELLERLUEFTER_MIT_KLAPPEN_EINSCHALTEN_doif
STATE cmd_2
TYPE DOIF
VERSION 26435 2022-09-20 20:49:19
eventCount 5
Helper:
DBLOG:
state:
DbLog:
TIME 1663971133.38226
VALUE cmd_2
READINGS:
2022-09-24 00:12:13 Device Kellerluefter_mit_Klappen
2022-09-24 00:12:13 cmd 2
2022-09-24 00:12:13 cmd_event Kellerluefter_mit_Klappen
2022-09-24 00:12:13 cmd_nr 2
2022-09-24 00:12:13 e_Kellerluefter_mit_Klappen_events off
2022-01-01 18:56:58 mode enabled
2022-09-24 00:12:13 state cmd_2
2022-09-24 00:11:51 wait_timer no timer
Regex:
accu:
collect:
cond:
Kellerluefter_mit_Klappen:
0:
&STATE ^Kellerluefter_mit_Klappen$
attr:
cmdState:
wait:
0:
0
20
waitdel:
condition:
0 ::EventDoIf('Kellerluefter_mit_Klappen',$hash,'on',1)
do:
0:
0 set HUEDevice18 on-for-timer 17
1 set HUEDevice9 on
1:
helper:
NOTIFYDEV Kellerluefter_mit_Klappen,global
event off
globalinit 1
last_timer 0
sleepdevice Kellerluefter_mit_Klappen
sleepsubtimer -1
sleeptimer -1
timerdev Kellerluefter_mit_Klappen
timerevent off
triggerDev Kellerluefter_mit_Klappen
DOIF_eventa:
cmd_nr: 2
cmd: 2
cmd_event: Kellerluefter_mit_Klappen
cmd_2
DOIF_eventas:
cmd_nr: 2
cmd: 2
cmd_event: Kellerluefter_mit_Klappen
state: cmd_2
timerevents:
off
timereventsState:
state: off
triggerEvents:
off
triggerEventsState:
state: off
internals:
perlblock:
readings:
trigger:
all Kellerluefter_mit_Klappen
uiState:
uiTable:
Attributes:
room Kellerlüftung
wait 0,20
Hier das List fürs Ausschalten:
Internals:
DEF ([Kellerluefter_mit_Klappen:"off"]) (set HUEDevice9 off) (set HUEDevice7 on-for-timer 17)
FUUID 61d096e2-f33f-f59f-af16-3c5efb8da9916e28
MODEL FHEM
NAME KELLERLUEFTER_MIT_KLAPPEN_AUSSCHALTEN_doif
NOTIFYDEV Kellerluefter_mit_Klappen,global
NR 147
NTFY_ORDER 50-KELLERLUEFTER_MIT_KLAPPEN_AUSSCHALTEN_doif
STATE cmd_1
TYPE DOIF
VERSION 26435 2022-09-20 20:49:19
eventCount 5
Helper:
DBLOG:
state:
DbLog:
TIME 1663971153.38645
VALUE cmd_1
READINGS:
2022-09-24 00:12:13 Device Kellerluefter_mit_Klappen
2022-09-24 00:12:33 cmd 1.2
2022-09-24 00:12:33 cmd_event Kellerluefter_mit_Klappen
2022-09-24 00:12:33 cmd_nr 1
2022-09-24 00:12:33 cmd_seqnr 2
2022-09-24 00:12:13 e_Kellerluefter_mit_Klappen_events off
2022-01-01 19:06:27 mode enabled
2022-09-24 00:12:33 state cmd_1
2022-09-24 00:12:33 wait_timer no timer
Regex:
accu:
collect:
cond:
Kellerluefter_mit_Klappen:
0:
&STATE ^Kellerluefter_mit_Klappen$
attr:
cmdState:
wait:
0:
0
20
waitdel:
condition:
0 ::EventDoIf('Kellerluefter_mit_Klappen',$hash,'off',1)
do:
0:
0 set HUEDevice9 off
1 set HUEDevice7 on-for-timer 17
1:
helper:
NOTIFYDEV Kellerluefter_mit_Klappen,global
event off
globalinit 1
last_timer 0
sleepdevice Kellerluefter_mit_Klappen
sleepsubtimer -1
sleeptimer -1
timerdev Kellerluefter_mit_Klappen
timerevent off
triggerDev Kellerluefter_mit_Klappen
DOIF_eventa:
cmd_nr: 1
cmd_seqnr: 2
cmd_event: Kellerluefter_mit_Klappen
cmd_1
DOIF_eventas:
cmd_nr: 1
cmd_seqnr: 2
cmd_event: Kellerluefter_mit_Klappen
state: cmd_1
timerevents:
off
timereventsState:
state: off
triggerEvents:
off
triggerEventsState:
state: off
internals:
perlblock:
readings:
trigger:
all Kellerluefter_mit_Klappen
uiState:
uiTable:
Attributes:
room Kellerlüftung
wait 0,20
Hier das List vom Device Lüfter (ist eine schaltbare Steckdose):
Internals:
DEF 9 IODev=deCONZ
FUUID 5f1bd2bf-f33f-f59f-7701-05ebb3629e9342e1
FVERSION 31_HUEDevice.pm:0.262040/2022-07-09
ID 9
INTERVAL
IODev deCONZ
NAME HUEDevice9
NR 44
STATE off
TYPE HUEDevice
desired 0
eventCount 16
has_events 1
manufacturername OSRAM
modelid Plug 01
name Keller_Steckdose_Luefter
swversion V1.04.90
type On/Off plug-in unit
uniqueid 7c:b0:3e:aa:0a:07:10:dd-03
Helper:
DBLOG:
state:
DbLog:
TIME 1663999740.23855
VALUE off
READINGS:
2022-09-24 00:09:58 IODev deCONZ
2022-09-24 00:10:00 alert none
2022-09-17 23:42:59 dynamics_status none
2022-09-24 08:48:01 lastseen 2022-09-24T06:47Z
2022-09-24 08:09:00 onoff 0
2022-09-24 08:09:00 pct 0
2022-09-24 08:48:01 reachable 1
2022-09-24 08:09:00 state off
2022-09-17 23:42:59 v2effect no_effect
helper:
alert none
battery -1
bri -1
colormode
ct -1
devtype
dynamics_status
effect
hue -1
lastseen
mode
on 0
pct 0
reachable 1
rgb
sat -1
update_timeout -1
v2effect
xy
json:
etag 4845b7ac0cb3744a9e4da15975e7af4c
lastannounced
lastseen 2022-09-24T06:47Z
manufacturername OSRAM
modelid Plug 01
name Keller_Steckdose_Luefter
swversion V1.04.90
type On/Off plug-in unit
uniqueid 7c:b0:3e:aa:0a:07:10:dd-03
state:
alert none
Attributes:
IODev deCONZ
alias Luefter_Steckdose_ACHTUNG_ohne_Rohrklappe
color-icons 2
devStateIcon off:Ventilator_fett on:vent_ventilation_level_3@red
event-on-change-reading state
model Plug 01
room HUEDevice,Keller
subType switch
webCmd toggle:on:off
Hier das List zum Lüfterklappe öffnen (ist ein Xiaomi zweifach Relais):
Internals:
DEF 18 IODev=deCONZ
FUUID 6054ea6f-f33f-f59f-eba5-fa5809c0fbbf37e7
FVERSION 31_HUEDevice.pm:0.262040/2022-07-09
ID 18
INTERVAL
IODev deCONZ
NAME HUEDevice18
NR 101
STATE off
TYPE HUEDevice
desired 0
eventCount 27
has_events 1
manufacturername Unknown
modelid lumi.relay.c2acn01
name Lüftungsrohr_Zu
swversion 02-27-2019
type Dimmable light
uniqueid 00:15:8d:00:04:28:b3:c5-02
Helper:
DBLOG:
state:
DbLog:
TIME 1663999718.28445
VALUE off
READINGS:
2022-09-24 00:09:58 IODev deCONZ
2022-09-24 00:10:00 alert none
2022-09-17 23:42:59 dynamics_status none
2022-09-24 08:48:59 lastseen 2022-09-24T06:47Z
2022-09-24 08:08:38 onoff 0
2022-09-24 08:08:38 pct 0
2022-09-24 08:08:22 reachable 1
2022-09-24 08:08:38 state off
2022-09-17 23:42:59 v2effect no_effect
helper:
alert none
battery -1
bri -1
colormode
ct -1
devtype
dynamics_status
effect
hue -1
lastseen
mode
on 0
pct 0
reachable 1
rgb
sat -1
update_timeout 1
v2effect
xy
json:
e changed
id 18
r lights
source event
t event
uniqueid 00:15:8d:00:04:28:b3:c5-02
attr:
id 18
lastannounced
lastseen 2022-09-24T06:49Z
manufacturername Unknown
modelid lumi.relay.c2acn01
name Lüftungsrohr_Zu
swversion 02-27-2019
type Dimmable light
uniqueid 00:15:8d:00:04:28:b3:c5-02
Attributes:
IODev deCONZ
alias Lüftungsrohr öffnen
color-icons 2
devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
event-on-change-reading state
group HUEDevice
model lumi.relay.c2acn01
room HUEDevice,Keller,Kellerlüftung
subType dimmer
webCmd pct:toggle:on:off
Hier das List zum Lüfterklappe schließen (ist ein Xiaomi zweifach Relais):
Internals:
DEF 7 IODev=deCONZ
FUUID 6054ea6e-f33f-f59f-098a-2c18147ac015eec8
FVERSION 31_HUEDevice.pm:0.262040/2022-07-09
ID 7
INTERVAL
IODev deCONZ
NAME HUEDevice7
NR 100
STATE off
TYPE HUEDevice
desired 0
eventCount 16
has_events 1
manufacturername LUMI
modelid lumi.relay.c2acn01
name Lüftungsrohr_Auf
swversion 02-27-2019
type Dimmable light
uniqueid 00:15:8d:00:04:28:b3:c5-01
Helper:
DBLOG:
state:
DbLog:
TIME 1663996718.25613
VALUE off
READINGS:
2022-09-24 00:09:58 IODev deCONZ
2022-09-24 00:10:00 alert none
2022-09-17 23:42:59 dynamics_status none
2022-09-24 08:49:59 lastseen 2022-09-24T06:49Z
2022-09-24 07:18:38 onoff 0
2022-09-24 07:18:38 pct 0
2022-09-24 00:10:00 reachable 1
2022-09-24 07:18:38 state off
2022-09-17 23:42:59 v2effect no_effect
helper:
alert none
battery -1
bri -1
colormode
ct -1
devtype
dynamics_status
effect
hue -1
lastseen
mode
on 0
pct 0
reachable 1
rgb
sat -1
update_timeout 1
v2effect
xy
json:
etag 083b1779f5d9c8da4ce777bbcfe4977d
lastannounced
lastseen 2022-09-24T06:49Z
manufacturername LUMI
modelid lumi.relay.c2acn01
name Lüftungsrohr_Auf
swversion 02-27-2019
type Dimmable light
uniqueid 00:15:8d:00:04:28:b3:c5-01
state:
alert none
Attributes:
IODev deCONZ
alias Lüftungsrohr schließen
color-icons 2
devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
event-on-change-reading state
group HUEDevice
model lumi.relay.c2acn01
room HUEDevice,Keller,Kellerlüftung
subType dimmer
webCmd pct:toggle:on:off
An den Listings kann ich kein Fehlverhalten der beiden DOIF-Definitionen erkennen.
set HUEDevice18 on-for-timer 17
schaltete ja ebenfalls aus.
Ich kann mir es ja auch nicht erklären, warum der Lüfter (HUEDevice9) nach ein paar Sekunden wieder ausschaltet. Dieser sollte ja eigentlich auf "on" bleiben.
Das HUEDevice18 schaltet richtigerweise aus.
An was könnte es noch liegen?
Es kann sein, dass die schaltbare Steckdose (Osram Smart+) einen Defekt hat.
Diese schaltet nach ein paar Sekunden aus, auch wenn ich sie mit dem Tastschalter einschalte.
Dies schaue ich mir abends oder morgen nochmal an.
Leider gibt es immer noch das "Phänomen", dass sich die Steckdose Osram Smart + nach ca. 30 Sekunden automatisch wieder ausschaltet.
Ich habe es mit einer andern Smart+ versucht, da war es das selbe.
Wenn ich direkt im Device (HUEDevice9) die Smart+ einschalte bleibt sie eingeschalten.
Wenn ich sie jedoch über den Dummy (mit einen DOIF für Einschalten und einen DOIF für Ausschalten) einschalte, schaltet sie sich ca. 8 Sekunden aus, nachdem das DOIF für Einschalten abgearbeitet wurde.
Folgende Devices habe ich:
HUEDevice9 = Smart+ (Steckdose mit Lüfter; derzeit habe ich zum Testen den Lüfter nicht angesteckt)
HUEDevice18 = Relaist für Lüfterklappe öffnen (Xiaomi Doppelrelais)
HUEDevice7 = Relais für Lüfterklappe schließen (Xiaomi Doppelrelais)
So ist der Ablauf:
Ich klicke beim Dummy auf "on"
-> Relais für Lüfterklappe schaltet sofort ein (HUEDevice18)
-> nach 17 Sekunden Relais für Lüfterklappe schaltet aus (HUEDevice18)
-> nach ca. 2 Sekunden Lüfter (HUEDevice9) schaltet ein.
---soweit würde es passen
...aber nach ein paar Sekunden (Dauer ist unterschiedlich; einmal nach 8, dann nach 16, dann nach 40 Sekunden) schaltet sich die Smart+ (HUEDevice9) von selber aus.
An was kann das liegen?
Zitat von: Ruggy am 25 September 2022, 11:31:26
Leider gibt es immer noch das "Phänomen", dass sich die Steckdose Osram Smart + nach ca. 30 Sekunden automatisch wieder ausschaltet.
Ich habe es mit einer andern Smart+ versucht, da war es das selbe.
Wenn ich direkt im Device (HUEDevice9) die Smart+ einschalte bleibt sie eingeschalten.
Wenn ich sie jedoch über den Dummy (mit einen DOIF für Einschalten und einen DOIF für Ausschalten) einschalte, schaltet sie sich ca. 8 Sekunden aus, nachdem das DOIF für Einschalten abgearbeitet wurde.
Folgende Devices habe ich:
HUEDevice9 = Smart+ (Steckdose mit Lüfter; derzeit habe ich zum Testen den Lüfter nicht angesteckt)
HUEDevice18 = Relaist für Lüfterklappe öffnen (Xiaomi Doppelrelais)
HUEDevice7 = Relais für Lüfterklappe schließen (Xiaomi Doppelrelais)
So ist der Ablauf:
Ich klicke beim Dummy auf "on"
-> Relais für Lüfterklappe schaltet sofort ein (HUEDevice18)
-> nach 17 Sekunden Relais für Lüfterklappe schaltet aus (HUEDevice18)
-> nach ca. 2 Sekunden Lüfter (HUEDevice9) schaltet ein.
---soweit würde es passen
...aber nach ein paar Sekunden (Dauer ist unterschiedlich; einmal nach 8, dann nach 16, dann nach 40 Sekunden) schaltet sich die Smart+ (HUEDevice9) von selber aus.
An was kann das liegen?
Dann musst du im Log schauen, ob ein set-off-Befehl erfolgt.
Du kannst mal testen, was passiert, wenn man zeitversetzt mehrere set HUEDevice18 on-for-timer 17 Befehle absetzt. Wird die Zeit verlängert oder ergeben sich damit bereits mehrere Ausschaltbefehle jeweils nach 17 Sekunden.
Sollte ich die Logs nicht in der Datei finden, welche unter global festgelegt wurde mit
./log/fhem-%Y-%m.log
?
Also folgende
fhem-2022-09.log
?
In dieser werden die Befehle aber nicht aufgeführt. Auch nicht die zum Einschalten usw.
Oder finde ich die in einem anderen Log?
Hi Ruggy
ich würde in der Gerätelog suchen
und am zum beobachtenden gerät "attr verbose 5 " eingeben
vg tagedieb
Habe das verbose bei den drei Geräten gesetzt (Steckdose und Relais).
Wo kann ich die Logs einsehen?
Habe mit PUTTy in /opt/fhem/log nachgesehen. Dort befinend sich die Logs zu den Geräten nicht.
Mir ist noch aufgefallen, dass im global ein Fehler im Zusammenhang mit deCONZ steht.
List von global:
Internals:
DEF no definition
FD 3
NAME global
NR 1
STATE no definition
TYPE Global
currentlogfile ./log/fhem-2022-09.log
eventCount 33
init_errors Messages collected while initializing FHEM:configfile: deCONZ: unknown attribute model. Type 'attr deCONZ ?' for a detailed list.
deCONZ: unknown attribute subType. Type 'attr deCONZ ?' for a detailed list.
Autosave deactivated
logfile ./log/fhem-%Y-%m.log
Attributes:
autoload_undefined_devices 1
autosave 0
configfile fhem.cfg
logfile ./log/fhem-%Y-%m.log
modpath .
motd 1
statefile ./log/fhem.save
userattr DbLogExclude DbLogInclude DbLogValueFn:textField-long cmdIcon devStateIcon devStateIcon:textField-long devStateStyle icon sortby webCmd webCmdLabel:textField-long widgetOverride
verbose 3
version fhem.pl:26379/2022-09-03
Habe wie geschriben, letzten Samstag, ein Update vom Raspberry und FHEM durchgeführt (habe schon länger keins mehr gemacht).
Seit dem funtkoniert es nicht mehr richtig.
Habe heute noch versucht die Firmware der Phoscon App (von deCONZ) upzudaten. Danach konnte ich nicht mehr auf die Phoscon App zugreifen.
Habe dann wieder auf die alte (von 2021) downgegradet und ich konnte wieder darauf zugreifen.
Habe dann noch etwas gefunden, dass die Phoscon App anscheinen u.a. nicht mehr mit Jessi zusammen arbeitet (die habe ich auf meinen Raspberry).
Deshalb wir wahrscheinlich das Firmwareupdate nicht mehr funktionieren?
https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Update-deCONZ-manually
Wie es aussieht ist wahrscheinlich etwas beim Update schief gegagnen.
Dies habe ich wie geschrieben vor einer Woche (18.09.) durchgeführt.
Dabei habe ich nicht nur Probleme mit der Steuerung bzlg. der Lüftung sondern mehr.
In der Logfile sind seit dem hunderte Einträge wie nachfolgend. Diese wiederholen sich immer wieder
2022.09.18 22:21:52 4: parse status message for AUS_LUFTFEUCHTIGKEIT
2022.09.18 22:21:52 5: AUS_LUFTFEUCHTIGKEIT: using offsetUTC 7200 from bridge
2022.09.18 22:21:52 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading reachable with timestamp 2022-09-18 21:40:34, current reading timestamp is 2022-09-18 21:40:34
2022.09.18 22:21:52 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading batteryPercent with timestamp 2022-09-18 21:40:34, current reading timestamp is 2022-09-18 21:40:34
2022.09.18 22:21:52 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading lastseen with timestamp 2022-09-18 21:40:34, current reading timestamp is 2022-09-18 21:40:34
2022.09.18 22:21:52 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading battery with timestamp 2022-09-18 21:40:34, current reading timestamp is 2022-09-18 21:40:34
2022.09.18 22:21:52 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading humidity with timestamp 2022-09-18 21:40:34, current reading timestamp is 2022-09-18 21:40:34
2022.09.18 22:21:52 4: parse status message for KEL_LUFTFEUCHTIGKEIT
2022.09.18 22:21:52 5: KEL_LUFTFEUCHTIGKEIT: using offsetUTC 7200 from bridge
2022.09.18 22:21:52 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading reachable with timestamp 2022-09-18 22:11:32, current reading timestamp is 2022-09-18 22:11:32
2022.09.18 22:21:52 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading batteryPercent with timestamp 2022-09-18 22:11:32, current reading timestamp is 2022-09-18 22:11:32
2022.09.18 22:21:52 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading lastseen with timestamp 2022-09-18 22:11:32, current reading timestamp is 2022-09-18 22:11:32
2022.09.18 22:21:52 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading humidity with timestamp 2022-09-18 22:11:32, current reading timestamp is 2022-09-18 22:11:32
2022.09.18 22:21:52 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading battery with timestamp 2022-09-18 22:11:32, current reading timestamp is 2022-09-18 22:11:32
Hier das Logfile ab den Update am 18.09.
2022.09.18 10:20:22 1: update finished, "shutdown restart" is needed to activate the changes.
2022.09.18 10:20:22 1:
2022.09.18 10:20:22 1: Please consider using the global attribute sendStatistics
2022.09.18 10:21:26 2: DbLog DbLog - Last database write cycle due to shutdown ...
2022.09.18 10:21:26 2: DbLog DbLog - no data for last database write cycle
2022.09.18 10:21:26 1: Server shutdown delayed due to DbLog for max 10 sec
2022.09.18 10:21:36 0: Server shutdown
2022.09.18 10:21:38 1: Including fhem.cfg
2022.09.18 10:21:38 1: PERL WARNING: Subroutine myUtils_Initialize redefined at ./FHEM/99_MyUtils.pm line 15, <$fh> line 5.
2022.09.18 10:21:38 1: PERL WARNING: Subroutine winOpenStart redefined at ./FHEM/99_MyUtils.pm line 25, <$fh> line 5.
2022.09.18 10:21:38 1: PERL WARNING: Subroutine PushInfo redefined at ./FHEM/99_MyUtils.pm line 112, <$fh> line 5.
2022.09.18 10:21:38 1: PERL WARNING: Subroutine winOpenStop redefined at ./FHEM/99_MyUtils.pm line 118, <$fh> line 5.
2022.09.18 10:21:38 3: WEB: port 8083 opened
2022.09.18 10:21:39 2: eventTypes: loaded 2503 lines from ./log/eventTypes.txt
2022.09.18 10:21:43 3: HUEGroup0: I/O device is deCONZ
2022.09.18 10:21:43 3: SCH_EG_TEMPERATUR: I/O device is deCONZ
2022.09.18 10:21:43 3: SCH_EG_LUFTFEUCHTIGKEIT: I/O device is deCONZ
2022.09.18 10:21:43 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet/:
2022.09.18 10:21:43 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2022.09.18 10:21:43 3: HUEGroup1: I/O device is deCONZ
2022.09.18 10:21:43 1: dewpoint dewpointToAllDeviceReadings: attribute 'absFeuchte' is deprecated, please use 'absoluteHumidity'
2022.09.18 10:21:43 3: GARAGE_STECKDOSE: I/O device is deCONZ
2022.09.18 10:21:43 3: SCHEUNE_TUER: I/O device is deCONZ
2022.09.18 10:21:44 3: GARTENHAUS_TUER: I/O device is deCONZ
2022.09.18 10:21:45 3: KEL_TEMPERATUR: I/O device is deCONZ
2022.09.18 10:21:45 3: KEL_LUFTFEUCHTIGKEIT: I/O device is deCONZ
2022.09.18 10:21:45 3: HUEDevice9: I/O device is deCONZ
2022.09.18 10:21:45 3: HUEGroup2: I/O device is deCONZ
2022.09.18 10:21:45 3: HUEDevice1: I/O device is deCONZ
2022.09.18 10:21:45 3: STODL_TUER: I/O device is deCONZ
2022.09.18 10:21:45 3: GARAGENTOR: I/O device is deCONZ
2022.09.18 10:21:45 3: GARTENTUERE_CZ: I/O device is deCONZ
2022.09.18 10:21:45 3: HUEDevice4: I/O device is deCONZ
2022.09.18 10:21:45 3: HUEGroup30676: I/O device is deCONZ
2022.09.18 10:21:45 3: HUEDevice6: I/O device is deCONZ
2022.09.18 10:21:45 3: HUEDevice3: I/O device is deCONZ
2022.09.18 10:21:46 3: WASSERMELDER_WASCHMASCHINE: I/O device is deCONZ
2022.09.18 10:21:46 3: SAFE_BOX_LUFTFEUCHTIGKEIT: I/O device is deCONZ
2022.09.18 10:21:46 3: SAFE_BOX_TEMPERATUR: I/O device is deCONZ
2022.09.18 10:21:46 3: HUEDevice10: I/O device is deCONZ
2022.09.18 10:21:46 3: WASSERMELDER_KUECHE_OG: I/O device is deCONZ
2022.09.18 10:21:46 3: SAFE_BOX_VIBRATION: I/O device is deCONZ
2022.09.18 10:21:46 3: HUEDevice15: I/O device is deCONZ
2022.09.18 10:21:46 3: STODL_TEMPERATUR: I/O device is deCONZ
2022.09.18 10:21:46 3: STODL_LUFTFEUCHTIGKEIT: I/O device is deCONZ
2022.09.18 10:21:46 3: HUEDevice16: I/O device is deCONZ
2022.09.18 10:21:46 3: AUS_LUFTFEUCHTIGKEIT: I/O device is deCONZ
2022.09.18 10:21:46 3: AUS_LUFTDRUCK: I/O device is deCONZ
2022.09.18 10:21:46 3: AUS_TEMPERATUR: I/O device is deCONZ
2022.09.18 10:21:46 3: SCHALTER_AUSSENSTRAHLER: I/O device is deCONZ
2022.09.18 10:21:46 3: REGENSENSOR_SCHIPFL: I/O device is deCONZ
2022.09.18 10:21:46 3: HUEDevice7: I/O device is deCONZ
2022.09.18 10:21:46 3: HUEDevice18: I/O device is deCONZ
2022.09.18 10:21:46 3: HUEDevice21: I/O device is deCONZ
2022.09.18 10:21:46 3: CARPORT_ROLLO_LINKS: I/O device is deCONZ
2022.09.18 10:21:46 3: CARPORT_ROLLO_RECHTS: I/O device is deCONZ
2022.09.18 10:21:47 3: AMADCommBridge (AMADBridge) - defined AMADCommBridge with Socketport 8090
2022.09.18 10:21:47 3: AMADBridge: port 8090 opened
2022.09.18 10:21:47 3: AMADCommBridge (AMADBridge) - Socket opened.
2022.09.18 10:21:48 3: AMADDevice (FHEM_Tablet) - I/O device is AMADBridge
2022.09.18 10:21:48 3: AMADDevice (FHEM_Tablet) - set remoteServer to Automagic
2022.09.18 10:21:48 3: AMADDevice (FHEM_Tablet) - defined with AMAD_ID: 1620895465318 on port 8090
2022.09.18 10:21:48 3: AMADDevice (FHEM_Tablet) - set remoteServer to Automagic
2022.09.18 10:21:48 3: HUESensor31: I/O device is deCONZ
2022.09.18 10:21:48 3: HUESensor1: I/O device is deCONZ
2022.09.18 10:21:48 3: HUESensor24: I/O device is deCONZ
2022.09.18 10:21:48 3: HUESensor56: I/O device is deCONZ
2022.09.18 10:21:48 3: KLINGELSENSOR_OG: I/O device is deCONZ
2022.09.18 10:21:48 3: HUESensor57: I/O device is deCONZ
2022.09.18 10:21:48 3: HUEDevice24: I/O device is deCONZ
2022.09.18 10:21:48 3: HUESensor58: I/O device is deCONZ
2022.09.18 10:21:48 3: HUEDevice25: I/O device is deCONZ
2022.09.18 10:21:49 3: TelegramBot_Define teleBot: called
2022.09.18 10:21:49 3: HUESensor38: I/O device is deCONZ
2022.09.18 10:21:49 3: HUESensor41: I/O device is deCONZ
2022.09.18 10:21:49 3: HUEDevice11: I/O device is deCONZ
2022.09.18 10:21:49 3: HUEDevice12: I/O device is deCONZ
2022.09.18 10:21:49 3: HUESensor47: I/O device is deCONZ
2022.09.18 10:21:49 3: HUESensor19: I/O device is deCONZ
2022.09.18 10:21:49 3: HUESensor44: I/O device is deCONZ
2022.09.18 10:21:49 3: HUESensor37: I/O device is deCONZ
2022.09.18 10:21:49 3: HUESensor45: I/O device is deCONZ
2022.09.18 10:21:49 3: HUESensor13: I/O device is deCONZ
2022.09.18 10:21:49 3: HUESensor36: I/O device is deCONZ
2022.09.18 10:21:49 3: HUESensor49: I/O device is deCONZ
2022.09.18 10:21:49 3: FUIP: Registering ui for URL /ui
2022.09.18 10:21:50 3: HUESensor59: I/O device is deCONZ
2022.09.18 10:21:50 3: HUESensor60: I/O device is deCONZ
2022.09.18 10:21:50 3: HUESensor61: I/O device is deCONZ
2022.09.18 10:21:50 3: HUESensor62: I/O device is deCONZ
2022.09.18 10:21:50 3: HUESensor63: I/O device is deCONZ
2022.09.18 10:21:50 3: HUESensor64: I/O device is deCONZ
2022.09.18 10:21:50 1: Including ./log/fhem.save
2022.09.18 10:21:50 3: Opening myHmUART device /dev/ttyAMA0
2022.09.18 10:21:50 3: Setting myHmUART serial parameters to 115200,8,N,1
2022.09.18 10:21:50 3: myHmUART device opened
2022.09.18 10:21:50 3: deCONZ: websocket opened to 192.168.1.141:443
2022.09.18 10:21:50 2: deCONZ: autocreate: created 0/0/0 devices (ignored 0/0/0)
2022.09.18 10:21:50 1: usb create starting
2022.09.18 10:21:51 3: Probing ZWDongle device /dev/serial1
2022.09.18 10:21:51 3: Probing CUL device /dev/ttyS0
2022.09.18 10:21:51 3: Probing TCM_ESP3 device /dev/ttyUSB0
2022.09.18 10:21:51 1: TCM_ESP3: Can't open /dev/ttyUSB0: Device or resource busy
2022.09.18 10:21:51 1: usb create end
2022.09.18 10:21:51 0: Featurelevel: 6.1
2022.09.18 10:21:51 0: Server started with 159 defined entities (fhem.pl:26379/2022-09-03 perl:5.024001 os:linux user:fhem pid:23422)
2022.09.18 10:21:51 3: DbLog DbLog - Creating Push-Handle to database SQLite:dbname=/opt/fhem/fhem.db with user
2022.09.18 10:21:51 3: DbLog DbLog - Push-Handle to db SQLite:dbname=/opt/fhem/fhem.db created
2022.09.18 10:21:51 3: deCONZ: websocket: Switching Protocols ok
2022.09.18 10:21:52 3: CUL_HM set HM_6CE949 statusRequest noArg
2022.09.18 10:22:17 3: ABFALL Muelltonnen - CALENDAR:Muelltonnen_Kalender triggered, updating ABFALL Muelltonnen ...
2022.09.18 10:36:10 2: AttrTemplates: got 249 entries
2022.09.18 11:50:39 1: RMDIR: ./restoreDir/save/2022-07-28
2022.09.18 16:10:50 1: PERL WARNING: Argument "open" isn't numeric in numeric gt (>) at ./FHEM/98_SVG.pm line 1622.
2022.09.18 16:10:50 1: PERL WARNING: Argument "open" isn't numeric in subtraction (-) at ./FHEM/98_SVG.pm line 2164.
2022.09.18 16:10:50 1: PERL WARNING: Argument "open" isn't numeric in sprintf at ./FHEM/98_SVG.pm line 2256.
2022.09.18 16:22:17 3: ABFALL Muelltonnen - CALENDAR:Muelltonnen_Kalender triggered, updating ABFALL Muelltonnen ...
2022.09.18 17:55:57 3: IPCAM (Eingang_Kamera) - getSnapshot URI: http://192.168.1.76/cgi-bin/api.cgi?cmd=Snap&channel=0&rs=wuuPkjUhCeI9WG7C&user=admin&password=
2022.09.18 17:55:57 3: IPCAM (Eingang_Kamera) - ExecuteSnapshotRequest blocking: 0, camUrl: http://192.168.1.76/cgi-bin/api.cgi?cmd=Snap&channel=0&rs=wuuPkjUhCeI9WG7C&user=admin&password=
2022.09.18 17:55:58 3: IPCAM (Eingang_Kamera) - getSnapshot URI: http://192.168.1.76/cgi-bin/api.cgi?cmd=Snap&channel=0&rs=wuuPhkmUCeI9WG7C&user=admin&password=
2022.09.18 17:55:58 3: IPCAM (Eingang_Kamera) - ExecuteSnapshotRequest blocking: 0, camUrl: http://192.168.1.76/cgi-bin/api.cgi?cmd=Snap&channel=0&rs=wuuPkjUhCeI9WG7C&user=admin&password=
2022.09.18 17:55:58 3: IPCAM (Eingang_Kamera) - Snapshot Image Format: jpg
2022.09.18 17:55:59 3: IPCAM (Eingang_Kamera) - Snapshot Image Format: jpg
2022.09.18 17:56:00 3: IPCAM (Eingang_Kamera) - getSnapshot URI: http://192.168.1.76/cgi-bin/api.cgi?cmd=Snap&channel=0&rs=wuuPhkmUCeI9WG7C&user=admin&password=
2022.09.18 17:56:00 3: IPCAM (Eingang_Kamera) - ExecuteSnapshotRequest blocking: 0, camUrl: http://192.168.1.76/cgi-bin/api.cgi?cmd=Snap&channel=0&rs=wuuPkjUhCeI9WG7C&user=admin&password=
2022.09.18 17:56:01 3: IPCAM (Eingang_Kamera) - getSnapshot URI: http://192.168.1.76/cgi-bin/api.cgi?cmd=Snap&channel=0&rs=wuuPhkmUCeI9WG7C&user=admin&password=
2022.09.18 17:56:01 3: IPCAM (Eingang_Kamera) - ExecuteSnapshotRequest blocking: 0, camUrl: http://192.168.1.76/cgi-bin/api.cgi?cmd=Snap&channel=0&rs=wuuPkjUhCeI9WG7C&user=admin&password=
2022.09.18 17:56:01 3: IPCAM (Eingang_Kamera) - Snapshot Image Format: jpg
2022.09.18 17:56:02 3: IPCAM (Eingang_Kamera) - Snapshot Image Format: jpg
2022.09.18 17:56:03 3: IPCAM (Eingang_Kamera) - getSnapshot URI: http://192.168.1.76/cgi-bin/api.cgi?cmd=Snap&channel=0&rs=wuuPkjUhCeI9WG7C&user=admin&password=
2022.09.18 17:56:03 3: IPCAM (Eingang_Kamera) - ExecuteSnapshotRequest blocking: 0, camUrl: http://192.168.1.76/cgi-bin/api.cgi?cmd=Snap&channel=0&rs=wuuPkjUhCeI9WG7C&user=admin&password=
2022.09.18 17:56:04 3: IPCAM (Eingang_Kamera) - getSnapshot URI: http://192.168.1.76/cgi-bin/api.cgi?cmd=Snap&channel=0&rs=wuuPkjUhCeI9WG7C&user=admin&password=
2022.09.18 17:56:04 3: IPCAM (Eingang_Kamera) - ExecuteSnapshotRequest blocking: 0, camUrl: http://192.168.1.76/cgi-bin/api.cgi?cmd=Snap&channel=0&rs=wuuPkjUhCeI9WG7C&user=admin&password=
2022.09.18 17:56:04 3: IPCAM (Eingang_Kamera) - Snapshot Image Format: jpg
2022.09.18 17:56:05 3: IPCAM (Eingang_Kamera) - Snapshot Image Format: jpg
2022.09.18 22:12:44 1: PERL WARNING: Argument "open" isn't numeric in numeric gt (>) at ./FHEM/98_SVG.pm line 1622.
2022.09.18 22:12:44 1: PERL WARNING: Argument "closed" isn't numeric in numeric gt (>) at ./FHEM/98_SVG.pm line 1622.
2022.09.18 22:12:44 1: PERL WARNING: Argument "open" isn't numeric in subtraction (-) at ./FHEM/98_SVG.pm line 2164.
2022.09.18 22:12:44 1: PERL WARNING: Argument "closed" isn't numeric in subtraction (-) at ./FHEM/98_SVG.pm line 2164.
2022.09.18 22:12:44 1: PERL WARNING: Argument "closed" isn't numeric in sprintf at ./FHEM/98_SVG.pm line 2256.
2022.09.18 22:14:44 1: PERL WARNING: Argument "open" isn't numeric in numeric gt (>) at ./FHEM/98_SVG.pm line 1622.
2022.09.18 22:14:44 1: PERL WARNING: Argument "closed" isn't numeric in numeric gt (>) at ./FHEM/98_SVG.pm line 1622.
2022.09.18 22:14:44 1: PERL WARNING: Argument "open" isn't numeric in subtraction (-) at ./FHEM/98_SVG.pm line 2164.
2022.09.18 22:14:44 1: PERL WARNING: Argument "closed" isn't numeric in subtraction (-) at ./FHEM/98_SVG.pm line 2164.
2022.09.18 22:14:44 1: PERL WARNING: Argument "closed" isn't numeric in sprintf at ./FHEM/98_SVG.pm line 2256.
2022.09.18 22:21:52 4: parse status message for AUS_LUFTFEUCHTIGKEIT
2022.09.18 22:21:52 5: AUS_LUFTFEUCHTIGKEIT: using offsetUTC 7200 from bridge
2022.09.18 22:21:52 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading reachable with timestamp 2022-09-18 21:40:34, current reading timestamp is 2022-09-18 21:40:34
2022.09.18 22:21:52 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading batteryPercent with timestamp 2022-09-18 21:40:34, current reading timestamp is 2022-09-18 21:40:34
2022.09.18 22:21:52 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading lastseen with timestamp 2022-09-18 21:40:34, current reading timestamp is 2022-09-18 21:40:34
2022.09.18 22:21:52 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading battery with timestamp 2022-09-18 21:40:34, current reading timestamp is 2022-09-18 21:40:34
2022.09.18 22:21:52 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading humidity with timestamp 2022-09-18 21:40:34, current reading timestamp is 2022-09-18 21:40:34
2022.09.18 22:21:52 4: parse status message for KEL_LUFTFEUCHTIGKEIT
2022.09.18 22:21:52 5: KEL_LUFTFEUCHTIGKEIT: using offsetUTC 7200 from bridge
2022.09.18 22:21:52 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading reachable with timestamp 2022-09-18 22:11:32, current reading timestamp is 2022-09-18 22:11:32
2022.09.18 22:21:52 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading batteryPercent with timestamp 2022-09-18 22:11:32, current reading timestamp is 2022-09-18 22:11:32
2022.09.18 22:21:52 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading lastseen with timestamp 2022-09-18 22:11:32, current reading timestamp is 2022-09-18 22:11:32
2022.09.18 22:21:52 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading humidity with timestamp 2022-09-18 22:11:32, current reading timestamp is 2022-09-18 22:11:32
2022.09.18 22:21:52 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading battery with timestamp 2022-09-18 22:11:32, current reading timestamp is 2022-09-18 22:11:32
2022.09.18 22:22:17 3: ABFALL Muelltonnen - CALENDAR:Muelltonnen_Kalender triggered, updating ABFALL Muelltonnen ...
2022.09.18 22:22:52 4: parse status message for AUS_LUFTFEUCHTIGKEIT
2022.09.18 22:22:52 5: AUS_LUFTFEUCHTIGKEIT: using offsetUTC 7200 from bridge
2022.09.18 22:22:52 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading batteryPercent with timestamp 2022-09-18 21:40:34, current reading timestamp is 2022-09-18 21:40:34
2022.09.18 22:22:52 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading reachable with timestamp 2022-09-18 21:40:34, current reading timestamp is 2022-09-18 21:40:34
2022.09.18 22:22:52 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading battery with timestamp 2022-09-18 21:40:34, current reading timestamp is 2022-09-18 21:40:34
2022.09.18 22:22:52 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading humidity with timestamp 2022-09-18 21:40:34, current reading timestamp is 2022-09-18 21:40:34
2022.09.18 22:22:52 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading lastseen with timestamp 2022-09-18 21:40:34, current reading timestamp is 2022-09-18 21:40:34
2022.09.18 22:22:52 4: parse status message for KEL_LUFTFEUCHTIGKEIT
2022.09.18 22:22:52 5: KEL_LUFTFEUCHTIGKEIT: using offsetUTC 7200 from bridge
2022.09.18 22:22:52 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading battery with timestamp 2022-09-18 22:11:32, current reading timestamp is 2022-09-18 22:11:32
2022.09.18 22:22:52 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading humidity with timestamp 2022-09-18 22:11:32, current reading timestamp is 2022-09-18 22:11:32
2022.09.18 22:22:52 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading lastseen with timestamp 2022-09-18 22:11:32, current reading timestamp is 2022-09-18 22:11:32
2022.09.18 22:22:52 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading batteryPercent with timestamp 2022-09-18 22:11:32, current reading timestamp is 2022-09-18 22:11:32
2022.09.18 22:22:52 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading reachable with timestamp 2022-09-18 22:11:32, current reading timestamp is 2022-09-18 22:11:32
2022.09.18 22:23:52 4: parse status message for KEL_LUFTFEUCHTIGKEIT
Was stimmt hier nicht?
Und auch solche Meldungen wiederholen sich.
2022.09.26 17:27:58 4: parse status message for HUEDevice9
2022.09.26 17:27:58 4: parse status message for HUEDevice7
2022.09.26 17:27:58 4: parse status message for HUEDevice18
2022.09.26 17:27:59 4: parse status message for HUEDevice9
hat niemand eine Idee?
Zumindest wo ich anfangen könnte zu suchen?
ich glaube nämlich, dass die vielen, gleichen Logeinträge das System ganz schön ausbremsen.
Zitat von: Ruggy am 29 September 2022, 07:40:49
hat niemand eine Idee?
Zumindest wo ich anfangen könnte zu suchen?
ich glaube nämlich, dass die vielen, gleichen Logeinträge das System ganz schön ausbremsen.
Ich kann zumindest sagen, dass die Meldungen nicht vom DOIF-Modul kommen.
Zitat von: Damian am 29 September 2022, 08:16:42
Ich kann zumindest sagen, dass die Meldungen nicht vom DOIF-Modul kommen.
Sollte ich meinen Betreff ändern oder den Thread gleich in einen andere Kategorie verschieben; oder neue Frage stellen?
Ich würde den Raspberry neu aufsetzen.
Du schreibst Du hast ein Update gefahren, bist aber noch immer auf Jessie...
btw: Support für Jessie endete am 30.06.2020...
Ich habe das OS neu aufgesetzt.
Habe versucht, es nach dieser Anleitung (https://heinz-otto.blogspot.com/2022/08/howto-fhem-umzug-von-system-nach-system.html ;und den dort verwiesenen) zu machen.
Es ist wirklich gut geschrieben; bin mir aber nicht sicher, ob ich dann doch alles richtig gemacht habe.
FHEM läuft meiner Meinung nach soweit. Es werden vor allem die vielen o.g. Meldungen in der Logfile nicht mehr angezeigt.
Leider funktioniert aber die Kommunikation mit ConBee (Deconz; Phoscon App) nicht richtig.
Hierzu sind auch Fehler in der Logfile. Hier ein Auszug davon; ab den Fehler bis zum Schluss der Logfile
2022.10.02 16:22:32 2: HUEBridge_OpenDev: error reading description: http://192.168.1.141/description.xml: Can't connect(1) to http://192.168.1.141:80: IO::Socket::INET: connect: Connection refused
2022.10.02 16:22:32 2: deCONZ: empty answer received for http://192.168.1.141/api/7A75D31B55/config
2022.10.02 16:22:32 2: HUEBridge_OpenDev: got empty config
2022.10.02 16:22:32 1: usb create starting
2022.10.02 16:22:32 3: Probing ZWDongle device /dev/serial1
2022.10.02 16:22:32 3: Probing CUL device /dev/ttyS0
2022.10.02 16:22:32 3: Probing TCM_ESP3 device /dev/ttyUSB0
2022.10.02 16:22:32 3: Probing TCM_ESP2 device /dev/ttyUSB0
2022.10.02 16:22:32 3: Probing FHZ device /dev/ttyUSB0
2022.10.02 16:22:33 3: Probing TRX device /dev/ttyUSB0
2022.10.02 16:22:33 3: Probing ZWDongle device /dev/ttyUSB0
2022.10.02 16:22:33 3: Probing SIGNALDuino device /dev/ttyUSB0
2022.10.02 16:22:34 3: Probing MYSENSORS device /dev/ttyUSB0
2022.10.02 16:22:34 3: Probing ArduCounter device /dev/ttyUSB0
2022.10.02 16:22:34 3: Probing ElsnerWS device /dev/ttyUSB0
2022.10.02 16:22:35 3: Probing FRM device /dev/ttyUSB0
2022.10.02 16:22:40 1: usb create end
2022.10.02 16:22:40 0: Featurelevel: 6.1
2022.10.02 16:22:40 0: Server started with 158 defined entities (fhem.pl:26379/2022-09-03 perl:5.032001 os:linux user:fhem pid:553)
2022.10.02 16:22:40 3: DbLog DbLog - Creating Push-Handle to database SQLite:dbname=/opt/fhem/fhem.db with user
2022.10.02 16:22:40 3: DbLog DbLog - Push-Handle to db SQLite:dbname=/opt/fhem/fhem.db created
2022.10.02 16:22:41 3: CUL_HM set HM_6CE949 statusRequest noArg
2022.10.02 16:22:53 3: ABFALL Muelltonnen - CALENDAR:Muelltonnen_Kalender triggered, updating ABFALL Muelltonnen ...
2022.10.02 16:38:41 3: FHEMWEB WEB CSRF error: csrf_153019247140477 ne csrf_267031206106046 for client WEB_192.168.1.10_50464 / command get deCONZ sensors . For details see the csrfToken FHEMWEB attribute.
2022.10.02 16:38:46 2: AttrTemplates: got 249 entries
Außerdem ist noch folgendes:
"Lastseen" der Sensoren ist vom 25.09.22 und ändert sich nicht.
Das Device deCONZ hat als state -> initialized
und mit Datum von heute.
Die restlichen Datum sind aber wiederum vom 24. oder 25.09.22
Ich habe jetzt auf die Phoscon App das aktuellste Update darauf gemacht. Konnte zwischendurch nicht mehr auf die Phoscan App zugreifen, was aber mittlerweile wieder funkioniert.
Ich kann mir im Gerät deCONZ die Sensoren mit get deCONZ sensors
anzeigen lassen.
Habe versuchsweise in der Phoscon App einen Sensor gelöscht und neu angelernt. Dieser wurde dann wieder mit vorherigen Befehl erkannt. Wenn ich jedoch auf den Link von den Sensor klicke (angezeigte "links" bei den Ergebnis von "get ... sensors") springt mir FHEM in einen anderen Temperatursensor.
Jetzt habe ich wieder den Sensor in der Phoscon App gelöscht um ihn neu anzulernen. Das Anlernen funktionierte aber der "Link" wird nicht angezeigt.
Irgendwie stimmt die Verbindung zum ConBee-USB Stick nicht.
Weiter ist mir beim Schreiben jetzt eingefallen, dass ich das Betriebssytem auf einen anderen "Test-Raspberry" mit einer anderen IP-Adresse aufgesetzt habe. Habe dann die SD-Karte in meinen "normalen" Raspberry und dann erst das FHEM Backup eingespielt. Wobei in deCONZ die richtige IP (192.168.1.141) eingetragen ist.
Kann es damit auch zusammen hängen?
Hier noch das List von deCONZ
Internals:
DEF 192.168.1.141
FUUID 5f1bd2bc-f33f-f59f-3727-c2e7350f6569509f
FVERSION 30_HUEBridge.pm:0.264380/2022-09-22
INTERVAL 60
NAME deCONZ
NOTIFYDEV global
NR 15
NTFY_ORDER 50-deCONZ
STATE initialized
TYPE HUEBridge
host 192.168.1.141
READINGS:
2022-09-24 20:52:02 alert none
2022-07-02 16:02:29 groups 1/8
2022-09-25 10:16:51 lastError resource, /lights/11, not available
2022-09-24 20:52:02 lastseen 2022-09-24T18:40Z
2022-09-25 10:13:50 lights 8/16
2022-09-24 20:52:02 reachable 0
2022-01-29 17:30:35 rules 0
2022-01-29 17:30:35 scenes 0
2022-01-29 17:30:35 schedules 0
2022-09-25 00:12:53 sensors 30/64
2022-10-02 16:17:11 state initialized
helper:
count 0
last_config_timestamp 0
ignored:
Attributes:
devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
httpUtils 1
key 7A75D31B55
room deCONZ_Geraete
webCmd toggle:on:off
Hier ein List als Beispiel von einen Temperatursensor:
Internals:
DEF sensor 17 IODev=deCONZ
FUUID 5f1bd2bc-f33f-f59f-0f09-8b15fafc524f758d
FVERSION 31_HUEDevice.pm:0.262040/2022-07-09
ID S17
INTERVAL
IODev deCONZ
NAME SCH_EG_TEMPERATUR
NR 17
STATE ???
TYPE HUEDevice
READINGS:
2022-10-02 16:22:32 IODev deCONZ
2022-09-25 16:13:10 battery 78
2022-09-25 16:13:10 batteryPercent 78
2018-12-25 11:15:47 dewpoint 4.2
2018-12-25 11:15:47 humidity 74.35
2022-09-25 16:13:10 lastseen 2022-09-25T14:13Z
2022-09-25 16:13:10 reachable 1
2022-09-25 16:13:10 temperature 14.8
helper:
devtype S
state
update_timeout 1
configList:
setList:
Attributes:
IODev deCONZ
event-on-change-reading temperature
model lumi.weather
room EG_Schlafzimmer
Im Gerät deCONZ steht nicht "connected" sondern "toggle" und "on" "off"
Bei einer Erstinstallation müsste ich ja folgenderes eingeben.
define deConz HUEBridge 192.168.1.141
attr httpUtils 1
set deConz active
Kann ich dies nochmal eingeben?
Oder müsste ich alle Geräte (welche über deConz verbunden sind) in FHEM wieder neu verbinden?
Zitat von: Ruggy am 02 Oktober 2022, 19:29:40
Bei einer Erstinstallation müsste ich ja folgenderes eingeben.
attr httpUtils 1
sicher dass das nicht
attr deConz httpUtils 1
sein muss?
Ja stimmt, ist ein Schreibfehler und muß
attr deConz httpUtils 1
heißen.
Habe es jetzt mal nur mit
set deConz active
und in der Phoscon App auf "App verbinden" geklickt.
Die verschiedenen Sensoren haben jetzt das Datum von heute drinnen. Scheint also etwas positives erstmal bewirkt zu haben.
Werde es jetzt mal beobachten.
Jetzt wird das Logfile aber leider mit folgenden Einträgen vollbombadiert :(
Also das selbe als wie mit dem alten OS.
Hier ein Ausschnitt vom Logfile:
2022.10.02 20:15:40 5: KEL_LUFTFEUCHTIGKEIT: using offsetUTC 7200 from bridge
2022.10.02 20:15:40 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading reachable with timestamp 2022-10-02 19:55:02, current reading timestamp is 2022-10-02 19:55:02
2022.10.02 20:15:40 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading lastseen with timestamp 2022-10-02 19:55:02, current reading timestamp is 2022-10-02 19:55:02
2022.10.02 20:15:40 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading batteryPercent with timestamp 2022-10-02 19:55:02, current reading timestamp is 2022-10-02 19:55:02
2022.10.02 20:15:40 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading humidity with timestamp 2022-10-02 19:55:02, current reading timestamp is 2022-10-02 19:55:02
2022.10.02 20:15:40 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading temperature with timestamp 2022-10-02 19:55:02, current reading timestamp is 2022-10-02 20:14:44
2022.10.02 20:15:40 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading battery with timestamp 2022-10-02 19:55:02, current reading timestamp is 2022-10-02 19:55:02
2022.10.02 20:15:40 4: parse status message for AUS_LUFTFEUCHTIGKEIT
2022.10.02 20:15:40 5: AUS_LUFTFEUCHTIGKEIT: using offsetUTC 7200 from bridge
2022.10.02 20:15:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading humidity with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:15:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading batteryPercent with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:15:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading lastseen with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:15:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading reachable with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:15:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading battery with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:15:40 4: parse status message for HUEDevice7
2022.10.02 20:15:40 4: parse status message for HUEDevice18
2022.10.02 20:15:40 4: parse status message for HUEDevice9
2022.10.02 20:15:42 4: parse status message for HUEDevice9
2022.10.02 20:16:07 4: parse status message for HUEDevice9
2022.10.02 20:16:07 4: HUEDevice9: bridge has events api: 1
2022.10.02 20:16:14 4: parse status message for KEL_LUFTFEUCHTIGKEIT
2022.10.02 20:16:14 4: KEL_LUFTFEUCHTIGKEIT: bridge has events api: 1
2022.10.02 20:16:14 4: parse status message for KEL_LUFTFEUCHTIGKEIT
2022.10.02 20:16:14 5: KEL_LUFTFEUCHTIGKEIT: using offsetUTC 7200 from bridge
2022.10.02 20:16:16 4: parse status message for HUEDevice9
2022.10.02 20:16:37 4: parse status message for HUEDevice18
2022.10.02 20:16:40 4: parse status message for KEL_LUFTFEUCHTIGKEIT
2022.10.02 20:16:40 5: KEL_LUFTFEUCHTIGKEIT: using offsetUTC 7200 from bridge
2022.10.02 20:16:40 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading humidity with timestamp 2022-10-02 20:16:14, current reading timestamp is 2022-10-02 20:16:14
2022.10.02 20:16:40 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading temperature with timestamp 2022-10-02 20:16:14, current reading timestamp is 2022-10-02 20:16:14
2022.10.02 20:16:40 4: parse status message for AUS_LUFTFEUCHTIGKEIT
2022.10.02 20:16:40 5: AUS_LUFTFEUCHTIGKEIT: using offsetUTC 7200 from bridge
2022.10.02 20:16:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading battery with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:16:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading lastseen with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:16:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading reachable with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:16:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading humidity with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:16:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading batteryPercent with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:16:40 4: parse status message for HUEDevice7
2022.10.02 20:16:40 4: parse status message for HUEDevice9
2022.10.02 20:16:40 4: parse status message for HUEDevice18
2022.10.02 20:16:41 4: parse status message for HUEDevice9
2022.10.02 20:17:40 4: parse status message for AUS_LUFTFEUCHTIGKEIT
2022.10.02 20:17:40 5: AUS_LUFTFEUCHTIGKEIT: using offsetUTC 7200 from bridge
2022.10.02 20:17:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading battery with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:17:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading reachable with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:17:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading lastseen with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:17:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading batteryPercent with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:17:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading humidity with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:17:40 4: parse status message for KEL_LUFTFEUCHTIGKEIT
Welchen verbose Level hast du eingestellt?
Sind doch "debug" Meldungen auf Level 4 bzw. 5.
Gruß, Joachim
In "global" ist verbose 3
im KEL_LUFTFEUCHTIGKEIT ist verbose 5;
Habe noch von drei weiteren Geräten verbose auf 5 gesetzt. Dies habe ich aufgrund dieses Threads zur Fehlersuche (Seite 1) gemacht. Das wegen KEL_LUFTFEUCHTIGKEIT weiß ich jetzt gar nicht wann ich das gemacht habe.
Soll diese Attributes wieder löschen?
Ist das bzgl. dem timestamp dann keine Fehler?
https://wiki.fhem.de/wiki/Verbose
Ich weiß nicht was du meinst...
Zur Fehlersuche eben verbose anpassen, dann wird nat. mehr geloggt...
Wenn das nicht hilft halt verbose wieder zurückstellen (oder Attribut löschen), sonst wird nat. weiterhin mehr geloggt...
Gruß, Joachim
Das ursprünglicht Problem und der Grund für diesen Thread war folgendes.
Ich kopiere die Beschreibung des seltsamen Verhaltens nochmal hier her, was der Grund für den Thread war. Ich dachte es hängt irgendwie mit dem "at" zusammen. Die Lists der Geräte würden sich in meinen 1. Beitrag befinden.
Zitat von: Ruggy am 25 September 2022, 11:31:26
Leider gibt es immer noch das "Phänomen", dass sich die Steckdose Osram Smart + nach ca. 30 Sekunden automatisch wieder ausschaltet.
Ich habe es mit einer andern Smart+ versucht, da war es das selbe.
Wenn ich direkt im Device (HUEDevice9) die Smart+ einschalte bleibt sie eingeschalten.
Wenn ich sie jedoch über den Dummy (mit einen DOIF für Einschalten und einen DOIF für Ausschalten) einschalte, schaltet sie sich ca. 8 Sekunden aus, nachdem das DOIF für Einschalten abgearbeitet wurde.
Folgende Devices habe ich:
HUEDevice9 = Smart+ (Steckdose mit Lüfter; derzeit habe ich zum Testen den Lüfter nicht angesteckt)
HUEDevice18 = Relaist für Lüfterklappe öffnen (Xiaomi Doppelrelais)
HUEDevice7 = Relais für Lüfterklappe schließen (Xiaomi Doppelrelais)
So ist der Ablauf:
Ich klicke beim Dummy auf "on"
-> Relais für Lüfterklappe schaltet sofort ein (HUEDevice18)
-> nach 17 Sekunden Relais für Lüfterklappe schaltet aus (HUEDevice18)
-> nach ca. 2 Sekunden Lüfter (HUEDevice9) schaltet ein.
---soweit würde es passen
...aber nach ein paar Sekunden (Dauer ist unterschiedlich; einmal nach 8, dann nach 16, dann nach 40 Sekunden) schaltet sich die Smart+ (HUEDevice9) von selber aus.
An was kann das liegen?
Leider ist das Verhalten unverändert, obwohl ich jetzt ein aktuelles OS darauf habe.
Im Logfile wird es so angezeigt. Ganz genau kann ich es nicht feststellen, wann ich auf "on" im Dummy geklickt habe, weil die "parse status message for..." geloggt werden, ohne dass ich etwas klicke.
Hier wäre noch das DOIF fürs einschalten.
defmod KELLERLUEFTER_MIT_KLAPPEN_EINSCHALTEN_doif DOIF ([Kellerluefter_mit_Klappen:"on"]) (set HUEDevice18 on-for-timer 17) (set HUEDevice9 on)
attr KELLERLUEFTER_MIT_KLAPPEN_EINSCHALTEN_doif room Kellerlüftung
attr KELLERLUEFTER_MIT_KLAPPEN_EINSCHALTEN_doif wait 0,20
deconz hast du auch aktualisiert?
Und mach mal aus den HUE-Dimmern ein/aus-Typen. Da verrutscht manchmal was....
deconz hätte ich aktualisiert:
Ver. 2.18.02 / 19.09.22
Firmware 26400500
Zitat von: Beta-User am 02 Oktober 2022, 22:34:51
Und mach mal aus den HUE-Dimmern ein/aus-Typen. Da verrutscht manchmal was....
Meinst Du aus dem
attr HUEDevice7 WebCmd pct:toggle:on:off
ein
attr HUEDevice7 WebCmd on:off
reicht das dafür?
Habe die drei Geräte auf on:off geändert.
Leider ist das Verhalten immer noch unverändert.
Wobei ja alles, vor dem Update vor ca. einer Woche, alles genauso funktioniert hat; auch mit den Dimmern.
Nicht der "Anstrich" ist das Problem, sondern der Inhalt (subType)...
Habe es geändert auf ::)
attr HUEDevice18 subType switch
Leider unverändert.
HUEDevice9 schaltet immer noch automatisch aus.
Stelle doch mal deine Logik testweise um dass sie kein echtes Gerät schaltet, sondern einen (neuen) Dummy.
Damit bekommst dann zumindest raus obs am aktor oder der Logik klemmt.
Und evtl zur Fehlersuche in den betroffenen Geräten dann das verbose erhöhen.
Zitat von: Ruggy am 02 Oktober 2022, 22:44:22
deconz hätte ich aktualisiert:
Ver. 2.18.02 / 19.09.22
Firmware 26400500
Hmm, die firmware ist nicht die "latest stable", meine war bis grade noch von August 21. Habe dann auf die beta aus Mai 22 geflasht (https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Update-deCONZ-manually#update-in-ubuntu-or-debian (https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Update-deCONZ-manually#update-in-ubuntu-or-debian)): https://deconz.dresden-elektronik.de/deconz-firmware/?C=M;O=D (https://deconz.dresden-elektronik.de/deconz-firmware/?C=M;O=D)
Meine Erfahrungen mit Relay-Geräten von Xiaomi sind eher nicht gut, ich habe beide wieder ausgebaut, weil die nicht so wollten wie ich das erwartet hatte (automatisch ausschalten war aber nicht dabei).
Von daher ist der Tipp von Frank_Huber sicher gut, das mal auf was "neutrales" umzuleiten; das klingt danach, als würde entweder die Hardware nicht korrekt funktionieren, oder es gibt noch einen Event-Handler, der da reinspuckt.
Wollte jetzt doch noch mal die Firmware aktualisieren, bevor ich das Dummy erstelle.
Habe gestern eigentlich den vom 18.08.21 installiert (haben den ConBee I)
Bei folgenden Befehl (laut der verlinkten Installationsanleitung) in Putty wird mir folgendes ausgegeben:
ls -la /dev/serial/by-id/
pi@raspberrypi:~ $ ls -la /dev/serial/by-id/
insgesamt 0
drwxr-xr-x 2 root root 60 2. Okt 19:08 .
drwxr-xr-x 4 root root 80 2. Okt 19:08 ..
lrwxrwxrwx 1 root root 13 2. Okt 19:08 usb-FTDI_FT230X_Basic_UART_DM01H1SS-if00-port0 -> ../../ttyUSB0
Ist das soweit richtig?
Sollte hier nicht etwas mit Deconz stehen?
Zusätzlich steckt ein Homatic Funktmodul HM-MOD-RPI-PCB auf den Raspberry.
Für ConBee I scheinst du aktuell zu sein, und wie sich ein ConBee I meldet, kann ich dir nicht sagen, ConBee II ist mit dem Herstellernamen und der Produktbezeichnung sehr gut erkennbar.
Ansonsten müßtest du ja wissen, ob da nur das eine Gerät an USB angeschlossen ist...
(an UART (Pi-HM-PCB) ist egal)
Habe jetzt mit folgenden Befehlen nochmal ein Update durchgeführt.
sudo systemctl stop deconz
wget https://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26400500.bin.GCF
sudo systemctl stop ModemManager
sudo GCFFlasher_internal -t 60 -d 0 -f deCONZ_Rpi_0x26400500.bin.GCF
wget https://deconz.dresden-elektronik.de/ubuntu/stable/deconz-2.18.02-qt5.deb
sudo dpkg -i deconz-2.18.02-qt5.deb
sudo systemctl start deconz
Wird aber trotzdem wieder so in der Phoscon App angezeigt:
Ver. 2.18.02 / 19.09.22
Firmware 26400500
Zitat von: Beta-User am 03 Oktober 2022, 10:26:45
Ansonsten müßtest du ja wissen, ob da nur das eine Gerät an USB angeschlossen ist...
Es ist nur der ConBee I Stick am USB Port angeschlossen.
Dachte mir nur, weil nichts mit Conbee oder Deconz oder ähnliches steht sondern UART...
Na ja, beides war ja aktuell gewesen, ich war nur fälschlicherweise von einem ConBee II ausgegangen.
Aber wieso ModemManager?!? Hast du eine GUI-Version des OS installiert?!?
Zitat von: Beta-User am 03 Oktober 2022, 11:06:21
Aber wieso ModemManager?!? Hast du eine GUI-Version des OS installiert?!?
Nein, habe ich nicht.
Habe es so ausgeführt, weil es in der Anleitung so steht.
Habe es jetzt mit einen Dummy Testluefter probiert.
Hier schaltet der Testlüfter nicht aus.
Habe jetzt aber nur den Befehl
set HUEDevice9 on
gegeben und der HUEDevice9 (Steckdose Osram Smart+) hat sich ein paar Sekunden danach von selber wieder ausgeschaltet.
Gibt es hierfür eine Erklärung?
Das ist wahrscheinlich das Problem der ganzen Sache.
Verbose steht beim HUEDevice9 auf 5.
Im Event monitor kommt nach ein paar Sekunden (Zeitdauer ist unterschiedlich) das Ausschaltsignal
Hier die Eintragungen zwischen on und off im Event monitor:
2022-10-03 11:19:10 HUEDevice HUEDevice9 on
2022-10-03 11:19:13 HUEDevice HUESensor45 current: 0
2022-10-03 11:19:13 HUEDevice HUESensor45 voltage: 230
2022-10-03 11:19:13 HUEDevice HUESensor45 power: 0
2022-10-03 11:19:18 HUEDevice HUESensor23 nomotion
2022-10-03 11:19:24 HUEDevice HUESensor22 lux: 44
2022-10-03 11:19:24 HUEDevice HUESensor22 lightlevel: 16436
2022-10-03 11:19:24 HUEDevice HUESensor22 dark: 0
2022-10-03 11:19:24 HUEDevice HUESensor22 daylight: 0
2022-10-03 11:19:25 HUEDevice HUESensor23 motion
2022-10-03 11:19:41 HUEDevice HUESensor45 voltage: 230
2022-10-03 11:19:41 HUEDevice HUESensor45 current: 0
2022-10-03 11:19:41 HUEDevice HUESensor45 power: 0
2022-10-03 11:19:43 DOIF TAUPUNKT_LUEFTUNG_WINTER cmd_nr: 2
2022-10-03 11:19:43 DOIF TAUPUNKT_LUEFTUNG_WINTER cmd: 2
2022-10-03 11:19:43 DOIF TAUPUNKT_LUEFTUNG_WINTER cmd_event: AUS_LUFTFEUCHTIGKEIT
2022-10-03 11:19:43 DOIF TAUPUNKT_LUEFTUNG_WINTER cmd_2
2022-10-03 11:19:43 HUEDevice AUS_LUFTFEUCHTIGKEIT temperature: 9.04
2022-10-03 11:19:24 HUEDevice HUESensor22 batteryPercent: 95
2022-10-03 11:19:24 HUEDevice HUESensor22 lastseen: 2022-10-03T09:19Z
2022-10-03 11:19:24 HUEDevice HUESensor22 reachable: 1
2022-10-03 11:19:24 HUEDevice HUESensor22 battery: 95
2022-10-03 11:19:25 HUEDevice HUESensor23 temperature: 21
2022-10-03 11:19:25 HUEDevice HUESensor23 battery: 95
2022-10-03 11:19:25 HUEDevice HUESensor23 batteryPercent: 95
2022-10-03 11:19:25 HUEDevice HUESensor23 reachable: 1
2022-10-03 11:19:25 HUEDevice HUESensor23 lastseen: 2022-10-03T09:19Z
2022-10-03 11:19:43 DOIF TAUPUNKT_LUEFTUNG_KALT cmd_nr: 2
2022-10-03 11:19:43 DOIF TAUPUNKT_LUEFTUNG_KALT cmd: 2
2022-10-03 11:19:43 DOIF TAUPUNKT_LUEFTUNG_KALT cmd_event: KEL_LUFTFEUCHTIGKEIT
2022-10-03 11:19:43 DOIF TAUPUNKT_LUEFTUNG_KALT cmd_2
2022-10-03 11:19:43 DOIF TAUPUNKT_LUEFTUNG_NORMAL cmd_nr: 2
2022-10-03 11:19:43 DOIF TAUPUNKT_LUEFTUNG_NORMAL cmd: 2
2022-10-03 11:19:43 DOIF TAUPUNKT_LUEFTUNG_NORMAL cmd_event: KEL_LUFTFEUCHTIGKEIT
2022-10-03 11:19:43 DOIF TAUPUNKT_LUEFTUNG_NORMAL cmd_2
2022-10-03 11:19:43 DOIF TAUPUNKT_LUEFTUNG_WINTER cmd_nr: 2
2022-10-03 11:19:43 DOIF TAUPUNKT_LUEFTUNG_WINTER cmd: 2
2022-10-03 11:19:43 DOIF TAUPUNKT_LUEFTUNG_WINTER cmd_event: KEL_LUFTFEUCHTIGKEIT
2022-10-03 11:19:43 DOIF TAUPUNKT_LUEFTUNG_WINTER cmd_2
2022-10-03 11:19:43 HUEDevice KEL_LUFTFEUCHTIGKEIT temperature: 13.65
2022-10-03 11:19:43 HUEDevice STODL_LUFTFEUCHTIGKEIT temperature: 13.01
2022-10-03 11:19:43 HUEDevice HUESensor68 temperature: 20.35
2022-10-03 11:19:41 HUEDevice HUESensor45 temperature: 32
2022-10-03 11:19:41 HUEDevice HUESensor45 lastseen: 2022-10-03T09:18Z
2022-10-03 11:19:41 HUEDevice HUESensor45 reachable: 1
2022-10-03 11:19:43 HUEDevice HUESensor65 temperature: 21.88
2022-10-03 11:19:43 HUEDevice HUEDevice11 lastseen: 2022-10-03T09:18Z
2022-10-03 11:19:43 HUEDevice HUEDevice9 off
Hier das List vom HUEDevice9
Internals:
DEF 9 IODev=deCONZ
FUUID 63300dc8-f33f-f59f-33e0-075c8c15be8d955f
FVERSION 31_HUEDevice.pm:0.262040/2022-07-09
ID 9
INTERVAL
IODev deCONZ
NAME HUEDevice9
NR 165
STATE off
TYPE HUEDevice
desired 0
eventCount 48
has_events 1
manufacturername OSRAM
modelid Plug 01
name Keller_Steckdose_Luefter
swversion V1.04.90
type On/Off plug-in unit
uniqueid 7c:b0:3e:aa:0a:07:10:dd-03
Helper:
DBLOG:
state:
DbLog:
TIME 1664788783.42052
VALUE off
READINGS:
2022-10-02 19:08:38 IODev deCONZ
2022-10-02 20:14:45 alert none
2022-10-03 11:21:44 lastseen 2022-10-03T09:20Z
2022-10-03 11:19:43 onoff 0
2022-10-03 11:19:43 pct 0
2022-10-03 11:21:44 reachable 1
2022-10-03 11:19:43 state off
helper:
alert none
battery -1
bri -1
colormode
ct -1
devtype
dynamics_status
effect
hue -1
lastseen
mode
on 0
pct 0
reachable 1
rgb
sat -1
update_timeout -1
v2effect
xy
json:
e changed
id 9
r lights
source event
t event
uniqueid 7c:b0:3e:aa:0a:07:10:dd-03
attr:
id 9
lastannounced
lastseen 2022-10-03T09:22Z
manufacturername OSRAM
modelid Plug 01
name Keller_Steckdose_Luefter
swversion V1.04.90
type On/Off plug-in unit
uniqueid 7c:b0:3e:aa:0a:07:10:dd-03
Attributes:
IODev deCONZ
alias Luefter_Steckdose_ACHTUNG_ohne_Rohrklappe
color-icons 2
devStateIcon off:Ventilator_fett on:vent_ventilation_level_3@red
event-on-change-reading state
group HUEDevice
model Plug 01
room Keller,Kellerlüftung,deCONZ_Geraete
subType switch
verbose 5
webCmd on:off
Na ja, entweder gibt es in FHEM was, das das so steuert; dann sollte (v.a. bei verbose 5) was im Log zu finden sein.
Oder es ist in deconz oder auf dem Aktor selbst was konfiguriert. (Wäre vermutlich über deconz-GUI rauszufinden, kann man bei entsprechender Konfiguration auch remote starten).
Oder das Ding ist halt einfach kaputt...
Das sind die Eintragungen in der Logfile (hier ist schon die Logfile gemeint, welche ich links vom "Standart-FHEM" per link aufrufen kann?) vom ein bis zum ausschalten
2022.10.03 11:33:43 4: parse status message for HUEDevice9
2022.10.03 11:33:43 4: parse status message for HUEDevice18
2022.10.03 11:33:43 4: parse status message for HUEDevice7
2022.10.03 11:33:44 4: parse status message for HUEDevice9
2022.10.03 11:33:50 4: parse status message for HUEDevice9
2022.10.03 11:33:50 4: parse status message for HUEDevice9
2022.10.03 11:34:00 4: parse status message for HUEDevice7
2022.10.03 11:34:00 4: parse status message for HUEDevice18
2022.10.03 11:34:00 4: parse status message for HUEDevice18
2022.10.03 11:34:43 4: parse status message for AUS_LUFTFEUCHTIGKEIT
2022.10.03 11:34:43 5: AUS_LUFTFEUCHTIGKEIT: using offsetUTC 7200 from bridge
2022.10.03 11:34:43 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading battery with timestamp 2022-10-03 11:20:09, current reading timestamp is 2022-10-03 11:20:09
2022.10.03 11:34:43 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading batteryPercent with timestamp 2022-10-03 11:20:09, current reading timestamp is 2022-10-03 11:20:09
2022.10.03 11:34:43 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading humidity with timestamp 2022-10-03 11:20:09, current reading timestamp is 2022-10-03 11:20:09
2022.10.03 11:34:43 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading reachable with timestamp 2022-10-03 11:20:09, current reading timestamp is 2022-10-03 11:20:09
2022.10.03 11:34:43 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading lastseen with timestamp 2022-10-03 11:20:09, current reading timestamp is 2022-10-03 11:20:09
2022.10.03 11:34:43 4: parse status message for HUEDevice9
2022.10.03 11:34:43 4: parse status message for HUEDevice18
2022.10.03 11:34:43 4: parse status message for HUEDevice7
2022.10.03 11:34:43 4: parse status message for HUEDevice9
Beim Aktor, also die Steckdose hätte ich schon einen Reset durchgeführt und neu mit Phoscon App verbunden.
Bei deconz wüsste ich nicht, wo ich etwas konfigurieren könnte?
Wo sollte das sein?
Zitat von: Ruggy am 03 Oktober 2022, 11:36:10
Das sind die Eintragungen in der Logfile (hier ist schon die Logfile gemeint, welche ich links vom "Standart-FHEM" per link aufrufen kann?) vom ein bis zum ausschalten
Das ist komisch und sieht eher danach aus, als würde die HUEBridge auf einem erhöhten verbose-Level stehen. Was wie konfiguriert ist, sollte das hier zeigen:
list verbose=.+ verbose
(Und bitte verschone uns mit den Ergebnissen, stelle es einfach sinnvoll ein bzw. lösche es da, wo es keinen erkennbaren Grund mehr gibt).
Zitat
Bei deconz wüsste ich nicht, wo ich etwas konfigurieren könnte?
Wo sollte das sein?
Wenn, dann geht das nur über deconz-GUI. Im "firmware-update"-Thread wäre afaik zu finden, wie man das remote startet, aber wenn dir das alles nichts sagt, glaube ich nicht daran, dass du da versehentlich irgendwas konfiguriert hast, erst recht nicht, wenn du das Ding zurückgesetzt hast...
Zitat von: Beta-User am 03 Oktober 2022, 11:44:57
(Und bitte verschone uns mit den Ergebnissen, stelle es einfach sinnvoll ein bzw. lösche es da, wo es keinen erkennbaren Grund mehr gibt).
Sorry, falls ich hier nerve. Aber ich kenne mich leider zu wenig mit den Abläufen aus. Ich mache es auch nicht aus Absicht. Hänge nur schon sehr viele Stunden und Tage an dem Problem.
Deshalb bemühe ich das Forum. Hier ist doch geballtes Wissen und Erfahrung unterwegs. :(
Ich habe jetzt den Befehl eingegeben; ich weiß es jetzt. Aber hilft mir auch nicht weiter.
Die HUEBridge ist aber nicht dabei.
In deconz-GUI habe ich nichts verstellt.
Zitat von: Beta-User am 03 Oktober 2022, 11:24:40
Oder das Ding ist halt einfach kaputt...
Das werde ich jetzt nochmal mit einer dritten (habe es mit einer anderen nämlich schon versucht) Osram Smart+ versuchen.
Nachdem wir ja jetzt wissen dass es nicht deine Logik ist bleiben zwei Ursachen:
1. Das Ding ist defekt
2. Eine andere Logik grätscbt rein.
Vorschlag:
Benenne den Aktor um und schalte nochmal manuell.
Geht er wieder aus liegt es am aktor.
Bleibt er an hast noch irgendwo ne Logik versteckt die ihn abschaltet.
Ich vermute aber eher nen defekt...
Habe jetzt nochmal eine andere Steckdose genommen und mit der funktioniert es jetzt soweit. Hoffe, dass es so bleibt.
Vielen Dank @Beta-User, @MadMax-FHEM und @Frank_Huber für die ausdauernde Hilfe und Geduld
Sind die Meldungen von den Xiaomi Temperatursensor, welche durch Verbose 5 angezeigt werden Fehler, welche im Hintergrund etwas ausbremsen, oder kann ich einfach Verbose entfernen und gut ist es?
2022.10.03 13:30:43 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading humidity with timestamp 2022-10-03 12:43:33, current reading timestamp is 2022-10-03 12:43:33
Zitat von: Ruggy am 03 Oktober 2022, 13:36:01
Habe jetzt nochmal eine andere Steckdose genommen und mit der funktioniert es jetzt soweit. Hoffe, dass es so bleibt.
Wenn du mit 2 von der Sorte schon Probleme hattest, müßtest du ggf. mal schauen, ob es besser geeignete gäbe. Kann sein, dass das zu viel (Anlauf-) Strom zieht, was da dran hängt, und dann (zum Glück!) irgendeine Sicherheitsfunktion greift.
Zitat
Vielen Dank @Beta-User, @MadMax-FHEM und @Frank_Huber für die ausdauernde Hilfe und Geduld
:) Gerne.
Mancher kritische Unterton ist übrigens auch nicht böse gemeint, sondern z.B. das mit "verschone" war als "Schubs" gemeint, selbst anzuschauen, was da kommt und ggf. zu korrigieren ist.
Einfach das Ergebnis zeigen bringt uns nämlich nicht weiter. Anscheinend ist aber noch nicht klar, was es mit den verbose-Leveln auf sich hat. Schau mal in die Hilfe (commandref) dazu, dürfte bei global zu finden sein. Die meisten Maintainer nehmen in etwa das als Maßstab.
Zitat
Sind die Meldungen von den Xiaomi Temperatursensor, welche durch Verbose 5 angezeigt werden Fehler, welche im Hintergrund etwas ausbremsen, oder kann ich einfach Verbose entfernen und gut ist es?
2022.10.03 13:30:43 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading humidity with timestamp 2022-10-03 12:43:33, current reading timestamp is 2022-10-03 12:43:33
Es ist nämlich immer wieder irritierend, wenn zum wiederholten Mal gefragt wird, ob es eigentlich ein Problem ist, wenn verbose 4 oder 5 was ins Log schreibt. Ist es nicht, es ist eine Info zur Fehlersuche bzw. eine Hilfe um rauszufinden, wie ein Modul denn so hinter den Kulissen tickt...
Echte Probleme sind in der Regel verbose 2 oder kleiner!
[gelöst]?
Momentan bin ich etwas deprimiert.
Es geht nämlich jetzt schon wieder los. Es schaltet die andere Steckdose auch wieder von selber aus. :-\
Also muß es doch an etwas anderen liegen.
Evlt. hat der ConBee-Stick einen defekt?
Anscheinend wird aber an den ConBee I auch nicht mehr so viel entwickelt und es liegt an entwas anderen?
Zitat von: Beta-User am 03 Oktober 2022, 14:44:54
Mancher kritische Unterton ist übrigens auch nicht böse gemeint, sondern z.B. das mit "verschone" war als "Schubs" gemeint, selbst anzuschauen, was da kommt und ggf. zu korrigieren ist.
Kein Problem. Wobei ich es Euch manchmal nicht verübeln könnte ;)
Ich versuche schon, dass ich selber die Lösung finde. Oft bleibe ich aber an einen Detail hängen und frage lieber, bevor ich noch mehr kaputt mache.
Schon bei diesem Problem habe ich etliche Stunden verbracht und probiert und bin jetzt wieder nicht weiter.
Wahrscheinlich hätte es gar kein neues OS benötigt. Wobei ich jetzt schon froh bin, dass dieses jetzt mal wieder aktuell ist (auf diesen Raspberry zumindest... :-\)
Die Steckdose schaltet sich sogar automatisch aus, auch wenn ich sie manuell am Taster einschalte.
Vielleicht solltest du zum einen dann man den Thread-Titel ändern - mit der FHEM-Logik oder einem bestimmten Modul hat es dann wohl eher wenig zu tun, sondern eher damit, dass der von dir eingesetzte Aktor vielleicht einfach nicht für die Aufgabe gemacht ist, die du von ihm erwartest.
Wir wissen bisher noch nicht, welche Art Lüfter an dem Ding hängt, aber manche E-Motoren haben relativ hohe Anlaufströme - und das kann eben nicht jeder Aktor ab... Wenn das also eher was größeres ist, erhöht das die Wahrscheinlichkeit, dass das das Problem ist (oder vielleicht hat auch der Lüfter selbst einen Hau; sowas kann es auch geben).
Die Lüfter benötigen nicht viel Strom. Es sind zwei Lüfter, welche gleichzeitig einschalten. Insgesamt brauchen sie 50 Watt.
Habe jetzt anstatt der Osram Smart+ Plug Steckdose eine Shelly Plug1 verwendet. Dies funktioniert bisher.
Die Lüfterklappten vom Rohr bleiben vorerst immer geöffnet. Das Xiaomi Schaltrelais dafür ist abgeklemmt.
Dies ist ein Notbehelf, damit der Keller zumindest wieder belüftet wird.
Hab vor, einen Conbee II Stick bestellen. Evlt. liegt es ja an diesen?
Oder gibt es einen "besseren" für Zigbee?
Welcher Schaltaktor wäre zuverlässiger als der Xiaomi (benötige 2 Relais)?
Der Homematic 2fach Unterputz Schaltaktor?
Oder gäbe es eine zuverlässigere Methode (nur für die Schaltung für die Lüftung)?
Zitat von: Ruggy am 03 Oktober 2022, 19:05:34
Die Steckdose schaltet sich sogar automatisch aus, auch wenn ich sie manuell am Taster einschalte.
Habe mich mal selber Zitiert.
Wie es aussieht ist dies aber nur, wenn sie mit den Conbee verbunden sind. Habe die Steckdose länger vom Strom gehabt und mehrmals einen Reset durchgeführt. Danach hat sie sich bisher nicht mehr selber ausgeschaltet.
Den Thread-Titel ändere ich. Fällt nur auf die schnelle nicht ein, was aussagekräftig für das Problem ist.
Vor dem Reset-Test hätte man noch fhem stoppen können, also deCONZ weiterlaufen lassen und schalten...
Nicht, dass doch eine "unbekannte" /"vergessene" Logik in fhem die Ursache ist...
Gruß, Joachim
Zitat von: MadMax-FHEM am 04 Oktober 2022, 08:16:16
Vor dem Reset-Test hätte man noch fhem stoppen können, also deCONZ weiterlaufen lassen und schalten...
Nicht, dass doch eine "unbekannte" /"vergessene" Logik in fhem die Ursache ist...
Gruß, Joachim
Stimmt, das wäre noch eine gute Möglichkeit gewesen um bei dem Problem wieder etwas auszuschließen.
Kann es eine verstecke Logik geben?
Das automatische ausschalten war auch gegeben, als ich eine andere Steckdose (mit anderen Gerätenamen HUEDevice9 und HUEDevice11) verwendet hatte.
Ich habe den Thread-Titel geändert (welcher eigenlich schon länger nicht mehr zutrifft).
Ich hoffe er ist jetzt passender.
Anfangs ging ich nämlich davon aus, dass es evlt. mit einem DOIF zusammenhängt. Dies ist aber nicht der Fall.
An was es genau liegt, konnte bisher noch nicht geklärt werden.
OS ist mittlerweile neu aufgesetzt.
ConBee I hat das aktuellste Firmware und "Software" Update.
Evlt. ist aber der ConBee I Stick defekt (Hardware; Firmware)?
Oder an einen anderen "verstecken" Fehler.
Das Problem ist (kurz und ganz grob zusammengefasst), dass eine Osram Smart+ Plug Steckdose sich nach kurzer Zeit wieder automatisch ausschaltet, nachdem sie mit einen DOIF eingeschaltet wurde.
Das selbe geschieht aber auch, wenn ich die Steckdose manuell am Taster oder mit set HUEDevice9 on
einschalte.
(soweit ich es bisher feststellen konnte, ist dieses Schaltverhalten, nur wenn die Steckdose am ConBee angelernt ist)
Wie das DOIF ablaufen sollte ist in Beitrag #24 nochmal gezeigt. Ist aber bei dem Problem wahscheinlich nicht die Ursache.
Zitat von: Ruggy am 04 Oktober 2022, 08:12:46
Die Lüfter benötigen nicht viel Strom. Es sind zwei Lüfter, welche gleichzeitig einschalten. Insgesamt brauchen sie 50 Watt.
Die absolute Leistungsaufnahme ist uU. gar nicht das Problem, aber wie groß die "induktive Last" von deinen Lüftern sein kann, kann ich nicht beurteilen, ebensowenig, ob da sonst irgendwas komisches an Elektrosmog mit reinspielen könnte.
Zitat
Habe jetzt anstatt der Osram Smart+ Plug Steckdose eine Shelly Plug1 verwendet. Dies funktioniert bisher.
Das klingt danach, als wäre es ein spezifisches Problem dieser anderen Dosen.
Zitat
Die Lüfterklappten vom Rohr bleiben vorerst immer geöffnet. Das Xiaomi Schaltrelais dafür ist abgeklemmt.
Welcher Schaltaktor wäre zuverlässiger als der Xiaomi (benötige 2 Relais)?
Da der bei dir ja anscheinden zuverlässig funktioniert hat, würde ich den schlicht wieder anklemmen...
ZitatHab vor, einen Conbee II Stick bestellen. Evlt. liegt es ja an diesen?
An ein Problem des Hardwareinterfaces mag ich nicht recht glauben. Wenn der Conbee I sonst mit allem klarkommt, liegt da vermutlich nicht die Ursache, sondern eben irgendwo in der dahinterliegenden Logik, also deconz oder FHEM.
Evlt. doch ein "Logikproblem"?
Jetzt habe ich mal wieder Zeit gehabt mich damit zu beschäftigen und gesehen, dass es mit dem Shelly_Plug_1 auch nicht funktioniert.
Also kann es nicht am DeConz liegen.
Ich meine etwas gefunden zu haben, dass es evtl. doch mit einer bestimmten "Logik" zusammenhängt. Diese verstehe ich aber nicht ganz, wenn es daran liegen sollte.
Ich habe ja für die Lüftungssteuerung vier bzw. fünf DOIF für die verschiedenen Gegebenheiten. Der Gedanke dahinter ist, dass der Keller im Sommer nicht zu warm und im Winter nicht zu kalt wird und eine "Zwangslüftung, dass zumindest die Luft zweimal am Tag ausgetauscht wird.
TAUPUNKT_LUEFTUNG_KALT, TAUPUNKT_LUEFTUNG_NORMAL, TAUPUNKT_LUEFTUNG_WARM, TAUPUNKT_LUEFTUNG_WINTER sowie eine KELLER_ZWANGSLUEFTUNG
Für Testzwecke habe ich nur das DOIF Shelly_Plug_1 im DOIF TAUPUNKT_LUEFTUNG_WARM geändert, weil es wegen den Bedingungen das aktuell zutreffende ist (Kellertemperatur).
Wenn ich jetzt die Shelly_Plug_1 im eigenen Device mit "on" einschalte, schaltet sich diese auch wieder automatisch ab. Wenn ich das DOIF TAUPUNKT_LUEFTUNG_WARM deaktiviere, schaltet sich die Shelly_Plug_1 nicht aus.
Also ist es wahrscheinlich so, dass das DOIF (so wie ich es angelegt habe) abgearbeitet wird und dann die Shelly_Plug_1 abschaltet, auch wenn die Bedingungen nicht erfüllt sind, durch das
DOELSE (set myShelly_Plug_1 off
im DOIF.
Kann dies der Fehler sein?
Als weiteren Test habe ich jetzt die ursprüngliche Steckdose über deConz (HUEDevice11) eingeschaltet und alle DOIF, welche sich darauf beziehen deaktiviert (TAUPUNKT_LUEFTUNG_KALT, TAUPUNKT_LUEFTUNG_NORMAL, TAUPUNKT_LUEFTUNG_WINTER).
Jetzt bleibt die Steckdose an und schaltet sich nicht automatisch aus.
Wenn ich jetzt eins von diesen DOIF aktiviere, dauert es nicht lange und die Steckdose schaltet sich automatisch aus.
Liegt es hier auch wieder an dem
DOELSE (set HUEDevice11 off
im DOIF?
Falls dies der Fehler ist, wie kann ich diesen beseitigen?
Würde es reichen, wenn ich das DOELSE (set HUEDevice11 off
einfach weg lasse?
Also, wenn die Bedingungen zutreffen, soll es ausgeführt werden, ansonsten soll nichts gemacht werden.
Hier ein List vom TAUPUNKT_LUEFTUNG_WARM (für die Shelly)
Internals:
DEF ([deltadewpoint:state]>3.4 and [KEL_LUFTFEUCHTIGKEIT:temperature]>=12 and [AUS_LUFTFEUCHTIGKEIT:temperature]<[KEL_LUFTFEUCHTIGKEIT:temperature])(set HUEDevice18 on-for-timer 17)(set myShelly_Plug_1 on-for-timer 2700)(set HUEDevice7 on-for-timer 17) DOELSE (set myShelly_Plug_1 off)
FUUID 6060f068-f33f-f59f-7b67-d2e5224f86ac0104
MODEL FHEM
NAME TAUPUNKT_LUEFTUNG_WARM
NOTIFYDEV deltadewpoint,KEL_LUFTFEUCHTIGKEIT,AUS_LUFTFEUCHTIGKEIT,global
NR 102
NTFY_ORDER 50-TAUPUNKT_LUEFTUNG_WARM
STATE cmd_2
TYPE DOIF
VERSION 26444 2022-09-25 16:29:19
eventCount 14570
Helper:
DBLOG:
state:
DbLog:
TIME 1665909679.56718
VALUE cmd_2
READINGS:
2022-10-16 10:41:19 Device AUS_LUFTFEUCHTIGKEIT
2022-10-16 10:41:19 cmd 2
2022-10-16 10:41:19 cmd_event AUS_LUFTFEUCHTIGKEIT
2022-10-16 10:41:19 cmd_nr 2
2022-10-16 10:41:19 e_AUS_LUFTFEUCHTIGKEIT_temperature 14.88
2022-10-16 10:41:19 e_KEL_LUFTFEUCHTIGKEIT_temperature 12.8
2022-10-16 10:35:39 e_deltadewpoint_state -1.7
2022-10-15 23:34:15 mode enabled
2022-10-16 10:41:19 state cmd_2
2022-10-13 23:33:20 wait_timer no timer
Regex:
accu:
collect:
cond:
AUS_LUFTFEUCHTIGKEIT:
0:
temperature ^AUS_LUFTFEUCHTIGKEIT$:^temperature:
KEL_LUFTFEUCHTIGKEIT:
0:
temperature ^KEL_LUFTFEUCHTIGKEIT$:^temperature:
deltadewpoint:
0:
state ^deltadewpoint$:^state:
attr:
cmdState:
repeatcmd:
3000
wait:
0:
0
20
2720
1:
0
waitdel:
condition:
0 ::ReadingValDoIf($hash,'deltadewpoint','state')>3.4 and ::ReadingValDoIf($hash,'KEL_LUFTFEUCHTIGKEIT','temperature')>=12 and ::ReadingValDoIf($hash,'AUS_LUFTFEUCHTIGKEIT','temperature')<::ReadingValDoIf($hash,'KEL_LUFTFEUCHTIGKEIT','temperature')
do:
0:
0 set HUEDevice18 on-for-timer 17
1 set myShelly_Plug_1 on-for-timer 2700
2 set HUEDevice7 on-for-timer 17
1:
0 set myShelly_Plug_1 off
helper:
NOTIFYDEV deltadewpoint,KEL_LUFTFEUCHTIGKEIT,AUS_LUFTFEUCHTIGKEIT,global
event temperature: 14.88
globalinit 1
last_timer 0
sleepdevice deltadewpoint
sleepsubtimer 0
sleeptimer -1
timerdev AUS_LUFTFEUCHTIGKEIT
timerevent temperature: 14.88
triggerDev AUS_LUFTFEUCHTIGKEIT
DOIF_eventa:
cmd_nr: 2
cmd: 2
cmd_event: AUS_LUFTFEUCHTIGKEIT
cmd_2
DOIF_eventas:
cmd_nr: 2
cmd: 2
cmd_event: AUS_LUFTFEUCHTIGKEIT
state: cmd_2
bm:
DOIF_Get:
cnt 23
dmx -1000
dtot 0
dtotcnt 0
mTS 15.10. 22:43:06
max 0.00181698799133301
tot 0.00249385833740234
mAr:
HASH(0x34b73a8)
TAUPUNKT_LUEFTUNG_WARM
?
DOIF_Notify:
cnt 21657
dmx -1000
dtot 0
dtotcnt 0
mTS 15.10. 03:25:35
max 0.386093139648438
tot 792.957351922989
mAr:
HASH(0x34b73a8)
HASH(0x35af1f8)
DOIF_Set:
cnt 1416
dmx -1000
dtot 0
dtotcnt 0
mTS 15.10. 22:45:27
max 0.0307021141052246
tot 0.264838457107544
mAr:
HASH(0x34b73a8)
TAUPUNKT_LUEFTUNG_WARM
?
timerevents:
temperature: 14.88
timereventsState:
temperature: 14.88
triggerEvents:
temperature: 14.88
triggerEventsState:
temperature: 14.88
internals:
perlblock:
readings:
all deltadewpoint:state KEL_LUFTFEUCHTIGKEIT:temperature AUS_LUFTFEUCHTIGKEIT:temperature
trigger:
uiState:
uiTable:
Attributes:
do always
repeatcmd 3000
room Kellerlüftung
wait 0,20,2720:0
List vom TAUPUNKT_LUEFTUNG_NORMAL (für die deConz)
Internals:
DEF ([deltadewpoint:state]>3.1 and
[KEL_LUFTFEUCHTIGKEIT:temperature]>10 and
[KEL_LUFTFEUCHTIGKEIT:temperature]<12)
(set HUEDevice18 on-for-timer 17)
(set HUEDevice11 on-for-timer 1200)
(set HUEDevice7 on-for-timer 17)
DOELSE
(set HUEDevice11 off)
FUUID 6060ee07-f33f-f59f-9eb7-12b1002aa68bffa8
MODEL FHEM
NAME TAUPUNKT_LUEFTUNG_NORMAL
NOTIFYDEV KEL_LUFTFEUCHTIGKEIT,global,deltadewpoint
NR 100
NTFY_ORDER 50-TAUPUNKT_LUEFTUNG_NORMAL
STATE cmd_2
TYPE DOIF
VERSION 26444 2022-09-25 16:29:19
eventCount 11048
Helper:
DBLOG:
state:
DbLog:
TIME 1665909679.34347
VALUE cmd_2
READINGS:
2022-10-16 10:41:19 Device KEL_LUFTFEUCHTIGKEIT
2022-10-16 10:41:19 cmd 2
2022-10-16 10:41:19 cmd_event KEL_LUFTFEUCHTIGKEIT
2022-10-16 10:41:19 cmd_nr 2
2022-10-16 10:41:19 e_KEL_LUFTFEUCHTIGKEIT_temperature 12.8
2022-10-16 10:35:39 e_deltadewpoint_state -1.7
2022-10-15 23:33:40 mode enabled
2022-10-16 10:41:19 state cmd_2
Regex:
accu:
collect:
cond:
KEL_LUFTFEUCHTIGKEIT:
0:
temperature ^KEL_LUFTFEUCHTIGKEIT$:^temperature:
deltadewpoint:
0:
state ^deltadewpoint$:^state:
attr:
cmdState:
repeatcmd:
4800
wait:
0:
0
20
1220
1:
0
waitdel:
condition:
0 ::ReadingValDoIf($hash,'deltadewpoint','state')>3.1 and ::ReadingValDoIf($hash,'KEL_LUFTFEUCHTIGKEIT','temperature')>10 and ::ReadingValDoIf($hash,'KEL_LUFTFEUCHTIGKEIT','temperature')<12
do:
0:
0 set HUEDevice18 on-for-timer 17
1 set HUEDevice11 on-for-timer 1200
2 set HUEDevice7 on-for-timer 17
1:
0 set HUEDevice11 off
helper:
NOTIFYDEV KEL_LUFTFEUCHTIGKEIT,global,deltadewpoint
event temperature: 12.8
globalinit 1
last_timer 0
sleeptimer -1
timerdev KEL_LUFTFEUCHTIGKEIT
timerevent temperature: 12.8
triggerDev KEL_LUFTFEUCHTIGKEIT
DOIF_eventa:
cmd_nr: 2
cmd: 2
cmd_event: KEL_LUFTFEUCHTIGKEIT
cmd_2
DOIF_eventas:
cmd_nr: 2
cmd: 2
cmd_event: KEL_LUFTFEUCHTIGKEIT
state: cmd_2
bm:
DOIF_Get:
cnt 8
dmx -1000
dtot 0
dtotcnt 0
mTS 16.10. 10:41:54
max 9.58442687988281e-05
tot 0.000302553176879883
mAr:
HASH(0x3786420)
TAUPUNKT_LUEFTUNG_NORMAL
?
DOIF_Notify:
cnt 11095
dmx -1000
dtot 0
dtotcnt 0
mTS 15.10. 13:38:18
max 0.296895027160645
tot 235.467659235001
mAr:
HASH(0x3786420)
HASH(0x2c5b858)
DOIF_Set:
cnt 757
dmx -1000
dtot 0
dtotcnt 0
mTS 15.10. 23:30:15
max 0.0243158340454102
tot 0.120814085006714
mAr:
HASH(0x3786420)
TAUPUNKT_LUEFTUNG_NORMAL
disable
timerevents:
temperature: 12.8
timereventsState:
temperature: 12.8
triggerEvents:
temperature: 12.8
triggerEventsState:
temperature: 12.8
internals:
perlblock:
readings:
all deltadewpoint:state KEL_LUFTFEUCHTIGKEIT:temperature
trigger:
uiState:
uiTable:
Attributes:
do always
repeatcmd 4800
room Kellerlüftung
wait 0,20,1220:0
Leider funktioniert es immer noch nicht so wie es soll. Auf meine letzte Frage habe ich noch keine Antwort erhalten.
Wahrscheinlich habe ich zu viel geschrieben und es ist zu unübesichtlich geworten.
Wie ich geschrieben habe, könnte es sein, dass es doch ein Logikproblem innerhalt FHEM ist.
Ich versuche nur einen Teil der "Schaltung" mal zu zeigen, damit es evlt. etwas übersichtlicher wird.
Derzeit wird aufgrund der verschiedenen Temperaturen, das Notifi "TAUPUNKT_LUEFTUNG_WARM" aktiv.
Internals:
DEF ([deltadewpoint:state]>3.4 and [KEL_LUFTFEUCHTIGKEIT:temperature]>=12 and [AUS_LUFTFEUCHTIGKEIT:temperature]<[KEL_LUFTFEUCHTIGKEIT:temperature])(set HUEDevice18 on-for-timer 17)(set myShelly_Plug_1 on-for-timer 2700)(set HUEDevice7 on-for-timer 17) DOELSE (set myShelly_Plug_1 off)
FUUID 6060f068-f33f-f59f-7b67-d2e5224f86ac0104
MODEL FHEM
NAME TAUPUNKT_LUEFTUNG_WARM
NOTIFYDEV global,AUS_LUFTFEUCHTIGKEIT,deltadewpoint,KEL_LUFTFEUCHTIGKEIT
NR 101
NTFY_ORDER 50-TAUPUNKT_LUEFTUNG_WARM
STATE cmd_1_2
TYPE DOIF
VERSION 26444 2022-09-25 16:29:19
eventCount 11706
Helper:
DBLOG:
state:
DbLog:
TIME 1668286199.71869
VALUE cmd_1_2
READINGS:
2022-11-12 22:25:31 Device AUS_LUFTFEUCHTIGKEIT
2022-11-12 21:49:59 cmd 1.2
2022-11-12 21:49:59 cmd_event deltadewpoint
2022-11-12 21:49:59 cmd_nr 1
2022-11-12 21:49:59 cmd_seqnr 2
2022-11-12 22:25:31 e_AUS_LUFTFEUCHTIGKEIT_temperature 1.59
2022-11-12 22:25:30 e_KEL_LUFTFEUCHTIGKEIT_temperature 12.03
2022-11-12 22:14:05 e_deltadewpoint_state 10.4
2022-10-22 17:52:03 mode enabled
2022-11-12 21:49:59 state cmd_1_2
2022-11-12 21:49:59 wait_timer 12.11.2022 22:35:19 cmd_1_3 deltadewpoint
Regex:
accu:
collect:
cond:
AUS_LUFTFEUCHTIGKEIT:
0:
temperature ^AUS_LUFTFEUCHTIGKEIT$:^temperature:
KEL_LUFTFEUCHTIGKEIT:
0:
temperature ^KEL_LUFTFEUCHTIGKEIT$:^temperature:
deltadewpoint:
0:
state ^deltadewpoint$:^state:
attr:
cmdState:
repeatcmd:
3000
wait:
0:
0
20
2720
1:
0
waitdel:
condition:
0 ::ReadingValDoIf($hash,'deltadewpoint','state')>3.4 and ::ReadingValDoIf($hash,'KEL_LUFTFEUCHTIGKEIT','temperature')>=12 and ::ReadingValDoIf($hash,'AUS_LUFTFEUCHTIGKEIT','temperature')<::ReadingValDoIf($hash,'KEL_LUFTFEUCHTIGKEIT','temperature')
do:
0:
0 set HUEDevice18 on-for-timer 17
1 set myShelly_Plug_1 on-for-timer 2700
2 set HUEDevice7 on-for-timer 17
1:
0 set myShelly_Plug_1 off
helper:
NOTIFYDEV global,AUS_LUFTFEUCHTIGKEIT,deltadewpoint,KEL_LUFTFEUCHTIGKEIT
event temperature: 1.59
globalinit 1
last_timer 0
sleepdevice deltadewpoint
sleepsubtimer 2
sleeptimer 0
timerdev AUS_LUFTFEUCHTIGKEIT
timerevent temperature: 1.59
triggerDev AUS_LUFTFEUCHTIGKEIT
bm:
DOIF_Get:
cnt 11
dmx -1000
dtot 0
dtotcnt 0
mTS 12.11. 22:20:49
max 0.000114202499389648
tot 0.000474691390991211
mAr:
HASH(0x3fed4b8)
TAUPUNKT_LUEFTUNG_WARM
?
DOIF_Notify:
cnt 21467
dmx -1000
dtot 0
dtotcnt 0
mTS 08.11. 12:39:21
max 0.677268981933594
tot 640.038106918335
mAr:
HASH(0x3fed4b8)
HASH(0x384a180)
DOIF_Set:
cnt 75
dmx -1000
dtot 0
dtotcnt 0
mTS 12.11. 22:26:20
max 0.000576019287109375
tot 0.00722551345825195
mAr:
HASH(0x3fed4b8)
TAUPUNKT_LUEFTUNG_WARM
?
timerevents:
temperature: 1.59
timereventsState:
temperature: 1.59
triggerEvents:
temperature: 1.59
triggerEventsState:
temperature: 1.59
internals:
perlblock:
readings:
all deltadewpoint:state KEL_LUFTFEUCHTIGKEIT:temperature AUS_LUFTFEUCHTIGKEIT:temperature
trigger:
uiState:
uiTable:
Attributes:
do always
repeatcmd 3000
room Kellerlüftung
wait 0,20,2720:0
Dieses schaltet den Lüfter richtigerweise ein. Dieser läuft aber nicht wie im notifi vorgegebene Zeit von 1200 Sekunden, sondern schaltet nach ein paar Sekunden automatisch wieder aus (derzeit ist eine Shelly Steckdose dran; also lage es anscheinden nicht am Osram smart plus).
Die Temperatur im Keller hat derzeit 12,03 Grad. Jedoch wird es während dem kurzen lüften nicht unter 12 Grad.
Also an der Grenze an dem dieses notify noch zuständig ist. Danach käme das notify "TAUPUNKT_LUEFTUNG_NORMAL" in Frage.
Kann es sein, dass das
DOELSE (set myShelly_Plug_1 off)
im gerade nicht zuständigen notify (z.B. das "TAUPUNKT_LUEFTUNG_NORMAL"), das laufende notify ausschaltet?
Internals:
DEF ([deltadewpoint:state]>3.1 and [KEL_LUFTFEUCHTIGKEIT:temperature]>10 and [KEL_LUFTFEUCHTIGKEIT:temperature]<12)(set HUEDevice18 on-for-timer 17)(set myShelly_Plug_1 on-for-timer 1200)(set HUEDevice7 on-for-timer 17) DOELSE (set myShelly_Plug_1 off)
FUUID 6060ee07-f33f-f59f-9eb7-12b1002aa68bffa8
MODEL FHEM
NAME TAUPUNKT_LUEFTUNG_NORMAL
NOTIFYDEV KEL_LUFTFEUCHTIGKEIT,global,deltadewpoint
NR 99
NTFY_ORDER 50-TAUPUNKT_LUEFTUNG_NORMAL
STATE cmd_2
TYPE DOIF
VERSION 26444 2022-09-25 16:29:19
eventCount 7725
Helper:
DBLOG:
state:
DbLog:
TIME 1668288510.75713
VALUE cmd_2
READINGS:
2022-11-12 22:28:30 Device KEL_LUFTFEUCHTIGKEIT
2022-11-12 22:28:30 cmd 2
2022-11-12 22:28:30 cmd_event KEL_LUFTFEUCHTIGKEIT
2022-11-12 22:28:30 cmd_nr 2
2022-11-12 22:28:30 e_KEL_LUFTFEUCHTIGKEIT_temperature 12.03
2022-11-12 22:14:05 e_deltadewpoint_state 10.4
2022-11-12 21:44:45 mode enabled
2022-11-12 22:28:30 state cmd_2
Regex:
accu:
collect:
cond:
KEL_LUFTFEUCHTIGKEIT:
0:
temperature ^KEL_LUFTFEUCHTIGKEIT$:^temperature:
deltadewpoint:
0:
state ^deltadewpoint$:^state:
attr:
cmdState:
repeatcmd:
4800
wait:
0:
0
20
1220
1:
0
waitdel:
condition:
0 ::ReadingValDoIf($hash,'deltadewpoint','state')>3.1 and ::ReadingValDoIf($hash,'KEL_LUFTFEUCHTIGKEIT','temperature')>10 and ::ReadingValDoIf($hash,'KEL_LUFTFEUCHTIGKEIT','temperature')<12
do:
0:
0 set HUEDevice18 on-for-timer 17
1 set myShelly_Plug_1 on-for-timer 1200
2 set HUEDevice7 on-for-timer 17
1:
0 set myShelly_Plug_1 off
helper:
NOTIFYDEV KEL_LUFTFEUCHTIGKEIT,global,deltadewpoint
event temperature: 12.03
globalinit 1
last_timer 0
sleeptimer -1
timerdev KEL_LUFTFEUCHTIGKEIT
timerevent temperature: 12.03
triggerDev KEL_LUFTFEUCHTIGKEIT
DOIF_eventa:
cmd_nr: 2
cmd: 2
cmd_event: KEL_LUFTFEUCHTIGKEIT
cmd_2
DOIF_eventas:
cmd_nr: 2
cmd: 2
cmd_event: KEL_LUFTFEUCHTIGKEIT
state: cmd_2
bm:
DOIF_Get:
cnt 1
dmx -1000
dtot 0
dtotcnt 0
mTS 12.11. 22:20:57
max 0.0001220703125
tot 0.0001220703125
mAr:
HASH(0x415d7b0)
TAUPUNKT_LUEFTUNG_NORMAL
?
DOIF_Notify:
cnt 49
dmx -1000
dtot 0
dtotcnt 0
mTS 12.11. 21:57:31
max 0.466669082641602
tot 3.30851268768311
mAr:
HASH(0x415d7b0)
HASH(0x3695758)
DOIF_Set:
cnt 53
dmx -1000
dtot 0
dtotcnt 0
mTS 12.11. 22:20:57
max 0.000663042068481445
tot 0.00517725944519043
mAr:
HASH(0x415d7b0)
TAUPUNKT_LUEFTUNG_NORMAL
?
timerevents:
temperature: 12.03
timereventsState:
temperature: 12.03
triggerEvents:
temperature: 12.03
triggerEventsState:
temperature: 12.03
internals:
readings:
all deltadewpoint:state KEL_LUFTFEUCHTIGKEIT:temperature
trigger:
uiState:
uiTable:
Attributes:
do always
repeatcmd 4800
room Kellerlüftung
wait 0,20,1220:0
Ebenso passiert es nämlich auch, wenn ich die myShelly_Plug_1 in FHEM manuel auf on schalte.
Sorry, jetzt habe ich schon wieder mehr geschrieben, als ich vorgehabt hätte.
Der Auslöser ist die Kelller-Temperatur
2022-11-12 22:28:30 cmd_nr 2
2022-11-12 22:28:30 e_KEL_LUFTFEUCHTIGKEIT_temperature 12.03
und in diesem Augenblick ist entweder
[deltadewpoint:state]>3.4
oder
[AUS_LUFTFEUCHTIGKEIT:temperature]<[KEL_LUFTFEUCHTIGKEIT:temperature
nicht wahr.
Damit ist der ganze Ausdruck nicht wahr und der Off-Befehl schlägt zu.
Wenn das nicht so wäre, dann wäre Perl kaputt ;)
[deltadewpoint:state]>3.4
ist wahr, weil dewpoint derzeit 10.4 hat
[AUS_LUFTFEUCHTIGKEIT:temperature]<[KEL_LUFTFEUCHTIGKEIT:temperature
ist auch wahr, weil Außentemperatur momentan 1.9 und Kellertemperatur derzeit 12.04 hat
1.9 < 12.04
Dies würde doch auch zutreffen. Die Temperatur liegt knapp über 12
[KEL_LUFTFEUCHTIGKEIT:temperature]>=12
Also müsste doch beides wahr sein und somit dürfte in diesem notify der Off Befehl nicht ausgeführt werden.
Oder habe ich das falsch verstanden?
ja, der Auszug
2022-11-12 22:28:30 cmd_nr 2
2022-11-12 22:28:30 e_KEL_LUFTFEUCHTIGKEIT_temperature 12.03
war aus dem zweiten DOIF, da war es dann eben
[deltadewpoint:state]>3.1 and [KEL_LUFTFEUCHTIGKEIT:temperature]>10 and [KEL_LUFTFEUCHTIGKEIT:temperature]<12
Ist es dann so, wie ich es jetzt vermutet habe (habe das Problem schon etwas länger und komme nicht dahinter), dass momentan das zweite DOIF das erste DOIF (was ja eigenlich von den Bedingungen das richtige wäre) ausschaltet, weil dessen Bedingungen nicht erfüllt sind?
Wie kann ich es aber machen, dass das zweite das erste nicht beeinflusst?
Derzeit sollte das erste DOIF ablaufen und nicht vom zweiten ausgeschaltet werden.
Was ist wenn ich das
DOELSE (set myShelly_Plug_1 off)
im DOIF bei allen Notifi weg lasse?
Also wenn die Bedingung zutrifft sollen die Befehle ausgeführt werden, wenn nicht, dann soll nichts gemacht werden.
Aber ohne DOELSE ist es ja kein komplettes DOIF.
Du hast zwei DOIFs definiert, die nichts von einander wissen, aber das gleich Device schalten. Und dann wunderst du dich?
Die Logik musst du entweder in ein DOIF verpacken oder die Zustände des einen DOIFs im anderen abfragen.
Es kommt noch schlimmer, ich habe insgesamt vier bzw. fünf DOIF, welche das selbe Device schalten.
:-[
Diese DOIF gibt es, damit der Keller im Winter nicht auskühlt und im Sommer nicht zu warm wird.
Außerdem gibt es ein DOIF für eine "Zwangslüftung", damit der Keller zumindest belüftet wird, falls aufgrund den Verhältnissen der Luftfeuchtigkeit und Temperatur sonst der Keller länger nicht belüftet würde.
TAUPUNKT_LUEFTUNG_KALT:
([deltadewpoint:state]>2.3 and [KEL_LUFTFEUCHTIGKEIT:temperature]>8.5 and [KEL_LUFTFEUCHTIGKEIT:temperature]<=10)(set HUEDevice18 on-for-timer 17)(set myShelly_Plug_1 on-for-timer 900)(set HUEDevice7 on-for-timer 17) DOELSE (set myShelly_Plug_1 off)
TAUPUNKT_LUEFTUNG_NORMAL:
([deltadewpoint:state]>3.1 and [KEL_LUFTFEUCHTIGKEIT:temperature]>10 and [KEL_LUFTFEUCHTIGKEIT:temperature]<12)(set HUEDevice18 on-for-timer 17)(set myShelly_Plug_1 on-for-timer 1200)(set HUEDevice7 on-for-timer 17) DOELSE (set myShelly_Plug_1 off)
TAUPUNKT_LUEFTUNG_WARM:
([deltadewpoint:state]>3.4 and [KEL_LUFTFEUCHTIGKEIT:temperature]>=12 and [AUS_LUFTFEUCHTIGKEIT:temperature]<[KEL_LUFTFEUCHTIGKEIT:temperature])(set HUEDevice18 on-for-timer 17)(set myShelly_Plug_1 on-for-timer 2700)(set HUEDevice7 on-for-timer 17) DOELSE (set myShelly_Plug_1 off)
TAUPUNKT_LUEFTUNG_WINTER:
([deltadewpoint:state]>2.3 and [KEL_LUFTFEUCHTIGKEIT:temperature]<=8.5 and [AUS_LUFTFEUCHTIGKEIT:temperature]>[KEL_LUFTFEUCHTIGKEIT:temperature])(set HUEDevice18 on-for-timer 17)(set myShelly_Plug_1 on-for-timer 480)(set HUEDevice7 on-for-timer 17) DOELSE (set myShelly_Plug_1 off)
KELLER_ZWANGSLUEFTUNG:
([04:00] or [11:00])(set HUEDevice18 on-for-timer 17)(set myShelly_Plug_1 on-for-timer 900) (set HUEDevice7 on-for-timer 17) DOELSE (set myShelly_Plug_1 off)
Leider kenne ich mich nicht so gut aus.
Deshalb ist dieser Thread auch schon vier Seiten lang und es konnte der Fehler bisher noch nicht so richtig gefunden werden.
Und war der Verzweiflung schon ziemlich nahe. ::)
Habe auch schon gedacht, dass es an der Steckdose liegt und diese ausgetauscht und sogar Raspberry und FHEM komplett neu installiert.
Aber ich freund mich, dass ich jetzt zumindest den Grund weiß.
Wie ich es lösen kann habe ich aber bisher noch keine so richtige Idee.
Wie stelle ich es jetzt am geschicktesten an?
Alles auf ein DOIF zusammenfassen? Geht das mit so vielen Bedingungen?
Wie kann ich die Zustände der anderen DOIFs abfragen?
Zitat von: Ruggy am 13 November 2022, 00:22:27
Wie stelle ich es jetzt am geschicktesten an?
Alles auf ein DOIF zusammenfassen? Geht das mit so vielen Bedingungen?
Wie kann ich die Zustände der anderen DOIFs abfragen?
Wie man Readings abfragt, weißt du ja. DOIFs haben ja das cmd oder cmd_nr-Reading, dort findest du den aktuellen Zustand. Alternativ müssen die einzelnen DOIFs nicht das Device schalten, sondern einen Dummy oder setzen ein Reading im DOIF und ein zentrales DOIF entscheidet dann, was tatsächlich zu tun ist.
Über eine mögliche Zusammenfassung der DOIFs musst du dir schon selbst Gedanken machen. Ein DOIF im FHEM-Modus führt bei einem Event immer nur einen Zweig aus und niemals mehrere, das kann DOIF im Perlmodus.