Rückmeldung zu V1.9

[aschwith]

Estmal vielen Dank für den Einsatz der Treiber und Ersteller des neuen V1.9 Releases!

Eine Frage zu diesem Logeintrag:

2021-12-28  22:05:14 NOTICE   lib.smarthome        - Loglevel NOTICE is set to value 31 because handler of root logger is set to level WARNING or higher  -  Set level of handler 'shng_warnings_file' to 'NOTICE'!

Was mich hier irritiert ist, dass die logging.yaml.default aus dem V1.9 Release hier auch den Handler 'shng_warnings_file' nicht auf 'NOTICE' gesetzt hat. Könnt Ihr das auflösen?

Danke und Gruß
Alex

[Msinn]

Die logging.yaml.default hat es aus irgendeinem Grund nicht auf github geschafft. I develop branch ist jetzt die aktualisierte Version.

Der Level NOTICE sollte an 3 Stellen verwendet werden:

• im handler shng_warnings_file
• im loger lib
• im logger lib.smarthome

handlers:

    shng_warnings_file:
        # This handler writes only entries with level NOTICE/WARNING and above
        # to the file. This allows for a quick check if all is running smooth.
        #
        # To keep the warnings file easy readable, the level should always be NOTICE!
        #
        # The TimedRotatingFileHandler seperates the logentries by day and
        # keeps the entries of the last seven days in seperate files.
        #
        #class: logging.handlers.TimedRotatingFileHandler
        (): lib.log.ShngTimedRotatingFileHandler
        formatter: shng_simple
        level: NOTICE
        utc: false
        when: midnight
        backupCount: 7
        filename: ./var/log/smarthome-warnings.log
        encoding: utf8

    ...

loggers:
    # The following default loggers should not be changed. If additional logging
    # is required, a logger for the specific lib, module or plugin shoud be added.
    #
    functions:
        handlers: [shng_details_file]
        level: INFO

    lib:
        # Default logger for SmartHomeNG libraries
        handlers: [shng_details_file]
        level: NOTICE

    lib.smarthome:
        # Add all logging handlers that should receive the initial log lines after a startup
        # (example below) but leave out the logging handlers that are defined in the root-logger
        # (otherwise log entries will be doubled).
        #
        # 2020-12-29  11:35:34 NOTICE  lib.smarthome   --------------------   Init SmartHomeNG 1.8.0   --------------------
        # 2020-12-29  11:35:34 NOTICE  lib.smarthome   Running in Python interpreter 'v3.8.3 final' in virtual environment
        # 2020-12-29  11:35:34 NOTICE  lib.smarthome    - on Linux-4.9.0-6-amd64-x86_64-with-glibc2.17 (pid=24407)
        # 2020-12-29  11:35:35 NOTICE  lib.smarthome    - Nutze Feiertage für Land 'DE', Provinz 'HH', 1 benutzerdefinierte(r) Feiertag(e) definiert
        # 2020-12-29  11:36:54 NOTICE  lib.smarthome   --------------------   SmartHomeNG initialization finished   --------------------
        #
        # logging to shng_details_file is already enabled in logger lib:
        #handlers: [shng_develop_file]

        # set to WARNING LEVEL to prevent unwanted log entries and add ONLY start and stop log-messages to further logfiles
        level: NOTICE

    ...

[aschwith]

Danke Dir. So passt es.

Ein anderes Thema: Ich nutze Smartvisu seitig das basic.trigger widget, mit dem auf Smarthome Seite direkt Logiken getriggert werden können. Das funktioniert seit je her sehr gut. Der Websocket meldet das nur jedes Mal als Warning:

2021-12-29 11:28:35 WARNING modules.websocket ws <CMD not yet tested: '{'cmd': 'logic', 'name': 'speak_logic', 'val': ''}' - from 192.X.X.X:52320

Frage, wollen wir das Warning rausnehmen? Getestet ist es bei mir

[Msinn]

Ok, danke
Da siehst Du wie selten das verwendet wird. Du bist der erste der daszu Rückmeldung gibt und die Warnung existiert seit der Version v1.8 😏

[aschwith]

Ok, alles klar. Noch eine letzte Sache, die auch schon seit 1.8.2 bei mir beim Start auftaucht. Es geht um ein item Attribut, welches von keinem Plugin definiert wird (nutze ich nur in einer Logik):

2021-12-29 11:01:10 WARNING lib.metadata Item 'my_radio1', attribute 'my_sonos_section': Attribute is undefined and has value 'Sonos.Kitchen' (defined in myradio.yaml)

Ich dachte immer, wenn das Atrribute mit my_* beginnt, würde es hier keine Warnung geben. Funktioniert das bei Euch?

VG
Alex

[Msinn]

Bei mir funktioniert das mit dem my_ . Ich hatte das vor einigen Tagen wegen eines Posts zu dem Thema noch mal ausprobiert.

[Msinn]

Ich habe gefunden, wiso my_ bei mir funktioniert. Ich habe das in einem privaten Plugin definiert. In den Metadaten (plugin.yaml) habe ich folgenden Abschnitt definiert:

item_attribute_prefixes:
    # Definition of item attributes that only have a common prefix (enter 'item_attribute_prefixes: NONE' or ommit this section, if section should be empty)
    # NOTE: This section should only be used, if really nessesary (e.g. for the stateengine plugin)
    my_:
        type: foo
        description:
            de: 'Attribute für verschiedene Tests'
            en: 'Attributes for various tests'

Für das nächste Release muss ich das mal richtig implementieren, damit man einzelne persönliche Attirbute definieren kann (auch mit Datentyp, etc. damit später ein Item Editor in der Admin GUI auch dmit umgehen kann).

[Morg]

Ich habe noch einen Fehler in der lib.network gefunden, der auftritt, wenn der UDP-Server genutzt wird (z.B. network-Plugin mit nw_udp_listen: ...).

Fix ist in develop.

[schuma]

Hallo, ich kann das Webif des Telegramm Plugins nicht mehr aufrufen (Error500).
Weis aber auch nicht ob das nicht vor dem Update schon so war.

Grüße, Marc

[64er]

Hi Leute,
wenn ich auf der Webseite:
https://www.smarthomeng.de/smarthome...-release-notes
auf den Link "Post im Forum" klicke, lande ich immer wieder beim Thread vom Release 1.8.

[Onkelandy]

schuma
Da wurde offenbar das falsche Template für telegram webif herangezogen. Ich habe einen Fix erstellt, ist im Develop und somit im nächsten Minor Release.
https://github.com/smarthomeNG/plugins/pull/554

[aschwith]

Hallo Msinn ,

ich habe gesehen, dass Du für das Release 1.9.1 die Unterstützung für user defined attributes hinzugefügt hast. Bei mir werden die User defined Attributes (UDA) weiterhin von der lib.metadata bewarnt, z.B. so:

2022-02-13 20:49:02 WARNING lib.metadata Item 'Enocean.handle_bath.status', attribute 'my_hkr_item': Attribute is undefined and has value 'avm.dect.hkr_bad' (defined in enocean.yaml)

Das relevante Item mit UDA sieht folgendermaßen aus:

status:
    type: num
    enocean_rx_key: STATUS
    visu_acl: ro
    cache: True
    enforce_updates: True
    my_hkr_item: 'avm.dect.hkr_bad'

Doku zu UDA habe ich nicht gefunden. Kannst Du hier weiterhelfen?

[Msinn]

Das kann ich im Moment nicht nachvollziehen.
Ich habe zwei Test Items angelegt, eines mit das_attr und eines mit my_attr. Bei mir wird nur das_attr angemeckert.

[aschwith]

Msinn : Ich habe die Vermutung, dass Du in mindestens einem plugin eine ITEMATTRIBUTEPREFIX_SECTION nutzt und es deshalb bei Dir funktioniert.

Ich habe mir Deinen Code genauer angeschaut. Bei mir fügt er das "my_" gar nicht hinzu, da self.itemprefixdefinitions immer None ist. Ich habe anscheinend in keinem genutzten Plugin eine ITEMATTRIBUTEPREFIX_SECTION.

[Msinn]

Ich habe die Vermutung, dass Du in mindestens einem plugin eine ITEMATTRIBUTEPREFIX_SECTION nutzt und es deshalb bei Dir funktioniert

Das hatte ich früher, aber das habe ich für die Tests zum 1.9.1 Release entfernt.

da self.itemprefixdefinitions immer None ist. Ich habe anscheinend in keinem genutzten Plugin eine ITEMATTRIBUTEPREFIX_SECTION.

Da kommen wir der Sache vermutlich näher. Ich habe zumindest das stateengine Plugin im Einsatz, welches eine ITEMATTRIBUTEPREFIX_SECTION besitzt.