[archetype] - support Thread ab 2022

[Beta-User]

Mein Plan wäre, das im Fall, dass die kommenden Tage keine Probleme mehr auftauchen, dann bei Gelegenheit mal einzuchecken.

Done!

[Florian_GT]

Hallo,

leider bin ich eine der Personen, die diese Warnung erst nach dem Update gelesen hat. Jetzt funktioniert bei mir natürlich (aufgrund intensiver Nutzung des Modules) ein Großteil meiner Devices nicht mehr. Ich habe die neue Command Ref überflogen, kann jedoch nicht sehen was sich nun konkret geändert hat, und warum meine Konfiguration nicht mehr funktioniert.

Hier ein Beispiel:

Code Auswählen Erweitern


define dev_tasmota_rgbww_1192 MQTT2_DEVICE
attr dev_tasmota_rgbww_1192 archetypeFilter TASMOTA-RGBWW
attr dev_tasmota_rgbww_1192 alias RGBW - Licht - Wohnzimmer - Fenster - rechts
attr dev_tasmota_rgbww_1192 room Wohnzimmer
attr dev_tasmota_rgbww_1192 group Global-RGB
attr dev_tasmota_rgbww_1192 deviceID 1192

define dev_tasmota_rgbww_0111 MQTT2_DEVICE
attr dev_tasmota_rgbww_0111 archetypeFilter TASMOTA-RGBWW
attr dev_tasmota_rgbww_0111 alias RGBW - Licht - Wohnzimmer - Fenster - links
attr dev_tasmota_rgbww_0111 room Wohnzimmer
attr dev_tasmota_rgbww_0111 group Global-RGB
attr dev_tasmota_rgbww_0111 deviceID 0111


##################
# EXAMPLE - RGBW #
##################
define archetype_tasmota_rgbw archetype TYPE=MQTT2_DEVICE:FILTER=archetypeFilter=TASMOTA-RGBW
attr archetype_tasmota_rgbw userattr userattr readingsWatcher stateFormat IODev DbLogExclude DbLogInclude devStateIcon event-min-interval event-on-change-reading group icon jsonMap lightSceneParamsToSave retain setList readingList useSetExtensions webCmd widgetOverride setStateList userReadings
attr archetype_tasmota_rgbw IODev mqtt2server
attr archetype_tasmota_rgbw devStateIcon {\
  if(ReadingsVal("$name","White","error") eq "0"){\
    sprintf('1.online:WLAN_Status.1@green 1.Online:WLAN_Status.1@green 1.offline:WLAN_Status.0@red 1.Offline:WLAN_Status.0@red' . "\n" . '2.' . "%s", Color::devStateIcon($name,"rgb","RGBColor","Dimmer","state"));;;;\
  }else{\
    sprintf('1.online:WLAN_Status.1@green 1.Online:WLAN_Status.1@green 1.offline:WLAN_Status.0@red 1.Offline:WLAN_Status.0@red' . "\n" . '2.' . "%s", Color::devStateIcon($name,"dimmer","","White","state"));;;;\
  }\
}
attr archetype_tasmota_rgbw event-min-interval (ENERGY.*|POWER|Vcc|Wifi_RSSI|state|precence|sensor|setup|result):1800
attr archetype_tasmota_rgbw event-on-change-reading (ENERGY.*|POWER|Vcc|Wifi_RSSI|state|precence|sensor|setup|result)
attr archetype_tasmota_rgbw DbLogInclude state
attr archetype_tasmota_rgbw group RGB-Einzeln
attr archetype_tasmota_rgbw icon light_led_stripe_rgb
attr archetype_tasmota_rgbw jsonMap POWER:state
attr archetype_tasmota_rgbw lightSceneParamsToSave {if(ReadingsVal($DEVICE,"state","error") eq "ON"){if(ReadingsVal($DEVICE, "White", "error") eq "0"){"RGBColor,Dimmer"}else{"White"}}else{"state"}}
attr archetype_tasmota_rgbw retain 1
attr archetype_tasmota_rgbw actual_setList\
  OFF:noArg /gosund_%deviceID%/cmnd/POWER 0\
  ON:noArg /gosund_%deviceID%/cmnd/POWER 1\
  RGBColor:colorpicker,RGB /gosund_%deviceID%/cmnd/Color2\
  Dimmer:colorpicker,BRI,0,5,80 /gosund_%deviceID%/cmnd/Dimmer\
  White:colorpicker,BRI,0,5,80 /gosund_%deviceID%/cmnd/White\
  Fade:0 /gosund_%deviceID%/cmnd/Fade 0\
  Fade:1 /gosund_%deviceID%/cmnd/Fade 1\
  Speed:1-10 /gosund_%deviceID%/cmnd/Speed
attr archetype_tasmota_rgbw actual_readingList \
  /gosund_%deviceID%/tele/LWT:.* precence\
  /gosund_%deviceID%/tele/STATUS(2|5|11):.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /gosund_%deviceID%/tele/INFO(1|2|3):.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /gosund_%deviceID%/tele/STATE:.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /gosund_%deviceID%/stat/RESULT:.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /gosund_%deviceID%/stat/POWER:.* state
attr archetype_tasmota_rgbw useSetExtensions 1
attr archetype_tasmota_rgbw webCmd RGBColor:Dimmer:White:RGBColor ffffff:RGBColor ff0000:RGBColor 00ff00:RGBColor 0000ff:ON:OFF
attr archetype_tasmota_rgbw widgetOverride Dimmer:colorpicker,BRI,0,1,80 White:colorpicker,BRI,0,1,80 RGBColor:colorpicker,RGB
attr archetype_tasmota_rgbw setStateList ON OFF
attr archetype_tasmota_rgbw userReadings RGBColor {\
  my $color = ReadingsVal($name,"Color","error");;;;\
  $color =~ /([0-9a-fA-F]{6})/;;;;\
  return($1||"error");;;;\
}
attr archetype_tasmota_rgbw stateFormat\
1:precence\
2:state
attr archetype_tasmota_rgbw actual_readingsWatcher 900,,state
#SELF
attr archetype_tasmota_rgbw room System
attr archetype_tasmota_rgbw attributes userattr readingsWatcher stateFormat IODev DbLogExclude DbLogInclude devStateIcon event-min-interval event-on-change-reading group icon jsonMap lightSceneParamsToSave retain setList readingList useSetExtensions webCmd widgetOverride setStateList userReadings
attr archetype_tasmota_rgbw attributesExclude attributes attributesExclude room
#attr archetype_tasmota_rgbw delteAttributes 0
#attr archetype_tasmota_rgbw defined_by archetype.archetype_tasmota_rgbw



Daraus entsteht dann normalerweise:

Code Auswählen Erweitern


define dev_tasmota_rgbww_1192 MQTT2_DEVICE
setuuid dev_tasmota_rgbww_1192 629beee5-f33f-1a24-74f1-ad4b7b3e42e427fe
attr dev_tasmota_rgbww_1192 userattr DbLogExclude DbLogInclude IODev actual_readingList actual_setList devStateIcon event-min-interval event-on-change-reading icon jsonMap lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 readingList readingsWatcher retain setList setStateList stateFormat useSetExtensions userReadings webCmd widgetOverride
attr dev_tasmota_rgbww_1192 DbLogInclude state
attr dev_tasmota_rgbww_1192 IODev mqtt2server
attr dev_tasmota_rgbww_1192 alias RGBW - Licht - Wohnzimmer - Fenster - rechts
attr dev_tasmota_rgbww_1192 archetypeFilter TASMOTA-RGBWW
attr dev_tasmota_rgbww_1192 devStateIcon {\
  if(ReadingsVal("$name","White","error") eq "0"){\
    sprintf('1.online:WLAN_Status.1@green 1.Online:WLAN_Status.1@green 1.offline:WLAN_Status.0@red 1.Offline:WLAN_Status.0@red' . "\n" . '2.' . "%s", Color::devStateIcon($name,"rgb","RGBColor","Dimmer","state"));;\
  }else{\
    sprintf('1.online:WLAN_Status.1@green 1.Online:WLAN_Status.1@green 1.offline:WLAN_Status.0@red 1.Offline:WLAN_Status.0@red' . "\n" . '2.' . "%s", Color::devStateIcon($name,"dimmer","","White","state"));;\
  }\
}
attr dev_tasmota_rgbww_1192 deviceID 1192
attr dev_tasmota_rgbww_1192 event-min-interval (ENERGY.*|POWER|Vcc|Wifi_RSSI|state|precence|sensor|setup|result):1800
attr dev_tasmota_rgbww_1192 event-on-change-reading (ENERGY.*|POWER|Vcc|Wifi_RSSI|state|precence|sensor|setup|result)
attr dev_tasmota_rgbww_1192 group RGB-Einzeln
attr dev_tasmota_rgbww_1192 icon light_led_stripe_rgb
attr dev_tasmota_rgbww_1192 jsonMap POWER:state
attr dev_tasmota_rgbww_1192 lightSceneParamsToSave {if(ReadingsVal($DEVICE,"state","error") eq "ON"){if(ReadingsVal($DEVICE, "White", "error") eq "0"){"RGBColor,Dimmer"}else{"White,CT"}}else{"state"}}
attr dev_tasmota_rgbww_1192 readingList /gosund_1192/tele/LWT:.* precence\
  /gosund_1192/tele/STATUS(2|5|11):.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /gosund_1192/tele/INFO(1|2|3):.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /gosund_1192/tele/STATE:.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /gosund_1192/stat/RESULT:.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /gosund_1192/stat/POWER:.* state
attr dev_tasmota_rgbww_1192 retain 1
attr dev_tasmota_rgbww_1192 room Wohnzimmer
attr dev_tasmota_rgbww_1192 setList OFF:noArg /gosund_1192/cmnd/POWER 0\
  TOGGLE:noArg /gosund_1192/cmnd/TOGGLE\
  ON:noArg /gosund_1192/cmnd/POWER 1\
  RGBColor:colorpicker,RGB /gosund_1192/cmnd/Color2\
  Dimmer:colorpicker,BRI,0,5,80 /gosund_1192/cmnd/Dimmer\
  White:colorpicker,BRI,0,5,80 /gosund_1192/cmnd/White\
  CT:colorpicker,CT /gosund_1192/cmnd/CT\
  Fade:0 /gosund_1192/cmnd/Fade 0\
  Fade:1 /gosund_1192/cmnd/Fade 1\
  Speed:1-10 /gosund_1192/cmnd/Speed
attr dev_tasmota_rgbww_1192 setStateList ON OFF
attr dev_tasmota_rgbww_1192 stateFormat 1:precence\
2:state
attr dev_tasmota_rgbww_1192 useSetExtensions 1
attr dev_tasmota_rgbww_1192 userReadings RGBColor {\
  my $color = ReadingsVal($name,"Color","error");;\
  $color =~ /([0-9a-fA-F]{6})/;;\
  return($1||"error");;\
}
attr dev_tasmota_rgbww_1192 webCmd RGBColor:Dimmer:White:CT:RGBColor ffffff:RGBColor ff0000:RGBColor 00ff00:RGBColor 0000ff:ON:OFF
attr dev_tasmota_rgbww_1192 widgetOverride Dimmer:colorpicker,BRI,0,1,100 White:colorpicker,BRI,0,1,100 RGBColor:colorpicker,RGB CT:colorpicker,CT,153,1,500


[Beta-User]

Moin, ich schau's mir im Lauf der kommenden Woche mal näher an, was da das Problem sein könnte.

[Beta-User]

Eine Frage: Wie "rollst" du das archetype aus? Falls du den "clean"-command (z.B. iVm. einem FHEM-start-Event-Handler) in Verwendung hast: bitte mal in "archetype clean" ändern.

[Florian_GT]

Eine Frage: Wie "rollst" du das archetype aus? Falls du den "clean"-command (z.B. iVm. einem FHEM-start-Event-Handler) in Verwendung hast: bitte mal in "archetype clean" ändern.

ich deploy meine FHEM Instanz mit Chef als Automatisierung, ähnliche Ansible und zukünftig wird es Docker. Das bedeutet, die Archetype wird bei Runtime ausgeführt. Deshalb habe ich bei den RGB Devices auch nur ein paar wenige Zeilen, die dann bei Fhem Start oder Restart ergänzt werden.

Ich habe jetzt gestern natürlich erst einmal ein Roleback gemacht, ich habe aber auch eine Test Instanz, dort werde ich dass dann mal in Ruhe testen...

Im Log beim starten sieht das übrigens so mit dem alten Module aus:

Code Auswählen Erweitern

2022.06.05 01:46:45.357 1: Including ./conf/sub_configuration/fhem.cfg-DEV-TASMOTA
2022.06.05 01:46:45.513 3: archetype (archetype_tasmota_rgbw) - starting inheritance inheritors
2022.06.05 01:46:45.530 3: archetype (archetype_tasmota_rgbw) - inheritance inheritors done
2022.06.05 01:46:45.538 3: archetype (archetype_tasmota_rgbww) - starting inheritance inheritors
2022.06.05 01:46:45.557 3: archetype (archetype_tasmota_rgbww) - inheritance inheritors done
2022.06.05 01:46:45.563 3: archetype (archetype_tasmota_power) - starting inheritance inheritors
2022.06.05 01:46:45.626 3: archetype (archetype_tasmota_power) - inheritance inheritors done
2022.06.05 01:46:45.631 3: archetype (archetype_tasmota_smokedetector) - starting inheritance inheritors
2022.06.05 01:46:45.637 3: archetype (archetype_tasmota_doorswitch) - starting inheritance inheritors
2022.06.05 01:46:45.655 3: archetype (archetype_tasmota_doorswitch) - inheritance inheritors done
2022.06.05 01:46:45.656 1: Including ./conf/sub_configuration/fhem.cfg-DEV-ESPEASY
2022.06.05 01:46:45.676 3: archetype (archetype_espeasy_bme280) - starting inheritance inheritors
2022.06.05 01:46:45.703 3: archetype (archetype_espeasy_bme280) - inheritance inheritors done
2022.06.05 01:46:45.704 1: Including ./conf/sub_configuration/fhem.cfg-LUEFTEN
2022.06.05 01:46:45.790 1: Including ./conf/sub_configuration/fhem.cfg-TELEGRAM


Ach und mir fällt gerade noch ein, ich habe einige Attribute in der Global definiert, wie z.B. DeviceID:

Code Auswählen Erweitern

attr global userattr archetypeFilter readingsWatcher actual_readingList actual_devicetopic actual_setList taupunktlimitdiff deviceID DbLogExclude DbLogInclude DbLogValueFn:textField-long alarmDevice:Actor,Sensor alarmSettings cmdIcon devStateIcon devStateIcon:textField-long devStateStyle icon lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 msgContactAudio msgContactLight msgContactMail msgContactPush msgContactScreen msgParams msgPriority msgRecipient msgRecipientAudio msgRecipientLight msgRecipientMail msgRecipientPush msgRecipientScreen msgRecipientText msgTitle msgTitleShrt msgType:text,push,mail,screen,light,audio,queue sortby structexclude webCmd webCmdLabel:textField-long widgetOverrid widgetOverride

[Beta-User]

Was steht denn in der

Code Auswählen Erweitern

2022.06.05 01:46:45.357 1: Including ./conf/sub_configuration/fhem.cfg-DEV-TASMOTA
usw.?
Falls da der "clear"-Befehl aufgerufen wird, muss das für die neue Syntax einfach angepaßt werden...

[Florian_GT]

Was steht denn in der

Code Auswählen Erweitern

2022.06.05 01:46:45.357 1: Including ./conf/sub_configuration/fhem.cfg-DEV-TASMOTA
usw.?
Falls da der "clear"-Befehl aufgerufen wird, muss das für die neue Syntax einfach angepaßt werden...

Dort steht kein clear Befehl drin, dort steht nur drin, was ich oben Beispielweise am RGBW auch schon gepostet habe.

[Beta-User]

OK, jetzt bin ich dahintergestiegen, was das Problem ist/war:

So, hier also mal eine erste Lautmeldung und gleich eine Ladung Fragezeichen...

[...]
Hintergrund dazu ist der, dass mir der Gedanke, dass ein "archetype clean" wirklich immer alles "aufräumt", ist mir noch unheimlich; bin am Überlegen, ob es ein Attribut geben sollte, mit dem man selektiv ausschalten kann, ohne ganz gleich "disable" zu verwenden.

Gab es einen Grund, warum beim Setzen der Attribute vor $init_done weiterer Code aufgerufen wurde?

Ich finde es weiterhin ausgesprochen "schräg", Attribute vor Abschluss der FHEM-Initialisierung irgendwas ausführen zu lassen. Das wird also nur dann wiederkommen, wenn es wirklich triftige Gründe dafür gäbe.

Bei der jetzigen Durchsicht sind mir dann aber auch noch ein paar weitere "Problemchen" mit dem (scheinbar von niemandem genutzten!) "clean"-Befehl aufgefallen, anbei daher eine aktualisierte Fassung, ich gedenke die zeitnah einzuchecken.

Mit der Version funktioniert zum einen dann "archetype clean" wieder, zum anderen gibt es ein neues Attribut "autoclean_init", mit dem man zum Abschluss der FHEM-Initialisierung (also bei "global:INITIALIZED") dann selektiv einzelne archetype "anschalten" kann.

@Florian_GT: Deine Problemlage sollte sich durch das pauschale "clean" im Rahmen eines "INITIALIZED"-Eventhandlers lösen lassen.

PS:
In deinem Beispiel sind ein paar Attribute dabei, die noch von MQTT_DEVICE herrühren, und das archetype-devspec paßt nicht 100% auf die beiden Muster-Devices.
Edit: ist im svn.

[Florian_GT]

OK, jetzt bin ich dahintergestiegen, was das Problem ist/war:Ich finde es weiterhin ausgesprochen "schräg", Attribute vor Abschluss der FHEM-Initialisierung irgendwas ausführen zu lassen. Das wird also nur dann wiederkommen, wenn es wirklich triftige Gründe dafür gäbe.

Bei der jetzigen Durchsicht sind mir dann aber auch noch ein paar weitere "Problemchen" mit dem (scheinbar von niemandem genutzten!) "clean"-Befehl aufgefallen, anbei daher eine aktualisierte Fassung, ich gedenke die zeitnah einzuchecken.

Mit der Version funktioniert zum einen dann "archetype clean" wieder, zum anderen gibt es ein neues Attribut "autoclean_init", mit dem man zum Abschluss der FHEM-Initialisierung (also bei "global:INITIALIZED") dann selektiv einzelne archetype "anschalten" kann.

@Florian_GT: Deine Problemlage sollte sich durch das pauschale "clean" im Rahmen eines "INITIALIZED"-Eventhandlers lösen lassen.

PS:
In deinem Beispiel sind ein paar Attribute dabei, die noch von MQTT_DEVICE herrühren, und das archetype-devspec paßt nicht 100% auf die beiden Muster-Devices.
Edit: ist im svn.

Also wann dann etwas ausgeführt wird oder nicht kann ich so nicht einschätzen, dafür bin ich nicht weit genug in FHEM drin. Fakt ist halt, wenn ich ein neues Device so wie oben angegeben konfiguriere, dann soll halt bei start oder neustart von FHEM automatisch alles weitere gesetzt werden. Wenn ich dafür noch ein weiteren Parameter an dem archetype setzen muss, auch ok, aber darüber hinaus sollte alles weitere in Hintergrund automatisch passieren. So war das von dem Module gedacht.

Und ja, sorry, du hast recht, ich habe dir da das falsche Template kopiert:

Code Auswählen Erweitern


###################
# EXAMPLE - RGBWW #
###################
define archetype_tasmota_rgbww archetype TYPE=MQTT2_DEVICE:FILTER=archetypeFilter=TASMOTA-RGBWW
attr archetype_tasmota_rgbww userattr userattr readingsWatcher stateFormat IODev DbLogExclude DbLogInclude devStateIcon event-min-interval event-on-change-reading group icon jsonMap lightSceneParamsToSave retain setList readingList useSetExtensions webCmd widgetOverride setStateList userReadings
attr archetype_tasmota_rgbww IODev mqtt2server
attr archetype_tasmota_rgbww devStateIcon {\
  if(ReadingsVal("$name","White","error") eq "0"){\
    sprintf('1.online:WLAN_Status.1@green 1.Online:WLAN_Status.1@green 1.offline:WLAN_Status.0@red 1.Offline:WLAN_Status.0@red' . "\n" . '2.' . "%s", Color::devStateIcon($name,"rgb","RGBColor","Dimmer","state"));;;;\
  }else{\
    sprintf('1.online:WLAN_Status.1@green 1.Online:WLAN_Status.1@green 1.offline:WLAN_Status.0@red 1.Offline:WLAN_Status.0@red' . "\n" . '2.' . "%s", Color::devStateIcon($name,"dimmer","","White","state"));;;;\
  }\
}
attr archetype_tasmota_rgbww event-min-interval (ENERGY.*|POWER|Vcc|Wifi_RSSI|state|precence|sensor|setup|result):1800
attr archetype_tasmota_rgbww event-on-change-reading (ENERGY.*|POWER|Vcc|Wifi_RSSI|state|precence|sensor|setup|result)
attr archetype_tasmota_rgbww DbLogInclude state
attr archetype_tasmota_rgbww group RGB-Einzeln
attr archetype_tasmota_rgbww icon light_led_stripe_rgb
attr archetype_tasmota_rgbww jsonMap POWER:state
attr archetype_tasmota_rgbww lightSceneParamsToSave {if(ReadingsVal($DEVICE,"state","error") eq "ON"){if(ReadingsVal($DEVICE, "White", "error") eq "0"){"RGBColor,Dimmer"}else{"White,CT"}}else{"state"}}
attr archetype_tasmota_rgbww retain 1
attr archetype_tasmota_rgbww actual_setList\
  OFF:noArg /gosund_%deviceID%/cmnd/POWER 0\
  TOGGLE:noArg /gosund_%deviceID%/cmnd/TOGGLE\
  ON:noArg /gosund_%deviceID%/cmnd/POWER 1\
  RGBColor:colorpicker,RGB /gosund_%deviceID%/cmnd/Color2\
  Dimmer:colorpicker,BRI,0,5,80 /gosund_%deviceID%/cmnd/Dimmer\
  White:colorpicker,BRI,0,5,80 /gosund_%deviceID%/cmnd/White\
  CT:colorpicker,CT /gosund_%deviceID%/cmnd/CT\
  Fade:0 /gosund_%deviceID%/cmnd/Fade 0\
  Fade:1 /gosund_%deviceID%/cmnd/Fade 1\
  Speed:1-10 /gosund_%deviceID%/cmnd/Speed
attr archetype_tasmota_rgbww actual_readingList \
  /gosund_%deviceID%/tele/LWT:.* precence\
  /gosund_%deviceID%/tele/STATUS(2|5|11):.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /gosund_%deviceID%/tele/INFO(1|2|3):.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /gosund_%deviceID%/tele/STATE:.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /gosund_%deviceID%/stat/RESULT:.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /gosund_%deviceID%/stat/POWER:.* state
attr archetype_tasmota_rgbww useSetExtensions 1
attr archetype_tasmota_rgbww webCmd RGBColor:Dimmer:White:CT:RGBColor ffffff:RGBColor ff0000:RGBColor 00ff00:RGBColor 0000ff:ON:OFF
attr archetype_tasmota_rgbww widgetOverride Dimmer:colorpicker,BRI,0,1,100 White:colorpicker,BRI,0,1,100 RGBColor:colorpicker,RGB CT:colorpicker,CT,153,1,500
attr archetype_tasmota_rgbww setStateList ON OFF
attr archetype_tasmota_rgbww userReadings RGBColor {\
  my $color = ReadingsVal($name,"Color","error");;;;\
  $color =~ /([0-9a-fA-F]{6})/;;;;\
  return($1||"error");;;;\
}
attr archetype_tasmota_rgbww stateFormat\
1:precence\
2:state
attr archetype_tasmota_power actual_readingsWatcher 900,,state
#SELF
attr archetype_tasmota_rgbww room System
attr archetype_tasmota_rgbww attributes userattr readingsWatcher stateFormat IODev DbLogExclude DbLogInclude devStateIcon event-min-interval event-on-change-reading group icon jsonMap lightSceneParamsToSave retain setList readingList useSetExtensions webCmd widgetOverride setStateList userReadings
attr archetype_tasmota_rgbww attributesExclude attributes attributesExclude room
attr archetype_tasmota_rgbww autoclean_init 1
#attr archetype_tasmota_rgbww delteAttributes 0
#attr archetype_tasmota_rgbww defined_by archetype.archetype_tasmota_rgbww


Was genau muss ich jetzt anpassen damit es wieder wie vorher funktioniert? Muss ich dass autoclean_init im archetype setzen? EDIT: Schon gelesen in der Doku dass es damit dann geht, sehr schön!

EDIT:
Fix einmal getestet und tut auch wieder wie vorher:

Code Auswählen Erweitern

2022.06.09 00:50:21.783 3: archetype (archetype_tasmota_doorswitch) - starting inheritance (initial autoclean )
2022.06.09 00:50:21.826 3: archetype (archetype_tasmota_doorswitch) - inheritance inheritors done
2022.06.09 00:50:21.826 3: archetype (archetype_tasmota_power) - starting inheritance (initial autoclean )
2022.06.09 00:50:21.979 3: archetype (archetype_tasmota_power) - inheritance inheritors done
2022.06.09 00:50:21.979 3: archetype (archetype_tasmota_rgbw) - starting inheritance (initial autoclean )
2022.06.09 00:50:22.017 3: archetype (archetype_tasmota_rgbw) - inheritance inheritors done
2022.06.09 00:50:22.018 3: archetype (archetype_tasmota_rgbww) - starting inheritance (initial autoclean )
2022.06.09 00:50:22.074 3: archetype (archetype_tasmota_rgbww) - inheritance inheritors done
2022.06.09 00:50:22.075 3: archetype (archetype_tasmota_smokedetector) - starting inheritance (initial autoclean )
2022.06.09 00:50:22.077 3: archetype (archetype_zigbee_heating) - starting inheritance (initial autoclean )
2022.06.09 00:50:22.148 3: archetype (archetype_zigbee_heating) - inheritance inheritors done


Danke

[Beta-User]

Was genau muss ich jetzt anpassen damit es wieder wie vorher funktioniert? Muss ich dass autoclean_init im archetype setzen? EDIT: Schon gelesen in der Doku dass es damit dann geht, sehr schön!

Na ja, meine Anregung war eigentlich gewesen, das "pauschal" via global-INITIALIZED-Eventhandler zu machen:

Code Auswählen Erweitern

defmod initialArchetypeClean notify global:INITIALIZED|global:REREADCFG archetype clean

Die andere Variante wäre, das "archetype clean" ans Ende der fhem.cfg zu schreiben (@all: Cool bleiben, s.u.).

Aber natürlich geht es auch, das über die Aktivierung des Attributs im Einzeldevice zu machen. Es gibt aber dennoch ein paar Unterschiede zum vorherigen Verhalten, die ich an der Stelle gerne nochmal erläutere. Dann wird ggf. auch klarer, warum das bisherige Verhalten m.E. zwingend geändert werden musste...

Der eigentliche (früher auch vor $init_done angewendete) trigger, damit das archetype seine Arbeit tut, war/ist das "attributes"-Attribut. Das findet sich bei deinen Definitionen nicht zufällig ziemlich am Ende der Definition (das darauf folgende dürfte übrigens wirkungslos sein!). Das ist aber nicht der Ort, an dem fhem.pl das "freiwillig" abspeichern würde ("list -r archetype_tasmota_rgbw" würde zeigen, wie das "manipulationsfrei" aussähe).
Ergo funktioniert deine ganze Konstruktion nur
- wenn die Reihenfolge der define-Anweisungen "korrekt" ist (erst alle zu ändernden Devices, dann das archetype), und
- die Reihenfolge der Attribute in der cfg bei diesem archetype ebenfalls paßt.
Sowas bekommen nur 100%-cfg-Editierer hin (und selbst die müssen aufpassen, dass das "vercodete Wissen" zu dem Zeitpnkt präsent ist, zu dem sie die nächste Änderung machen, ein "save" ist jedenfalls "nogo-Zone"...)

Jetzt ist es so, dass archetype (unabhängig davon, ob es via Einzel-Attribut oder INITIALIZED-notify erfolgt) erst aktiv ist, wenn $init_done wahr (bzw. korrekt: 1) ist, also:
- die ganze fhem.cfg gelesen ist (alle defines + Attribute sind bekannt), und
- die statefile ist gelesen (alle alten Reading-Werte sind bekannt).

Es gibt dabei aber einen Haken: ab $init_done sind auch alle Dispatch-Funktionen usw. bereits aktiv, es werden also z.B. alle eingehenden MQTT-Nachrichten verteilt. Es könnte also passieren, dass eine eingehende Nachricht auf ein noch nicht "fertig konfiguriertes" Device trifft und dann "falsch" interpretiert wird (also ggf. einfach anders als mit der angepaßten readingList).

Will man das als "echter cfg-Editierer" vermeiden, kann man den "archetype clean"-Befehl eben ans Ende der cfg setzen. Dann wird der "zum richtigen Zeitpunkt" ausgeführt, also _vor $init_done_. Aus dem vorstehenden ergibt sich: sowas macht m.E. nur für "100%-cfg-Editierer" Sinn, der Rest sollte bitte einfach die "notwendigen" Attribute (also in meinem Beispiel v.a. die readingList) so in der cfg anspeichern, dass das paßt und "archetype" dann dazu nutzen, abweichende Konfigurationen "einzufangen" und/oder direkt bei Neudefinition eines Devices "passende" Attribute zu setzen.

Hoffe, das ist jetzt etwas klarer?

[Florian_GT]

Na ja, meine Anregung war eigentlich gewesen, das "pauschal" via global-INITIALIZED-Eventhandler zu machen:

Code Auswählen Erweitern

defmod initialArchetypeClean notify global:INITIALIZED|global:REREADCFG archetype clean

Die andere Variante wäre, das "archetype clean" ans Ende der fhem.cfg zu schreiben (@all: Cool bleiben, s.u.).

Aber natürlich geht es auch, das über die Aktivierung des Attributs im Einzeldevice zu machen. Es gibt aber dennoch ein paar Unterschiede zum vorherigen Verhalten, die ich an der Stelle gerne nochmal erläutere. Dann wird ggf. auch klarer, warum das bisherige Verhalten m.E. zwingend geändert werden musste...

Der eigentliche (früher auch vor $init_done angewendete) trigger, damit das archetype seine Arbeit tut, war/ist das "attributes"-Attribut. Das findet sich bei deinen Definitionen nicht zufällig ziemlich am Ende der Definition (das darauf folgende dürfte übrigens wirkungslos sein!). Das ist aber nicht der Ort, an dem fhem.pl das "freiwillig" abspeichern würde ("list -r archetype_tasmota_rgbw" würde zeigen, wie das "manipulationsfrei" aussähe).
Ergo funktioniert deine ganze Konstruktion nur
- wenn die Reihenfolge der define-Anweisungen "korrekt" ist (erst alle zu ändernden Devices, dann das archetype), und
- die Reihenfolge der Attribute in der cfg bei diesem archetype ebenfalls paßt.
Sowas bekommen nur 100%-cfg-Editierer hin (und selbst die müssen aufpassen, dass das "vercodete Wissen" zu dem Zeitpnkt präsent ist, zu dem sie die nächste Änderung machen, ein "save" ist jedenfalls "nogo-Zone"...)

Jetzt ist es so, dass archetype (unabhängig davon, ob es via Einzel-Attribut oder INITIALIZED-notify erfolgt) erst aktiv ist, wenn $init_done wahr (bzw. korrekt: 1) ist, also:
- die ganze fhem.cfg gelesen ist (alle defines + Attribute sind bekannt), und
- die statefile ist gelesen (alle alten Reading-Werte sind bekannt).

Es gibt dabei aber einen Haken: ab $init_done sind auch alle Dispatch-Funktionen usw. bereits aktiv, es werden also z.B. alle eingehenden MQTT-Nachrichten verteilt. Es könnte also passieren, dass eine eingehende Nachricht auf ein noch nicht "fertig konfiguriertes" Device trifft und dann "falsch" interpretiert wird (also ggf. einfach anders als mit der angepaßten readingList).

Will man das als "echter cfg-Editierer" vermeiden, kann man den "archetype clean"-Befehl eben ans Ende der cfg setzen. Dann wird der "zum richtigen Zeitpunkt" ausgeführt, also _vor $init_done_. Aus dem vorstehenden ergibt sich: sowas macht m.E. nur für "100%-cfg-Editierer" Sinn, der Rest sollte bitte einfach die "notwendigen" Attribute (also in meinem Beispiel v.a. die readingList) so in der cfg anspeichern, dass das paßt und "archetype" dann dazu nutzen, abweichende Konfigurationen "einzufangen" und/oder direkt bei Neudefinition eines Devices "passende" Attribute zu setzen.

Hoffe, das ist jetzt etwas klarer?

Ja jetzt verstehe ich was du meinst. Ein paar Hinweise zum Module und dann sollte das so passen.

[Beta-User]

Ein paar Hinweise zum Module und dann sollte das so passen.

Weiß nicht so recht, was du mir damit sagen willst? Welche Hinweise?

M.E. war das bisherige Verhalten einfach "weird", und bisher bist du der erste, der sich überhaupt dazu gemeldet hat (meine Frage, ob das irgendeinen tieferen Sinn hat, hängt ja schon lange im Raum...).

Da cfg-Editieren eh in die Kategorie "not recommended" (für nicht-Spezialisten) gehört, werde ich nicht hergehen und noch irgendwo sonst erklären, wie man das ggf. hinbiegt...
(mit configDB geht es eh' nicht, Befehle direkt in die cfg zu schreiben, und auch die Reihenfolge der "normalen" Attribute kann man afaik nicht wirklich beeinflussen).

[Florian_GT]

Weiß nicht so recht, was du mir damit sagen willst? Welche Hinweise?

M.E. war das bisherige Verhalten einfach "weird", und bisher bist du der erste, der sich überhaupt dazu gemeldet hat (meine Frage, ob das irgendeinen tieferen Sinn hat, hängt ja schon lange im Raum...).

Da cfg-Editieren eh in die Kategorie "not recommended" (für nicht-Spezialisten) gehört, werde ich nicht hergehen und noch irgendwo sonst erklären, wie man das ggf. hinbiegt...
(mit configDB geht es eh' nicht, Befehle direkt in die cfg zu schreiben, und auch die Reihenfolge der "normalen" Attribute kann man afaik nicht wirklich beeinflussen).

Hm, jetzt weiß ich leider auch nicht mehr, welche Hinweise ich meinte. Möglicherweise deine Erklärung weiter oben im cmdref. Ja, mag wenige geben die dieses Module in Verbindung mit manuellen Editieren an den cfg. nutzen. Ich für meinen Teil mache das aber gerne in vsc. Und habe auch gleich eine Versionierung in Git. Und durch das Module auch weniger Attribute. Die ganzen anderen Attribute werden automatisch vergeben und anders ist es auch nicht notwendig. Zumindest aus meiner Sicht.

Gruß Florian